From tim at klingt.org Tue Mar 1 07:15:30 2016 From: tim at klingt.org (Tim Blechmann) Date: Tue, 1 Mar 2016 14:15:30 +0800 Subject: [Development] ci timeouts Message-ID: hi all, it seems that i cannot integrate changes into 5.6 anymore: > http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1456811813.thrift_bin seems that i'm always hitting a timeout somewhere ... is this a known issue? i was hoping that the following changes could make it into 5.6: https://codereview.qt-project.org/#/c/149223/ https://codereview.qt-project.org/#/c/150084/ https://codereview.qt-project.org/#/c/150645/ all of them are bug fixes ... thnx, tim From Kai.Koehne at theqtcompany.com Tue Mar 1 08:37:02 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Tue, 1 Mar 2016 07:37:02 +0000 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <56D4B48E.4040009@michaelmoellney.de> References: <56D480F3.2050307@michaelmoellney.de> <201602292247.02877.marc.mutz@kdab.com> <56D4B48E.4040009@michaelmoellney.de> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Michael Mollney > Sent: Monday, February 29, 2016 10:14 PM > To: development at qt-project.org > Subject: Re: [Development] Q_COMPILER_RANGE_FOR not supported > by/defined for VS2012 and VS2013 ? > [...] > Maybe someone could teach the "Qt Sanity Bot" to detect that pattern, so > (gcc) developers that are VS agnostic > (or simply do not have that MS platform in access) could still support in > patching Qt. Well, we have also experienced reviewers + a CI system that will catch simple compiler errors. So don't be shy to submit stuff even if you yourself can't test compilation on every platform ... In fact I'd be happy if all submitters would do a test compile on at least _one_ platform ;) Regards Kai From jani.heikkinen at theqtcompany.com Tue Mar 1 08:38:14 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 1 Mar 2016 07:38:14 +0000 Subject: [Development] Dropping VS 2012 in Qt 5.7 In-Reply-To: <6940019.VT1iTT2XCW@tjmaciei-mobl4> References: <8947616.A7UhMYDDIY@tjmaciei-mobl4> <9463E139-8671-4FBD-9C28-CC9C9ADE7275@theqtcompany.com> <6940019.VT1iTT2XCW@tjmaciei-mobl4> Message-ID: Done, please review Br, Jani >>-----Original Message----- >>From: Development [mailto:development- >>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>Thiago Macieira >>Sent: 29. helmikuuta 2016 18:41 >>To: development at qt-project.org >>Subject: Re: [Development] Dropping VS 2012 in Qt 5.7 >> >>On segunda-feira, 29 de fevereiro de 2016 13:08:18 PST Heikkinen Jani wrote: >>> Hi! >>> >>> It seems we need a decision for this now to be able to proceed with >>> https://codereview.qt-project.org/#/c/149325/ >> >>Hi Jani >> >>We have so far not got any objections. Assume it's going to be the case and >>add it to the changelog. >> >>-- >>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 alexander.blasche at theqtcompany.com Tue Mar 1 09:16:55 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Tue, 1 Mar 2016 08:16:55 +0000 Subject: [Development] Approver status for Michal Klocek In-Reply-To: References: Message-ID: Approver rights have been granted. Congratulations to Michal. -- Alex ________________________________________ From: Blasche Alexander Sent: Monday, February 8, 2016 15:18 To: development at qt-project.org Subject: Approver status for Michal Klocek Hello, I would like to nominate Michal Klocek for Approver status in the Qt Project. Throughout the last year he has been working on QtLocation and QtWebEngine: https://codereview.qt-project.org/#/q/owner:michal.klocek,n,z -- Alex From mike.klocek at gmail.com Tue Mar 1 11:00:58 2016 From: mike.klocek at gmail.com (Michal Klocek) Date: Tue, 1 Mar 2016 11:00:58 +0100 Subject: [Development] Approver status for Michal Klocek In-Reply-To: References: Message-ID: Hi, Thanks a lot ! Michal On 1 March 2016 at 09:16, Blasche Alexander wrote: > Approver rights have been granted. Congratulations to Michal. > > -- > > Alex > > ________________________________________ > From: Blasche Alexander > Sent: Monday, February 8, 2016 15:18 > To: development at qt-project.org > Subject: Approver status for Michal Klocek > > Hello, > > I would like to nominate Michal Klocek for Approver status in the Qt Project. Throughout the last year he has been working on QtLocation and QtWebEngine: > > https://codereview.qt-project.org/#/q/owner:michal.klocek,n,z > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From notmart at gmail.com Tue Mar 1 13:54:44 2016 From: notmart at gmail.com (Marco Martin) Date: Tue, 1 Mar 2016 13:54:44 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <56CDBD3A.5060405@canonical.com> References: <56CDBD3A.5060405@canonical.com> Message-ID: <201603011354.44652.notmart@gmail.com> On Wednesday 24 February 2016 14:24:58 Gerry Boland wrote: > Hey Simon, > I can try offering the Ubuntu Touch perspective on units with QML (sorry > if late, was busy for MWC). > > We created a units system for our QML apps, called grid unit: units.gu(x). Just to keep the picture complete to see the various approaches taken around here, in Plasma, we taken a similar approach, with an "units" singleton that defines a gridUnit value that is determined from the font size (M size actually, again to make it similar to CSS). It works surprisingly well (basically the text is the center in the Plasma GUI and all the rest is sized/laid out around it) As Gerry mentioned, we also had some problems to make it work nicely with DevicePixelRatio even tough that's kinda solved nowdays, but the main problem is that being a singleton it poses problems for multimonitor when different screens have a different desity. And yeah, I would be very happy to see this kind of stuff directly managed by lower level QtQuick. -- Marco Martin From gunnar.roth at gmx.de Tue Mar 1 14:50:57 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 1 Mar 2016 14:50:57 +0100 Subject: [Development] Dropping VS 2012 in Qt 5.7 In-Reply-To: References: <8947616.A7UhMYDDIY@tjmaciei-mobl4> <9463E139-8671-4FBD-9C28-CC9C9ADE7275@theqtcompany.com> <6940019.VT1iTT2XCW@tjmaciei-mobl4>, Message-ID: Well so be it, goodbye Qt from wec2013 Users. But who takes care that changes for wec2013 in 5.7 and dev are merged back to 5.6.x?   I know at least of configure: Fix (Open)SSL detection on WinCE (Merged)[https://codereview.qt-project.org/122437]     https://codereview.qt-project.org/#/c/122437/   Fixing the SQLite3 build for WEC2013 again. https://codereview.qt-project.org/#/c/115571/5     furthermore wec2013 x86 needs at least 2 patches to build. 1. a problem with the fake OleInitialize and OleUninitialize in qtbase\src\plugins\platforms\windows\qplatformfunctions_wince.h, probably due to calling convention. 2. bitscan intrinsic --- a\qtbase\src\corelib\tools\qsimd_p.h +++ b\qtbase\src\corelib\tools\qsimd_p.h @@ -430,11 +430,17 @@ #define qCpuHasFeature(feature) ((qCompilerCpuFeatures & (Q_UINT64_C(1) << CpuFeature ## feature)) \ || (qCpuFeatures() & (Q_UINT64_C(1) << CpuFeature ## feature))) #ifdef Q_PROCESSOR_X86 // Bit scan functions for x86 -# if defined(Q_CC_MSVC) && !defined(Q_OS_WINCE) +# if defined(Q_CC_MSVC) +#if defined _WIN32_WCE && _WIN32_WCE < 0x800 +extern "C" unsigned char _BitScanForward(unsigned long* Index, unsigned long Mask); +extern "C" unsigned char _BitScanReverse(unsigned long* Index, unsigned long Mask); +#pragma intrinsic(_BitScanForward) +#pragma intrinsic(_BitScanReverse) +#endif // MSVC calls it _BitScanReverse and returns the carry flag, which we don't need static __forceinline unsigned long _bit_scan_reverse(uint val) { unsigned long result; _BitScanReverse(&result, val); and all programs using native file dialogs simply crash, qmlscene.exe for example. --- a\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp +++ b\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp @@ -173,6 +173,10 @@ static inline unsigned parseOptions(const QStringList ¶mList, int *tabletAbsoluteRange, QtWindows::ProcessDpiAwareness *dpiAwareness) { +#if defined _WIN32_WCE && _WIN32_WCE >= 0x800 + unsigned options = QWindowsIntegration::NoNativeDialogs; +#else unsigned options = 0; +#endif a problem with spdy protocol occurs for me: diff -r -U 5 -N -x '*.orig' -x '*.rej' -x '*.bak' -x .git -x doc -x tests -x examples a\qtbase\src\network\access/qspdyprotocolhandler.cpp b\qtbase\src\network\access/qspdyprotocolhandler.cpp --- a\qtbase\src\network\access/qspdyprotocolhandler.cpp +++ b\qtbase\src\network\access/qspdyprotocolhandler.cpp @@ -31,5 +31,6 @@ ** $QT_END_LICENSE$ ** ****************************************************************************/ #include +#undef ZLIB_H // this makes qfunctions_wince.h line 201 stuff not break the build for wince and a fix to allow to use sse2 ( and opensll): --- a\qtbase\tools\configure\configureapp.cpp +++ b\qtbase\tools\configure\configureapp.cpp @@ -1698,20 +1698,10 @@ dictionary[ "STYLE_WINDOWSVISTA" ] = "no"; dictionary[ "STYLE_FUSION" ] = "no"; dictionary[ "STYLE_WINDOWSCE" ] = "yes"; dictionary[ "STYLE_WINDOWSMOBILE" ] = "yes"; dictionary[ "OPENGL" ] = "no"; - dictionary[ "SSL" ] = "no"; - dictionary[ "OPENSSL" ] = "no"; - dictionary[ "RTTI" ] = "no"; - dictionary[ "SSE2" ] = "no"; - dictionary[ "SSE3" ] = "no"; - dictionary[ "SSSE3" ] = "no"; - dictionary[ "SSE4_1" ] = "no"; - dictionary[ "SSE4_2" ] = "no"; - dictionary[ "AVX" ] = "no"; - dictionary[ "AVX2" ] = "no"; dictionary[ "CE_CRT" ] = "yes"; dictionary[ "LARGE_FILE" ] = "no"; dictionary[ "ANGLE" ] = "no"; dictionary[ "DYNAMICGL" ] = "no"; if (dictionary[ "XQMAKESPEC" ].startsWith("wincewm")) { Regards, Gunnar Roth Gesendet: Dienstag, 01. März 2016 um 08:38 Uhr Von: "Heikkinen Jani" An: "Thiago Macieira" , "development at qt-project.org" Betreff: Re: [Development] Dropping VS 2012 in Qt 5.7 Done, please review Br, Jani >>-----Original Message----- >>From: Development [mailto:development- >>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>Thiago Macieira >>Sent: 29. helmikuuta 2016 18:41 >>To: development at qt-project.org >>Subject: Re: [Development] Dropping VS 2012 in Qt 5.7 >> >>On segunda-feira, 29 de fevereiro de 2016 13:08:18 PST Heikkinen Jani wrote: >>> Hi! >>> >>> It seems we need a decision for this now to be able to proceed with >>> https://codereview.qt-project.org/#/c/149325/[https://codereview.qt-project.org/#/c/149325/] >> >>Hi Jani >> >>We have so far not got any objections. Assume it's going to be the case and >>add it to the changelog. >> >>-- >>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[http://lists.qt-project.org/mailman/listinfo/development] _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development] From thiago.macieira at intel.com Tue Mar 1 16:23:19 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 01 Mar 2016 07:23:19 -0800 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: References: <56D480F3.2050307@michaelmoellney.de> <56D4B48E.4040009@michaelmoellney.de> Message-ID: <4485464.U5eS8SqyHQ@tjmaciei-mobl4> On terça-feira, 1 de março de 2016 07:37:02 PST Koehne Kai wrote: > Well, we have also experienced reviewers + a CI system that will catch > simple compiler errors. So don't be shy to submit stuff even if you > yourself can't test compilation on every platform ... In fact I'd be happy > if all submitters would do a test compile on at least _one_ platform ;) There's a difference between getting tripped by some corner case you didn't know about and being told that there's something you should be aware of. If you ignore advice, get the brown paper bag to put over your head. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 1 16:25:21 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 01 Mar 2016 07:25:21 -0800 Subject: [Development] Dropping VS 2012 in Qt 5.7 In-Reply-To: References: <8947616.A7UhMYDDIY@tjmaciei-mobl4> Message-ID: <1842313.ZkoUdHNy0H@tjmaciei-mobl4> On terça-feira, 1 de março de 2016 14:50:57 PST Gunnar Roth wrote: > Well so be it, goodbye Qt from wec2013 Users. > But who takes care that changes for wec2013 in 5.7 and dev are merged back > to 5.6.x? Hi Gunnar Thanks for pointing those changes out. The WEC 2013 platform maintainers will go over your list and backport those fixes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ahartmetz at gmail.com Tue Mar 1 17:12:46 2016 From: ahartmetz at gmail.com (Andreas Hartmetz) Date: Tue, 01 Mar 2016 17:12:46 +0100 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <20160218132045.GC28638@troll08.it.local> References: <20160218132045.GC28638@troll08.it.local> Message-ID: <2012052.SHaLYvPTNu@z25> On Donnerstag, 18. Februar 2016 14:20:45 CET Oswald Buddenhagen wrote: > On Thu, Feb 18, 2016 at 10:50:22AM +0000, Hausmann Simon wrote: > > What do you think? > > that it's a bit silly that we're having this discussion *yet again*. > ;) http://thread.gmane.org/gmane.comp.lib.qt.devel/6572/focus=6807 > > i find the point about using arcminutes as a truly device independent > unit particularly relevant. i thought we discussed this topic > somewhere in more depth already, but i failed to find anything > relevant. Arcminutes are a really good idea. The size of screen elements isn't really about physical dimensions, it's about size on retina (the actual biological thing ;) really, or legibility. Recently I set up a PC with a large screen for entertainment purposes. Physical DPI detection worked fine for a change - it successfully made the standard font about four pixels high and barely readable. If the system had "known" that the typical user to screen distance was 2-3 meters and acted accordingly, that wouldn't have happened. Of course, you need to know the "typical viewing distance" for a screen, which is sometimes clear from the kind of platform or screen and sometimes not. Such practical considerations may unfortunately sink this idea... From mathias at taschenorakel.de Tue Mar 1 17:39:28 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Tue, 1 Mar 2016 17:39:28 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2004097.UGxYAqL1YT@tjmaciei-mobl4> References: <2146618.dGbZ6ML4ne@tjmaciei-mobl4> <1939915.iN7lKn2x1G@milian-kdab2> <2004097.UGxYAqL1YT@tjmaciei-mobl4> Message-ID: <56D5C5C0.2010703@taschenorakel.de> Am 29.02.2016 um 17:40 schrieb Thiago Macieira: > On segunda-feira, 29 de fevereiro de 2016 13:21:52 PST Milian Wolff wrote: >> What do you say? What am I missing that would break my assumptions? > > This is what Olivier proposed too. > > Like I said, I don't like it, but it works. > Well, and it's proposed as temporary solution until we got a clang based moc. Such solutions don't have to be perfect. Well yes, and I know what they say about temporary solutions (and how they become a permanent solution). Ciao, Mathias From milian.wolff at kdab.com Tue Mar 1 17:43:01 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Tue, 01 Mar 2016 17:43:01 +0100 Subject: [Development] debug symbols for official Qt releases Message-ID: <8332748.PF6apbcbs5@milian-kdab2> Hey all, I'm seeing some issues with the status quo of debug symbols for official Qt releases: a) Qt 5.5 for msvc2013_64 does not ship any .pdb files for most of the core libraries. Seems to be fixed for 5.6. But is there a way to get the pdb files for 5.5 as well? b) Apparently there are never any debug symbols shipped for the release build fo Qt. Having debug symbols even for a release build is crucial for a good profiling experience. Could we maybe get release builds in the future with - force-debug-info to improve this situation? I'm aware that one can get some sense out of a profiler when only the end-level application is build in that way, but one can often get much more insight when the stack below (or even in- between for the eventloop and signal/slot magic) also gets annotated stack frames. Right now, I have to suggest people to build Qt themselves for the sole purpose of profiling... A pity! Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Mar 1 18:27:23 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 01 Mar 2016 09:27:23 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <56D5C5C0.2010703@taschenorakel.de> References: <2004097.UGxYAqL1YT@tjmaciei-mobl4> <56D5C5C0.2010703@taschenorakel.de> Message-ID: <4250247.5XxsvYAs3M@tjmaciei-mobl4> On terça-feira, 1 de março de 2016 17:39:28 PST Mathias Hasselmann wrote: > Am 29.02.2016 um 17:40 schrieb Thiago Macieira: > > On segunda-feira, 29 de fevereiro de 2016 13:21:52 PST Milian Wolff wrote: > >> What do you say? What am I missing that would break my assumptions? > > > > This is what Olivier proposed too. > > > > Like I said, I don't like it, but it works. > > Well, and it's proposed as temporary solution until we got a clang based > moc. Such solutions don't have to be perfect. Well yes, and I know what > they say about temporary solutions (and how they become a permanent > solution). If Olivier is willing to modify current moc (non-ng) to support explicit template instantiation, go for it. Another possibility is to provide a separate moc-ng that accomplishes that goal and writes meta objects. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nospam at vuorela.dk Tue Mar 1 20:38:28 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Tue, 1 Mar 2016 19:38:28 +0000 (UTC) Subject: [Development] debug symbols for official Qt releases References: <8332748.PF6apbcbs5@milian-kdab2> Message-ID: On 2016-03-01, Milian Wolff wrote: > b) Apparently there are never any debug symbols shipped for the release build > fo Qt. Having debug symbols even for a release build is crucial for a good > profiling experience. Could we maybe get release builds in the future with - > force-debug-info to improve this situation? I'm aware that one can get some > sense out of a profiler when only the end-level application is build in that > way, but one can often get much more insight when the stack below (or even in- > between for the eventloop and signal/slot magic) also gets annotated stack > frames. Right now, I have to suggest people to build Qt themselves for the > sole purpose of profiling... A pity! This would be amazing. Also for getting better backtraces from crashes at users systems. /Sune From rolland at ghs.com Wed Mar 2 08:24:50 2016 From: rolland at ghs.com (Rolland Dudemaine) Date: Wed, 2 Mar 2016 08:24:50 +0100 Subject: [Development] INTEGRITY changes for 5.7 Message-ID: <56D69542.50600@ghs.com> Hi, I understand that 5.7 has now reached feature freeze, but I would like to ask for an exception for patches that have been pushed a few months ago already but never got merged (partially because of the CI woes). This would cover all the patches with a positive code review status at https://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open,n,z Thanks, Best regards, -- ---------------------------------------------------------- Rolland Dudemaine tel direct:+33 143 143 702 Green Hills Software tel:+33 143 143 700 4 rue de la Pierre Levee mailto:rolland at ghs.com 75011 Paris fax: +33 143 143 707 France web: http://www.ghs.com ---------------------------------------------------------- From cavendish.qi at gmail.com Wed Mar 2 08:28:31 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Wed, 2 Mar 2016 08:28:31 +0100 Subject: [Development] INTEGRITY changes for 5.7 In-Reply-To: <56D69542.50600@ghs.com> References: <56D69542.50600@ghs.com> Message-ID: Do you plan to have them in 5.7 release? Current dev branch means 5.8... On 2 March 2016 at 08:24, Rolland Dudemaine wrote: > Hi, > > I understand that 5.7 has now reached feature freeze, but I would like > to ask for an exception for patches that have been pushed a few months > ago already but never got merged (partially because of the CI woes). > > This would cover all the patches with a positive code review status at > > https://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open,n,z > > Thanks, > Best regards, > > -- > ---------------------------------------------------------- > Rolland Dudemaine tel direct:+33 143 143 702 > Green Hills Software tel:+33 143 143 700 > 4 rue de la Pierre Levee mailto:rolland at ghs.com > 75011 Paris fax: +33 143 143 707 > France web: http://www.ghs.com > ---------------------------------------------------------- > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- http://www.qiliang.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Wed Mar 2 09:00:35 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Wed, 2 Mar 2016 09:00:35 +0100 Subject: [Development] debug symbols for official Qt releases In-Reply-To: References: <8332748.PF6apbcbs5@milian-kdab2>, Message-ID: >On 2016-03-01, Milian Wolff wrote: >> b) Apparently there are never any debug symbols shipped for the release build >> fo Qt. Having debug symbols even for a release build is crucial for a good >> profiling experience. Could we maybe get release builds in the future with - >> force-debug-info to improve this situation? I'm aware that one can get some >> sense out of a profiler when only the end-level application is build in that >> way, but one can often get much more insight when the stack below (or even in- >> between for the eventloop and signal/slot magic) also gets annotated stack >> frames. Right now, I have to suggest people to build Qt themselves for the >> sole purpose of profiling... A pity! > >This would be amazing. Also for getting better backtraces from crashes >at users systems. I normally use release build always even for debugging. It were also nice if Qt would set the enhanced pdb option to get better release debugging experience, /d2Zi+ option for vs2012 and /Zo for Vs2013 upd3 and VS2015. As i have other reasons to always build Qt myself and maintain patches others than these, i have no real problem with the current state, but would still be glad if pdb for release are build and delivered with the enhanced pdb option. Regards, Gunnar Roth     From rolland at ghs.com Wed Mar 2 09:07:27 2016 From: rolland at ghs.com (Rolland Dudemaine) Date: Wed, 2 Mar 2016 08:07:27 +0000 Subject: [Development] INTEGRITY changes for 5.7 Message-ID: <609b550a-26de-4a43-89f1-35f15b76e46e@ghs.com> Ideally i'd like to get those also in 5.7 indeed. For 5.8/dev, there is no need for asking for an exception i guess, just following the regular merge procedure would do just fine. --Rolland From: Liang Qi Sent: Mar 2, 2016 08:28 To: Rolland Dudemaine Cc: development at qt-project.org Subject: Re: [Development] INTEGRITY changes for 5.7 Do you plan to have them in 5.7 release? Current dev branch means 5.8... On 2 March 2016 at 08:24, Rolland Dudemaine > wrote: Hi, I understand that 5.7 has now reached feature freeze, but I would like to ask for an exception for patches that have been pushed a few months ago already but never got merged (partially because of the CI woes). This would cover all the patches with a positive code review status at https://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open,n,z Thanks, Best regards, -- ---------------------------------------------------------- Rolland Dudemaine tel direct:+33 143 143 702 Green Hills Software tel:+33 143 143 700 4 rue de la Pierre Levee mailto:rolland at ghs.com 75011 Paris fax: +33 143 143 707 France web: http://www.ghs.com ---------------------------------------------------------- _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- http://www.qiliang.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Wed Mar 2 08:34:12 2016 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 02 Mar 2016 08:34:12 +0100 Subject: [Development] 5.7 feature freeze In-Reply-To: <59A5F98F-EC4D-4F0B-89DB-628794ACC895@theqtcompany.com> References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> <59A5F98F-EC4D-4F0B-89DB-628794ACC895@theqtcompany.com> Message-ID: <2476881.tnJRaTeZjt@finn> Am Freitag, 26. Februar 2016, 19:07:53 CET schrieb Nurmi J-P: > I would like to ask for an exception for text selection handles. It's a > crucial feature to make the new editor controls usable on mobile and > embedded. There's a task for qtquickcontrols2 > (https://bugreports.qt.io/browse/QTBUG-51010), but the groundwork needs to > be done in qtbase and qtdeclarative. > > I'm aware of the following WIP patches: > - qtbase: Add support for ImhAnchorRectangle: > https://codereview.qt-project.org/#/c/142132/ - qtbase: Android selection > handles: https://codereview.qt-project.org/#/c/142466/ - qtdeclarative: > WIP: Add support for input method selection handles: > https://codereview.qt-project.org/#/c/142133/ > > I would imagine that we may need some new API in such areas as QInputMethod, > Qt::InputMethodHint, and QStyleHints. Would it be acceptable to finish off > this work in the 5.7 branch? +1 It is a shame that you still can't copy/paste properly on Android. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From edward.welbourne at theqtcompany.com Wed Mar 2 09:37:22 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Wed, 2 Mar 2016 08:37:22 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: <2012052.SHaLYvPTNu@z25> References: <20160218132045.GC28638@troll08.it.local>,<2012052.SHaLYvPTNu@z25> Message-ID: Andreas Hartmetz said: > Arcminutes are a really good idea. The size of screen elements isn't > really about physical dimensions, it's about size on retina (the > actual biological thing ;) really, or legibility. [...] > If the system had "known" that the typical user to screen distance was > 2-3 meters and acted accordingly, that wouldn't have happened. Of > course, you need to know the "typical viewing distance" for a screen, So perhaps what we should be using to configure UI scaling isn't a scale factor but this typical viewing distance; as long as the system has some way to discover the physical dimensions of the screen and its pixels, it then know everything it needs to scale the UI sensibly. Eddy. From Kai.Koehne at theqtcompany.com Wed Mar 2 09:52:10 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Wed, 2 Mar 2016 08:52:10 +0000 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <4485464.U5eS8SqyHQ@tjmaciei-mobl4> References: <56D480F3.2050307@michaelmoellney.de> <56D4B48E.4040009@michaelmoellney.de> <4485464.U5eS8SqyHQ@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Thiago Macieira > Sent: Tuesday, March 01, 2016 4:23 PM > To: development at qt-project.org > Subject: Re: [Development] Q_COMPILER_RANGE_FOR not supported > by/defined for VS2012 and VS2013 ? > > On terça-feira, 1 de março de 2016 07:37:02 PST Koehne Kai wrote: > > Well, we have also experienced reviewers + a CI system that will catch > > simple compiler errors. So don't be shy to submit stuff even if you > > yourself can't test compilation on every platform ... In fact I'd be > > happy if all submitters would do a test compile on at least _one_ > > platform ;) > > There's a difference between getting tripped by some corner case you didn't > know about and being told that there's something you should be aware of. > If you ignore advice, get the brown paper bag to put over your head. Fair enough, I didn't want to imply otherwise. But I read your statement as 'don't dare to use range-for unless you test with MSVC yourself', which is IMO too much to ask for. The rule of thumb I got is "use ranged-for with curly brackets". Doesn't this cover it? Regards Kai From eskil.abrahamsen-blomfeldt at theqtcompany.com Wed Mar 2 09:54:51 2016 From: eskil.abrahamsen-blomfeldt at theqtcompany.com (Eskil Abrahamsen Blomfeldt) Date: Wed, 2 Mar 2016 09:54:51 +0100 Subject: [Development] 5.7 feature freeze In-Reply-To: <59A5F98F-EC4D-4F0B-89DB-628794ACC895@theqtcompany.com> References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> <59A5F98F-EC4D-4F0B-89DB-628794ACC895@theqtcompany.com> Message-ID: <56D6AA5B.2000906@theqtcompany.com> Den 26.02.2016 20:07, skrev Nurmi J-P: > Hi Lars, > >> On 27. jan. 2016, at 09.30, Knoll Lars wrote: >> >> If anybody else has a feature he believes absolutely has to make it to 5.7, get it done until Monday or talk to me :) > I would like to ask for an exception for text selection handles. It's a crucial feature to make the new editor controls usable on mobile and embedded. There's a task for qtquickcontrols2 (https://bugreports.qt.io/browse/QTBUG-51010), but the groundwork needs to be done in qtbase and qtdeclarative. > > I'm aware of the following WIP patches: > - qtbase: Add support for ImhAnchorRectangle: https://codereview.qt-project.org/#/c/142132/ > - qtbase: Android selection handles: https://codereview.qt-project.org/#/c/142466/ > - qtdeclarative: WIP: Add support for input method selection handles: https://codereview.qt-project.org/#/c/142133/ > > I would imagine that we may need some new API in such areas as QInputMethod, Qt::InputMethodHint, and QStyleHints. Would it be acceptable to finish off this work in the 5.7 branch? +1 from me. -- Eskil From alexander.blasche at theqtcompany.com Wed Mar 2 10:31:53 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Wed, 2 Mar 2016 09:31:53 +0000 Subject: [Development] INTEGRITY changes for 5.7 In-Reply-To: <609b550a-26de-4a43-89f1-35f15b76e46e@ghs.com> References: <609b550a-26de-4a43-89f1-35f15b76e46e@ghs.com> Message-ID: It never worked in the Qt5.x releases so far. For what it's worth I'd argue this is bugfixing for a non-working platform. Your gerrit reviews would have to be retargeted to 5.7 (A Gerrit admin can do that if that's the conclusion we come to in this thread). -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=theqtcompany.com at qt-project.org] On Behalf Of > Rolland Dudemaine > Sent: Wednesday, 2 March 2016 9:07 > To: Liang Qi > Cc: development at qt-project.org > Subject: Re: [Development] INTEGRITY changes for 5.7 > > Ideally i'd like to get those also in 5.7 indeed. > > For 5.8/dev, there is no need for asking for an exception i guess, just following > the regular merge procedure would do just fine. > > --Rolland > > From: Liang Qi > Sent: Mar 2, 2016 08:28 > To: Rolland Dudemaine > Cc: development at qt-project.org > Subject: Re: [Development] INTEGRITY changes for 5.7 > > > > Do you plan to have them in 5.7 release? Current dev branch means 5.8... > > On 2 March 2016 at 08:24, Rolland Dudemaine > wrote: > > > Hi, > > I understand that 5.7 has now reached feature freeze, but I > would like > to ask for an exception for patches that have been pushed a few > months > ago already but never got merged (partially because of the CI > woes). > > This would cover all the patches with a positive code review > status at > https://codereview.qt- > project.org/#/q/owner:rolland%2540ghs.com+status:open,n,z > > Thanks, > Best regards, > > -- > ---------------------------------------------------------- > Rolland Dudemaine tel direct:+33 143 143 702 > > Green Hills Software tel:+33 143 143 700 > > 4 rue de la Pierre Levee mailto:rolland at ghs.com > > 75011 Paris fax: +33 143 143 707 > > France web: http://www.ghs.com > > ---------------------------------------------------------- > > _______________________________________________ > Development mailing list > Development at qt-project.org project.org> > http://lists.qt-project.org/mailman/listinfo/development > > > > > > -- > > http://www.qiliang.net From Lars.Knoll at theqtcompany.com Wed Mar 2 11:12:38 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 2 Mar 2016 10:12:38 +0000 Subject: [Development] 5.7 feature freeze In-Reply-To: <56D6AA5B.2000906@theqtcompany.com> References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> <59A5F98F-EC4D-4F0B-89DB-628794ACC895@theqtcompany.com> <56D6AA5B.2000906@theqtcompany.com> Message-ID: <6D7E7F46-5BDC-4C5C-8BCB-6D2BD805D744@theqtcompany.com> Ok, go for it. Cheers, Lars On 02/03/16 09:54, "Development on behalf of Eskil Abrahamsen Blomfeldt" wrote: > > >Den 26.02.2016 20:07, skrev Nurmi J-P: >> Hi Lars, >> >>> On 27. jan. 2016, at 09.30, Knoll Lars wrote: >>> >>> If anybody else has a feature he believes absolutely has to make it to 5.7, get it done until Monday or talk to me :) >> I would like to ask for an exception for text selection handles. It's a crucial feature to make the new editor controls usable on mobile and embedded. There's a task for qtquickcontrols2 (https://bugreports.qt.io/browse/QTBUG-51010), but the groundwork needs to be done in qtbase and qtdeclarative. >> >> I'm aware of the following WIP patches: >> - qtbase: Add support for ImhAnchorRectangle: https://codereview.qt-project.org/#/c/142132/ >> - qtbase: Android selection handles: https://codereview.qt-project.org/#/c/142466/ >> - qtdeclarative: WIP: Add support for input method selection handles: https://codereview.qt-project.org/#/c/142133/ >> >> I would imagine that we may need some new API in such areas as QInputMethod, Qt::InputMethodHint, and QStyleHints. Would it be acceptable to finish off this work in the 5.7 branch? > >+1 from me. > >-- Eskil > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Eike.Ziller at theqtcompany.com Wed Mar 2 11:14:18 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Wed, 2 Mar 2016 10:14:18 +0000 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <1939915.iN7lKn2x1G@milian-kdab2> References: <1566797.NsfuvUYKtX@agathebauer> <2146618.dGbZ6ML4ne@tjmaciei-mobl4> <1939915.iN7lKn2x1G@milian-kdab2> Message-ID: > On Feb 29, 2016, at 1:21 PM, Milian Wolff wrote: > > On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote: >> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote: >>>> The main problems of templated QObject are captured more or less in >>>> this >>>> >>>> thread: >>>> http://lists.qt-project.org/pipermail/development/2013-March/010288.html >>>> >>>> Personally I still think it would be a fancy feature, a bit dangerous >>>> to >>>> >>>> implement maybe even dangerous to use, but really cool :-D >>> >>> Thanks for the link. How often is the MOC layout changed in an ABI >>> incompatible way? >> >> There's no historical pattern. There was a major break from Qt 3 to 4 and >> smaller one from 4 to 5. Qt 4 did have updates that didn't break the ABI; >> the Qt 5.0 update removed the ability to read meta objects created with Qt >> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still >> used register-on-load meta objects). >> >> But since the meta object itself has a version number and the only code that >> ever reads the internal data is inside QtCore, so we could make changes >> that change the layout. We haven't done that: all changes between major >> releases have added things without changing the layout. >> >> That's the structure layout though. The file itself compares the >> Q_MOC_OUTPUT_REVISION macro for equality (not ordering). > > OK, but changing the layout between major versions is fine as we break ABI > anyways then, no? > >>> I.e. what problems would we get from having to install the >>> moc files? >> >> Lots. > > > >> Have I convinced you? I'm only getting warmed up. I'm sure I can find more >> issues. > > Thanks for the exhaustive, and educative list! I think this should be put on > the Wiki somewhere for future reference. > >>> Alternatively: couldn't moc re-create the required data from included >>> files >>> when they contain templated objects? That would solve the problem as well, >>> no? >> >> I have no idea what you meant here. >> >> Or, well, I do have one, but I don't think that I understood correctly what >> you're suggesting. I understood that we keep a copy of the header file's >> source in the target application and run moc at runtime to dynamically >> create the meta object, on the fly. >> >> Since I don't think that's what you're suggesting and since the above has so >> many problems (starting with the fact that it doesn't resolve the problem), >> I'm not even going to analyse it. >> >> Can you clarify what you meant? > > Yes, what I had in mind from my outsiders POV was the following, and I have no > clue whether it is feasible at all: > > We have the following structure: > > $path1/lib/foo.h > template Foo : QObject { ...}; > > moc is not doing anything here as the templated QObject is not fully > specialized. > > $path2/app/bar.h: > #include > using Bar = Foo; That would break if any other code in the application (possibly in a different library linked to it) has e.g. using Blah = Foo; right? That sounds pretty fragile. Especially if an application loads plugins. Br, Eike > Now when we compile app, moc runs over the fully specialized templated QObject > and can instantiate it as needed and put all the required code into the > moc_bar.cpp file as it would for a "normal" QObject. I.e. there is no need to > install the templated QObject's moc file. This also is close to how an > ordinary template is handled by a C++ compiler as far as I know. > > Maybe I'm missing something, but this sounds like an elegant solution? The > only downside is increased complexity in moc to find such instantiations. > Until clang can be used for moc, we could add a macro, lets say > Q_INSTANTIATE(Foo), or similar. > > What do you say? What am I missing that would break my assumptions? > -- > Milian Wolff | milian.wolff at kdab.com | Software Engineer > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company > Tel: +49-30-521325470 > KDAB - The Qt Experts_______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From bogdan.vatra at kdab.com Wed Mar 2 11:21:51 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Wed, 02 Mar 2016 12:21:51 +0200 Subject: [Development] 5.7 feature freeze In-Reply-To: <59A5F98F-EC4D-4F0B-89DB-628794ACC895@theqtcompany.com> References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> <59A5F98F-EC4D-4F0B-89DB-628794ACC895@theqtcompany.com> Message-ID: <2881217.A8gYWXtEEL@zmeu> On Friday 26 February 2016 19:07:53 Nurmi J-P wrote: > Hi Lars, > > > On 27. jan. 2016, at 09.30, Knoll Lars > > wrote: > > > > If anybody else has a feature he believes absolutely has to make it to > > 5.7, get it done until Monday or talk to me :) > I would like to ask for an exception for text selection handles. It's a > crucial feature to make the new editor controls usable on mobile and > embedded. There's a task for qtquickcontrols2 > (https://bugreports.qt.io/browse/QTBUG-51010), but the groundwork needs to > be done in qtbase and qtdeclarative. > > I'm aware of the following WIP patches: > - qtbase: Add support for ImhAnchorRectangle: > https://codereview.qt-project.org/#/c/142132/ - qtbase: Android selection > handles: https://codereview.qt-project.org/#/c/142466/ - qtdeclarative: > WIP: Add support for input method selection handles: > https://codereview.qt-project.org/#/c/142133/ > > I would imagine that we may need some new API in such areas as QInputMethod, > Qt::InputMethodHint, and QStyleHints. Would it be acceptable to finish off > this work in the 5.7 branch? > I agree that we need to do something on this matter. But ... :) Are you sure this is the right approach? Isn't better (or easier) to handle it in Qt side and don't rely on platform? What will you do on embedded devices where you don't have any platform support for such things. Cheers, BogDan. From milian.wolff at kdab.com Wed Mar 2 11:23:56 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 02 Mar 2016 11:23:56 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: References: <1939915.iN7lKn2x1G@milian-kdab2> Message-ID: <3160962.X1ysfh7tbh@agathebauer> On Mittwoch, 2. März 2016 10:14:18 CET Ziller Eike wrote: > > On Feb 29, 2016, at 1:21 PM, Milian Wolff wrote: > > > > On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote: > > > >> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote: > >> > >>>> The main problems of templated QObject are captured more or less in > >>>> this > >>>> > >>>> thread: > >>>> http://lists.qt-project.org/pipermail/development/2013-March/010288.htm > >>>> l > >>>> > >>>> Personally I still think it would be a fancy feature, a bit dangerous > >>>> to > >>>> > >>>> implement maybe even dangerous to use, but really cool :-D > >>> > >>> > >>> Thanks for the link. How often is the MOC layout changed in an ABI > >>> incompatible way? > >> > >> > >> There's no historical pattern. There was a major break from Qt 3 to 4 > >> and > >> smaller one from 4 to 5. Qt 4 did have updates that didn't break the > >> ABI; > >> the Qt 5.0 update removed the ability to read meta objects created with > >> Qt > >> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still > >> used register-on-load meta objects). > >> > >> But since the meta object itself has a version number and the only code > >> that ever reads the internal data is inside QtCore, so we could make > >> changes that change the layout. We haven't done that: all changes > >> between major releases have added things without changing the layout. > >> > >> That's the structure layout though. The file itself compares the > >> Q_MOC_OUTPUT_REVISION macro for equality (not ordering). > > > > > > OK, but changing the layout between major versions is fine as we break ABI > > anyways then, no? > > > > > >>> I.e. what problems would we get from having to install the > >>> moc files? > >> > >> > >> Lots. > > > > > > > > > > > >> Have I convinced you? I'm only getting warmed up. I'm sure I can find > >> more > >> issues. > > > > > > Thanks for the exhaustive, and educative list! I think this should be put > > on the Wiki somewhere for future reference. > > > > > >>> Alternatively: couldn't moc re-create the required data from included > >>> files > >>> when they contain templated objects? That would solve the problem as > >>> well, > >>> no? > >> > >> > >> I have no idea what you meant here. > >> > >> Or, well, I do have one, but I don't think that I understood correctly > >> what you're suggesting. I understood that we keep a copy of the header > >> file's source in the target application and run moc at runtime to > >> dynamically create the meta object, on the fly. > >> > >> Since I don't think that's what you're suggesting and since the above has > >> so many problems (starting with the fact that it doesn't resolve the > >> problem), I'm not even going to analyse it. > >> > >> Can you clarify what you meant? > > > > > > Yes, what I had in mind from my outsiders POV was the following, and I > > have no clue whether it is feasible at all: > > > > We have the following structure: > > > > $path1/lib/foo.h > > template Foo : QObject { ...}; > > > > moc is not doing anything here as the templated QObject is not fully > > specialized. > > > > $path2/app/bar.h: > > #include > > using Bar = Foo; > > > That would break if any other code in the application (possibly in a > different library linked to it) has e.g. using Blah = Foo; > right? > That sounds pretty fragile. Especially if an application loads plugins. Can you clarify what would break here? Isn't it exactly the same as doing QVector in multiple TUs? Thanks -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From helmut.muelner at gmail.com Wed Mar 2 11:26:25 2016 From: helmut.muelner at gmail.com (=?iso-8859-1?Q?Helmut_M=FClner?=) Date: Wed, 2 Mar 2016 11:26:25 +0100 Subject: [Development] Crash at program end Message-ID: <004801d1746d$f9dd4420$ed97cc60$@gmail.com> I have a complex mixed QML and C++ desktop application where I get crashes when closing the program. I use Qt-5.5.1/msvc2013 (32 bit) on Windows 7. I did not yet report a bug because I could not produce a small sample program to reproduce the bug. The problem seems to be a double free of the OpenGL context a program end. A pre-condition of the crash seems to be that the program opens a second QML ApplicationWindow or a QML Dialog. Before the crash I always see the message "External WM_DESTROY received for ..." in the debug output. (qtbase\src\plugins\platforms\windows\qwindowscontext.cpp line 933). Does anybody have an idea how to prevent or fix this crash? Best regards, Helmut The call stack at the crash is: Qt5Cored.dll!qt_message_fatal(QtMsgType __formal, const QMessageLogContext & context, const QString & message) Line 1571 C++ Qt5Cored.dll!QMessageLogger::fatal(const char * msg, ...) Line 781 C++ Qt5Cored.dll!qt_assert(const char * assertion, const char * file, int line) Line 2966 C++ > Qt5Guid.dll!qt_gl_functions(QOpenGLContext * context) Line 214 C++ Qt5Guid.dll!`anonymous namespace'::Resolver::operator()(int p1, const unsigned int * p2) Line 2355 C++ Qt5Guid.dll!qopenglfResolveDeleteRenderbuffers(int n, const unsigned int * renderbuffers) Line 2813 C++ Qt5Guid.dll!QOpenGLFunctions::glDeleteRenderbuffers(int n, const unsigned int * renderbuffers) Line 1323 C++ Qt5Quickd.dll!QSGDefaultDepthStencilBuffer::free() Line 146 C++ Qt5Quickd.dll!QSGDefaultDepthStencilBuffer::~QSGDefaultDepthStencilBuffer() Line 140 C++ [External Code] Qt5Quickd.dll!QtSharedPointer::CustomDeleter::execute() Line 189 C++ Qt5Quickd.dll!QtSharedPointer::ExternalRefCountWithCustomDeleter::deleter(QtSharedPointer::Externa lRefCountData * self) Line 211 C++ Qt5Quickd.dll!QtSharedPointer::ExternalRefCountData::destroy() Line 151 C++ Qt5Quickd.dll!QSharedPointer::deref(QtSharedPointer:: ExternalRefCountData * d) Line 474 C++ Qt5Quickd.dll!QSharedPointer::deref() Line 467 C++ Qt5Quickd.dll!QSharedPointer::~QSharedPointer() Line 306 C++ Qt5Quickd.dll!QSGDefaultLayer::~QSGDefaultLayer() Line 106 C++ [External Code] Qt5Quickd.dll!QQuickShaderEffectSource::invalidateSceneGraph() Line 698 C++ Qt5Quickd.dll!QQuickShaderEffectSource::qt_static_metacall(QObject * _o, QMetaObject::Call _c, int _id, void * * _a) Line 191 C++ Qt5Cored.dll!QMetaMethod::invoke(QObject * object, Qt::ConnectionType connectionType, QGenericReturnArgument returnValue, QGenericArgument val0, QGenericArgument val1, QGenericArgument val2, QGenericArgument val3, QGenericArgument val4, QGenericArgument val5, QGenericArgument val6, QGenericArgument val7, QGenericArgument val8, QGenericArgument val9) Line 2212 C++ Qt5Cored.dll!QMetaMethod::invoke(QObject * object, Qt::ConnectionType connectionType, QGenericArgument val0, QGenericArgument val1, QGenericArgument val2, QGenericArgument val3, QGenericArgument val4, QGenericArgument val5, QGenericArgument val6, QGenericArgument val7, QGenericArgument val8, QGenericArgument val9) Line 118 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2690 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown(QQuickItem * item) Line 2691 C++ Qt5Quickd.dll!QQuickWindowPrivate::cleanupNodesOnShutdown() Line 2699 C++ Qt5Quickd.dll!QSGRenderThread::invalidateOpenGL(QQuickWindow * window, bool inDestructor, QOffscreenSurface * fallback) Line 461 C++ Qt5Quickd.dll!QSGRenderThread::event(QEvent * e) Line 383 C++ Qt5Quickd.dll!QSGRenderThread::processEventsAndWaitForMore() Line 659 C++ Qt5Quickd.dll!QSGRenderThread::run() Line 687 C++ Qt5Cored.dll!QThreadPrivate::start(void * arg) Line 369 C++ [External Code] From Shawn.Rutledge at theqtcompany.com Wed Mar 2 13:47:34 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Wed, 2 Mar 2016 12:47:34 +0000 Subject: [Development] Scalable UIs in QtQuick (take 2) In-Reply-To: References: <20160218132045.GC28638@troll08.it.local> <2012052.SHaLYvPTNu@z25> Message-ID: <64FA9081-228C-416C-8D41-B7D1AD5BB23A@digia.com> > On 2 Mar 2016, at 09:37, Welbourne Edward wrote: > > Andreas Hartmetz said: >> Arcminutes are a really good idea. The size of screen elements isn't >> really about physical dimensions, it's about size on retina (the >> actual biological thing ;) really, or legibility. > [...] >> If the system had "known" that the typical user to screen distance was >> 2-3 meters and acted accordingly, that wouldn't have happened. Of >> course, you need to know the "typical viewing distance" for a screen, > > So perhaps what we should be using to configure UI scaling isn't a scale > factor but this typical viewing distance; as long as the system has some > way to discover the physical dimensions of the screen and its pixels, it > then know everything it needs to scale the UI sensibly. But some devices tell lies in their EDID data, and some don’t. And with a projector you don’t know the physical size either. So we can’t always discover the physical dimensions without user intervention. (At least xorg.conf provides a way to override it.) We could have some kind of calibration tool to help close the loop: a wizard that detects all possible settings, tries some tweaks, asks you to measure some calibration rects and text (rendered with both QtQuick and widgets) with a ruler, and then suggests settings that you probably need to adjust manually. Kindof like using a colorimeter to calibrate color. Except other software and hardware would keep changing out of our control, so this tool would never be “done”. And really the desktop environment should have a sufficiently powerful control panel that we don’t need to write that. But maybe it’s worth a try anyhow. From Eike.Ziller at theqtcompany.com Wed Mar 2 14:48:49 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Wed, 2 Mar 2016 13:48:49 +0000 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <3160962.X1ysfh7tbh@agathebauer> References: <1939915.iN7lKn2x1G@milian-kdab2> <3160962.X1ysfh7tbh@agathebauer> Message-ID: <2779904C-6D93-4A6E-969B-8B2ACF835724@theqtcompany.com> > On Mar 2, 2016, at 11:23 AM, Milian Wolff wrote: > > On Mittwoch, 2. März 2016 10:14:18 CET Ziller Eike wrote: >>> On Feb 29, 2016, at 1:21 PM, Milian Wolff wrote: >>> >>> On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote: >>> >>>> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff wrote: >>>> >>>>>> The main problems of templated QObject are captured more or less in >>>>>> this >>>>>> >>>>>> thread: >>>>>> http://lists.qt-project.org/pipermail/development/2013-March/010288.htm >>>>>> l >>>>>> >>>>>> Personally I still think it would be a fancy feature, a bit dangerous >>>>>> to >>>>>> >>>>>> implement maybe even dangerous to use, but really cool :-D >>>>> >>>>> >>>>> Thanks for the link. How often is the MOC layout changed in an ABI >>>>> incompatible way? >>>> >>>> >>>> There's no historical pattern. There was a major break from Qt 3 to 4 >>>> and >>>> smaller one from 4 to 5. Qt 4 did have updates that didn't break the >>>> ABI; >>>> the Qt 5.0 update removed the ability to read meta objects created with >>>> Qt >>>> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 still >>>> used register-on-load meta objects). >>>> >>>> But since the meta object itself has a version number and the only code >>>> that > ever reads the internal data is inside QtCore, so we could make >>>> changes that change the layout. We haven't done that: all changes >>>> between major releases have added things without changing the layout. >>>> >>>> That's the structure layout though. The file itself compares the >>>> Q_MOC_OUTPUT_REVISION macro for equality (not ordering). >>> >>> >>> OK, but changing the layout between major versions is fine as we break ABI >>> > anyways then, no? >>> >>> >>>>> I.e. what problems would we get from having to install the >>>>> moc files? >>>> >>>> >>>> Lots. >>> >>> >>> >>> >>> >>>> Have I convinced you? I'm only getting warmed up. I'm sure I can find >>>> more >>>> issues. >>> >>> >>> Thanks for the exhaustive, and educative list! I think this should be put >>> on > the Wiki somewhere for future reference. >>> >>> >>>>> Alternatively: couldn't moc re-create the required data from included >>>>> files >>>>> when they contain templated objects? That would solve the problem as >>>>> well, >>>>> no? >>>> >>>> >>>> I have no idea what you meant here. >>>> >>>> Or, well, I do have one, but I don't think that I understood correctly >>>> what > you're suggesting. I understood that we keep a copy of the header >>>> file's source in the target application and run moc at runtime to >>>> dynamically create the meta object, on the fly. >>>> >>>> Since I don't think that's what you're suggesting and since the above has >>>> so > many problems (starting with the fact that it doesn't resolve the >>>> problem), I'm not even going to analyse it. >>>> >>>> Can you clarify what you meant? >>> >>> >>> Yes, what I had in mind from my outsiders POV was the following, and I >>> have no > clue whether it is feasible at all: >>> >>> We have the following structure: >>> >>> $path1/lib/foo.h >>> template Foo : QObject { ...}; >>> >>> moc is not doing anything here as the templated QObject is not fully >>> specialized. >>> >>> $path2/app/bar.h: >>> #include >>> using Bar = Foo; >> >> >> That would break if any other code in the application (possibly in a >> different library linked to it) has e.g. > using Blah = Foo; >> right? >> That sounds pretty fragile. Especially if an application loads plugins. > > Can you clarify what would break here? Isn't it exactly the same as doing > QVector in multiple TUs? As I understood it, moc would generate the MetaObject for Foo when it sees “using SomeAlias = Foo” (or some macro). So if lib A does it and lib B does it, and they both get linked into the same application, there would be two implementations of the static meta object, which Thiago said would not work? But maybe I missed something from the discussion. -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From milian.wolff at kdab.com Wed Mar 2 16:48:08 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 02 Mar 2016 16:48:08 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2779904C-6D93-4A6E-969B-8B2ACF835724@theqtcompany.com> References: <3160962.X1ysfh7tbh@agathebauer> <2779904C-6D93-4A6E-969B-8B2ACF835724@theqtcompany.com> Message-ID: <2352897.DmlodQsnvN@agathebauer> On Mittwoch, 2. März 2016 13:48:49 CET Ziller Eike wrote: > > On Mar 2, 2016, at 11:23 AM, Milian Wolff wrote: > > > > On Mittwoch, 2. März 2016 10:14:18 CET Ziller Eike wrote: > > > >>> On Feb 29, 2016, at 1:21 PM, Milian Wolff > >>> wrote: > >>> > >>> On Friday, February 26, 2016 3:56:08 PM CET Thiago Macieira wrote: > >>> > >>> > >>>> On sexta-feira, 26 de fevereiro de 2016 20:30:28 PST Milian Wolff > >>>> wrote: > >>>> > >>>> > >>>>>> The main problems of templated QObject are captured more or less in > >>>>>> this > >>>>>> > >>>>>> thread: > >>>>>> http://lists.qt-project.org/pipermail/development/2013-March/010288.h > >>>>>> tm > >>>>>> l > >>>>>> > >>>>>> Personally I still think it would be a fancy feature, a bit > >>>>>> dangerous > >>>>>> to > >>>>>> > >>>>>> implement maybe even dangerous to use, but really cool :-D > >>>>> > >>>>> > >>>>> > >>>>> Thanks for the link. How often is the MOC layout changed in an ABI > >>>>> incompatible way? > >>>> > >>>> > >>>> > >>>> There's no historical pattern. There was a major break from Qt 3 to 4 > >>>> and > >>>> smaller one from 4 to 5. Qt 4 did have updates that didn't break the > >>>> ABI; > >>>> the Qt 5.0 update removed the ability to read meta objects created > >>>> with > >>>> Qt > >>>> 4 moc. I don't remember how the 1→2 and 2→3 updates happened (Qt 3 > >>>> still > >>>> used register-on-load meta objects). > >>>> > >>>> But since the meta object itself has a version number and the only > >>>> code > >>>> that > > > > ever reads the internal data is inside QtCore, so we could make > > > >>>> changes that change the layout. We haven't done that: all changes > >>>> between major releases have added things without changing the layout. > >>>> > >>>> That's the structure layout though. The file itself compares the > >>>> Q_MOC_OUTPUT_REVISION macro for equality (not ordering). > >>> > >>> > >>> > >>> OK, but changing the layout between major versions is fine as we break > >>> ABI > >>> > > > > anyways then, no? > > > >>> > >>> > >>> > >>>>> I.e. what problems would we get from having to install the > >>>>> moc files? > >>>> > >>>> > >>>> > >>>> Lots. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>>> Have I convinced you? I'm only getting warmed up. I'm sure I can find > >>>> more > >>>> issues. > >>> > >>> > >>> > >>> Thanks for the exhaustive, and educative list! I think this should be > >>> put > >>> on > > > > the Wiki somewhere for future reference. > > > >>> > >>> > >>> > >>>>> Alternatively: couldn't moc re-create the required data from included > >>>>> files > >>>>> when they contain templated objects? That would solve the problem as > >>>>> well, > >>>>> no? > >>>> > >>>> > >>>> > >>>> I have no idea what you meant here. > >>>> > >>>> Or, well, I do have one, but I don't think that I understood correctly > >>>> what > > > > you're suggesting. I understood that we keep a copy of the header > > > >>>> file's source in the target application and run moc at runtime to > >>>> dynamically create the meta object, on the fly. > >>>> > >>>> Since I don't think that's what you're suggesting and since the above > >>>> has > >>>> so > > > > many problems (starting with the fact that it doesn't resolve the > > > >>>> problem), I'm not even going to analyse it. > >>>> > >>>> Can you clarify what you meant? > >>> > >>> > >>> > >>> Yes, what I had in mind from my outsiders POV was the following, and I > >>> have no > > > > clue whether it is feasible at all: > > > >>> > >>> We have the following structure: > >>> > >>> $path1/lib/foo.h > >>> template Foo : QObject { ...}; > >>> > >>> moc is not doing anything here as the templated QObject is not fully > >>> specialized. > >>> > >>> $path2/app/bar.h: > >>> #include > >>> using Bar = Foo; > >> > >> > >> > >> That would break if any other code in the application (possibly in a > >> different library linked to it) has e.g. > > > > using Blah = Foo; > > > >> right? > >> That sounds pretty fragile. Especially if an application loads plugins. > > > > > > Can you clarify what would break here? Isn't it exactly the same as doing > > > > QVector in multiple TUs? > > > As I understood it, moc would generate the MetaObject for Foo when it > sees “using SomeAlias = Foo” (or some macro). So if lib A does it and > lib B does it, and they both get linked into the same application, there > would be two implementations of the static meta object, which Thiago said > would not work? But maybe I missed something from the discussion. Ah, indeed - QMetaObject::cast e.g. does a pointer comparison on the static meta object. So if we end up with two instances of that in different TUs, we'll encounter issues. A simple solution would then be a macro for an explicit instantiation, similar to what we already do with Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only there then would moc generate the static meta object. That should work, no? Bye -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From thiago.macieira at intel.com Wed Mar 2 17:59:05 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 08:59:05 -0800 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: References: <56D480F3.2050307@michaelmoellney.de> <4485464.U5eS8SqyHQ@tjmaciei-mobl4> Message-ID: <8623796.XgM0mdbxRP@tjmaciei-mobl4> On quarta-feira, 2 de março de 2016 08:52:10 PST Koehne Kai wrote: > Fair enough, I didn't want to imply otherwise. But I read your statement as > 'don't dare to use range-for unless you test with MSVC yourself', which is > IMO too much to ask for. > > The rule of thumb I got is "use ranged-for with curly brackets". Doesn't > this cover it? Maybe. Who knows, the parser is buggy! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 2 18:00:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 09:00:55 -0800 Subject: [Development] INTEGRITY changes for 5.7 In-Reply-To: <56D69542.50600@ghs.com> References: <56D69542.50600@ghs.com> Message-ID: <2887887.syJd2lzSvv@tjmaciei-mobl4> On quarta-feira, 2 de março de 2016 08:24:50 PST Rolland Dudemaine wrote: > Hi, > > I understand that 5.7 has now reached feature freeze, but I would like > to ask for an exception for patches that have been pushed a few months > ago already but never got merged (partially because of the CI woes). > > This would cover all the patches with a positive code review status at > https://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open, > n,z I support Rolland in this. The patches were reviewed some time ago and were fine. Rolland wasn't aware that he needed to keep pushing the Stage button... This should bring Qt 5.7 to work on INTEGRITY, provided a C++11 compiler is available for that platform. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From robert.griebl at pelagicore.com Wed Mar 2 18:32:37 2016 From: robert.griebl at pelagicore.com (Robert Griebl) Date: Wed, 2 Mar 2016 18:32:37 +0100 Subject: [Development] INTEGRITY changes for 5.7 In-Reply-To: <2887887.syJd2lzSvv@tjmaciei-mobl4> References: <56D69542.50600@ghs.com> <2887887.syJd2lzSvv@tjmaciei-mobl4> Message-ID: <56D723B5.5070907@pelagicore.com> On 02.03.2016 18:00, Thiago Macieira wrote: > On quarta-feira, 2 de março de 2016 08:24:50 PST Rolland Dudemaine wrote: >> Hi, >> >> I understand that 5.7 has now reached feature freeze, but I would like >> to ask for an exception for patches that have been pushed a few months >> ago already but never got merged (partially because of the CI woes). >> >> This would cover all the patches with a positive code review status at >> https://codereview.qt-project.org/#/q/owner:rolland%2540ghs.com+status:open, >> n,z > > I support Rolland in this. The patches were reviewed some time ago and were > fine. Rolland wasn't aware that he needed to keep pushing the Stage button... > > This should bring Qt 5.7 to work on INTEGRITY, provided a C++11 compiler is > available for that platform. +1 -- Robert Griebl SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany robert.griebl at pelagicore.com www.pelagicore.com From Jake.Petroules at theqtcompany.com Wed Mar 2 18:45:27 2016 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Wed, 2 Mar 2016 17:45:27 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <15B8CB18-D3BC-41B2-B038-3501344ABD7A@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <56C80E81.3040602@kdab.com> <15B8CB18-D3BC-41B2-B038-3501344ABD7A@theqtcompany.com> Message-ID: <4B7CCA27-F3BF-45B3-8F6B-2E6D48C9F560@theqtcompany.com> On Feb 19, 2016, at 11:38 PM, Petroules Jake > wrote: * We require the latest Xcode toolchain and OS X on the Mac for compiling (see separate mailing list thread). We support deployment to OS X 10.9 and later (dropping 10.8) +1 * On iOS, we also require the latest Xcode toolchain for compiling. We continue with iOS 7 as the minimum supported version for deployment. "Continue" with iOS 7? It's currently iOS 6 in both 5.7 and dev branches. However, I wholeheartedly approve bumping it to 7. This puts us at a minimum of "last four releases" (by the time 5.8 is released) for both OS X and iOS. However I'd argue that iOS's schedule should be treated a little more aggressively given its extremely fast upgrade cycle compared to all other platforms. As of February 8th, 2016, the iOS version distribution (as measured by Apple - https://developer.apple.com/support/app-store/) is as follows: - iOS 9 - 77% - iOS 8 - 17% - iOS 7 and earlier - 6% By the time Qt 5.8 is released, iOS 10 will have just been released and iOS 8's market share will almost certainly less than 5%, as iOS 7's is now. In that case is there really much point supporting iOS 7 (or even 8)? iOS 8 was one of the biggest releases API-wise and so we would be able to reduce effort significantly by dropping v7. The current version of Xcode also provides no simulators for iOS prior to 8.1. Lars, Apple people, can you please provide your input here? -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Mar 2 18:46:39 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 09:46:39 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: References: <1939915.iN7lKn2x1G@milian-kdab2> Message-ID: <2831873.uidxHLOcuM@tjmaciei-mobl4> On quarta-feira, 2 de março de 2016 10:14:18 PST Ziller Eike wrote: > That would break if any other code in the application (possibly in a > different library linked to it) has e.g. using Blah = Foo; > right? > That sounds pretty fragile. Especially if an application loads plugins. Correct. You cannot compare the template instantiations' meta objects across libraries. They will compare as if they were different classes (with the same name). That's an ODR violation, but it's allowed because we're talking about DLLs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 2 18:47:33 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 09:47:33 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2352897.DmlodQsnvN@agathebauer> References: <2779904C-6D93-4A6E-969B-8B2ACF835724@theqtcompany.com> <2352897.DmlodQsnvN@agathebauer> Message-ID: <1598635.vvnm0mlMTQ@tjmaciei-mobl4> On quarta-feira, 2 de março de 2016 16:48:08 PST Milian Wolff wrote: > A simple solution would then be a macro for an explicit instantiation, > similar to what we already do with > Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only there then would moc > generate the static meta object. That should work, no? That is the case I mentioned before: the template class's author needs to know each and every possible instantiation ahead of time and instantiate them. Unlikely to be acceptable use-case. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From milian.wolff at kdab.com Wed Mar 2 19:24:15 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 02 Mar 2016 19:24:15 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <1598635.vvnm0mlMTQ@tjmaciei-mobl4> References: <2352897.DmlodQsnvN@agathebauer> <1598635.vvnm0mlMTQ@tjmaciei-mobl4> Message-ID: <1679243.BrTbPeIAAh@agathebauer> On Mittwoch, 2. März 2016 09:47:33 CET Thiago Macieira wrote: > On quarta-feira, 2 de março de 2016 16:48:08 PST Milian Wolff wrote: > > A simple solution would then be a macro for an explicit instantiation, > > similar to what we already do with > > Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only there then would moc > > generate the static meta object. That should work, no? > > That is the case I mentioned before: the template class's author needs to > know each and every possible instantiation ahead of time and instantiate > them. Unlikely to be acceptable use-case. For the use-case I have in mind, i.e. templated models, it would just fine. Note that I did not propose to have the macro for the instantiation where the template gets defined. Rather, I imagine users of the template to do that on demand. It's like QMetaType, no? We can, optionally, supply a set of instantiations for common types in the library. All others will be done by the user on- demand. If he then triggers an ODR violation, he can solve it by sharing the common code. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From thiago.macieira at intel.com Wed Mar 2 20:28:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 11:28:07 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <1679243.BrTbPeIAAh@agathebauer> References: <1598635.vvnm0mlMTQ@tjmaciei-mobl4> <1679243.BrTbPeIAAh@agathebauer> Message-ID: <1495635.9B4e7A5Ykb@tjmaciei-mobl4> On quarta-feira, 2 de março de 2016 19:24:15 PST Milian Wolff wrote: > On Mittwoch, 2. März 2016 09:47:33 CET Thiago Macieira wrote: > > On quarta-feira, 2 de março de 2016 16:48:08 PST Milian Wolff wrote: > > > A simple solution would then be a macro for an explicit instantiation, > > > similar to what we already do with > > > Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only there then would moc > > > generate the static meta object. That should work, no? > > > > That is the case I mentioned before: the template class's author needs to > > know each and every possible instantiation ahead of time and instantiate > > them. Unlikely to be acceptable use-case. > > For the use-case I have in mind, i.e. templated models, it would just fine. > Note that I did not propose to have the macro for the instantiation where > the template gets defined. Rather, I imagine users of the template to do > that on demand. That's not the case above. I was talking about pre-populating every possible instantiation. If the users do it on demand, then we have the runtime merging problem on Windows. Pick your poison. > It's like QMetaType, no? We can, optionally, supply a set of instantiations > for common types in the library. All others will be done by the user on- > demand. If he then triggers an ODR violation, he can solve it by sharing the > common code. No, it isn't. QMetaType doesn't compare pointers. QMetaType assumes that ODR wasn't violated. The meta objects will violate ODR. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at theqtcompany.com Wed Mar 2 20:46:48 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 2 Mar 2016 20:46:48 +0100 Subject: [Development] INTEGRITY changes for 5.7 In-Reply-To: <2887887.syJd2lzSvv@tjmaciei-mobl4> References: <56D69542.50600@ghs.com> <2887887.syJd2lzSvv@tjmaciei-mobl4> Message-ID: <20160302194648.GD3477@troll08.it.local> On Wed, Mar 02, 2016 at 09:00:55AM -0800, Thiago Macieira wrote: > On quarta-feira, 2 de março de 2016 08:24:50 PST Rolland Dudemaine wrote: > > I understand that 5.7 has now reached feature freeze, but I would like > > to ask for an exception for patches that have been pushed a few months > > ago already but never got merged (partially because of the CI woes). > > > > I support Rolland in this. > the series has been moved to 5.7. From milian.wolff at kdab.com Wed Mar 2 20:59:41 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 02 Mar 2016 20:59:41 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <1495635.9B4e7A5Ykb@tjmaciei-mobl4> References: <1679243.BrTbPeIAAh@agathebauer> <1495635.9B4e7A5Ykb@tjmaciei-mobl4> Message-ID: <3010962.ABWefQG401@agathebauer> On Mittwoch, 2. März 2016 11:28:07 CET Thiago Macieira wrote: > On quarta-feira, 2 de março de 2016 19:24:15 PST Milian Wolff wrote: > > On Mittwoch, 2. März 2016 09:47:33 CET Thiago Macieira wrote: > > > On quarta-feira, 2 de março de 2016 16:48:08 PST Milian Wolff wrote: > > > > A simple solution would then be a macro for an explicit instantiation, > > > > similar to what we already do with > > > > Q_DECLARE_LOGGING_CATEGORY/Q_LOGGING_CATEGORY. Only there then would > > > > moc > > > > generate the static meta object. That should work, no? > > > > > > That is the case I mentioned before: the template class's author needs > > > to > > > know each and every possible instantiation ahead of time and instantiate > > > them. Unlikely to be acceptable use-case. > > > > For the use-case I have in mind, i.e. templated models, it would just > > fine. > > Note that I did not propose to have the macro for the instantiation where > > the template gets defined. Rather, I imagine users of the template to do > > that on demand. > > That's not the case above. I was talking about pre-populating every possible > instantiation. > > If the users do it on demand, then we have the runtime merging problem on > Windows. > > Pick your poison. Hey Thiago, what is "the runtime merging problem on Windows"? Thanks -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From andre at familiesomers.nl Wed Mar 2 21:28:24 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 2 Mar 2016 21:28:24 +0100 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <15B8CB18-D3BC-41B2-B038-3501344ABD7A@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <56C80E81.3040602@kdab.com> <15B8CB18-D3BC-41B2-B038-3501344ABD7A@theqtcompany.com> Message-ID: <56D74CE8.2030508@familiesomers.nl> Op 20/02/2016 om 08:38 schreef Petroules Jake: > "Continue" with iOS 7? It's currently iOS 6 in both 5.7 and dev > branches. However, I wholeheartedly approve bumping it to 7. > > This puts us at a minimum of "last four releases" (by the time 5.8 is > released) for both OS X and iOS. However I'd argue that iOS's schedule > should be treated a little more aggressively given its extremely fast > upgrade cycle compared to all other platforms. > > As of February 8th, 2016, the iOS version distribution (as measured by > Apple - https://developer.apple.com/support/app-store/) is as follows: > - iOS 9 - 77% > - iOS 8 - 17% > - iOS 7 and earlier - 6% > > By the time Qt 5.8 is released, iOS 10 will have just been released > and iOS 8's market share will almost certainly less than 5%, as iOS > 7's is now. In that case is there really much point supporting iOS 7 > (or even 8)? > > iOS 8 was one of the biggest releases API-wise and so we would be able > to reduce effort significantly by dropping v7. The current version of > Xcode also provides no simulators for iOS prior to 8.1. Hmm... That would be annoying. iOS 7 is the last version supported on the iPhone 4 (which I am still using). To me, it doesn't even feel that old. Here is the list of devices that will be left behind for each version you bumb: http://www.everyi.com/by-capability/maximum-supported-ios-version-for-ipod-iphone-ipad.html André From marc.mutz at kdab.com Wed Mar 2 22:38:03 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 2 Mar 2016 22:38:03 +0100 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <8623796.XgM0mdbxRP@tjmaciei-mobl4> References: <56D480F3.2050307@michaelmoellney.de> <8623796.XgM0mdbxRP@tjmaciei-mobl4> Message-ID: <201603022238.03921.marc.mutz@kdab.com> On Wednesday 02 March 2016 17:59:05 Thiago Macieira wrote: > On quarta-feira, 2 de março de 2016 08:52:10 PST Koehne Kai wrote: > > Fair enough, I didn't want to imply otherwise. But I read your statement > > as 'don't dare to use range-for unless you test with MSVC yourself', > > which is IMO too much to ask for. > > > > The rule of thumb I got is "use ranged-for with curly brackets". Doesn't > > this cover it? > > Maybe. Who knows, the parser is buggy! Having introduced the most range-fors into Qt of all developers over the last weeks, I have come across only one issue, and it's the one from the bug report: for ( ... : ... ) do { ... } while As in, e.g., for (... : ...) QCOMPARE(..., ...) I think it's safe to say that range-for works as expected in so vast a majority of cases that the CI can be used to catch the rest. Without violating the Qt Code Formatting Guidelines and putting {} around each range-for loop body. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Wed Mar 2 21:59:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 12:59:30 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <3010962.ABWefQG401@agathebauer> References: <1495635.9B4e7A5Ykb@tjmaciei-mobl4> <3010962.ABWefQG401@agathebauer> Message-ID: <2982314.9xyceZ9k2C@tjmaciei-mobl4> On quarta-feira, 2 de março de 2016 20:59:41 PST Milian Wolff wrote: > Hey Thiago, > > what is "the runtime merging problem on Windows"? Ever heard of the dynamic_cast problem on Windows? It's the same. Here's the problem: QMetaObjects are identified by their pointer addresses: two meta objects are the same if their pointer addresses are the same (remember: QMetaObject has no operator==). qobject_cast uses that feature to conclude whether a given object derives from a given class. The way it's currently designed in Qt, the meta object is exported (Q_DECL_EXPORT) from the DLL in which the class is defined. Obviously, that can only happen for concrete types, not for templates. As I explained, we could add a feature to allow the class author to export all possible instantiations of a template. Each and every instantiation would be exported from the DLL. That's, in fact, why a full listing is required: to determine which instantiations to export in the first place. The other suggestion done here is that the user of a template create the meta object. That's how typeinfo works for types without virtual tables: each place where typeid() is called, the typeinfo is generated, then merged at runtime by the dynamic linker. On ELF systems without any special compiler flags, this works because symbols are global by default ("default" visibility) and all references to any symbol name are accessed via the GOT, which ensures that only one copy is active and all accesses get the same pointer address. Where this breaks down: 1) Windows: the PE-COFF file format does not work like ELF. Symbols are by local (the default), __declspec(dllexport), or __declspec(dllimport). If the symbol is local or exported, then the compiler generates access assuming that the copy in the current DLL is the active one; if it's imported, then the compiler generates code assuming it exists in another DLL and will not emit a copy. This means that if a DLL has a copy, it assumes its copy is active. If it has no copy, some other DLL must have it. What's more, imports are associated with a particular DLL, so the compile-time linker needs to know which DLL contains the symbol. I don't know how or even if throwing template types or dynamic_cast'ing them works on Windows. It's possible it doesn't work and will never work. I don't care to find out. 2) "hidden" visibility: modern libraries on Unix today compile with -fvisibility=hidden -fvisibility-inlines-hidden, like Qt does. Many of them, like Qt, heavily pollute the global namespace if you don't use those flags, and that's assuming they work at all. Every type with hidden visibility is, as the name says, not exported to the ELF dynamic symbol table, which means the dynamic linker doesn't see them and will not merge with other copies. 3) -Bsymbolic / "protected" visibility: this instructs the compiler and linker that the exported symbols are not subject to preemption and that, like Windows's __declspec(dllexport), the copy in this ELF module is always the active one and local accesses need not go through the GOT (that's why we use it). If this assumption fails, crazy things happen, as we've seen with platforms other than x86 for our -Bsymbolic usage. Summary: this is where the theory of the C++ Standard and reality do not agree. When you take the ABIs into consideration, the C++ Standard's definition of ODR is just wishful thinking. In time: C++17 Modules do not solve this issue. Modules replace some use of headers and #include; they have nothing to do with DLLs and symbol exporting/ importing. Glossary: * ELF: Executable and Linkable Format, the file format for all object files, libraries, executables and core dumps on modern Unix systems, first deployed by Sun on Solaris. * PE-COFF: Portable Executable COFF, Microsoft's variant of the COFF object file format, used for DLLs and executables (not for .obj files, that's OMF). * GOT: Global Offset Table, a technique used to achieve position- independence. Whenever a symbol "foo" is referenced, instead of writing its address into the code, the compiler generates an indirect load of the symbol's address from a fixed location in the GOT, which the dynamic linker will write to once it has finished loading all modules and can resolve all symbols. This can be used to make the code read-only and shareable. See also PLT and the GOT pointer (which is the value that the PIC register carries). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 2 21:59:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 12:59:55 -0800 Subject: [Development] Q_COMPILER_RANGE_FOR not supported by/defined for VS2012 and VS2013 ? In-Reply-To: <201603022238.03921.marc.mutz@kdab.com> References: <56D480F3.2050307@michaelmoellney.de> <8623796.XgM0mdbxRP@tjmaciei-mobl4> <201603022238.03921.marc.mutz@kdab.com> Message-ID: <2934355.sb2NsPSEj2@tjmaciei-mobl4> On quarta-feira, 2 de março de 2016 22:38:03 PST Marc Mutz wrote: > I think it's safe to say that range-for works as expected in so vast a > majority of cases that the CI can be used to catch the rest. Without > violating the Qt Code Formatting Guidelines and putting {} around each > range-for loop body. Good to know, thanks. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From milian.wolff at kdab.com Wed Mar 2 22:34:16 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 02 Mar 2016 22:34:16 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2982314.9xyceZ9k2C@tjmaciei-mobl4> References: <3010962.ABWefQG401@agathebauer> <2982314.9xyceZ9k2C@tjmaciei-mobl4> Message-ID: <3708001.aDn73GA3AX@agathebauer> On Mittwoch, 2. März 2016 12:59:30 CET Thiago Macieira wrote: > On quarta-feira, 2 de março de 2016 20:59:41 PST Milian Wolff wrote: > > Hey Thiago, > > > > what is "the runtime merging problem on Windows"? > > Ever heard of the dynamic_cast problem on Windows? It's the same. Great, thanks a lot for this insightful write-up! So, do you -2 a templated QObject then for these reasons? Personally, I still think that it would be nice to have. The cases I'm thinking of using this feature, i.e. QAIM, would always involve private data types. But of course, with Qt being a library, I realize that it has to care for all eventualities, like a common Foo being used repeatedly and then breaking ODR. Thanks > Here's the problem: > > QMetaObjects are identified by their pointer addresses: two meta objects are > the same if their pointer addresses are the same (remember: QMetaObject has > no operator==). qobject_cast uses that feature to conclude whether a given > object derives from a given class. > > The way it's currently designed in Qt, the meta object is exported > (Q_DECL_EXPORT) from the DLL in which the class is defined. Obviously, that > can only happen for concrete types, not for templates. As I explained, we > could add a feature to allow the class author to export all possible > instantiations of a template. Each and every instantiation would be > exported from the DLL. That's, in fact, why a full listing is required: to > determine which instantiations to export in the first place. > > The other suggestion done here is that the user of a template create the > meta object. That's how typeinfo works for types without virtual tables: > each place where typeid() is called, the typeinfo is generated, then merged > at runtime by the dynamic linker. On ELF systems without any special > compiler flags, this works because symbols are global by default ("default" > visibility) and all references to any symbol name are accessed via the GOT, > which ensures that only one copy is active and all accesses get the same > pointer address. > > Where this breaks down: > > 1) Windows: the PE-COFF file format does not work like ELF. Symbols are by > local (the default), __declspec(dllexport), or __declspec(dllimport). If the > symbol is local or exported, then the compiler generates access assuming > that the copy in the current DLL is the active one; if it's imported, then > the compiler generates code assuming it exists in another DLL and will not > emit a copy. > > This means that if a DLL has a copy, it assumes its copy is active. If it > has no copy, some other DLL must have it. What's more, imports are > associated with a particular DLL, so the compile-time linker needs to know > which DLL contains the symbol. > > I don't know how or even if throwing template types or dynamic_cast'ing them > works on Windows. It's possible it doesn't work and will never work. I > don't care to find out. > > 2) "hidden" visibility: modern libraries on Unix today compile with > -fvisibility=hidden -fvisibility-inlines-hidden, like Qt does. Many of them, > like Qt, heavily pollute the global namespace if you don't use those flags, > and that's assuming they work at all. Every type with hidden visibility is, > as the name says, not exported to the ELF dynamic symbol table, which means > the dynamic linker doesn't see them and will not merge with other copies. > > 3) -Bsymbolic / "protected" visibility: this instructs the compiler and > linker that the exported symbols are not subject to preemption and that, > like Windows's __declspec(dllexport), the copy in this ELF module is always > the active one and local accesses need not go through the GOT (that's why > we use it). If this assumption fails, crazy things happen, as we've seen > with platforms other than x86 for our -Bsymbolic usage. > > Summary: this is where the theory of the C++ Standard and reality do not > agree. When you take the ABIs into consideration, the C++ Standard's > definition of ODR is just wishful thinking. > > In time: C++17 Modules do not solve this issue. Modules replace some use of > headers and #include; they have nothing to do with DLLs and symbol > exporting/ importing. > > Glossary: > * ELF: Executable and Linkable Format, the file format for all object > files, libraries, executables and core dumps on modern Unix systems, first > deployed by Sun on Solaris. > * PE-COFF: Portable Executable COFF, Microsoft's variant of the COFF object > file format, used for DLLs and executables (not for .obj files, that's > OMF). * GOT: Global Offset Table, a technique used to achieve position- > independence. Whenever a symbol "foo" is referenced, instead of writing its > address into the code, the compiler generates an indirect load of the > symbol's address from a fixed location in the GOT, which the dynamic linker > will write to once it has finished loading all modules and can resolve all > symbols. This can be used to make the code read-only and shareable. See > also PLT and the GOT pointer (which is the value that the PIC register > carries). -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From thiago.macieira at intel.com Wed Mar 2 22:43:39 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 13:43:39 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <3708001.aDn73GA3AX@agathebauer> References: <2982314.9xyceZ9k2C@tjmaciei-mobl4> <3708001.aDn73GA3AX@agathebauer> Message-ID: <3025590.DxT4xyZKo2@tjmaciei-mobl4> On quarta-feira, 2 de março de 2016 22:34:16 PST Milian Wolff wrote: > On Mittwoch, 2. März 2016 12:59:30 CET Thiago Macieira wrote: > > On quarta-feira, 2 de março de 2016 20:59:41 PST Milian Wolff wrote: > > > Hey Thiago, > > > > > > what is "the runtime merging problem on Windows"? > > > > Ever heard of the dynamic_cast problem on Windows? It's the same. > > Great, thanks a lot for this insightful write-up! > > So, do you -2 a templated QObject then for these reasons? I'm not against the principle. I am against the implementation details, as Olivier's current commit has. In the course of this thread, we came up with workable solutions I wouldn't object to. I don't like them, I find that they are limited and will bite people in the back, but they don't have fatal flaws. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Stefan.Walter at lisec.com Thu Mar 3 05:09:25 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Thu, 3 Mar 2016 04:09:25 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ Message-ID: Hi, I am trying to build Qt 5.6.0-rc on a machine that builds Qt 5.5.1 just fine. I am facing several compilation issues with 5.6.0-rc and will start with the first one here. g++ -pipe -O2 -std=c++0x -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DQT_BUILD_SERIALBUS_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_NETWORK_LIB -DQT_SERIALPORT_LIB -DQT_CORE_LIB -I. -I../../include -I../../include/QtSerialBus -I../../include/QtSerialBus/5.6.0 -I../../include/QtSerialBus/5.6.0/QtSerialBus -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore/5.6.0 -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore/5.6.0/QtCore -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtNetwork -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtserialport/include -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtserialport/include/QtSerialPort -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore -I.moc -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/mkspecs/linux-g++ -x c++-header -c ../../include/QtSerialBus/QtSerialBusDepends -o .pch/Qt5SerialBus.gch/c++ g++ -c -include .pch/Qt5SerialBus -pipe -O2 -std=c++0x -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DQT_BUILD_SERIALBUS_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_NETWORK_LIB -DQT_SERIALPORT_LIB -DQT_CORE_LIB -I. -I../../include -I../../include/QtSerialBus -I../../include/QtSerialBus/5.6.0 -I../../include/QtSerialBus/5.6.0/QtSerialBus -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore/5.6.0 -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore/5.6.0/QtCore -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtNetwork -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtserialport/include -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtserialport/include/QtSerialPort -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore -I.moc -I/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/mkspecs/linux-g++ -o .obj/qcanbusdevice.o qcanbusdevice.cpp In file included from qcanbusdevice.cpp:37: qcanbusdevice.h:93: error: ISO C++ forbids initialization of member âframeIdâ qcanbusdevice.h:93: error: making âframeIdâ static qcanbusdevice.h:93: error: ISO C++ forbids in-class initialization of non-const static member âframeIdâ qcanbusdevice.h:94: error: ISO C++ forbids initialization of member âframeIdMaskâ qcanbusdevice.h:94: error: making âframeIdMaskâ static qcanbusdevice.h:94: error: ISO C++ forbids in-class initialization of non-const static member âframeIdMaskâ qcanbusdevice.h:95: error: ISO C++ forbids initialization of member âtypeâ qcanbusdevice.h:95: error: making âtypeâ static qcanbusdevice.h:95: error: ISO C++ forbids in-class initialization of non-const static member âtypeâ qcanbusdevice.h:96: error: ISO C++ forbids initialization of member âformatâ qcanbusdevice.h:96: error: making âformatâ static qcanbusdevice.h:96: error: ISO C++ forbids in-class initialization of non-const static member âformatâ make[3]: *** [.obj/qcanbusdevice.o] Error 1 make[3]: Leaving directory `/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtserialbus/src/serialbus' make[2]: *** [sub-serialbus-make_first] Error 2 make[2]: Leaving directory `/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtserialbus/src' make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory `/home/qt-build-user/qt-5.6/qt-5.6.0-rc/qt-source/qtserialbus' make: *** [module-qtserialbus-make_first] Error 2 Please advice what can I do to solve this? Regards, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Mar 3 06:40:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 21:40:45 -0800 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: References: Message-ID: <3109436.B1zXd9hWkc@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 04:09:25 PST Walter Stefan wrote: > qcanbusdevice.h:93: error: ISO C++ forbids initialization of member > âframeIdâ Context: struct Filter { enum FormatFilter { MatchBaseFormat = 0x0001, MatchExtendedFormat = 0x0002, MatchBaseAndExtendedFormat = 0x0003, }; Q_DECLARE_FLAGS(FormatFilters, FormatFilter) quint32 frameId = 0; quint32 frameIdMask = 0; QCanBusFrame::FrameType type = QCanBusFrame::InvalidFrame; FormatFilter format = MatchBaseAndExtendedFormat; }; This is using C++11 non-static member initialisation. That is not permitted in Qt 5.6 or 5.7[*]. b6ad22e5b43410cc01c9f59e1f4897cd270c635f should be reverted. I've created https://codereview.qt-project.org/151163 for it. When it gets approved, don't wait for me to stage it. [*] It might be permitted now, after we decided to drop VS2012 support, but we haven't yet re-done the list of allowed C++11 features in Qt 5.7. Until we do that, it's not allowed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Stefan.Walter at lisec.com Thu Mar 3 06:45:32 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Thu, 3 Mar 2016 05:45:32 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <3109436.B1zXd9hWkc@tjmaciei-mobl4> References: <3109436.B1zXd9hWkc@tjmaciei-mobl4> Message-ID: <0ab32c5ada2c48c7b8447b55a7f51df4@ATSE-MAIL4.lisec.internal> Dear Thiago, Thanks a lot. There are more compilation issues on CentOS 6.7 x86_64, shall I list them or what do you recommend? Regards, Stefan -----Original Message----- From: Development [mailto:development-bounces+stefan.walter=lisec.com at qt-project.org] On Behalf Of Thiago Macieira Sent: Donnerstag, 3. März 2016 09:41 To: development at qt-project.org Subject: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ On quinta-feira, 3 de março de 2016 04:09:25 PST Walter Stefan wrote: > qcanbusdevice.h:93: error: ISO C++ forbids initialization of member > âframeIdâ Context: struct Filter { enum FormatFilter { MatchBaseFormat = 0x0001, MatchExtendedFormat = 0x0002, MatchBaseAndExtendedFormat = 0x0003, }; Q_DECLARE_FLAGS(FormatFilters, FormatFilter) quint32 frameId = 0; quint32 frameIdMask = 0; QCanBusFrame::FrameType type = QCanBusFrame::InvalidFrame; FormatFilter format = MatchBaseAndExtendedFormat; }; This is using C++11 non-static member initialisation. That is not permitted in Qt 5.6 or 5.7[*]. b6ad22e5b43410cc01c9f59e1f4897cd270c635f should be reverted. I've created https://codereview.qt-project.org/151163 for it. When it gets approved, don't wait for me to stage it. [*] It might be permitted now, after we decided to drop VS2012 support, but we haven't yet re-done the list of allowed C++11 features in Qt 5.7. Until we do that, it's not allowed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Thu Mar 3 06:56:43 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 21:56:43 -0800 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <0ab32c5ada2c48c7b8447b55a7f51df4@ATSE-MAIL4.lisec.internal> References: <3109436.B1zXd9hWkc@tjmaciei-mobl4> <0ab32c5ada2c48c7b8447b55a7f51df4@ATSE-MAIL4.lisec.internal> Message-ID: <2227265.IvWIYyKyvX@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 05:45:32 PST Walter Stefan wrote: > Dear Thiago, > > Thanks a lot. > > There are more compilation issues on CentOS 6.7 x86_64, shall I list them or > what do you recommend? Usually, I'd ask for bug reports, one for each. But let's have them here... By the way, which GCC version is that? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at theqtcompany.com Thu Mar 3 07:17:53 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Thu, 3 Mar 2016 06:17:53 +0000 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <56D74CE8.2030508@familiesomers.nl> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <56C80E81.3040602@kdab.com> <15B8CB18-D3BC-41B2-B038-3501344ABD7A@theqtcompany.com>, <56D74CE8.2030508@familiesomers.nl> Message-ID: <6C7D8303-7F6A-43F9-8F4F-CDF5A84724BC@theqtcompany.com> > André Somers kirjoitti 2.3.2016 kello 22.28: > > > > Op 20/02/2016 om 08:38 schreef Petroules Jake: >> "Continue" with iOS 7? It's currently iOS 6 in both 5.7 and dev branches. However, I wholeheartedly approve bumping it to 7. >> >> This puts us at a minimum of "last four releases" (by the time 5.8 is released) for both OS X and iOS. However I'd argue that iOS's schedule should be treated a little more aggressively given its extremely fast upgrade cycle compared to all other platforms. >> >> As of February 8th, 2016, the iOS version distribution (as measured by Apple - https://developer.apple.com/support/app-store/) is as follows: >> - iOS 9 - 77% >> - iOS 8 - 17% >> - iOS 7 and earlier - 6% >> >> By the time Qt 5.8 is released, iOS 10 will have just been released and iOS 8's market share will almost certainly less than 5%, as iOS 7's is now. In that case is there really much point supporting iOS 7 (or even 8)? >> >> iOS 8 was one of the biggest releases API-wise and so we would be able to reduce effort significantly by dropping v7. The current version of Xcode also provides no simulators for iOS prior to 8.1. > > Hmm... That would be annoying. iOS 7 is the last version supported on the iPhone 4 (which I am still using). To me, it doesn't even feel that old. > Here is the list of devices that will be left behind for each version you bumb: http://www.everyi.com/by-capability/maximum-supported-ios-version-for-ipod-iphone-ipad.html > But how many really still use iPhone 4 still in 2017? Qt 5.8 is planned for October 2016. Anyway, I leave it for the platform maintainers to decide, if there are no issues in keeping also these older devices supported, we of course can consider it. Yours, Tuukka > André > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rpzrpzrpz at gmail.com Thu Mar 3 07:23:45 2016 From: rpzrpzrpz at gmail.com (rpzrpzrpz at gmail.com) Date: Thu, 3 Mar 2016 00:23:45 -0600 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <6C7D8303-7F6A-43F9-8F4F-CDF5A84724BC@theqtcompany.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <56C80E81.3040602@kdab.com> <15B8CB18-D3BC-41B2-B038-3501344ABD7A@theqtcompany.com> <56D74CE8.2030508@familiesomers.nl> <6C7D8303-7F6A-43F9-8F4F-CDF5A84724BC@theqtcompany.com> Message-ID: <56D7D871.503@gmail.com> With all the talk about support on 5.7 and 5.8, is 5.6 going to support debugging under IOS 9.2 Simulator? 5.6 releases tomorrow, Qt Creator Bug 15705 not fixed. Has anybody debugged Qt 5.6 under IOS 9.x Simulator recently? md On 3/3/2016 12:17 AM, Turunen Tuukka wrote: > >> André Somers kirjoitti 2.3.2016 kello 22.28: >> >> >> >> Op 20/02/2016 om 08:38 schreef Petroules Jake: >>> "Continue" with iOS 7? It's currently iOS 6 in both 5.7 and dev branches. However, I wholeheartedly approve bumping it to 7. >>> >>> This puts us at a minimum of "last four releases" (by the time 5.8 is released) for both OS X and iOS. However I'd argue that iOS's schedule should be treated a little more aggressively given its extremely fast upgrade cycle compared to all other platforms. >>> >>> As of February 8th, 2016, the iOS version distribution (as measured by Apple - https://developer.apple.com/support/app-store/) is as follows: >>> - iOS 9 - 77% >>> - iOS 8 - 17% >>> - iOS 7 and earlier - 6% >>> >>> By the time Qt 5.8 is released, iOS 10 will have just been released and iOS 8's market share will almost certainly less than 5%, as iOS 7's is now. In that case is there really much point supporting iOS 7 (or even 8)? >>> >>> iOS 8 was one of the biggest releases API-wise and so we would be able to reduce effort significantly by dropping v7. The current version of Xcode also provides no simulators for iOS prior to 8.1. >> Hmm... That would be annoying. iOS 7 is the last version supported on the iPhone 4 (which I am still using). To me, it doesn't even feel that old. >> Here is the list of devices that will be left behind for each version you bumb: http://www.everyi.com/by-capability/maximum-supported-ios-version-for-ipod-iphone-ipad.html >> > But how many really still use iPhone 4 still in 2017? Qt 5.8 is planned for October 2016. > > Anyway, I leave it for the platform maintainers to decide, if there are no issues in keeping also these older devices supported, we of course can consider it. > > Yours, > > Tuukka > > >> André >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From thiago.macieira at intel.com Thu Mar 3 07:26:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 22:26:45 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <56D7D871.503@gmail.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <6C7D8303-7F6A-43F9-8F4F-CDF5A84724BC@theqtcompany.com> <56D7D871.503@gmail.com> Message-ID: <2142342.OK9BUUGKzn@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 00:23:45 PST rpzrpzrpz at gmail.com wrote: > 5.6 releases tomorrow No, it doesn't. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rpzrpzrpz at gmail.com Thu Mar 3 07:36:34 2016 From: rpzrpzrpz at gmail.com (rpzrpzrpz at gmail.com) Date: Thu, 3 Mar 2016 00:36:34 -0600 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <2142342.OK9BUUGKzn@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <6C7D8303-7F6A-43F9-8F4F-CDF5A84724BC@theqtcompany.com> <56D7D871.503@gmail.com> <2142342.OK9BUUGKzn@tjmaciei-mobl4> Message-ID: <56D7DB72.70003@gmail.com> On 3/3/2016 12:26 AM, Thiago Macieira wrote: > On quinta-feira, 3 de março de 2016 00:23:45 PST rpzrpzrpz at gmail.com wrote: >> 5.6 releases tomorrow > No, it doesn't. > http://wiki.qt.io/Qt-5.6-release From thiago.macieira at intel.com Thu Mar 3 07:51:10 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 22:51:10 -0800 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <56D7DB72.70003@gmail.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <2142342.OK9BUUGKzn@tjmaciei-mobl4> <56D7DB72.70003@gmail.com> Message-ID: <2052071.xpf799mmQb@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 00:36:34 PST rpzrpzrpz at gmail.com wrote: > On 3/3/2016 12:26 AM, Thiago Macieira wrote: > > On quinta-feira, 3 de março de 2016 00:23:45 PST rpzrpzrpz at gmail.com wrote: > >> 5.6 releases tomorrow > > > > No, it doesn't. > > http://wiki.qt.io/Qt-5.6-release It's stale. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 3 07:59:15 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 22:59:15 -0800 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 Message-ID: <20816981.PMDPkoXTW7@tjmaciei-mobl4> The code was written for C++11 only and there isn't enough time to fix the build issues. Therefore, it needs Qt 5.7. I request that it be dropped from Qt 5.6 packages. See: https://codereview.qt-project.org/151163 https://codereview.qt-project.org/151168 Unfixed errors: qmodbuspdu.h:163:9: warning: identifier ‘static_assert’ is a keyword in C++11 [-Wc++0x-compat] qmodbusdataunit.h:57:25: warning: defaulted and deleted functions only available with -std=c++11 or -std=gnu++11 qmodbusdataunit.h:46:7: error: constructor required before non-static data member for ‘QModbusDataUnit::m_type’ has been parsed qmodbusdataunit.h:60:37: warning: delegating constructors only available with -std=c++11 or -std=gnu++11 => delegating constructors are not permitted even with Qt 5.7 qmodbuspdu.h:87:20: warning: defaulted and deleted functions only available with -std=c++11 or -std=gnu++11 qmodbuspdu.h:119:24: warning: variadic templates only available with -std=c+ +11 or -std=gnu++11 qmodbuspdu.h:159:24: error: ‘is_same’ is not a member of ‘std’ qmodbuspdu.h:168:23: error: ‘is_pod’ is not a member of ‘std’ => need to check if those allowed in Qt 5.7 After this, the parser gets lost. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at theqtcompany.com Thu Mar 3 08:05:10 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Thu, 3 Mar 2016 07:05:10 +0000 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <20816981.PMDPkoXTW7@tjmaciei-mobl4> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> Message-ID: Hi, QtSerialBus is a technology preview in 5.6 and so on this shouldn't matter that much, right? This "limitation" should be acceptable for TPs and so on adding this in known issues page (https://wiki.qt.io/Qt_5.6.0_Known_Issues) should be enough? Br, Jani >>-----Original Message----- >>From: Development [mailto:development- >>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>Thiago Macieira >>Sent: 3. maaliskuuta 2016 8:59 >>To: development at qt-project.org >>Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in >>C++98 >> >>The code was written for C++11 only and there isn't enough time to fix the >>build issues. Therefore, it needs Qt 5.7. >> >>I request that it be dropped from Qt 5.6 packages. >> >>See: >> >>https://codereview.qt-project.org/151163 >>https://codereview.qt-project.org/151168 >> >>Unfixed errors: >>qmodbuspdu.h:163:9: warning: identifier ‘static_assert’ is a keyword in C++11 >>[-Wc++0x-compat] >> >>qmodbusdataunit.h:57:25: warning: defaulted and deleted functions only >>available with -std=c++11 or -std=gnu++11 >> >>qmodbusdataunit.h:46:7: error: constructor required before non-static data >>member for ‘QModbusDataUnit::m_type’ has been parsed >> >>qmodbusdataunit.h:60:37: warning: delegating constructors only available with >>-std=c++11 or -std=gnu++11 >> => delegating constructors are not permitted even with Qt 5.7 >> >>qmodbuspdu.h:87:20: warning: defaulted and deleted functions only available >>with -std=c++11 or -std=gnu++11 >> >>qmodbuspdu.h:119:24: warning: variadic templates only available with -std=c+ >>+11 or -std=gnu++11 >> >>qmodbuspdu.h:159:24: error: ‘is_same’ is not a member of ‘std’ >>qmodbuspdu.h:168:23: error: ‘is_pod’ is not a member of ‘std’ >> => need to check if those allowed in Qt 5.7 >> >>After this, the parser gets lost. >> >>-- >>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 olivier at woboq.com Thu Mar 3 08:24:23 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 03 Mar 2016 08:24:23 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <3025590.DxT4xyZKo2@tjmaciei-mobl4> References: <3708001.aDn73GA3AX@agathebauer> <3025590.DxT4xyZKo2@tjmaciei-mobl4> Message-ID: <7753306.oD3i0CX6v8@finn> Am Mittwoch, 2. März 2016, 13:43:39 CET schrieb Thiago Macieira: > On quarta-feira, 2 de março de 2016 22:34:16 PST Milian Wolff wrote: > > On Mittwoch, 2. März 2016 12:59:30 CET Thiago Macieira wrote: > > > On quarta-feira, 2 de março de 2016 20:59:41 PST Milian Wolff wrote: > > > > Hey Thiago, > > > > > > > > what is "the runtime merging problem on Windows"? > > > > > > Ever heard of the dynamic_cast problem on Windows? It's the same. > > > > Great, thanks a lot for this insightful write-up! > > > > So, do you -2 a templated QObject then for these reasons? > > I'm not against the principle. I am against the implementation details, as > Olivier's current commit has. This commit was a starting point. Of course there are implementation details to address. However, I took your -2 as a "Don't even bother working on it". > In the course of this thread, we came up with workable solutions I wouldn't > object to. I don't like them, I find that they are limited and will bite > people in the back, but they don't have fatal flaws. As soon as the limitations are known and documented, it is fine. The current approach also has plenty of limitations. We are just removing some limitations. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Thu Mar 3 08:31:28 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 23:31:28 -0800 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> Message-ID: <2671342.ZslJYdW2iM@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 07:05:10 PST Heikkinen Jani wrote: > Hi, > > QtSerialBus is a technology preview in 5.6 and so on this shouldn't matter > that much, right? This "limitation" should be acceptable for TPs and so on > adding this in known issues page (https://wiki.qt.io/Qt_5.6.0_Known_Issues) > should be enough? It matters because it breaks the build. Please remove it from the build. It's ok for it to be present, but don't compile it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 3 08:33:02 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 23:33:02 -0800 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <7753306.oD3i0CX6v8@finn> References: <3025590.DxT4xyZKo2@tjmaciei-mobl4> <7753306.oD3i0CX6v8@finn> Message-ID: <1948109.M5M3K3m0Bm@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 08:24:23 PST Olivier Goffart wrote: > > I'm not against the principle. I am against the implementation details, as > > Olivier's current commit has. > > This commit was a starting point. Of course there are implementation details > to address. > However, I took your -2 as a "Don't even bother working on it". I thought I was clear that the -2 was because we needed to have a mailing list discussion. Which we've now had. > > In the course of this thread, we came up with workable solutions I > > wouldn't > > object to. I don't like them, I find that they are limited and will bite > > people in the back, but they don't have fatal flaws. > > As soon as the limitations are known and documented, it is fine. > The current approach also has plenty of limitations. We are just removing > some limitations. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Stefan.Walter at lisec.com Thu Mar 3 08:50:26 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Thu, 3 Mar 2016 07:50:26 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <2227265.IvWIYyKyvX@tjmaciei-mobl4> References: <3109436.B1zXd9hWkc@tjmaciei-mobl4> <0ab32c5ada2c48c7b8447b55a7f51df4@ATSE-MAIL4.lisec.internal> <2227265.IvWIYyKyvX@tjmaciei-mobl4> Message-ID: <4116a3087b3549f6b05a3f2940979156@ATSE-MAIL4.lisec.internal> Dear Thiago, Thank you very much. I will start to skip now qt modules with the -skip configure flag to get from one error to the next one. Therefore I can't tell you, if there would be more errors within the same module. If you guide me how could I use your fixed sources, then I could continue testing after your fixes. This is my compiler used: g++ (GCC) 4.4.7 20120313 (Red Hat 4.4.7-16) Copyright (C) 2010 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. This is my CentOS used: CentOS release 6.7 (Final) Linux aedu2-build-qt 2.6.32-573.18.1.el6.x86_64 #1 SMP Tue Feb 9 22:46:17 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux I get this error after skipping module qtserialbus: g++ -c -include .pch/Qt53DRender -pipe -O2 -std=c++0x -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DQT3DRENDER_LIBRARY -DQT_BUILD_3DRENDER_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_3DCORE_LIB -DQT_OPENGLEXTENSIONS_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -I. -I../../include -I../../include/Qt3DRender -I../../include/Qt3DRender/5.6.0 -I../../include/Qt3DRender/5.6.0/Qt3DRender -Ibackend -Igeometry -Igraphicshelpers -Iframegraph -Ifrontend -Ijobs -Ilights -Imaterialsystem -Irenderstates -Iio -Idefaults -Ipicking -Iraycasting -Iservices -Itexture -I../../include/Qt3DCore/5.6.0 -I../../include/Qt3DCore/5.6.0/Qt3DCore -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtGui/5.6.0 -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtGui/5.6.0/QtGui -I../../include/Qt3DCore -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtOpenGLExtensions -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtGui -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore/5.6.0 -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore/5.6.0/QtCore -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtConcurrent -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore -I.moc -isystem /usr/include/libdrm -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/mkspecs/linux-g++ -o .obj/scenemanager.o io/scenemanager.cpp io/scenemanager.cpp: In constructor âQt3DRender::Render::SceneManager::SceneManager()â: io/scenemanager.cpp:44: error: class âQt3DRender::Render::SceneManagerâ does not have any field named âQResourceManagerâ io/scenemanager.cpp:44: error: expected â(â before â<â token io/scenemanager.cpp:44: error: expected â{â before â<â token io/scenemanager.cpp: At global scope: io/scenemanager.cpp:44: error: expected unqualified-id before â<â token make[3]: *** [.obj/scenemanager.o] Error 1 make[3]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qt3d/src/render' make[2]: *** [sub-render-make_first] Error 2 make[2]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qt3d/src' make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qt3d' make: *** [module-qt3d-make_first] Error 2 I get this error after skipping module qt3d: g++ -c -pipe -O2 -std=gnu++0x -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_NFC_LIB -DQT_CORE_LIB -I. -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtWidgets -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtGui -I../../../include -I../../../include/QtNfc -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore -I.moc -isystem /usr/include/libdrm -I.uic -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/mkspecs/linux-g++ -o .obj/moc_annotatedurl.o .moc/moc_annotatedurl.cpp g++ -Wl,-O1 -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\$ORIGIN/../../../lib -o annotatedurl .obj/main.o .obj/mainwindow.o .obj/annotatedurl.o .obj/moc_mainwindow.o .obj/moc_annotatedurl.o -L/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/lib -lQt5Widgets -lQt5Gui -L/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib -lQt5Nfc -lQt5Core -lGL -lpthread /usr/bin/ld: warning: libQt5DBus.so.5, needed by /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so, not found (try using -rpath or -rpath-link) /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `operator<<(QDebug, QDBusError const&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusAbstractInterface::disconnectNotify(QMetaMethod const&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusAbstractInterface::staticMetaObject at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::beginMap() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::beginMapEntry() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::operator<<(QDBusObjectPath const&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusConnection::systemBus()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusAbstractInterface::asyncCallWithArgumentList(QString const&, QList const&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::beginMap(int, int)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::endMapEntry()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::endMap() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusPendingCall::error() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusAbstractInterface::connectNotify(QMetaMethod const&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusPendingCall::~QDBusPendingCall()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `typeinfo for QDBusAbstractInterface at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusPendingCall::waitForFinished()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusAbstractInterface::qt_metacall(QMetaObject::Call, int, void**)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusPendingReplyData::setMetaTypes(int, int const*)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::operator<<(QString const&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::QDBusArgument(QDBusArgument const&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::~QDBusArgument()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::operator>>(QDBusVariant&) const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusAbstractInterface::qt_metacast(char const*)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::QDBusArgument()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::operator<<(QDBusVariant const&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusPendingReplyData::argumentAt(int) const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `operator>>(QDBusArgument const&, QVariant&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusPendingReplyData::QDBusPendingReplyData()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::operator>>(QDBusObjectPath&) const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::beginMapEntry()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusAbstractInterface::QDBusAbstractInterface(QString const&, QString const&, char const*, QDBusConnection const&, QObject*)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusAbstractInterface::~QDBusAbstractInterface()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::endMap()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusPendingReplyData::~QDBusPendingReplyData()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::atEnd() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusPendingCall::isError() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusConnection::~QDBusConnection()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusPendingReplyData::assign(QDBusPendingCall const&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusMetaType::registerMarshallOperators(int, void (*)(QDBusArgument&, void const*), void (*)(QDBusArgument const&, void*))@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::endMapEntry() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusArgument::operator>>(QString&) const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so: undefined reference to `QDBusAbstractInterface::isValid() const at Qt_5' collect2: ld returned 1 exit status make[4]: *** [annotatedurl] Error 1 make[4]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/examples/nfc/annotatedurl' make[3]: *** [sub-annotatedurl-make_first] Error 2 make[3]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/examples/nfc' make[2]: *** [sub-nfc-make_first] Error 2 make[2]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/examples' make[1]: *** [sub-examples-make_first] Error 2 make[1]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity' make: *** [module-qtconnectivity-make_first] Error 2 I get this error after skipping module qtconnectivity: g++ -c -pipe -O2 -std=gnu++0x -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_WEBSOCKETS_LIB -DQT_NETWORK_LIB -DQT_WEBCHANNEL_LIB -DQT_CORE_LIB -I. -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebsockets/include -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebsockets/include/QtWebSockets -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtNetwork -I../../../include -I../../../include/QtWebChannel -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/include/QtCore -I.moc -I/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/mkspecs/linux-g++ -o .obj/moc_websockettransport.o .moc/moc_websockettransport.cpp g++ -Wl,-O1 -Wl,--enable-new-dtags -Wl,-rpath,/home/walteste/qt-5.6/qt-5.6.0-rc/qt-install/lib -o chatserver .obj/main.o .obj/chatserver.o .obj/websocketclientwrapper.o .obj/websockettransport.o .obj/moc_chatserver.o .obj/moc_websocketclientwrapper.o .obj/moc_websockettransport.o -L/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebsockets/lib -lQt5WebSockets -L/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/lib -lQt5Network -L/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/lib -lQt5WebChannel -lQt5Core -lpthread /usr/bin/ld: warning: libQt5Qml.so.5, needed by /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/lib/libQt5WebChannel.so, not found (try using -rpath or -rpath-link) /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/lib/libQt5WebChannel.so: undefined reference to `QJSValue::QJSValue(QJSValue::SpecialValue)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/lib/libQt5WebChannel.so: undefined reference to `QJSValue::toVariant() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/lib/libQt5WebChannel.so: undefined reference to `QJSValue::QJSValue(QJSValue const&)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/lib/libQt5WebChannel.so: undefined reference to `QtQml::qmlAttachedPropertiesObject(int*, QObject const*, QMetaObject const*, bool)@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/lib/libQt5WebChannel.so: undefined reference to `QQmlContext::nameForObject(QObject*) const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/lib/libQt5WebChannel.so: undefined reference to `QJSValue::~QJSValue()@Qt_5' /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/lib/libQt5WebChannel.so: undefined reference to `QtQml::qmlContext(QObject const*)@Qt_5' collect2: ld returned 1 exit status make[4]: *** [chatserver] Error 1 make[4]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/examples/webchannel/chatserver-cpp' make[3]: *** [sub-chatserver-cpp-make_first] Error 2 make[3]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/examples/webchannel' make[2]: *** [sub-webchannel-make_first] Error 2 make[2]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel/examples' make[1]: *** [sub-examples-make_first] Error 2 make[1]: Leaving directory `/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtwebchannel' make: *** [module-qtwebchannel-make_first] Error 2 Best Regards, Stefan -----Original Message----- From: Development [mailto:development-bounces+stefan.walter=lisec.com at qt-project.org] On Behalf Of Thiago Macieira Sent: Donnerstag, 3. März 2016 09:57 To: development at qt-project.org Subject: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ On quinta-feira, 3 de março de 2016 05:45:32 PST Walter Stefan wrote: > Dear Thiago, > > Thanks a lot. > > There are more compilation issues on CentOS 6.7 x86_64, shall I list > them or what do you recommend? Usually, I'd ask for bug reports, one for each. But let's have them here... By the way, which GCC version is that? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at theqtcompany.com Thu Mar 3 08:50:51 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 3 Mar 2016 07:50:51 +0000 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <2671342.ZslJYdW2iM@tjmaciei-mobl4> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <2671342.ZslJYdW2iM@tjmaciei-mobl4> Message-ID: <63468B53-7C83-4C50-B4D2-4EE6268E29A8@theqtcompany.com> On 03/03/16 08:31, "Development on behalf of Thiago Macieira" wrote: >On quinta-feira, 3 de março de 2016 07:05:10 PST Heikkinen Jani wrote: >> Hi, >> >> QtSerialBus is a technology preview in 5.6 and so on this shouldn't matter >> that much, right? This "limitation" should be acceptable for TPs and so on >> adding this in known issues page (https://wiki.qt.io/Qt_5.6.0_Known_Issues) >> should be enough? > >It matters because it breaks the build. > >Please remove it from the build. It's ok for it to be present, but don't >compile it. Which build are you talking about? The split source packages shouldn't have a problem with this. For the unified source packages, we should probably simply skip the module if the compiler is not c++11 compliant. But I see no reason to remove it for compilers that can handle it. It's certainly not different from other modules such as web engine that also have stricter requirements on compilers or platforms than e.g. Qtbase. Cheers, Lars From thiago.macieira at intel.com Thu Mar 3 08:54:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 02 Mar 2016 23:54:14 -0800 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <63468B53-7C83-4C50-B4D2-4EE6268E29A8@theqtcompany.com> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <2671342.ZslJYdW2iM@tjmaciei-mobl4> <63468B53-7C83-4C50-B4D2-4EE6268E29A8@theqtcompany.com> Message-ID: <3505245.nkBub75YL8@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 07:50:51 PST Knoll Lars wrote: > >It matters because it breaks the build. > > > >Please remove it from the build. It's ok for it to be present, but don't > >compile it. > > > Which build are you talking about? The split source packages shouldn't have > a problem with this. The convenience build for the "qt-everywhere" tarball. > For the unified source packages, we should probably simply skip the module > if the compiler is not c++11 compliant. Please see Stefan Walter's email. He got failures while using -std=c++0x, so this trick won't work. > But I see no reason to remove it > for compilers that can handle it. It's certainly not different from other > modules such as web engine that also have stricter requirements on > compilers or platforms than e.g. Qtbase. So long as they don't break the build. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From roland.m.winklmeier at gmail.com Thu Mar 3 08:56:35 2016 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Thu, 3 Mar 2016 08:56:35 +0100 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? Message-ID: Dear list, I'm trying to understand a strange situation and hope you can enlighten me. In December I have raised QTBUG-49971 (a FTBFS bug) since it was not possible to build MinGW 4.9 with the alpha sources and also from git since then. The issue is obvious: Commit e19bedc8466a6b8086a0048b7b88c0f6d3fa822f introduced ''WINAPI_FAMILY_PC_APP" which is defined in the MSVC Windows API but not in MinGW 4.9. So the built with MinGW fails. So how is it possible that this error does not show up in CI? I did download the Qt MinGW 4.9 version, so CI should fail to build. Does anyone have an idea why it passes anyway? Cheers Roland -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at theqtcompany.com Thu Mar 3 08:59:04 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 3 Mar 2016 07:59:04 +0000 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <3505245.nkBub75YL8@tjmaciei-mobl4> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <2671342.ZslJYdW2iM@tjmaciei-mobl4> <63468B53-7C83-4C50-B4D2-4EE6268E29A8@theqtcompany.com> <3505245.nkBub75YL8@tjmaciei-mobl4> Message-ID: IMO https://codereview.qt-project.org/#/c/151180/1/qtserialbus.pro should fix it. Is there a bug report already that I can link to? Regards Kai > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Thiago Macieira > Sent: Thursday, March 03, 2016 8:54 AM > To: development at qt-project.org > Subject: Re: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't > compile in C++98 > > On quinta-feira, 3 de março de 2016 07:50:51 PST Knoll Lars wrote: > > >It matters because it breaks the build. > > > > > >Please remove it from the build. It's ok for it to be present, but > > >don't compile it. > > > > > > Which build are you talking about? The split source packages shouldn't > > have a problem with this. > > The convenience build for the "qt-everywhere" tarball. > > > For the unified source packages, we should probably simply skip the > > module if the compiler is not c++11 compliant. > > Please see Stefan Walter's email. He got failures while using -std=c++0x, so > this trick won't work. > > > But I see no reason to remove it > > for compilers that can handle it. It's certainly not different from > > other modules such as web engine that also have stricter requirements > > on compilers or platforms than e.g. Qtbase. > > So long as they don't break the build. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Thu Mar 3 09:00:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 00:00:40 -0800 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <4116a3087b3549f6b05a3f2940979156@ATSE-MAIL4.lisec.internal> References: <2227265.IvWIYyKyvX@tjmaciei-mobl4> <4116a3087b3549f6b05a3f2940979156@ATSE-MAIL4.lisec.internal> Message-ID: <3565189.exAmCz8Lvy@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 07:50:26 PST Walter Stefan wrote: > io/scenemanager.cpp:44: error: class âQt3DRender::Render::SceneManagerâ does > not have any field named âQResourceManagerâ https://codereview.qt-project.org/151171 > g++ -Wl,-O1 -Wl,--enable-new-dtags -Wl,-z,origin > -Wl,-rpath,\$ORIGIN/../../../lib -o annotatedurl .obj/main.o > .obj/mainwindow.o .obj/annotatedurl.o .obj/moc_mainwindow.o > .obj/moc_annotatedurl.o > -L/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/lib -lQt5Widgets > -lQt5Gui -L/home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib > -lQt5Nfc -lQt5Core -lGL -lpthread > > /usr/bin/ld: warning: libQt5DBus.so.5, needed by > /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib/libQt5Nfc.so > , not found (try using -rpath or -rpath-link) Is libQt5DBus.so.5 not in /home/walteste/qt-5.6/qt-5.6.0-rc/qt-source/qtbase/ lib? It should be there. There's something else wrong too because there should be no /home/walteste/ qt-5.6/qt-5.6.0-rc/qt-source/qtconnectivity/lib. This will probably clear when you do a clean rebuild. Ditto on the next error. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at theqtcompany.com Thu Mar 3 09:03:54 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 3 Mar 2016 08:03:54 +0000 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <3505245.nkBub75YL8@tjmaciei-mobl4> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <2671342.ZslJYdW2iM@tjmaciei-mobl4> <63468B53-7C83-4C50-B4D2-4EE6268E29A8@theqtcompany.com> <3505245.nkBub75YL8@tjmaciei-mobl4> Message-ID: On 03/03/16 08:54, "Development on behalf of Thiago Macieira" wrote: >On quinta-feira, 3 de março de 2016 07:50:51 PST Knoll Lars wrote: >> >It matters because it breaks the build. >> > >> >Please remove it from the build. It's ok for it to be present, but don't >> >compile it. >> >> >> Which build are you talking about? The split source packages shouldn't have >> a problem with this. > >The convenience build for the "qt-everywhere" tarball. > >> For the unified source packages, we should probably simply skip the module >> if the compiler is not c++11 compliant. > >Please see Stefan Walter's email. He got failures while using -std=c++0x, so >this trick won't work. I guess he's using gcc 4.4 or something similar. One solution could be to add a configure test and disable the module if it doesn't pass. > >> But I see no reason to remove it >> for compilers that can handle it. It's certainly not different from other >> modules such as web engine that also have stricter requirements on >> compilers or platforms than e.g. Qtbase. > >So long as they don't break the build. Agree, it shouldn't break the build. Cheers, Lars From Lars.Knoll at theqtcompany.com Thu Mar 3 09:05:41 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 3 Mar 2016 08:05:41 +0000 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <2671342.ZslJYdW2iM@tjmaciei-mobl4> <63468B53-7C83-4C50-B4D2-4EE6268E29A8@theqtcompany.com> <3505245.nkBub75YL8@tjmaciei-mobl4> Message-ID: <5CD9B6F8-F6C2-48F2-AE1D-1DD89BD9D072@theqtcompany.com> This looks good. Cheers, Lars On 03/03/16 08:59, "Development on behalf of Koehne Kai" wrote: >IMO > >https://codereview.qt-project.org/#/c/151180/1/qtserialbus.pro > >should fix it. Is there a bug report already that I can link to? > >Regards > >Kai > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of >> Thiago Macieira >> Sent: Thursday, March 03, 2016 8:54 AM >> To: development at qt-project.org >> Subject: Re: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't >> compile in C++98 >> >> On quinta-feira, 3 de março de 2016 07:50:51 PST Knoll Lars wrote: >> > >It matters because it breaks the build. >> > > >> > >Please remove it from the build. It's ok for it to be present, but >> > >don't compile it. >> > >> > >> > Which build are you talking about? The split source packages shouldn't >> > have a problem with this. >> >> The convenience build for the "qt-everywhere" tarball. >> >> > For the unified source packages, we should probably simply skip the >> > module if the compiler is not c++11 compliant. >> >> Please see Stefan Walter's email. He got failures while using -std=c++0x, so >> this trick won't work. >> >> > But I see no reason to remove it >> > for compilers that can handle it. It's certainly not different from >> > other modules such as web engine that also have stricter requirements >> > on compilers or platforms than e.g. Qtbase. >> >> So long as they don't break the build. >> >> -- >> 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 thiago.macieira at intel.com Thu Mar 3 09:06:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 00:06:41 -0800 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? In-Reply-To: References: Message-ID: <1607479.SZ4LZPosDG@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 08:56:35 PST Roland Winklmeier wrote: > So how is it possible that this error does not show up in CI? I did > download the Qt MinGW 4.9 version, so CI should fail to build. -Wundef is not enabled by either -Wall or -Wextra. It's entirely correct C source to #if on undefined tokens: they become zeroes. -Werror is never enabled to end-users either, so QTBUG-49971 is not a real FTBFS. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 3 09:12:29 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 00:12:29 -0800 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <5CD9B6F8-F6C2-48F2-AE1D-1DD89BD9D072@theqtcompany.com> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <5CD9B6F8-F6C2-48F2-AE1D-1DD89BD9D072@theqtcompany.com> Message-ID: <1588404.r8uEWk6RVc@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 08:05:41 PST Knoll Lars wrote: > This looks good. It's good, but not sufficient. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 3 09:14:20 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 00:14:20 -0800 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? In-Reply-To: <1607479.SZ4LZPosDG@tjmaciei-mobl4> References: <1607479.SZ4LZPosDG@tjmaciei-mobl4> Message-ID: <145773145.geWBlOxzao@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 00:06:41 PST Thiago Macieira wrote: > On quinta-feira, 3 de março de 2016 08:56:35 PST Roland Winklmeier wrote: > > So how is it possible that this error does not show up in CI? I did > > download the Qt MinGW 4.9 version, so CI should fail to build. > > -Wundef is not enabled by either -Wall or -Wextra. It's entirely correct C > source to #if on undefined tokens: they become zeroes. > > -Werror is never enabled to end-users either, so QTBUG-49971 is not a real > FTBFS. But -Wundef and -Werror are part of our headersclean target. So you have a point: how is the CI building this? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at theqtcompany.com Thu Mar 3 09:24:41 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 3 Mar 2016 08:24:41 +0000 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <1588404.r8uEWk6RVc@tjmaciei-mobl4> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <5CD9B6F8-F6C2-48F2-AE1D-1DD89BD9D072@theqtcompany.com> <1588404.r8uEWk6RVc@tjmaciei-mobl4> Message-ID: <268DEEF2-27ED-4BDD-913F-94153416722A@theqtcompany.com> On 03/03/16 09:12, "Development on behalf of Thiago Macieira" wrote: >On quinta-feira, 3 de março de 2016 08:05:41 PST Knoll Lars wrote: >> This looks good. > >It's good, but not sufficient. How is it not sufficient? Lars From olivier at woboq.com Thu Mar 3 09:35:03 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 03 Mar 2016 09:35:03 +0100 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <268DEEF2-27ED-4BDD-913F-94153416722A@theqtcompany.com> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <1588404.r8uEWk6RVc@tjmaciei-mobl4> <268DEEF2-27ED-4BDD-913F-94153416722A@theqtcompany.com> Message-ID: <2550552.paA18HyhLP@finn> Am Donnerstag, 3. März 2016, 08:24:41 CET schrieb Knoll Lars: > On 03/03/16 09:12, "Development on behalf of Thiago Macieira" > of thiago.macieira at intel.com> wrote: > > > > >On quinta-feira, 3 de março de 2016 08:05:41 PST Knoll Lars wrote: > > > >> This looks good. > > > > > >It's good, but not sufficient. Apparently it requires Non-static data member initializers which is only implemented in GCC 4.7. So I guess there need to be an explicit check for GCC 4.7 or more. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From Lars.Knoll at theqtcompany.com Thu Mar 3 09:48:12 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 3 Mar 2016 08:48:12 +0000 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <2550552.paA18HyhLP@finn> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <1588404.r8uEWk6RVc@tjmaciei-mobl4> <268DEEF2-27ED-4BDD-913F-94153416722A@theqtcompany.com> <2550552.paA18HyhLP@finn> Message-ID: <5FC5F012-8056-4022-B490-75822FC07737@theqtcompany.com> On 03/03/16 09:35, "Olivier Goffart" wrote: >Am Donnerstag, 3. März 2016, 08:24:41 CET schrieb Knoll Lars: >> On 03/03/16 09:12, "Development on behalf of Thiago Macieira" >> > of thiago.macieira at intel.com> wrote: > >> >> >> >> >On quinta-feira, 3 de março de 2016 08:05:41 PST Knoll Lars wrote: >> > >> >> This looks good. >> > >> > >> >It's good, but not sufficient. > >Apparently it requires Non-static data member initializers which is only >implemented in GCC 4.7. So I guess there need to be an explicit check for GCC >4.7 or more. And require(c++11) doesn't prevent things to be compiled for gcc 4.6? Cheers, Lars From andreas.holzammer at kdab.com Thu Mar 3 10:06:35 2016 From: andreas.holzammer at kdab.com (Andreas Holzammer) Date: Thu, 3 Mar 2016 10:06:35 +0100 Subject: [Development] Dropping VS 2012 in Qt 5.7 In-Reply-To: References: <8947616.A7UhMYDDIY@tjmaciei-mobl4> <9463E139-8671-4FBD-9C28-CC9C9ADE7275@theqtcompany.com> <6940019.VT1iTT2XCW@tjmaciei-mobl4> Message-ID: <56D7FE9B.5080506@kdab.com> Hi, as Maintainer of the Windows Embedded Compact Platforms it makes sense to look forward and agree with dropping the platform in favor to support new features. Also Microsoft seems to abandon this platform, so Qt needs todo the same for going forward. But we will still support 5.6 as LTS Version with WEC7 and WEC2013. I will have a look at those patches which went in 5.7. The OpenSSL patch seems to be no release blocker for 5.6.0 as well as the sqlite build problem can only be seen if -qt-sql-sqlite is getting passed to configure. If nothing is specified, it defaults to plugin and does not break the build. The rest I will have a look. Thank you Andy Am 01.03.2016 um 14:50 schrieb Gunnar Roth: > > Well so be it, goodbye Qt from wec2013 Users. > But who takes care that changes for wec2013 in 5.7 and dev are merged back to 5.6.x? > > I know at least of > > configure: Fix (Open)SSL detection on WinCE (Merged)[https://codereview.qt-project.org/122437] > https://codereview.qt-project.org/#/c/122437/ > > > Fixing the SQLite3 build for WEC2013 again. > https://codereview.qt-project.org/#/c/115571/5 > > > > > furthermore wec2013 x86 needs at least 2 patches to build. > 1. a problem with the fake OleInitialize and OleUninitialize in qtbase\src\plugins\platforms\windows\qplatformfunctions_wince.h, probably due to calling convention. > 2. bitscan intrinsic > --- a\qtbase\src\corelib\tools\qsimd_p.h > +++ b\qtbase\src\corelib\tools\qsimd_p.h > @@ -430,11 +430,17 @@ > #define qCpuHasFeature(feature) ((qCompilerCpuFeatures & (Q_UINT64_C(1) << CpuFeature ## feature)) \ > || (qCpuFeatures() & (Q_UINT64_C(1) << CpuFeature ## feature))) > > #ifdef Q_PROCESSOR_X86 > // Bit scan functions for x86 > -# if defined(Q_CC_MSVC) && !defined(Q_OS_WINCE) > +# if defined(Q_CC_MSVC) > +#if defined _WIN32_WCE && _WIN32_WCE < 0x800 > +extern "C" unsigned char _BitScanForward(unsigned long* Index, unsigned long Mask); > +extern "C" unsigned char _BitScanReverse(unsigned long* Index, unsigned long Mask); > +#pragma intrinsic(_BitScanForward) > +#pragma intrinsic(_BitScanReverse) > +#endif > // MSVC calls it _BitScanReverse and returns the carry flag, which we don't need > static __forceinline unsigned long _bit_scan_reverse(uint val) > { > unsigned long result; > _BitScanReverse(&result, val); > > > > > and all programs using native file dialogs simply crash, qmlscene.exe for example. > > --- a\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp > +++ b\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp > @@ -173,6 +173,10 @@ > > static inline unsigned parseOptions(const QStringList ¶mList, > int *tabletAbsoluteRange, > QtWindows::ProcessDpiAwareness *dpiAwareness) > { > +#if defined _WIN32_WCE && _WIN32_WCE >= 0x800 > + unsigned options = QWindowsIntegration::NoNativeDialogs; > +#else > unsigned options = 0; > +#endif > > > a problem with spdy protocol occurs for me: > diff -r -U 5 -N -x '*.orig' -x '*.rej' -x '*.bak' -x .git -x doc -x tests -x examples a\qtbase\src\network\access/qspdyprotocolhandler.cpp b\qtbase\src\network\access/qspdyprotocolhandler.cpp > --- a\qtbase\src\network\access/qspdyprotocolhandler.cpp > +++ b\qtbase\src\network\access/qspdyprotocolhandler.cpp > @@ -31,5 +31,6 @@ > ** $QT_END_LICENSE$ > ** > ****************************************************************************/ > > #include > +#undef ZLIB_H // this makes qfunctions_wince.h line 201 stuff not break the build for wince > > > and a fix to allow to use sse2 ( and opensll): > --- a\qtbase\tools\configure\configureapp.cpp > +++ b\qtbase\tools\configure\configureapp.cpp > @@ -1698,20 +1698,10 @@ > dictionary[ "STYLE_WINDOWSVISTA" ] = "no"; > dictionary[ "STYLE_FUSION" ] = "no"; > dictionary[ "STYLE_WINDOWSCE" ] = "yes"; > dictionary[ "STYLE_WINDOWSMOBILE" ] = "yes"; > dictionary[ "OPENGL" ] = "no"; > - dictionary[ "SSL" ] = "no"; > - dictionary[ "OPENSSL" ] = "no"; > - dictionary[ "RTTI" ] = "no"; > - dictionary[ "SSE2" ] = "no"; > - dictionary[ "SSE3" ] = "no"; > - dictionary[ "SSSE3" ] = "no"; > - dictionary[ "SSE4_1" ] = "no"; > - dictionary[ "SSE4_2" ] = "no"; > - dictionary[ "AVX" ] = "no"; > - dictionary[ "AVX2" ] = "no"; > dictionary[ "CE_CRT" ] = "yes"; > dictionary[ "LARGE_FILE" ] = "no"; > dictionary[ "ANGLE" ] = "no"; > dictionary[ "DYNAMICGL" ] = "no"; > if (dictionary[ "XQMAKESPEC" ].startsWith("wincewm")) { > > > > Regards, > Gunnar Roth > > > Gesendet: Dienstag, 01. März 2016 um 08:38 Uhr > Von: "Heikkinen Jani" > An: "Thiago Macieira" , "development at qt-project.org" > Betreff: Re: [Development] Dropping VS 2012 in Qt 5.7 > Done, please review > > Br, > Jani > >>> -----Original Message----- >>> From: Development [mailto:development- >>> bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>> Thiago Macieira >>> Sent: 29. helmikuuta 2016 18:41 >>> To: development at qt-project.org >>> Subject: Re: [Development] Dropping VS 2012 in Qt 5.7 >>> >>> On segunda-feira, 29 de fevereiro de 2016 13:08:18 PST Heikkinen Jani wrote: >>>> Hi! >>>> >>>> It seems we need a decision for this now to be able to proceed with >>>> https://codereview.qt-project.org/#/c/149325/[https://codereview.qt-project.org/#/c/149325/] >>> >>> Hi Jani >>> >>> We have so far not got any objections. Assume it's going to be the case and >>> add it to the changelog. >>> >>> -- >>> 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[http://lists.qt-project.org/mailman/listinfo/development] > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development] > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Andreas Holzammer | andreas.holzammer at kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4070 bytes Desc: S/MIME Cryptographic Signature URL: From Lars.Knoll at theqtcompany.com Thu Mar 3 10:22:23 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 3 Mar 2016 09:22:23 +0000 Subject: [Development] Dropping VS 2012 in Qt 5.7 In-Reply-To: <56D7FE9B.5080506@kdab.com> References: <8947616.A7UhMYDDIY@tjmaciei-mobl4> <9463E139-8671-4FBD-9C28-CC9C9ADE7275@theqtcompany.com> <6940019.VT1iTT2XCW@tjmaciei-mobl4> <56D7FE9B.5080506@kdab.com> Message-ID: <73F0928B-3516-424A-95CD-1F33C373355A@theqtcompany.com> On 03/03/16 10:06, "Development on behalf of Andreas Holzammer" wrote: >Hi, > >as Maintainer of the Windows Embedded Compact Platforms it makes sense >to look forward and agree with dropping the platform in favor to support >new features. Also Microsoft seems to abandon this platform, so Qt needs >todo the same for going forward. But we will still support 5.6 as LTS >Version with WEC7 and WEC2013. Great, thanks. With this I think we have full agreement to drop WEC2013 and VS2012 from 5.7. > >I will have a look at those patches which went in 5.7. Thanks. Feel free to back port whatever is required for WEC2013 from 5.7 back into 5.6. Cheers, Lars > >The OpenSSL patch seems to be no release blocker for 5.6.0 as well as >the sqlite build problem can only be seen if -qt-sql-sqlite is getting >passed to configure. If nothing is specified, it defaults to plugin and >does not break the build. > >The rest I will have a look. > >Thank you > >Andy > > >Am 01.03.2016 um 14:50 schrieb Gunnar Roth: >> >> Well so be it, goodbye Qt from wec2013 Users. >> But who takes care that changes for wec2013 in 5.7 and dev are merged back to 5.6.x? >> >> I know at least of >> >> configure: Fix (Open)SSL detection on WinCE (Merged)[https://codereview.qt-project.org/122437] >> https://codereview.qt-project.org/#/c/122437/ >> >> >> Fixing the SQLite3 build for WEC2013 again. >> https://codereview.qt-project.org/#/c/115571/5 >> >> >> >> >> furthermore wec2013 x86 needs at least 2 patches to build. >> 1. a problem with the fake OleInitialize and OleUninitialize in qtbase\src\plugins\platforms\windows\qplatformfunctions_wince.h, probably due to calling convention. >> 2. bitscan intrinsic >> --- a\qtbase\src\corelib\tools\qsimd_p.h >> +++ b\qtbase\src\corelib\tools\qsimd_p.h >> @@ -430,11 +430,17 @@ >> #define qCpuHasFeature(feature) ((qCompilerCpuFeatures & (Q_UINT64_C(1) << CpuFeature ## feature)) \ >> || (qCpuFeatures() & (Q_UINT64_C(1) << CpuFeature ## feature))) >> >> #ifdef Q_PROCESSOR_X86 >> // Bit scan functions for x86 >> -# if defined(Q_CC_MSVC) && !defined(Q_OS_WINCE) >> +# if defined(Q_CC_MSVC) >> +#if defined _WIN32_WCE && _WIN32_WCE < 0x800 >> +extern "C" unsigned char _BitScanForward(unsigned long* Index, unsigned long Mask); >> +extern "C" unsigned char _BitScanReverse(unsigned long* Index, unsigned long Mask); >> +#pragma intrinsic(_BitScanForward) >> +#pragma intrinsic(_BitScanReverse) >> +#endif >> // MSVC calls it _BitScanReverse and returns the carry flag, which we don't need >> static __forceinline unsigned long _bit_scan_reverse(uint val) >> { >> unsigned long result; >> _BitScanReverse(&result, val); >> >> >> >> >> and all programs using native file dialogs simply crash, qmlscene.exe for example. >> >> --- a\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp >> +++ b\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp >> @@ -173,6 +173,10 @@ >> >> static inline unsigned parseOptions(const QStringList ¶mList, >> int *tabletAbsoluteRange, >> QtWindows::ProcessDpiAwareness *dpiAwareness) >> { >> +#if defined _WIN32_WCE && _WIN32_WCE >= 0x800 >> + unsigned options = QWindowsIntegration::NoNativeDialogs; >> +#else >> unsigned options = 0; >> +#endif >> >> >> a problem with spdy protocol occurs for me: >> diff -r -U 5 -N -x '*.orig' -x '*.rej' -x '*.bak' -x .git -x doc -x tests -x examples a\qtbase\src\network\access/qspdyprotocolhandler.cpp b\qtbase\src\network\access/qspdyprotocolhandler.cpp >> --- a\qtbase\src\network\access/qspdyprotocolhandler.cpp >> +++ b\qtbase\src\network\access/qspdyprotocolhandler.cpp >> @@ -31,5 +31,6 @@ >> ** $QT_END_LICENSE$ >> ** >> ****************************************************************************/ >> >> #include >> +#undef ZLIB_H // this makes qfunctions_wince.h line 201 stuff not break the build for wince >> >> >> and a fix to allow to use sse2 ( and opensll): >> --- a\qtbase\tools\configure\configureapp.cpp >> +++ b\qtbase\tools\configure\configureapp.cpp >> @@ -1698,20 +1698,10 @@ >> dictionary[ "STYLE_WINDOWSVISTA" ] = "no"; >> dictionary[ "STYLE_FUSION" ] = "no"; >> dictionary[ "STYLE_WINDOWSCE" ] = "yes"; >> dictionary[ "STYLE_WINDOWSMOBILE" ] = "yes"; >> dictionary[ "OPENGL" ] = "no"; >> - dictionary[ "SSL" ] = "no"; >> - dictionary[ "OPENSSL" ] = "no"; >> - dictionary[ "RTTI" ] = "no"; >> - dictionary[ "SSE2" ] = "no"; >> - dictionary[ "SSE3" ] = "no"; >> - dictionary[ "SSSE3" ] = "no"; >> - dictionary[ "SSE4_1" ] = "no"; >> - dictionary[ "SSE4_2" ] = "no"; >> - dictionary[ "AVX" ] = "no"; >> - dictionary[ "AVX2" ] = "no"; >> dictionary[ "CE_CRT" ] = "yes"; >> dictionary[ "LARGE_FILE" ] = "no"; >> dictionary[ "ANGLE" ] = "no"; >> dictionary[ "DYNAMICGL" ] = "no"; >> if (dictionary[ "XQMAKESPEC" ].startsWith("wincewm")) { >> >> >> >> Regards, >> Gunnar Roth >> >> >> Gesendet: Dienstag, 01. März 2016 um 08:38 Uhr >> Von: "Heikkinen Jani" >> An: "Thiago Macieira" , "development at qt-project.org" >> Betreff: Re: [Development] Dropping VS 2012 in Qt 5.7 >> Done, please review >> >> Br, >> Jani >> >>>> -----Original Message----- >>>> From: Development [mailto:development- >>>> bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>>> Thiago Macieira >>>> Sent: 29. helmikuuta 2016 18:41 >>>> To: development at qt-project.org >>>> Subject: Re: [Development] Dropping VS 2012 in Qt 5.7 >>>> >>>> On segunda-feira, 29 de fevereiro de 2016 13:08:18 PST Heikkinen Jani wrote: >>>>> Hi! >>>>> >>>>> It seems we need a decision for this now to be able to proceed with >>>>> https://codereview.qt-project.org/#/c/149325/[https://codereview.qt-project.org/#/c/149325/] >>>> >>>> Hi Jani >>>> >>>> We have so far not got any objections. Assume it's going to be the case and >>>> add it to the changelog. >>>> >>>> -- >>>> 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[http://lists.qt-project.org/mailman/listinfo/development] >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development] >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > >-- >Andreas Holzammer | andreas.holzammer at kdab.com | Senior Software Engineer >KDAB (Deutschland) GmbH&Co KG, a KDAB Group company >Tel: +49-30-521325470 >KDAB - The Qt Experts > From mitch.curtis at theqtcompany.com Thu Mar 3 10:25:06 2016 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Thu, 3 Mar 2016 09:25:06 +0000 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? In-Reply-To: <1607479.SZ4LZPosDG@tjmaciei-mobl4> References: <1607479.SZ4LZPosDG@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+mitch.curtis=theqtcompany.com at qt-project.org] On Behalf Of Thiago > Macieira > Sent: Thursday, 3 March 2016 9:07 AM > To: development at qt-project.org > Subject: Re: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG- > 49971 open? > > On quinta-feira, 3 de março de 2016 08:56:35 PST Roland Winklmeier wrote: > > So how is it possible that this error does not show up in CI? I did > > download the Qt MinGW 4.9 version, so CI should fail to build. > > -Wundef is not enabled by either -Wall or -Wextra. It's entirely correct C > source to #if on undefined tokens: they become zeroes. > > -Werror is never enabled to end-users either, so QTBUG-49971 is not a real > FTBFS. Ferocious Triceratops Baring Fearsome Strength? Phew. I thought we'd gotten rid of all of those! > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at theqtcompany.com Thu Mar 3 10:31:33 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 3 Mar 2016 09:31:33 +0000 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? In-Reply-To: References: <1607479.SZ4LZPosDG@tjmaciei-mobl4> Message-ID: <178C4D98-A9FF-4962-8A8C-0AAF5245F585@theqtcompany.com> On 03/03/16 10:25, "Development on behalf of Curtis Mitch" wrote: > > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+mitch.curtis=theqtcompany.com at qt-project.org] On Behalf Of Thiago >> Macieira >> Sent: Thursday, 3 March 2016 9:07 AM >> To: development at qt-project.org >> Subject: Re: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG- >> 49971 open? >> >> On quinta-feira, 3 de março de 2016 08:56:35 PST Roland Winklmeier wrote: >> > So how is it possible that this error does not show up in CI? I did >> > download the Qt MinGW 4.9 version, so CI should fail to build. >> >> -Wundef is not enabled by either -Wall or -Wextra. It's entirely correct C >> source to #if on undefined tokens: they become zeroes. >> >> -Werror is never enabled to end-users either, so QTBUG-49971 is not a real >> FTBFS. > >Ferocious Triceratops Baring Fearsome Strength? Phew. I thought we'd gotten rid of all of those! Took me two minutes to parse that one as well. Failure to build from source. Cheers, Lars From roland.m.winklmeier at gmail.com Thu Mar 3 10:51:40 2016 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Thu, 3 Mar 2016 10:51:40 +0100 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? In-Reply-To: <145773145.geWBlOxzao@tjmaciei-mobl4> References: <1607479.SZ4LZPosDG@tjmaciei-mobl4> <145773145.geWBlOxzao@tjmaciei-mobl4> Message-ID: 2016-03-03 9:14 GMT+01:00 Thiago Macieira : > On quinta-feira, 3 de março de 2016 00:06:41 PST Thiago Macieira wrote: > > On quinta-feira, 3 de março de 2016 08:56:35 PST Roland Winklmeier wrote: > > > So how is it possible that this error does not show up in CI? I did > > > download the Qt MinGW 4.9 version, so CI should fail to build. > > > > -Wundef is not enabled by either -Wall or -Wextra. It's entirely correct > C > > source to #if on undefined tokens: they become zeroes. > > > > -Werror is never enabled to end-users either, so QTBUG-49971 is not a > real > > FTBFS. > > But -Wundef and -Werror are part of our headersclean target. So you have a > point: how is the CI building this? > No matter if I download the source from download.qt.io or clone from git and run the normal build as configured in CI, I get the build error. I'm not changing any flags. So my and CI configuration should be exactly the same and either both pass or fail. But CI passes and the build of several people locally fail. I wonder how thats possible. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at theqtcompany.com Thu Mar 3 12:06:18 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 3 Mar 2016 11:06:18 +0000 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? In-Reply-To: References: <1607479.SZ4LZPosDG@tjmaciei-mobl4> <145773145.geWBlOxzao@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Roland Winklmeier > Sent: Thursday, March 03, 2016 10:52 AM > To: Thiago Macieira > Cc: development at qt-project.org > Subject: Re: [Development] How can Qt 5.6.0 MinGW pass in CI with > QTBUG-49971 open? > > 2016-03-03 9:14 GMT+01:00 Thiago Macieira >: > > > On quinta-feira, 3 de março de 2016 00:06:41 PST Thiago Macieira > wrote: > > On quinta-feira, 3 de março de 2016 08:56:35 PST Roland > Winklmeier wrote: > > > So how is it possible that this error does not show up in CI? I did > > > download the Qt MinGW 4.9 version, so CI should fail to build. > > > > -Wundef is not enabled by either -Wall or -Wextra. It's entirely > correct C > > source to #if on undefined tokens: they become zeroes. > > > > -Werror is never enabled to end-users either, so QTBUG-49971 is > not a real > > FTBFS. > > But -Wundef and -Werror are part of our headersclean target. So > you have a > point: how is the CI building this? > > > > No matter if I download the source from download.qt.io > or clone from git and run the normal build as > configured in CI, I get the build error. I'm not changing any flags. So my and > CI configuration should be exactly the same and either both pass or fail. But > CI passes and the build of several people locally fail. I wonder how thats > possible. What mingw toolchain do you use? AFAIK the CI uses https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.2/threads-posix/dwarf/i686-4.9.2-release-posix-dwarf-rt_v3-rev1.7z/download Regards Kai From dhaumann at kde.org Thu Mar 3 14:05:18 2016 From: dhaumann at kde.org (Dominik Haumann) Date: Thu, 3 Mar 2016 14:05:18 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <6809745.CJ549IbFAA@agathebauer> References: <1698764.6Goq3gLcPQ@tjmaciei-mobl4> <6809745.CJ549IbFAA@agathebauer> Message-ID: Hi Milian, On Thu, Feb 25, 2016 at 7:22 PM, Milian Wolff wrote: > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote: >> On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote: >> > This might be a burden for some of the Qt developers (Windows ones). >> > >> > But all the Qt users get a modern / flexible moc, see this thread: >> > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c90e >> >> I don't think we need a more flexible moc. What do we want to do that we >> can't do with the current one? >> >> Don't say "template QObjects". That has other reasons for being a bad idea, >> currently. > > Can you explain what those reasons are? I'd really love to write a generic > QAbstractTableModel implementation that operates using concepts. Currently > that would require type erasure and thus another set of virtual function > calls... > [...] > If we'd have templates QObjects, the above could easily be written. I bet > there are other valid use-cases. It's not directly related, but instead of templated QObjects you could also find worksarounds like this: template class Foo { public: // ... QObject * notificationObject(); private: QObject * m_notificationObject; }; In the constructor, you can create the m_notificationObject and even to connects etc. I once used this trick (in a non-templated version) to obtain value-semantics for a class that can still have signals and slots etc (be careful with assignment operator, though). Of course, you still might not have the metadata moc typically creates for you. So I'm not claiming this is a totally cool solution, but sometimes this workaround comes in very handy. Cheers, Dominik From milian.wolff at kdab.com Thu Mar 3 14:28:17 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 03 Mar 2016 14:28:17 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: References: <6809745.CJ549IbFAA@agathebauer> Message-ID: <5843019.lyC1tWNk21@milian-kdab2> On Thursday, March 3, 2016 2:05:18 PM CET Dominik Haumann wrote: > Hi Milian, > > On Thu, Feb 25, 2016 at 7:22 PM, Milian Wolff wrote: > > On Donnerstag, 25. Februar 2016 09:02:11 CET Thiago Macieira wrote: > >> On quinta-feira, 25 de fevereiro de 2016 17:33:52 PST Cristian Adam wrote: > >> > This might be a burden for some of the Qt developers (Windows ones). > >> > > >> > But all the Qt users get a modern / flexible moc, see this thread: > >> > https://www.reddit.com/r/cpp/comments/470ama/qt_moc_myths_debunked/d09c > >> > 90e > >> > >> I don't think we need a more flexible moc. What do we want to do that we > >> can't do with the current one? > >> > >> Don't say "template QObjects". That has other reasons for being a bad > >> idea, > >> currently. > > > > Can you explain what those reasons are? I'd really love to write a generic > > QAbstractTableModel implementation that operates using concepts. Currently > > that would require type erasure and thus another set of virtual function > > calls... > > [...] > > If we'd have templates QObjects, the above could easily be written. I bet > > there are other valid use-cases. > > It's not directly related, but instead of templated QObjects you > could also find worksarounds like this: > template > class Foo { > public: > // ... > QObject * notificationObject(); > private: > QObject * m_notificationObject; > }; > > In the constructor, you can create the m_notificationObject > and even to connects etc. > > I once used this trick (in a non-templated version) to obtain > value-semantics for a class that can still have signals and > slots etc (be careful with assignment operator, though). > Of course, you still might not have the metadata moc > typically creates for you. So I'm not claiming this is a > totally cool solution, but sometimes this workaround > comes in very handy. Note that this won't work for the use-case I have in mind, namely templated QAIM implementations for efficient, and correct, list and table models on QVector. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From Kai.Koehne at theqtcompany.com Thu Mar 3 14:50:44 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 3 Mar 2016 13:50:44 +0000 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? In-Reply-To: <145773145.geWBlOxzao@tjmaciei-mobl4> References: <1607479.SZ4LZPosDG@tjmaciei-mobl4> <145773145.geWBlOxzao@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Thiago Macieira > Sent: Thursday, March 03, 2016 9:14 AM > To: development at qt-project.org > Subject: Re: [Development] How can Qt 5.6.0 MinGW pass in CI with > QTBUG-49971 open? > > On quinta-feira, 3 de março de 2016 00:06:41 PST Thiago Macieira wrote: > > On quinta-feira, 3 de março de 2016 08:56:35 PST Roland Winklmeier > wrote: > > > So how is it possible that this error does not show up in CI? I did > > > download the Qt MinGW 4.9 version, so CI should fail to build. > > > > -Wundef is not enabled by either -Wall or -Wextra. It's entirely > > correct C source to #if on undefined tokens: they become zeroes. > > > > -Werror is never enabled to end-users either, so QTBUG-49971 is not a > > real FTBFS. > > But -Wundef and -Werror are part of our headersclean target. So you have a > point: how is the CI building this? Checking the CI, we don't have a -developer-build MinGW configuration right now. So the headersclean check isn't run. Regards Kai From md at rpzdesign.com Thu Mar 3 15:29:52 2016 From: md at rpzdesign.com (md at rpzdesign.com) Date: Thu, 3 Mar 2016 08:29:52 -0600 Subject: [Development] [Qt bugreports] (QTCREATORBUG-15705) Xcode 7.2 IOS 9.2 Simulator Debugging not possible In-Reply-To: References: Message-ID: <56D84A60.6070001@rpzdesign.com> Eike: Well, that is a bit of news, thank you for looking at this. Thank you for your effort in this regard. md On 3/3/2016 7:47 AM, Eike Ziller (via JIRA) wrote: > Message Title > Eike Ziller > > *commented* on Bug QTCREATORBUG-15705 > > > Re: Xcode 7.2 IOS 9.2 Simulator Debugging not possible > > > bq Session could not be started: The operation couldn’t be completed. > (FBSOpenApplicationErrorDomain error 1.)Run ended.Debugging has failed > > I cannot reproduce this error message. > > The current state with Xcode 7.2 and iOS 9.2 is that debugging C++ on > iOS from Qt Creator only works on device, and debugging QML only works > on simulator. > As a workaround please either debug C++ from Xcode, or on device (and > QML on simulator). > Unfortunately Apple does not provide any official APIs for debugging, > so what Qt Creator does to try to pull it off is very fragile by nature. > > Add Comment > Add > Comment > > This message was sent by Atlassian JIRA (v6.3.9#6339-sha1:46fa261) > Atlassian logo > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1017 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 1084 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/png Size: 2983 bytes Desc: not available URL: From thiago.macieira at intel.com Thu Mar 3 16:51:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 07:51:47 -0800 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? In-Reply-To: References: <145773145.geWBlOxzao@tjmaciei-mobl4> Message-ID: <3220771.seeiKsZp9I@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 10:51:40 PST Roland Winklmeier wrote: > No matter if I download the source from download.qt.io or clone from git > and run the normal build as configured in CI, I get the build error. I'm > not changing any flags. So my and CI configuration should be exactly the > same and either both pass or fail. But CI passes and the build of several > people locally fail. I wonder how thats possible. Can you give us the command-line of the compilation that failed? Like I said, -Werror=undef is not supposed to be enabled by default, unless you turn headersclean on. And that's not the default. Note that -developer-build turns it on. But if you use that option, you say "I will fix bugs I find too". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 3 17:12:25 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 08:12:25 -0800 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <5FC5F012-8056-4022-B490-75822FC07737@theqtcompany.com> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <2550552.paA18HyhLP@finn> <5FC5F012-8056-4022-B490-75822FC07737@theqtcompany.com> Message-ID: <9123682.aXcI5DZ4cU@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 08:48:12 PST Knoll Lars wrote: > And require(c++11) doesn't prevent things to be compiled for gcc 4.6? Correct. Please add a test for each of the specific C++11 features, not for the compiler version. My email with the build errors lists them all, in addition to NSDMI. This will also replace the checks for VS2008-2012, since those compilers should then fail the test and the module gets disabled. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 3 17:25:28 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 08:25:28 -0800 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <9123682.aXcI5DZ4cU@tjmaciei-mobl4> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <5FC5F012-8056-4022-B490-75822FC07737@theqtcompany.com> <9123682.aXcI5DZ4cU@tjmaciei-mobl4> Message-ID: <2599027.huYhDFrUkO@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 08:12:25 PST Thiago Macieira wrote: > Please add a test for each of the specific C++11 features, not for the > compiler version. My email with the build errors lists them all, in > addition to NSDMI. To be clear: one config.test that happens to test each of the specific C++11 features used. Note that this may still disable the module in even in Qt 5.7, since things like delegating constructors are not yet permitted. I'd like the module to remove the tests and comply with Qt coding requirements before it leaves "tech preview" state. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Stefan.Walter at lisec.com Thu Mar 3 17:26:20 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Thu, 3 Mar 2016 16:26:20 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <3109436.B1zXd9hWkc@tjmaciei-mobl4> References: <3109436.B1zXd9hWkc@tjmaciei-mobl4> Message-ID: <9b04587cf7a6406cb0e8329d960f5900@ATSE-MAIL4.lisec.internal> Will there be another release candidate or how can I test the compilation with the already incorporated fixes since rc-1? Regards, Stefan -----Original Message----- From: Development [mailto:development-bounces+stefan.walter=lisec.com at qt-project.org] On Behalf Of Thiago Macieira Sent: Donnerstag, 3. März 2016 09:41 To: development at qt-project.org Subject: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ On quinta-feira, 3 de março de 2016 04:09:25 PST Walter Stefan wrote: > qcanbusdevice.h:93: error: ISO C++ forbids initialization of member > âframeIdâ Context: struct Filter { enum FormatFilter { MatchBaseFormat = 0x0001, MatchExtendedFormat = 0x0002, MatchBaseAndExtendedFormat = 0x0003, }; Q_DECLARE_FLAGS(FormatFilters, FormatFilter) quint32 frameId = 0; quint32 frameIdMask = 0; QCanBusFrame::FrameType type = QCanBusFrame::InvalidFrame; FormatFilter format = MatchBaseAndExtendedFormat; }; This is using C++11 non-static member initialisation. That is not permitted in Qt 5.6 or 5.7[*]. b6ad22e5b43410cc01c9f59e1f4897cd270c635f should be reverted. I've created https://codereview.qt-project.org/151163 for it. When it gets approved, don't wait for me to stage it. [*] It might be permitted now, after we decided to drop VS2012 support, but we haven't yet re-done the list of allowed C++11 features in Qt 5.7. Until we do that, it's not allowed. -- 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 roland.m.winklmeier at gmail.com Thu Mar 3 17:37:12 2016 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Thu, 3 Mar 2016 17:37:12 +0100 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? In-Reply-To: <3220771.seeiKsZp9I@tjmaciei-mobl4> References: <145773145.geWBlOxzao@tjmaciei-mobl4> <3220771.seeiKsZp9I@tjmaciei-mobl4> Message-ID: 2016-03-03 16:51 GMT+01:00 Thiago Macieira : > On quinta-feira, 3 de março de 2016 10:51:40 PST Roland Winklmeier wrote: > > No matter if I download the source from download.qt.io or clone from git > > and run the normal build as configured in CI, I get the build error. I'm > > not changing any flags. So my and CI configuration should be exactly the > > same and either both pass or fail. But CI passes and the build of several > > people locally fail. I wonder how thats possible. > > Can you give us the command-line of the compilation that failed? Like I > said, > -Werror=undef is not supposed to be enabled by default, unless you turn > headersclean on. And that's not the default. > > Note that -developer-build turns it on. But if you use that option, you > say "I > will fix bugs I find too". > I think that is the "mistake" I did. I'm pretty sure I tried the -developer-build. There is now a fix on the way and it was always easy to workaround the problem when building locally. I also understand why CI passed (no developer-build turned on) and everything makes sense now. I'm going to try once more with latest RC sources and then it should be good. Thanks everyone. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at theqtcompany.com Thu Mar 3 17:39:28 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Thu, 3 Mar 2016 16:39:28 +0000 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <2599027.huYhDFrUkO@tjmaciei-mobl4> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <5FC5F012-8056-4022-B490-75822FC07737@theqtcompany.com> <9123682.aXcI5DZ4cU@tjmaciei-mobl4> <2599027.huYhDFrUkO@tjmaciei-mobl4> Message-ID: -- Alex > On quinta-feira, 3 de março de 2016 08:12:25 PST Thiago Macieira wrote: > > Please add a test for each of the specific C++11 features, not for the > > compiler version. My email with the build errors lists them all, in > > addition to NSDMI. > > To be clear: one config.test that happens to test each of the specific C++11 > features used. Anything below gcc 4.7 is excluded now. I see little point in making such fine-grained test. IMO the result is not worth the effort. The module declares it requires C++11 and new modules do not necessarily have to comply with Qt base line requirements. That's why I see little point in making it anything worse than C++11 compliant. This is a conscious decision that accepts the exclusion of certain targets for the module. qtwebengine does the same thing already. > Note that this may still disable the module in even in Qt 5.7, since things > like delegating constructors are not yet permitted. I'd like the module to > remove the tests and comply with Qt coding requirements before it leaves "tech > preview" state. It is going to be TP in 5.6 and 5.7. There is simply not enough time between the two releases to evaluate the TP proposal. 5.8 will easily full the requirements. -- Alex From thiago.macieira at intel.com Thu Mar 3 17:42:02 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 08:42:02 -0800 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <9b04587cf7a6406cb0e8329d960f5900@ATSE-MAIL4.lisec.internal> References: <3109436.B1zXd9hWkc@tjmaciei-mobl4> <9b04587cf7a6406cb0e8329d960f5900@ATSE-MAIL4.lisec.internal> Message-ID: <10481168.tMfYUKVjTX@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 16:26:20 PST Walter Stefan wrote: > Will there be another release candidate or how can I test the compilation > with the already incorporated fixes since rc-1? The best would be to built the 5.6.0 branch from Git. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 3 17:47:27 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 08:47:27 -0800 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <2599027.huYhDFrUkO@tjmaciei-mobl4> Message-ID: <3781298.IVj7hYPjYB@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 16:39:28 PST Blasche Alexander wrote: > > On quinta-feira, 3 de março de 2016 08:12:25 PST Thiago Macieira wrote: > Anything below gcc 4.7 is excluded now. I see little point in making such > fine-grained test. IMO the result is not worth the effort. The module > declares it requires C++11 and new modules do not necessarily have to > comply with Qt base line requirements. That's why I see little point in > making it anything worse than C++11 compliant. This is a conscious decision > that accepts the exclusion of certain targets for the module. qtwebengine > does the same thing already. Because you also need to reject some older Clang versions. Did you add the check for them too? Please think of Clang on Linux and FreeBSD, plus the older XCode that we still support on OS X. This is LTS and the last version before we require C++11, so expect people will try to build it with older versions. Why do we insist on testing for something that proxies the real need? We need X and we know that Y provides X, so we test for Y. Why can't we just test for X? > > Note that this may still disable the module in even in Qt 5.7, since > > things > > like delegating constructors are not yet permitted. I'd like the module to > > remove the tests and comply with Qt coding requirements before it leaves > > "tech preview" state. > > It is going to be TP in 5.6 and 5.7. There is simply not enough time between > the two releases to evaluate the TP proposal. 5.8 will easily full the > requirements. Thanks. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From gunnar.roth at gmx.de Thu Mar 3 18:12:53 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Thu, 3 Mar 2016 18:12:53 +0100 Subject: [Development] Dropping VS 2012 in Qt 5.7 In-Reply-To: <56D7FE9B.5080506@kdab.com> References: <8947616.A7UhMYDDIY@tjmaciei-mobl4> <9463E139-8671-4FBD-9C28-CC9C9ADE7275@theqtcompany.com> <6940019.VT1iTT2XCW@tjmaciei-mobl4> , <56D7FE9B.5080506@kdab.com> Message-ID: Hello,   >The OpenSSL patch seems to be no release blocker for 5.6.0 as well as Well that patch is also non criticical, but if it only lands in 5.6.1 , that ok for me. >the sqlite build problem can only be seen if -qt-sql-sqlite is getting >passed to configure. If nothing is specified, it defaults to plugin and >does not break the build. My experience is different. It breaks the build and i do no pass -qt-sql-sqlite to configure. Afaik -qt-sql-sqlite means use qt included sqlite and this is the default. What do you mean defaults to plugin? The sqlite is used for the plugin. there is choice between qt provided sqlite and system provided sqlite, but for wince and windows there is no such a thing like system provided sqlite. Regards, Gunnar roth Am 01.03.2016 um 14:50 schrieb Gunnar Roth: > > Well so be it, goodbye Qt from wec2013 Users. > But who takes care that changes for wec2013 in 5.7 and dev are merged back to 5.6.x? > > I know at least of > > configure: Fix (Open)SSL detection on WinCE (Merged)[https://codereview.qt-project.org/122437] > https://codereview.qt-project.org/#/c/122437/[https://codereview.qt-project.org/#/c/122437/] > > > Fixing the SQLite3 build for WEC2013 again. > https://codereview.qt-project.org/#/c/115571/5[https://codereview.qt-project.org/#/c/115571/5] > > > > > furthermore wec2013 x86 needs at least 2 patches to build. > 1. a problem with the fake OleInitialize and OleUninitialize in qtbase\src\plugins\platforms\windows\qplatformfunctions_wince.h, probably due to calling convention. > 2. bitscan intrinsic > --- a\qtbase\src\corelib\tools\qsimd_p.h > +++ b\qtbase\src\corelib\tools\qsimd_p.h > @@ -430,11 +430,17 @@ > #define qCpuHasFeature(feature) ((qCompilerCpuFeatures & (Q_UINT64_C(1) << CpuFeature ## feature)) \ > || (qCpuFeatures() & (Q_UINT64_C(1) << CpuFeature ## feature))) > > #ifdef Q_PROCESSOR_X86 > // Bit scan functions for x86 > -# if defined(Q_CC_MSVC) && !defined(Q_OS_WINCE) > +# if defined(Q_CC_MSVC) > +#if defined _WIN32_WCE && _WIN32_WCE < 0x800 > +extern "C" unsigned char _BitScanForward(unsigned long* Index, unsigned long Mask); > +extern "C" unsigned char _BitScanReverse(unsigned long* Index, unsigned long Mask); > +#pragma intrinsic(_BitScanForward) > +#pragma intrinsic(_BitScanReverse) > +#endif > // MSVC calls it _BitScanReverse and returns the carry flag, which we don't need > static __forceinline unsigned long _bit_scan_reverse(uint val) > { > unsigned long result; > _BitScanReverse(&result, val); > > > > > and all programs using native file dialogs simply crash, qmlscene.exe for example. > > --- a\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp > +++ b\qtbase\src\plugins\platforms\windows\qwindowsintegration.cpp > @@ -173,6 +173,10 @@ > > static inline unsigned parseOptions(const QStringList ¶mList, > int *tabletAbsoluteRange, > QtWindows::ProcessDpiAwareness *dpiAwareness) > { > +#if defined _WIN32_WCE && _WIN32_WCE >= 0x800 > + unsigned options = QWindowsIntegration::NoNativeDialogs; > +#else > unsigned options = 0; > +#endif > > > a problem with spdy protocol occurs for me: > diff -r -U 5 -N -x '*.orig' -x '*.rej' -x '*.bak' -x .git -x doc -x tests -x examples a\qtbase\src\network\access/qspdyprotocolhandler.cpp b\qtbase\src\network\access/qspdyprotocolhandler.cpp > --- a\qtbase\src\network\access/qspdyprotocolhandler.cpp > +++ b\qtbase\src\network\access/qspdyprotocolhandler.cpp > @@ -31,5 +31,6 @@ > ** $QT_END_LICENSE$ > ** > ****************************************************************************/ > > #include > +#undef ZLIB_H // this makes qfunctions_wince.h line 201 stuff not break the build for wince > > > and a fix to allow to use sse2 ( and opensll): > --- a\qtbase\tools\configure\configureapp.cpp > +++ b\qtbase\tools\configure\configureapp.cpp > @@ -1698,20 +1698,10 @@ > dictionary[ "STYLE_WINDOWSVISTA" ] = "no"; > dictionary[ "STYLE_FUSION" ] = "no"; > dictionary[ "STYLE_WINDOWSCE" ] = "yes"; > dictionary[ "STYLE_WINDOWSMOBILE" ] = "yes"; > dictionary[ "OPENGL" ] = "no"; > - dictionary[ "SSL" ] = "no"; > - dictionary[ "OPENSSL" ] = "no"; > - dictionary[ "RTTI" ] = "no"; > - dictionary[ "SSE2" ] = "no"; > - dictionary[ "SSE3" ] = "no"; > - dictionary[ "SSSE3" ] = "no"; > - dictionary[ "SSE4_1" ] = "no"; > - dictionary[ "SSE4_2" ] = "no"; > - dictionary[ "AVX" ] = "no"; > - dictionary[ "AVX2" ] = "no"; > dictionary[ "CE_CRT" ] = "yes"; > dictionary[ "LARGE_FILE" ] = "no"; > dictionary[ "ANGLE" ] = "no"; > dictionary[ "DYNAMICGL" ] = "no"; > if (dictionary[ "XQMAKESPEC" ].startsWith("wincewm")) { > > > > Regards, > Gunnar Roth > > > Gesendet: Dienstag, 01. März 2016 um 08:38 Uhr > Von: "Heikkinen Jani" > An: "Thiago Macieira" , "development at qt-project.org" > Betreff: Re: [Development] Dropping VS 2012 in Qt 5.7 > Done, please review > > Br, > Jani > >>> -----Original Message----- >>> From: Development [mailto:development- >>> bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>> Thiago Macieira >>> Sent: 29. helmikuuta 2016 18:41 >>> To: development at qt-project.org >>> Subject: Re: [Development] Dropping VS 2012 in Qt 5.7 >>> >>> On segunda-feira, 29 de fevereiro de 2016 13:08:18 PST Heikkinen Jani wrote: >>>> Hi! >>>> >>>> It seems we need a decision for this now to be able to proceed with >>>> https://codereview.qt-project.org/#/c/149325/[https://codereview.qt-project.org/#/c/149325/][https://codereview.qt-project.org/#/c/149325/[https://codereview.qt-project.org/#/c/149325/]] >>> >>> Hi Jani >>> >>> We have so far not got any objections. Assume it's going to be the case and >>> add it to the changelog. >>> >>> -- >>> 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[http://lists.qt-project.org/mailman/listinfo/development][http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development]] > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development][http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development]] > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development] > -- Andreas Holzammer | andreas.holzammer at kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development] From edward.welbourne at theqtcompany.com Thu Mar 3 18:15:10 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 3 Mar 2016 17:15:10 +0000 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <3781298.IVj7hYPjYB@tjmaciei-mobl4> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <2599027.huYhDFrUkO@tjmaciei-mobl4> , <3781298.IVj7hYPjYB@tjmaciei-mobl4> Message-ID: > Why do we insist on testing for something that proxies the real need? > We need X and we know that Y provides X, so we test for Y. Why can't > we just test for X? Indeed. It reminds me of the web-sites that used to test with a few browsers and refuse access to anything but the known-good versions of those browsers - even if the untested browser works just fine. It pointlessly limits use and pressures folk into using one of the few things you've taken the trouble to test with; this marginalises new entrants in the market by punishing their customers for daring to try something new. Likewise for compilers: you want a particular feature, so test for that. Don't oblige your users to chose from among the few compilers you can spare the time to test, version-by-version. Better yet, when the compiler supplier introduces a regression that breaks support for some feature, the test automatically detects the problem in a version you never had a chance to check because it's been released since you released your code. Eddy. From Stefan.Walter at lisec.com Thu Mar 3 18:32:25 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Thu, 3 Mar 2016 17:32:25 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <10481168.tMfYUKVjTX@tjmaciei-mobl4> References: <3109436.B1zXd9hWkc@tjmaciei-mobl4> <9b04587cf7a6406cb0e8329d960f5900@ATSE-MAIL4.lisec.internal>, <10481168.tMfYUKVjTX@tjmaciei-mobl4> Message-ID: <1457026345252.28804@lisec.com> Hi Thiago, thanks, but unfortunately I am a subversion user and my git knowledge is very little. Is there a guide or some quick steps of how to check out this git 5.6.0 branch on my linux system? Thanks and sorry for this silly question. Regards, Stefan ________________________________________ Von: Development im Auftrag von Thiago Macieira Gesendet: Donnerstag, 03. März 2016 20:42 An: development at qt-project.org Betreff: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ On quinta-feira, 3 de março de 2016 16:26:20 PST Walter Stefan wrote: > Will there be another release candidate or how can I test the compilation > with the already incorporated fixes since rc-1? The best would be to built the 5.6.0 branch from Git. -- 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 Thu Mar 3 18:37:30 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 03 Mar 2016 20:37:30 +0300 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <2599027.huYhDFrUkO@tjmaciei-mobl4> , <3781298.IVj7hYPjYB@tjmaciei-mobl4> Message-ID: <1116751457026650@web26m.yandex.ru> 03.03.2016, 20:15, "Welbourne Edward" : >>  Why do we insist on testing for something that proxies the real need? >>  We need X and we know that Y provides X, so we test for Y. Why can't >>  we just test for X? > > Indeed. It reminds me of the web-sites that used to test with a few > browsers and refuse access to anything but the known-good versions of > those browsers - even if the untested browser works just fine. It > pointlessly limits use and pressures folk into using one of the few > things you've taken the trouble to test with; this marginalises new > entrants in the market by punishing their customers for daring to try > something new. > > Likewise for compilers: you want a particular feature, so test for that. > Don't oblige your users to chose from among the few compilers you can > spare the time to test, version-by-version. Better yet, when the > compiler supplier introduces a regression that breaks support for some > feature, the test automatically detects the problem in a version you > never had a chance to check because it's been released since you > released your code. With web sites you can change User-Agent string to see them; likewise, with compilers you can comment out checks and see if it works for you. It is just unsupported, in both cases. -- Regards, Konstantin From thiago.macieira at intel.com Thu Mar 3 19:22:27 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 10:22:27 -0800 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <1457026345252.28804@lisec.com> References: <10481168.tMfYUKVjTX@tjmaciei-mobl4> <1457026345252.28804@lisec.com> Message-ID: <85781467.L54sGM06E2@tjmaciei-mobl4> On quinta-feira, 3 de março de 2016 17:32:25 PST Walter Stefan wrote: > Hi Thiago, > > thanks, but unfortunately I am a subversion user and my git knowledge is > very little. Is there a guide or some quick steps of how to check out this > git 5.6.0 branch on my linux system? git clone -b 5.6.0 git://code.qt.io/qt/qt5.git less README.git The README tells you to run: ./init-repository I've never run that script and I have no idea what it does. I'd do instead: git submodule init git submodule update -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Stefan.Walter at lisec.com Fri Mar 4 05:49:39 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Fri, 4 Mar 2016 04:49:39 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <85781467.L54sGM06E2@tjmaciei-mobl4> References: <10481168.tMfYUKVjTX@tjmaciei-mobl4> <1457026345252.28804@lisec.com>,<85781467.L54sGM06E2@tjmaciei-mobl4> Message-ID: <1457066979299.8075@lisec.com> Hi, I am using now the actual sources from git for 5.6.0 and get now the next compilation issue regarding libQt5DBus.so. This mentioned library get's built and is also available in .../qtbase/lib/libQt5DBus.so For some reason while building the service framework it can find that library. See the compilation output: make[4]: Entering directory `/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/src/tools/servicefw' g++ -Wl,-O1 -Wl,--enable-new-dtags -Wl,-rpath,/home/walteste/qt-5.6/qt-5.6.0-git/qt-install/lib -o ../../../bin/servicefw .obj/servicefw.o .obj/servicemetadata.o -L/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib -lQt5ServiceFramework -L/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtbase/lib -lQt5Core -lpthread /usr/bin/ld: warning: libQt5DBus.so.5, needed by /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libQt5Network.so.5, needed by /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libQt5Sql.so.5, needed by /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so, not found (try using -rpath or -rpath-link) /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so: undefined reference to `QDBusAbstractInterface::isValid() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so: undefined reference to `QDBusAbstractInterface::connection() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so: undefined reference to `QDBusMetaType::registerMarshallOperators(int, void (*)(QDBusArgument&, void const*), void (*)(QDBusArgument const&, void*))@Qt_5' Thanks and Regards, Stefan ________________________________________ Von: Development im Auftrag von Thiago Macieira Gesendet: Donnerstag, 03. März 2016 22:22 An: development at qt-project.org Betreff: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ On quinta-feira, 3 de março de 2016 17:32:25 PST Walter Stefan wrote: > Hi Thiago, > > thanks, but unfortunately I am a subversion user and my git knowledge is > very little. Is there a guide or some quick steps of how to check out this > git 5.6.0 branch on my linux system? git clone -b 5.6.0 git://code.qt.io/qt/qt5.git less README.git The README tells you to run: ./init-repository I've never run that script and I have no idea what it does. I'd do instead: git submodule init git submodule update -- 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 helio at kde.org Fri Mar 4 07:07:14 2016 From: helio at kde.org (Helio Chissini de Castro) Date: Fri, 04 Mar 2016 06:07:14 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <1457066979299.8075@lisec.com> References: <10481168.tMfYUKVjTX@tjmaciei-mobl4> <1457026345252.28804@lisec.com> <85781467.L54sGM06E2@tjmaciei-mobl4> <1457066979299.8075@lisec.com> Message-ID: Hello all Just a question, did you tried the copr Qt repository that Fedora KDE Sig maintains ? https://copr.fedorainfracloud.org/coprs/g/kdesig We have everything compiled for Fedora 22, 23, rawhide, epel 7 and epel 6, meaning Centos 6 We're unable to dependency reasons have qtserialport, qtwayland, qt3d and Qt creator 5.6.o not ready yet, but for the rest is all ok Even the compiler we used the original, and not the SCL collection. Regards, Helio On Fri, Mar 4, 2016, 05:50 Walter Stefan wrote: > Hi, > > I am using now the actual sources from git for 5.6.0 and get now the next > compilation issue regarding libQt5DBus.so. > > This mentioned library get's built and is also available in > .../qtbase/lib/libQt5DBus.so > > For some reason while building the service framework it can find that > library. See the compilation output: > make[4]: Entering directory > `/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/src/tools/servicefw' > g++ -Wl,-O1 -Wl,--enable-new-dtags > -Wl,-rpath,/home/walteste/qt-5.6/qt-5.6.0-git/qt-install/lib -o > ../../../bin/servicefw .obj/servicefw.o .obj/servicemetadata.o > -L/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib > -lQt5ServiceFramework > -L/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtbase/lib -lQt5Core -lpthread > /usr/bin/ld: warning: libQt5DBus.so.5, needed by > /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so, > not found (try using -rpath or -rpath-link) > /usr/bin/ld: warning: libQt5Network.so.5, needed by > /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so, > not found (try using -rpath or -rpath-link) > /usr/bin/ld: warning: libQt5Sql.so.5, needed by > /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so, > not found (try using -rpath or -rpath-link) > /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so: > undefined reference to `QDBusAbstractInterface::isValid() const at Qt_5' > /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so: > undefined reference to `QDBusAbstractInterface::connection() const at Qt_5' > /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so: > undefined reference to `QDBusMetaType::registerMarshallOperators(int, void > (*)(QDBusArgument&, void const*), void (*)(QDBusArgument const&, > void*))@Qt_5' > > Thanks and Regards, > Stefan > > ________________________________________ > Von: Development lisec.com at qt-project.org> im Auftrag von Thiago Macieira < > thiago.macieira at intel.com> > Gesendet: Donnerstag, 03. März 2016 22:22 > An: development at qt-project.org > Betreff: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 > with g++ > > On quinta-feira, 3 de março de 2016 17:32:25 PST Walter Stefan wrote: > > Hi Thiago, > > > > thanks, but unfortunately I am a subversion user and my git knowledge is > > very little. Is there a guide or some quick steps of how to check out > this > > git 5.6.0 branch on my linux system? > > git clone -b 5.6.0 git://code.qt.io/qt/qt5.git > less README.git > > The README tells you to run: > ./init-repository > > I've never run that script and I have no idea what it does. I'd do instead: > git submodule init > git submodule update > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Mar 4 07:52:15 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 22:52:15 -0800 Subject: [Development] Are we free of code that checks this isn't null? Message-ID: <3576441.RbKHnCWb96@tjmaciei-mobl4> Found in GCC 6's changelog (http://gcc.gnu.org/gcc-6/changes.html): > Value range propagation now assumes that the this pointer of C++ member > functions is non-null. This eliminates common null pointer checks but also > breaks some non-conforming code-bases (such as Qt-5, Chromium, KDevelop). > As a temporary work-around -fno-delete-null-pointer-checks can be used. > Wrong code can be identified by using -fsanitize=undefined. Are we free of such mistakes? Or do we need to enable -fno-delete-null- pointer-checks? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Mar 4 07:40:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 22:40:08 -0800 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <1457066979299.8075@lisec.com> References: <85781467.L54sGM06E2@tjmaciei-mobl4> <1457066979299.8075@lisec.com> Message-ID: <2787217.9GmxOU6dtp@tjmaciei-mobl4> On sexta-feira, 4 de março de 2016 04:49:39 PST Walter Stefan wrote: > g++ -Wl,-O1 -Wl,--enable-new-dtags > -Wl,-rpath,/home/walteste/qt-5.6/qt-5.6.0-git/qt-install/lib -o > ../../../bin/servicefw .obj/servicefw.o > .obj/servicemetadata.o -L/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsy > stems/lib -lQt5ServiceFramework > -L/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtbase/lib -lQt5Core > -lpthread /usr/bin/ld: warning: libQt5DBus.so.5, needed by > /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFram > ework.so, not found (try using -rpath or -rpath-link) Same problem as before. I don't know what's happening. This seems to be the result of some recent changes to where libraries are stored during a build, alongside some RPATH options. However, I don't know what caused it and I can't reproduce locally. I built qtconnectivity/examples/nfc/annotatedurl example and the command-line for the linking is exactly like the one you reported before, modulo the build paths. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Stefan.Walter at lisec.com Fri Mar 4 08:07:00 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Fri, 4 Mar 2016 07:07:00 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <2787217.9GmxOU6dtp@tjmaciei-mobl4> References: <85781467.L54sGM06E2@tjmaciei-mobl4> <1457066979299.8075@lisec.com>,<2787217.9GmxOU6dtp@tjmaciei-mobl4> Message-ID: <1457075220219.86378@lisec.com> I have done a clean build. Where can we address this issue? Regards, Stefan ________________________________________ Von: Development im Auftrag von Thiago Macieira Gesendet: Freitag, 04. März 2016 10:40 An: development at qt-project.org Betreff: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ On sexta-feira, 4 de março de 2016 04:49:39 PST Walter Stefan wrote: > g++ -Wl,-O1 -Wl,--enable-new-dtags > -Wl,-rpath,/home/walteste/qt-5.6/qt-5.6.0-git/qt-install/lib -o > ../../../bin/servicefw .obj/servicefw.o > .obj/servicemetadata.o -L/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsy > stems/lib -lQt5ServiceFramework > -L/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtbase/lib -lQt5Core > -lpthread /usr/bin/ld: warning: libQt5DBus.so.5, needed by > /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFram > ework.so, not found (try using -rpath or -rpath-link) Same problem as before. I don't know what's happening. This seems to be the result of some recent changes to where libraries are stored during a build, alongside some RPATH options. However, I don't know what caused it and I can't reproduce locally. I built qtconnectivity/examples/nfc/annotatedurl example and the command-line for the linking is exactly like the one you reported before, modulo the build paths. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Mar 4 08:27:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 23:27:30 -0800 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <1457075220219.86378@lisec.com> References: <2787217.9GmxOU6dtp@tjmaciei-mobl4> <1457075220219.86378@lisec.com> Message-ID: <11637957.bfiLkViqEa@tjmaciei-mobl4> On sexta-feira, 4 de março de 2016 07:07:00 PST Walter Stefan wrote: > I have done a clean build. > > Where can we address this issue? I've managed to reproduce this issue now. It only happens with the old bfd linker (ld.bfd). Gold appears unaffected. Workaround: do not use the convenience qt-everywhere-* tarball. Build each module independently. Ossi: have there been changes to rpath or rpath-link handling recently? We need to bring it back. The command-line for linking the example was: g++ -Wl,-O1 -fuse-ld=bfd -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\ $ORIGIN/../../../lib -o annotatedurl .obj/main.o .obj/mainwindow.o .obj/ annotatedurl.o .obj/moc_mainwindow.o .obj/moc_annotatedurl.o -L/tmp/qt-build/ qtbase/lib -lQt5Widgets.t -lQt5Gui.t -L/tmp/qt-build/qtconnectivity/lib - lQt5Nfc.t -lQt5Core.t -lGL -lpthread Every Qt module path in an -L option needs to be repeated with -Wl,-rpath- link, -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Mar 4 08:10:32 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 23:10:32 -0800 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <1457075220219.86378@lisec.com> References: <2787217.9GmxOU6dtp@tjmaciei-mobl4> <1457075220219.86378@lisec.com> Message-ID: <1610858.17kE4vOank@tjmaciei-mobl4> On sexta-feira, 4 de março de 2016 07:07:00 PST Walter Stefan wrote: > I have done a clean build. > > Where can we address this issue? I don't know. It's hard to suggest a solution if I don't know what's wrong. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Stefan.Walter at lisec.com Fri Mar 4 08:40:20 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Fri, 4 Mar 2016 07:40:20 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: References: <10481168.tMfYUKVjTX@tjmaciei-mobl4> <1457026345252.28804@lisec.com> <85781467.L54sGM06E2@tjmaciei-mobl4> <1457066979299.8075@lisec.com>, Message-ID: <1457077220339.22524@lisec.com> ​Hi Helio, I use the GIT 5.6.0 version from qt as suggested by Thiago. The link provided by you does not work for me. Regards, Stefan ________________________________ Von: Helio Chissini de Castro Gesendet: Freitag, 04. März 2016 10:07 An: Walter Stefan; Thiago Macieira; development at qt-project.org Betreff: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ Hello all Just a question, did you tried the copr Qt repository that Fedora KDE Sig maintains ? https://copr.fedorainfracloud.org/coprs/g/kdesig We have everything compiled for Fedora 22, 23, rawhide, epel 7 and epel 6, meaning Centos 6 We're unable to dependency reasons have qtserialport, qtwayland, qt3d and Qt creator 5.6.o not ready yet, but for the rest is all ok Even the compiler we used the original, and not the SCL collection. Regards, Helio On Fri, Mar 4, 2016, 05:50 Walter Stefan > wrote: Hi, I am using now the actual sources from git for 5.6.0 and get now the next compilation issue regarding libQt5DBus.so. This mentioned library get's built and is also available in .../qtbase/lib/libQt5DBus.so For some reason while building the service framework it can find that library. See the compilation output: make[4]: Entering directory `/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/src/tools/servicefw' g++ -Wl,-O1 -Wl,--enable-new-dtags -Wl,-rpath,/home/walteste/qt-5.6/qt-5.6.0-git/qt-install/lib -o ../../../bin/servicefw .obj/servicefw.o .obj/servicemetadata.o -L/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib -lQt5ServiceFramework -L/home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtbase/lib -lQt5Core -lpthread /usr/bin/ld: warning: libQt5DBus.so.5, needed by /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libQt5Network.so.5, needed by /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so, not found (try using -rpath or -rpath-link) /usr/bin/ld: warning: libQt5Sql.so.5, needed by /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so, not found (try using -rpath or -rpath-link) /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so: undefined reference to `QDBusAbstractInterface::isValid() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so: undefined reference to `QDBusAbstractInterface::connection() const at Qt_5' /home/walteste/qt-5.6/qt-5.6.0-git/qt-build/qtsystems/lib/libQt5ServiceFramework.so: undefined reference to `QDBusMetaType::registerMarshallOperators(int, void (*)(QDBusArgument&, void const*), void (*)(QDBusArgument const&, void*))@Qt_5' Thanks and Regards, Stefan ________________________________________ Von: Development > im Auftrag von Thiago Macieira > Gesendet: Donnerstag, 03. März 2016 22:22 An: development at qt-project.org Betreff: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ On quinta-feira, 3 de março de 2016 17:32:25 PST Walter Stefan wrote: > Hi Thiago, > > thanks, but unfortunately I am a subversion user and my git knowledge is > very little. Is there a guide or some quick steps of how to check out this > git 5.6.0 branch on my linux system? git clone -b 5.6.0 git://code.qt.io/qt/qt5.git less README.git The README tells you to run: ./init-repository I've never run that script and I have no idea what it does. I'd do instead: git submodule init git submodule update -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Stefan.Walter at lisec.com Fri Mar 4 08:43:12 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Fri, 4 Mar 2016 07:43:12 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <11637957.bfiLkViqEa@tjmaciei-mobl4> References: <2787217.9GmxOU6dtp@tjmaciei-mobl4> <1457075220219.86378@lisec.com>,<11637957.bfiLkViqEa@tjmaciei-mobl4> Message-ID: <1457077392734.14445@lisec.com> Dear Thiago, It seems to me that 5.6.0 is far from ready to be released. The workaround mentioned by you is not clear to me. It sounds like a lot of work and tweaking, or correct me if I am wrong. As Qt 5.6.0 got announced as long time release, we really would like to bring all our systems to that version. Regards, Stefan ________________________________________ Von: Development im Auftrag von Thiago Macieira Gesendet: Freitag, 04. März 2016 11:27 An: development at qt-project.org Betreff: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ On sexta-feira, 4 de março de 2016 07:07:00 PST Walter Stefan wrote: > I have done a clean build. > > Where can we address this issue? I've managed to reproduce this issue now. It only happens with the old bfd linker (ld.bfd). Gold appears unaffected. Workaround: do not use the convenience qt-everywhere-* tarball. Build each module independently. Ossi: have there been changes to rpath or rpath-link handling recently? We need to bring it back. The command-line for linking the example was: g++ -Wl,-O1 -fuse-ld=bfd -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\ $ORIGIN/../../../lib -o annotatedurl .obj/main.o .obj/mainwindow.o .obj/ annotatedurl.o .obj/moc_mainwindow.o .obj/moc_annotatedurl.o -L/tmp/qt-build/ qtbase/lib -lQt5Widgets.t -lQt5Gui.t -L/tmp/qt-build/qtconnectivity/lib - lQt5Nfc.t -lQt5Core.t -lGL -lpthread Every Qt module path in an -L option needs to be repeated with -Wl,-rpath- link, -- 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 marc.mutz at kdab.com Fri Mar 4 09:58:53 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Mar 2016 09:58:53 +0100 Subject: [Development] Are we free of code that checks this isn't null? In-Reply-To: <3576441.RbKHnCWb96@tjmaciei-mobl4> References: <3576441.RbKHnCWb96@tjmaciei-mobl4> Message-ID: <201603040958.53429.marc.mutz@kdab.com> On Friday 04 March 2016 07:52:15 Thiago Macieira wrote: > Found in GCC 6's changelog (http://gcc.gnu.org/gcc-6/changes.html): > > Value range propagation now assumes that the this pointer of C++ member > > functions is non-null. This eliminates common null pointer checks but > > also breaks some non-conforming code-bases (such as Qt-5, Chromium, > > KDevelop). As a temporary work-around -fno-delete-null-pointer-checks > > can be used. Wrong code can be identified by using -fsanitize=undefined. > > Are we free of such mistakes? Or do we need to enable -fno-delete-null- > pointer-checks? This comes to mind; QPointer that = this; // ... if (!that) return; Not sure it's affected, though. Don't know off-handedly anything else that where this == nullptr would be valid. Only way to find out is to enable -fno-delete-null-pointer-checks except for -developer-build and trying to fix the ubsan issues. We should eventually put a ubsan build into the CI, we're not /that/ far away from building cleanly. It's some time since I last checked, but I can't remember any 3rd-party libs triggering in a ubsan Qt builds. /me upgrades to GCC 6. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Fri Mar 4 08:59:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 23:59:59 -0800 Subject: [Development] Are we free of code that checks this isn't null? In-Reply-To: <201603040958.53429.marc.mutz@kdab.com> References: <3576441.RbKHnCWb96@tjmaciei-mobl4> <201603040958.53429.marc.mutz@kdab.com> Message-ID: <4641502.ptqUsJBUAZ@tjmaciei-mobl4> On sexta-feira, 4 de março de 2016 09:58:53 PST Marc Mutz wrote: > On Friday 04 March 2016 07:52:15 Thiago Macieira wrote: > > Found in GCC 6's changelog (http://gcc.gnu.org/gcc-6/changes.html): > > > Value range propagation now assumes that the this pointer of C++ member > > > functions is non-null. This eliminates common null pointer checks but > > > also breaks some non-conforming code-bases (such as Qt-5, Chromium, > > > KDevelop). As a temporary work-around -fno-delete-null-pointer-checks > > > can be used. Wrong code can be identified by using -fsanitize=undefined. > > > > Are we free of such mistakes? Or do we need to enable -fno-delete-null- > > pointer-checks? > > This comes to mind; > > QPointer that = this; > // ... > if (!that) return; > > Not sure it's affected, though. Shouldn't be because that !that call isn't checking the this pointer, but instead is checking the strong refcount inside the QSharedPointer. > Don't know off-handedly anything else that where this == nullptr would be > valid. Only way to find out is to enable -fno-delete-null-pointer-checks > except for -developer-build and trying to fix the ubsan issues. It's not valid. The this pointer is never null, according to the standard. And yet we had code like that in V4 (qtdeclarative). Clang started complaining about it and I tried to fix it by just removing the checks, but they were apparently in use. Since I don't remember seeing that warning anymore, it's likely to be fixed. But I am asking to be sure. > /me upgrades to GCC 6. I might still have a patch or two that aren't merged that fix GCC 6 warnings. But when you compile with it, can you make sure it doesn't print any misleading-identation warnings? There were a couple of false positives that I reported and GCC fixed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Mar 4 08:49:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 03 Mar 2016 23:49:59 -0800 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <1457077392734.14445@lisec.com> References: <11637957.bfiLkViqEa@tjmaciei-mobl4> <1457077392734.14445@lisec.com> Message-ID: <2053584.oP3k7uZhGq@tjmaciei-mobl4> On sexta-feira, 4 de março de 2016 07:43:12 PST Walter Stefan wrote: > Dear Thiago, > > It seems to me that 5.6.0 is far from ready to be released. Actually, no, it's working well for the common scenario. You're the one with the old distro that has an old compiler and lacks Gold. Most people who build Qt from sources are in new distros that are working. I know you have a valid environment that deserves to be supported. It just happens that you're not part of the majority. Besides, the point of the RC is to find those issues and fix them. We have. > The workaround mentioned by you is not clear to me. It sounds like a lot of > work and tweaking, or correct me if I am wrong. The official Qt release is one tarball per Qt module. So you have to download qtbase-*.tar.gz, build it, install it, and after that is done you can move on to the next module. The qt-everywhere-*.tar.gz file is a convenience. It's not the official release. If it doesn't work for you, you can always just use the official way. > As Qt 5.6.0 got announced as long time release, we really would like to > bring all our systems to that version. And we'll keep fixing the issues so that you are able to. 5.6.0 is not the last release in the 5.6 series. We don't have to get everything fixed in the .0 release. There will be a 5.6.1, then a 5.6.2, then a 5.6.3, etc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at theqtcompany.com Fri Mar 4 09:11:42 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 4 Mar 2016 08:11:42 +0000 Subject: [Development] Are we free of code that checks this isn't null? In-Reply-To: <4641502.ptqUsJBUAZ@tjmaciei-mobl4> References: <3576441.RbKHnCWb96@tjmaciei-mobl4> <201603040958.53429.marc.mutz@kdab.com> <4641502.ptqUsJBUAZ@tjmaciei-mobl4> Message-ID: On 04/03/16 08:59, "Development on behalf of Thiago Macieira" wrote: >On sexta-feira, 4 de março de 2016 09:58:53 PST Marc Mutz wrote: >> On Friday 04 March 2016 07:52:15 Thiago Macieira wrote: >> > Found in GCC 6's changelog (http://gcc.gnu.org/gcc-6/changes.html): >> > > Value range propagation now assumes that the this pointer of C++ member >> > > functions is non-null. This eliminates common null pointer checks but >> > > also breaks some non-conforming code-bases (such as Qt-5, Chromium, >> > > KDevelop). As a temporary work-around -fno-delete-null-pointer-checks >> > > can be used. Wrong code can be identified by using -fsanitize=undefined. >> > >> > Are we free of such mistakes? Or do we need to enable -fno-delete-null- >> > pointer-checks? >> >> This comes to mind; >> >> QPointer that = this; >> // ... >> if (!that) return; >> >> Not sure it's affected, though. > >Shouldn't be because that !that call isn't checking the this pointer, but >instead is checking the strong refcount inside the QSharedPointer. > >> Don't know off-handedly anything else that where this == nullptr would be >> valid. Only way to find out is to enable -fno-delete-null-pointer-checks >> except for -developer-build and trying to fix the ubsan issues. > >It's not valid. The this pointer is never null, according to the standard. > >And yet we had code like that in V4 (qtdeclarative). Clang started complaining >about it and I tried to fix it by just removing the checks, but they were >apparently in use. Since I don't remember seeing that warning anymore, it's >likely to be fixed. > >But I am asking to be sure. Qt QML should be ok. I went through those issues and fixed the at some point. Cheers, Lars > >> /me upgrades to GCC 6. > >I might still have a patch or two that aren't merged that fix GCC 6 warnings. >But when you compile with it, can you make sure it doesn't print any >misleading-identation warnings? There were a couple of false positives that I >reported and GCC fixed. > >-- >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 Stefan.Walter at lisec.com Fri Mar 4 09:12:40 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Fri, 4 Mar 2016 08:12:40 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <2053584.oP3k7uZhGq@tjmaciei-mobl4> References: <11637957.bfiLkViqEa@tjmaciei-mobl4> <1457077392734.14445@lisec.com>,<2053584.oP3k7uZhGq@tjmaciei-mobl4> Message-ID: <1457079160075.80553@lisec.com> Dear Thiago, please don't take it as an offense. I just assume that I am for sure not the only one or a group of less coders that still need to support a not very old CentOS 6. All I want to do here is to give my input, to improve the code base to also work still fine with a CentOS 6. Regards, Stefan ________________________________________ Von: Development im Auftrag von Thiago Macieira Gesendet: Freitag, 04. März 2016 11:49 An: development at qt-project.org Betreff: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ On sexta-feira, 4 de março de 2016 07:43:12 PST Walter Stefan wrote: > Dear Thiago, > > It seems to me that 5.6.0 is far from ready to be released. Actually, no, it's working well for the common scenario. You're the one with the old distro that has an old compiler and lacks Gold. Most people who build Qt from sources are in new distros that are working. I know you have a valid environment that deserves to be supported. It just happens that you're not part of the majority. Besides, the point of the RC is to find those issues and fix them. We have. > The workaround mentioned by you is not clear to me. It sounds like a lot of > work and tweaking, or correct me if I am wrong. The official Qt release is one tarball per Qt module. So you have to download qtbase-*.tar.gz, build it, install it, and after that is done you can move on to the next module. The qt-everywhere-*.tar.gz file is a convenience. It's not the official release. If it doesn't work for you, you can always just use the official way. > As Qt 5.6.0 got announced as long time release, we really would like to > bring all our systems to that version. And we'll keep fixing the issues so that you are able to. 5.6.0 is not the last release in the 5.6 series. We don't have to get everything fixed in the .0 release. There will be a 5.6.1, then a 5.6.2, then a 5.6.3, etc. -- 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 jani.heikkinen at theqtcompany.com Fri Mar 4 09:47:10 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Fri, 4 Mar 2016 08:47:10 +0000 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: <11637957.bfiLkViqEa@tjmaciei-mobl4> References: <2787217.9GmxOU6dtp@tjmaciei-mobl4> <1457075220219.86378@lisec.com> <11637957.bfiLkViqEa@tjmaciei-mobl4> Message-ID: >>Workaround: do not use the convenience qt-everywhere-* tarball. Build each >>module independently. >> >>Ossi: have there been changes to rpath or rpath-link handling recently? We >>need to bring it back. There is some fixes for src packages coming in after RC, see https://codereview.qt-project.org/#/c/150517/ https://codereview.qt-project.org/#/c/150232/ https://codereview.qt-project.org/#/c/151015/ (+ c++98 related ones in https://codereview.qt-project.org/#/c/151328/ ) Those all are now in qt5.git but we don't have re-created src packages for testing yet :( Br, Jani >>-----Original Message----- >>From: Development [mailto:development- >>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>Thiago Macieira >>Sent: 4. maaliskuuta 2016 9:28 >>To: development at qt-project.org >>Subject: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with >>g++ >> >>On sexta-feira, 4 de março de 2016 07:07:00 PST Walter Stefan wrote: >>> I have done a clean build. >>> >>> Where can we address this issue? >> >>I've managed to reproduce this issue now. It only happens with the old bfd >>linker (ld.bfd). Gold appears unaffected. >> >>Workaround: do not use the convenience qt-everywhere-* tarball. Build each >>module independently. >> >>Ossi: have there been changes to rpath or rpath-link handling recently? We >>need to bring it back. >> >>The command-line for linking the example was: >> >>g++ -Wl,-O1 -fuse-ld=bfd -Wl,--enable-new-dtags -Wl,-z,origin -Wl,-rpath,\ >>$ORIGIN/../../../lib -o annotatedurl .obj/main.o .obj/mainwindow.o .obj/ >>annotatedurl.o .obj/moc_mainwindow.o .obj/moc_annotatedurl.o -L/tmp/qt- >>build/ >>qtbase/lib -lQt5Widgets.t -lQt5Gui.t -L/tmp/qt-build/qtconnectivity/lib - >>lQt5Nfc.t -lQt5Core.t -lGL -lpthread >> >>Every Qt module path in an -L option needs to be repeated with -Wl,-rpath- >>link, >> >>-- >>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 olivier at woboq.com Fri Mar 4 09:51:10 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 04 Mar 2016 09:51:10 +0100 Subject: [Development] Are we free of code that checks this isn't null? In-Reply-To: <4641502.ptqUsJBUAZ@tjmaciei-mobl4> References: <3576441.RbKHnCWb96@tjmaciei-mobl4> <201603040958.53429.marc.mutz@kdab.com> <4641502.ptqUsJBUAZ@tjmaciei-mobl4> Message-ID: <2161999.mCBdLPEh4r@finn> Am Donnerstag, 3. März 2016, 23:59:59 CET schrieb Thiago Macieira: > On sexta-feira, 4 de março de 2016 09:58:53 PST Marc Mutz wrote: > > On Friday 04 March 2016 07:52:15 Thiago Macieira wrote: > > > Found in GCC 6's changelog (http://gcc.gnu.org/gcc-6/changes.html): > > > > Value range propagation now assumes that the this pointer of C++ > > > > member > > > > functions is non-null. This eliminates common null pointer checks but > > > > also breaks some non-conforming code-bases (such as Qt-5, Chromium, > > > > KDevelop). As a temporary work-around -fno-delete-null-pointer-checks > > > > can be used. Wrong code can be identified by using > > > > -fsanitize=undefined. > > > > > > Are we free of such mistakes? Or do we need to enable -fno-delete-null- > > > pointer-checks? > > > > This comes to mind; > > > > QPointer that = this; > > // ... > > if (!that) return; > > > > Not sure it's affected, though. > > Shouldn't be because that !that call isn't checking the this pointer, but > instead is checking the strong refcount inside the QSharedPointer. > > > Don't know off-handedly anything else that where this == nullptr would be > > valid. Only way to find out is to enable -fno-delete-null-pointer-checks > > except for -developer-build and trying to fix the ubsan issues. > > It's not valid. The this pointer is never null, according to the standard. > > And yet we had code like that in V4 (qtdeclarative). Clang started > complaining about it and I tried to fix it by just removing the checks, but > they were apparently in use. Since I don't remember seeing that warning > anymore, it's likely to be fixed. It was fixed in 0704d2be63b484cb579c1507223db3f914b1338a > > But I am asking to be sure. > > > /me upgrades to GCC 6. > > I might still have a patch or two that aren't merged that fix GCC 6 > warnings. But when you compile with it, can you make sure it doesn't print > any misleading-identation warnings? There were a couple of false positives > that I reported and GCC fixed. I grepped for the warning. Here is all the files I could find. https://code.woboq.org/qt5/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/API/OpaqueJSString.h.html#50 https://code.woboq.org/qt5/qtscript/src/3rdparty/javascriptcore/JavaScriptCore/API/OpaqueJSString.cpp.html#44 https://code.woboq.org/qt5/qtwebkit/Source/JavaScriptCore/API/OpaqueJSString.h.html#56 https://code.woboq.org/qt5/qtwebkit/Source/JavaScriptCore/API/OpaqueJSString.cpp.html#44 https://code.woboq.org/qt5/qtwebkit/Source/JavaScriptCore/parser/SourceProvider.h.html#58 https://code.woboq.org/qt5/qtwebkit/Source/WebCore/html/HTMLElement.cpp.html#509 https://code.woboq.org/qt5/qtwebkit/Source/WebCore/rendering/RenderBlock.cpp.html#7403 https://code.woboq.org/qt5/qtwebkit/Source/WebCore/rendering/RenderObject.cpp.html#1593 So only in deprecated modules. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From helio at kde.org Fri Mar 4 10:02:47 2016 From: helio at kde.org (Helio Chissini de Castro) Date: Fri, 4 Mar 2016 10:02:47 +0100 Subject: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 with g++ In-Reply-To: References: <2787217.9GmxOU6dtp@tjmaciei-mobl4> <1457075220219.86378@lisec.com> <11637957.bfiLkViqEa@tjmaciei-mobl4> Message-ID: Hello again The packages built on copr repository IS 5.6.0rc and is the reference that we use to upstream in Fedora when reach final. This is the proper repository: https://copr.fedorainfracloud.org/coprs/g/kdesig/Qt5/ This is the repository to add on Yum https://copr.fedorainfracloud.org/coprs/g/kdesig/Qt5/repo/epel-6/heliocastro-Qt5-epel-6.repo This are the effective packages: https://copr.fedorainfracloud.org/coprs/g/kdesig/Qt5/packages/ []'s Helio On Fri, Mar 4, 2016 at 9:47 AM, Heikkinen Jani < jani.heikkinen at theqtcompany.com> wrote: > >>Workaround: do not use the convenience qt-everywhere-* tarball. Build > each > >>module independently. > >> > >>Ossi: have there been changes to rpath or rpath-link handling recently? > We > >>need to bring it back. > > There is some fixes for src packages coming in after RC, see > > https://codereview.qt-project.org/#/c/150517/ > https://codereview.qt-project.org/#/c/150232/ > https://codereview.qt-project.org/#/c/151015/ > > (+ c++98 related ones in https://codereview.qt-project.org/#/c/151328/ ) > > Those all are now in qt5.git but we don't have re-created src packages for > testing yet :( > > Br, > Jani > > > >>-----Original Message----- > >>From: Development [mailto:development- > >>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of > >>Thiago Macieira > >>Sent: 4. maaliskuuta 2016 9:28 > >>To: development at qt-project.org > >>Subject: Re: [Development] Qt 5.6.0-rc build issues on CentOS 6.7 x86_64 > with > >>g++ > >> > >>On sexta-feira, 4 de março de 2016 07:07:00 PST Walter Stefan wrote: > >>> I have done a clean build. > >>> > >>> Where can we address this issue? > >> > >>I've managed to reproduce this issue now. It only happens with the old > bfd > >>linker (ld.bfd). Gold appears unaffected. > >> > >>Workaround: do not use the convenience qt-everywhere-* tarball. Build > each > >>module independently. > >> > >>Ossi: have there been changes to rpath or rpath-link handling recently? > We > >>need to bring it back. > >> > >>The command-line for linking the example was: > >> > >>g++ -Wl,-O1 -fuse-ld=bfd -Wl,--enable-new-dtags -Wl,-z,origin > -Wl,-rpath,\ > >>$ORIGIN/../../../lib -o annotatedurl .obj/main.o .obj/mainwindow.o .obj/ > >>annotatedurl.o .obj/moc_mainwindow.o .obj/moc_annotatedurl.o -L/tmp/qt- > >>build/ > >>qtbase/lib -lQt5Widgets.t -lQt5Gui.t -L/tmp/qt-build/qtconnectivity/lib - > >>lQt5Nfc.t -lQt5Core.t -lGL -lpthread > >> > >>Every Qt module path in an -L option needs to be repeated with > -Wl,-rpath- > >>link, > >> > >>-- > >>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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at theqtcompany.com Fri Mar 4 11:03:22 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Fri, 4 Mar 2016 10:03:22 +0000 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: <3781298.IVj7hYPjYB@tjmaciei-mobl4> References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <2599027.huYhDFrUkO@tjmaciei-mobl4> , <3781298.IVj7hYPjYB@tjmaciei-mobl4> Message-ID: >Because you also need to reject some older Clang versions. Did you add the >check for them too? clang 3.4 is rejected by requires(c++11) already. >Please think of Clang on Linux and FreeBSD, plus the older XCode that we still >support on OS X. This is LTS and the last version before we require C++11, so >expect people will try to build it with older versions. >Why do we insist on testing for something that proxies the real need? We need >X and we know that Y provides X, so we test for Y. Why can't we just test for >X? Effort and speed. The compile test should not delay the 5.6.0 release and such a test would take much more time. After all we would have to go through the entire code base and identify all C++11 features we are using. That's bound to have the same gaps too. I want to emphasize qtserialbus is not the first module to do such a compiler based rejection pattern. For 5.6.0 this is good enough. Nevertheless I filed https://bugreports.qt.io/browse/QTBUG-51655 and we might have a better solution for 5.6.1. -- Alex From jedrzej.nowacki at theqtcompany.com Fri Mar 4 12:48:51 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 4 Mar 2016 12:48:51 +0100 Subject: [Development] ci timeouts In-Reply-To: References: Message-ID: <2940652.8CSySHLyHu@42> On Tuesday 01 of March 2016 14:15:30 Tim Blechmann wrote: > hi all, > > it seems that i cannot integrate changes into 5.6 anymore: > > http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1456811813.thrif > > t_bin > seems that i'm always hitting a timeout somewhere ... is this a known > issue? i was hoping that the following changes could make it into 5.6: > https://codereview.qt-project.org/#/c/149223/ > https://codereview.qt-project.org/#/c/150084/ > https://codereview.qt-project.org/#/c/150645/ > > all of them are bug fixes ... > > thnx, > tim Hi, Just fast update on the issue. I thought that this is fixed: http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1456811813.thrift_bin Thanks for pointing it out. Time handling in virtualiazed environment is not reliable, and sometimes source packages are created in future... Anyway I know how to workaround it a fix is coming hopefully soon. On the other hand this one https://codereview.qt-project.org/#/c/150084/ Was caused by a source incompatible change in qtbase. In such cases re-staging is just a waste of resources. This one https://codereview.qt-project.org/#/c/150645/ is most interesting. It contains a failure because make install in iOS build took more then 20 min(?). Another timeout was caused because of a temporary network failure (https://bugreports.qt.io/browse/QTQAINFRA-969). Cheers, Jędrek From jedrzej.nowacki at theqtcompany.com Fri Mar 4 13:08:08 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 4 Mar 2016 13:08:08 +0100 Subject: [Development] debug symbols for official Qt releases In-Reply-To: References: <8332748.PF6apbcbs5@milian-kdab2> Message-ID: <5849001.gGKWZOkOhf@42> On Wednesday 02 of March 2016 09:00:35 Gunnar Roth wrote: > >On 2016-03-01, Milian Wolff wrote: > >> b) Apparently there are never any debug symbols shipped for the release > >> build fo Qt. Having debug symbols even for a release build is crucial > >> for a good profiling experience. Could we maybe get release builds in > >> the future with - force-debug-info to improve this situation? I'm aware > >> that one can get some sense out of a profiler when only the end-level > >> application is build in that way, but one can often get much more > >> insight when the stack below (or even in- between for the eventloop and > >> signal/slot magic) also gets annotated stack frames. Right now, I have > >> to suggest people to build Qt themselves for the sole purpose of > >> profiling... A pity! > > > >This would be amazing. Also for getting better backtraces from crashes > >at users systems. > > I normally use release build always even for debugging. It were also nice if > Qt would set the enhanced pdb option to get better release debugging > experience, /d2Zi+ option for vs2012 and /Zo for Vs2013 upd3 and VS2015. > > As i have other reasons to always build Qt myself and maintain patches > others than these, i have no real problem with the current state, but would > still be glad if pdb for release are build and delivered with the enhanced > pdb option. > > Regards, > Gunnar Roth > This is related: https://bugreports.qt.io/browse/QTBUG-29668 The option is being evaluated. The main problem is that it seems that the installer size grows 2x with force-debug-info enabled, we need to confirm that it is not the case. Cheers, Jędrek From ulf.hermann at theqtcompany.com Fri Mar 4 13:22:05 2016 From: ulf.hermann at theqtcompany.com (Ulf Hermann) Date: Fri, 4 Mar 2016 13:22:05 +0100 Subject: [Development] debug symbols for official Qt releases In-Reply-To: <5849001.gGKWZOkOhf@42> References: <8332748.PF6apbcbs5@milian-kdab2> <5849001.gGKWZOkOhf@42> Message-ID: <56D97DED.6080908@theqtcompany.com> > The option is being evaluated. The main problem is that it seems that the > installer size grows 2x with force-debug-info enabled, we need to confirm that > it is not the case. You can add the debug symbols as optional separate packages. People who need them can install them then, and we don't need to push larger installers to anyone else. In fact, the current release packages could be even smaller if we strip out the rudimentary debug symbols they currently contain. regards, Ulf From jani.heikkinen at theqtcompany.com Fri Mar 4 13:23:10 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Fri, 4 Mar 2016 12:23:10 +0000 Subject: [Development] Qt 5.7 alpha packages available Message-ID: Hi all, We have Qt 5.7 Alpha src packages available here: http://download.qt.io/snapshots/qt/5.7/5.7.0-alpha/latest_src/ Please check the packages to see if those are ok for Alpha purposes (compilation seems to work, all needed modules etc are in the packages). We will release these packages as Qt 5.7 Alpha at the beginning of next week If no alpha blockers found so please inform all alpha blockers immediately to qt-releases at digia.com (please remember to fill proper bug report as well) . br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at theqtcompany.com Fri Mar 4 13:47:25 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 4 Mar 2016 13:47:25 +0100 Subject: [Development] debug symbols for official Qt releases In-Reply-To: <56D97DED.6080908@theqtcompany.com> References: <8332748.PF6apbcbs5@milian-kdab2> <5849001.gGKWZOkOhf@42> <56D97DED.6080908@theqtcompany.com> Message-ID: <1788947.PHRDAavIEV@42> On Friday 04 of March 2016 13:22:05 Ulf Hermann wrote: > > The option is being evaluated. The main problem is that it seems that the > > installer size grows 2x with force-debug-info enabled, we need to confirm > > that it is not the case. > > You can add the debug symbols as optional separate packages. People who need > them can install them then, and we don't need to push larger installers to > anyone else. In fact, the current release packages could be even smaller if > we strip out the rudimentary debug symbols they currently contain. > > regards, > Ulf Yes, of course we can, but it requires more work to do, so it is better to evaluate the size first :-) Cheers, Jędrek From jedrzej.nowacki at theqtcompany.com Fri Mar 4 14:18:00 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 4 Mar 2016 14:18:00 +0100 Subject: [Development] templated QObjects [was: Re: We are planning to upgrade qdoc to use clang for parsing C++] In-Reply-To: <2705763.7WDAeJMAmA@tjmaciei-mobl4> References: <2436443.lQHY3mroNT@42> <2705763.7WDAeJMAmA@tjmaciei-mobl4> Message-ID: <4690812.5qUBiZkdgb@42> On Monday 29 of February 2016 08:38:30 Thiago Macieira wrote: > On segunda-feira, 29 de fevereiro de 2016 10:09:51 PST Jędrzej Nowacki wrote: > > On Friday 26 of February 2016 15:56:08 Thiago Macieira wrote: > > > > I.e. what problems would we get from having to install the > > > > moc files? > > > > > > Lots. > > > > And probably all go away if instead of installing anything we use > > QMetaObjectBuilder (assuming it's api stabilization). Yes it would have > > performance impact, but only on the templated version and only during > > initialization, qml is paying that price constantly without bigger > > complains. It would not require any build system changes. The only > > limitation I can think of right now is that in QObject, Foo needs to > > be know to QMetaType system, which is not a big deal. > > What source data do you propose for QMOB? So for QObject moc should generate something like that: { QMetaObjectBuilder builder; // Side note: add overloads that takes type id builder.addProperty("property", "int") builder.addMethod("void Invokable(int)"); builder.setClassName("QObject<" + QMetaType::typeName(qMetaTypeId()) + ">") return builder.toMetaObject(); } Yes, it is super inefficient, but in the same time I think it is quite safe to support. Cheers, Jędrek From ulf.hermann at theqtcompany.com Fri Mar 4 14:36:05 2016 From: ulf.hermann at theqtcompany.com (Ulf Hermann) Date: Fri, 4 Mar 2016 14:36:05 +0100 Subject: [Development] debug symbols for official Qt releases In-Reply-To: <1788947.PHRDAavIEV@42> References: <8332748.PF6apbcbs5@milian-kdab2> <5849001.gGKWZOkOhf@42> <56D97DED.6080908@theqtcompany.com> <1788947.PHRDAavIEV@42> Message-ID: <56D98F45.6010807@theqtcompany.com> > Yes, of course we can, but it requires more work to do, so it is better to > evaluate the size first :-) I can tell you right away that debug symbols are insanely large. Just create a debug build of Qt and notice that it's gigabytes in size. Don't try to fit that into our current packages, please. That would just lead to bad compromises. Do create separate packages and include the full debug info there. We can even have separate debug symbols packages per module, to keep the size manageable. I guess not everyone wants to debug QtWebkit, after all, which has 650MB alone here. I guess QtWebengine is even larger, but I haven't built it. cheers, Ulf From filippocucchetto at gmail.com Fri Mar 4 14:37:15 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Fri, 4 Mar 2016 14:37:15 +0100 Subject: [Development] debug symbols for official Qt releases In-Reply-To: <56D98F45.6010807@theqtcompany.com> References: <8332748.PF6apbcbs5@milian-kdab2> <5849001.gGKWZOkOhf@42> <56D97DED.6080908@theqtcompany.com> <1788947.PHRDAavIEV@42> <56D98F45.6010807@theqtcompany.com> Message-ID: 2016-03-04 14:36 GMT+01:00 Ulf Hermann : > Yes, of course we can, but it requires more work to do, so it is better to >> evaluate the size first :-) >> > > I can tell you right away that debug symbols are insanely large. Just > create a debug build of Qt and notice that it's gigabytes in size. Don't > try to fit that into our current packages, please. That would just lead to > bad compromises. Do create separate packages and include the full debug > info there. We can even have separate debug symbols packages per module, to > keep the size manageable. I guess not everyone wants to debug QtWebkit, > after all, which has 650MB alone here. I guess QtWebengine is even larger, > but I haven't built it. > > cheers, > Ulf > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > +1 -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Mar 4 17:46:02 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Mar 2016 08:46:02 -0800 Subject: [Development] Dropping qtserialbus from Qt 5.6 -- it doesn't compile in C++98 In-Reply-To: References: <20816981.PMDPkoXTW7@tjmaciei-mobl4> <3781298.IVj7hYPjYB@tjmaciei-mobl4> Message-ID: <2599179.WNVl5iS2fx@tjmaciei-mobl4> On sexta-feira, 4 de março de 2016 10:03:22 PST Blasche Alexander wrote: > >Because you also need to reject some older Clang versions. Did you add the > >check for them too? > > clang 3.4 is rejected by requires(c++11) already. It shouldn't be. Clang 3.4 is C++11-feature-complete. I was thinking of Clang 3.1 or thereabouts and it shouldn't be rejected either. Think of XCode 5.0 that some people might be still using. > Effort and speed. The compile test should not delay the 5.6.0 release and > such a test would take much more time. After all we would have to go > through the entire code base and identify all C++11 features we are using. > That's bound to have the same gaps too. I already gave you a list. It might not be complete, but I think it is. More importantly, if you had used the list, it would catch issues that aren't being caught right now with the incomplete version-based check. > I want to emphasize qtserialbus is not the first module to do such a > compiler based rejection pattern. For 5.6.0 this is good enough. It shouldn't be. We've never had that. Adding that thing to an LTS release before we know how things work... > Nevertheless I filed https://bugreports.qt.io/browse/QTBUG-51655 and we > might have a better solution for 5.6.1. Thanks. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Mar 4 23:27:49 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 4 Mar 2016 23:27:49 +0100 Subject: [Development] Are we free of code that checks this isn't null? In-Reply-To: <4641502.ptqUsJBUAZ@tjmaciei-mobl4> References: <3576441.RbKHnCWb96@tjmaciei-mobl4> <201603040958.53429.marc.mutz@kdab.com> <4641502.ptqUsJBUAZ@tjmaciei-mobl4> Message-ID: <201603042327.49886.marc.mutz@kdab.com> On Friday 04 March 2016 08:59:59 Thiago Macieira wrote: > > /me upgrades to GCC 6. > > I might still have a patch or two that aren't merged that fix GCC 6 > warnings. But when you compile with it, can you make sure it doesn't > print any misleading-identation warnings? There were a couple of false > positives that I reported and GCC fixed. Do you also have a fix for this one: ../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qobjectdefs.h:175:108: error: ‘visibility’ attribute ignored [-Werror=attributes] Q_DECL_HIDDEN_STATIC_METACALL static void qt_static_metacall(QObject *, QMetaObject::Call, int, void **); \ ^ /home/marc/Qt/qt5/qtbase/src/widgets/dialogs/qcolordialog.cpp:181:5: note: in expansion of macro ‘Q_OBJECT’ Q_OBJECT ^~~~~~~~ ? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Sat Mar 5 00:21:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Mar 2016 15:21:38 -0800 Subject: [Development] Are we free of code that checks this isn't null? In-Reply-To: <201603042327.49886.marc.mutz@kdab.com> References: <3576441.RbKHnCWb96@tjmaciei-mobl4> <4641502.ptqUsJBUAZ@tjmaciei-mobl4> <201603042327.49886.marc.mutz@kdab.com> Message-ID: <8036338.OulfgGT4if@tjmaciei-mobl4> On sexta-feira, 4 de março de 2016 23:27:49 PST Marc Mutz wrote: > Do you also have a fix for this one: > > ../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qobjectdefs > .h:175:108: error: ‘visibility’ attribute ignored [-Werror=attributes] > Q_DECL_HIDDEN_STATIC_METACALL static void qt_static_metacall(QObject > *, QMetaObject::Call, int, void **); \ Yes, but I can't find it. I might have dropped it because it wasn't working, due to a GCC bug. The bug has since been fixed. We need to make Q_DECL_HIDDEN_STATIC_METACALL include the pragma disabling that particular warning. This is a blind, untested change: https://codereview.qt-project.org/151467 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Sat Mar 5 02:17:59 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 5 Mar 2016 02:17:59 +0100 Subject: [Development] Are we free of code that checks this isn't null? In-Reply-To: <8036338.OulfgGT4if@tjmaciei-mobl4> References: <3576441.RbKHnCWb96@tjmaciei-mobl4> <201603042327.49886.marc.mutz@kdab.com> <8036338.OulfgGT4if@tjmaciei-mobl4> Message-ID: <201603050218.01427.marc.mutz@kdab.com> On Saturday 05 March 2016 00:21:38 Thiago Macieira wrote: > On sexta-feira, 4 de março de 2016 23:27:49 PST Marc Mutz wrote: > > Do you also have a fix for this one: > > ../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qobjectd > > efs > > > > .h:175:108: error: ‘visibility’ attribute ignored [-Werror=attributes] > > > > Q_DECL_HIDDEN_STATIC_METACALL static void > > qt_static_metacall(QObject > > > > *, QMetaObject::Call, int, void **); \ > > Yes, but I can't find it. I might have dropped it because it wasn't > working, due to a GCC bug. The bug has since been fixed. > > We need to make Q_DECL_HIDDEN_STATIC_METACALL include the pragma disabling > that particular warning. > > This is a blind, untested change: > https://codereview.qt-project.org/151467 Didn't work for me, but gave me the right idea. Fixed now. Updated. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Sat Mar 5 01:14:19 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 04 Mar 2016 16:14:19 -0800 Subject: [Development] Are we free of code that checks this isn't null? In-Reply-To: <201603050218.01427.marc.mutz@kdab.com> References: <3576441.RbKHnCWb96@tjmaciei-mobl4> <8036338.OulfgGT4if@tjmaciei-mobl4> <201603050218.01427.marc.mutz@kdab.com> Message-ID: <1607687.y7o5Q6kZg0@tjmaciei-mobl4> On sábado, 5 de março de 2016 02:17:59 PST Marc Mutz wrote: > On Saturday 05 March 2016 00:21:38 Thiago Macieira wrote: > > On sexta-feira, 4 de março de 2016 23:27:49 PST Marc Mutz wrote: > > > Do you also have a fix for this one: > > > ../../include/QtCore/../../../../qt5/qtbase/src/corelib/kernel/qobject > > > d > > > efs > > > > > > .h:175:108: error: ‘visibility’ attribute ignored [-Werror=attributes] > > > > > > Q_DECL_HIDDEN_STATIC_METACALL static void > > > qt_static_metacall(QObject > > > > > > *, QMetaObject::Call, int, void **); \ > > > > Yes, but I can't find it. I might have dropped it because it wasn't > > working, due to a GCC bug. The bug has since been fixed. > > > > We need to make Q_DECL_HIDDEN_STATIC_METACALL include the pragma disabling > > that particular warning. > > > > This is a blind, untested change: > > https://codereview.qt-project.org/151467 > > Didn't work for me, but gave me the right idea. Fixed now. Updated. Thanks. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Sun Mar 6 01:38:04 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Sat, 05 Mar 2016 21:38:04 -0300 Subject: [Development] debug symbols for official Qt releases In-Reply-To: <56D98F45.6010807@theqtcompany.com> References: <8332748.PF6apbcbs5@milian-kdab2> <1788947.PHRDAavIEV@42> <56D98F45.6010807@theqtcompany.com> Message-ID: <3909644.94tANpcXlZ@luna> On Friday 04 March 2016 14:36:05 Ulf Hermann wrote: > > Yes, of course we can, but it requires more work to do, so it is better to > > evaluate the size first :-) > > I can tell you right away that debug symbols are insanely large. Just create > a debug build of Qt and notice that it's gigabytes in size. Don't try to > fit that into our current packages, please. That would just lead to bad > compromises. Do create separate packages and include the full debug info > there. We can even have separate debug symbols packages per module, to keep > the size manageable. I guess not everyone wants to debug QtWebkit, after > all, which has 650MB alone here. I guess QtWebengine is even larger, but I > haven't built it. Confirmed, debug packages are *huge*. I think it even makes sense to have them per-submodule too. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Sun Mar 6 03:07:57 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 06 Mar 2016 03:07:57 +0100 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? References: <1607479.SZ4LZPosDG@tjmaciei-mobl4> <178C4D98-A9FF-4962-8A8C-0AAF5245F585@theqtcompany.com> Message-ID: Knoll Lars wrote: > Curtis Mitch wrote: >>Ferocious Triceratops Baring Fearsome Strength? Phew. I thought we'd >>gotten rid of all of those! > > Took me two minutes to parse that one as well. Failure to build from > source. FTBFS is an acronym that, as far as I can tell, originated from Debian, but has since spread to other communities. (E.g., we now use it in Fedora, too.) Kevin Kofler From 416365416c at gmail.com Sun Mar 6 08:40:56 2016 From: 416365416c at gmail.com (Alan Alpert) Date: Sat, 5 Mar 2016 23:40:56 -0800 Subject: [Development] QtQuick Call for Maintainer Message-ID: Hi all, I have been drawn away from Qt Quick at work the past several months, for even I do not write back-end services with Qt Quick. Consequently I have not had time to fulfill the responsibilities of Qt Quick Maintainership and will have to pass the mantle onto someone new. Accepting the unfortunate nature of reality means that I must resign from the QtQuick maintainership position. Accordingly I have removed my name from the maintainers wiki page. Everyone on gerrit knows I'm not getting to my reviews anymore, so I can no longer hold a module maintainer position. It would be great if someone else could step up and take over, as I still believe QtQuick is a key component of the premier native GUI framework. Any volunteers? -- Alan Alpert From Lars.Knoll at theqtcompany.com Sun Mar 6 09:46:51 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Sun, 6 Mar 2016 08:46:51 +0000 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: References: Message-ID: Hi Alan, Thanks a lot for your work on Qt Quick over the years. Let's see who can take over this role, let me/us know if you have an interest and feel qualified. Cheers, Lars On 06/03/16 08:40, "Development on behalf of Alan Alpert" wrote: >Hi all, > >I have been drawn away from Qt Quick at work the past several months, >for even I do not write back-end services with Qt Quick. Consequently >I have not had time to fulfill the responsibilities of Qt Quick >Maintainership and will have to pass the mantle onto someone new. > >Accepting the unfortunate nature of reality means that I must resign >from the QtQuick maintainership position. Accordingly I have removed >my name from the maintainers wiki page. Everyone on gerrit knows I'm >not getting to my reviews anymore, so I can no longer hold a module >maintainer position. > >It would be great if someone else could step up and take over, as I >still believe QtQuick is a key component of the premier native GUI >framework. Any volunteers? > >-- >Alan Alpert >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From sean.harmer at kdab.com Sun Mar 6 10:16:13 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Sun, 06 Mar 2016 09:16:13 +0000 Subject: [Development] codereview.qt-project.org certificate has expired Message-ID: <112097908.sMxtiGV4nD@titan> As per the subject. Can the sysadmins please install a new certificate please? Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions From mitya57.ml at gmail.com Sun Mar 6 19:40:38 2016 From: mitya57.ml at gmail.com (Dmitry Shachnev) Date: Sun, 6 Mar 2016 21:40:38 +0300 Subject: [Development] Problems with QtWebKit 5.6 Message-ID: <20160306184038.GA1823@mitya57.me> Hi all, I am currently packaging Qt 5.6 release candidate for Debian and I have encountered some problems with QtWebKit. 1. Looks like the tarballs were build without calling syncqt. That issue was easy to work-around and we are now calling syncqt before the build. However it would be nice to have the final tarballs built properly. 2. There is a linking error when building libQt5WebKit.so on some architectures (arm, mipsel and s390x): it reports undefined reference to pthread_*, even though -lpthread is present in the command line. I compared it with QtWebKit 5.5.1 build log and noticed that in 5.5.0 log there are 10 occurences of -lpthread in link command, however in 5.6.0 there is only one — though it's early enough (before -lWebKit1 and -lWTF). Was there some optimization in qmake that removes duplicate link flags? Can it be the reason for this issue? If yes, is there any known workaround? The build logs are available at: https://buildd.debian.org/status/package.php?p=qtwebkit-opensource-src&suite=experimental -- Dmitry Shachnev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From annulen at yandex.ru Sun Mar 6 19:45:49 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 06 Mar 2016 21:45:49 +0300 Subject: [Development] Problems with QtWebKit 5.6 In-Reply-To: <20160306184038.GA1823@mitya57.me> References: <20160306184038.GA1823@mitya57.me> Message-ID: <863471457289949@web19j.yandex.ru> 06.03.2016, 21:40, "Dmitry Shachnev" : > Hi all, > > I am currently packaging Qt 5.6 release candidate for Debian and I have > encountered some problems with QtWebKit. > > 1. Looks like the tarballs were build without calling syncqt. That issue was >    easy to work-around and we are now calling syncqt before the build. However >    it would be nice to have the final tarballs built properly. > > 2. There is a linking error when building libQt5WebKit.so on some architectures >    (arm, mipsel and s390x): it reports undefined reference to pthread_*, even >    though -lpthread is present in the command line. > >    I compared it with QtWebKit 5.5.1 build log and noticed that in 5.5.0 log >    there are 10 occurences of -lpthread in link command, however in 5.6.0 there >    is only one — though it's early enough (before -lWebKit1 and -lWTF). This patch should help: https://codereview.qt-project.org/#/c/150601 > >    Was there some optimization in qmake that removes duplicate link flags? > >    Can it be the reason for this issue? If yes, is there any known workaround? > >    The build logs are available at: >    https://buildd.debian.org/status/package.php?p=qtwebkit-opensource-src&suite=experimental > > -- > Dmitry Shachnev > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From mitya57.ml at gmail.com Sun Mar 6 20:23:34 2016 From: mitya57.ml at gmail.com (Dmitry Shachnev) Date: Sun, 06 Mar 2016 22:23:34 +0300 Subject: [Development] Problems with QtWebKit 5.6 In-Reply-To: <863471457289949@web19j.yandex.ru> References: <863471457289949@web19j.yandex.ru> <20160306184038.GA1823@mitya57.me> Message-ID: <145729221479.3848.3299004348535638251@mitya57.me> On Sun, 06 Mar 2016 21:45:49 +0300, Konstantin Tokarev wrote: >> 2. There is a linking error when building libQt5WebKit.so on some architectures >> (arm, mipsel and s390x): it reports undefined reference to pthread_*, even >> though -lpthread is present in the command line. > > This patch should help: > > https://codereview.qt-project.org/#/c/150601 Thanks a lot! How could I not notice it… -- Dmitry Shachnev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From thiago.macieira at intel.com Sun Mar 6 20:43:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 06 Mar 2016 11:43:36 -0800 Subject: [Development] Problems with QtWebKit 5.6 In-Reply-To: <20160306184038.GA1823@mitya57.me> References: <20160306184038.GA1823@mitya57.me> Message-ID: <1670018.s4nNadPzIq@tjmaciei-mobl4> On domingo, 6 de março de 2016 21:40:38 PST Dmitry Shachnev wrote: > 2. There is a linking error when building libQt5WebKit.so on some > architectures (arm, mipsel and s390x): it reports undefined reference to > pthread_*, even though -lpthread is present in the command line. > > I compared it with QtWebKit 5.5.1 build log and noticed that in 5.5.0 log > there are 10 occurences of -lpthread in link command, however in 5.6.0 > there is only one — though it's early enough (before -lWebKit1 and -lWTF). If it's before, it's wrong. If A depends on B, the link order must be -lA -lB. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jedrzej.nowacki at theqtcompany.com Mon Mar 7 08:38:26 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 7 Mar 2016 08:38:26 +0100 Subject: [Development] codereview.qt-project.org certificate has expired In-Reply-To: <112097908.sMxtiGV4nD@titan> References: <112097908.sMxtiGV4nD@titan> Message-ID: <1667335.HSaMc7KJzs@42> On Sunday 06 of March 2016 09:16:13 Sean Harmer wrote: > As per the subject. Can the sysadmins please install a new certificate > please? > > Sean > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - Qt Experts - Platform-independent software solutions > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development I've already informed our IT support about the issue. Thanks, Jędrek From tuukka.turunen at theqtcompany.com Mon Mar 7 13:56:32 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Mon, 7 Mar 2016 12:56:32 +0000 Subject: [Development] codereview.qt-project.org certificate has expired In-Reply-To: <1667335.HSaMc7KJzs@42> References: <112097908.sMxtiGV4nD@titan> <1667335.HSaMc7KJzs@42> Message-ID: Hi, Yes, this is in progress. Unfortunately the renewal email went to a wrong address. We'll hopefully get new certificate in place very soon. Yours, Tuukka > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=theqtcompany.com at qt-project.org] On Behalf Of > Jedrzej Nowacki > Sent: maanantaina 7. maaliskuuta 2016 9.38 > To: development at qt-project.org > Cc: Sean Harmer > Subject: Re: [Development] codereview.qt-project.org certificate has > expired > > On Sunday 06 of March 2016 09:16:13 Sean Harmer wrote: > > As per the subject. Can the sysadmins please install a new certificate > > please? > > > > Sean > > -- > > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > > Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) > > +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - > > Platform-independent software solutions > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > I've already informed our IT support about the issue. > > Thanks, > Jędrek > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From frederik.gladhorn at theqtcompany.com Mon Mar 7 16:13:08 2016 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Mon, 7 Mar 2016 16:13:08 +0100 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: References: Message-ID: <2508645.p7ii8jUgpk@frederik-thinkcentre-m93p> Hello Alan, thanks a lot for all the work you've done! On Saturday, March 05, 2016 11:40:56 PM Alan Alpert wrote: > Hi all, > > I have been drawn away from Qt Quick at work the past several months, > for even I do not write back-end services with Qt Quick. Consequently > I have not had time to fulfill the responsibilities of Qt Quick > Maintainership and will have to pass the mantle onto someone new. > > Accepting the unfortunate nature of reality means that I must resign > from the QtQuick maintainership position. Accordingly I have removed > my name from the maintainers wiki page. Everyone on gerrit knows I'm > not getting to my reviews anymore, so I can no longer hold a module > maintainer position. > > It would be great if someone else could step up and take over, as I > still believe QtQuick is a key component of the premier native GUI > framework. Any volunteers? I'd like to propose Shawn Rutledge as maintainer for Qt Quick. Shawn has a lot of experience working with and on Qt Quick, recently also in some customer projects using Qt Quick. He'll be able to focus most of his work time on Qt Quick and has quite some ideas for improvements, for example when it comes to touch handling. Shawn has the team in Oslo behind him, so he wouldn't have to carry the torch/ mantle all by himself either ;) Greetings, Frederik > > -- > Alan Alpert > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lorn.potter at canonical.com Mon Mar 7 20:40:22 2016 From: lorn.potter at canonical.com (Lorn Potter) Date: Tue, 8 Mar 2016 05:40:22 +1000 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: <2508645.p7ii8jUgpk@frederik-thinkcentre-m93p> References: <2508645.p7ii8jUgpk@frederik-thinkcentre-m93p> Message-ID: <56DDD926.1060903@canonical.com> On 08/03/16 01:13, Frederik Gladhorn wrote: > I'd like to propose Shawn Rutledge as maintainer for Qt Quick. +1 -- Software Engineer Hardware Enablement Canonical Ltd From gunnar at sletta.org Mon Mar 7 20:45:01 2016 From: gunnar at sletta.org (Gunnar Sletta) Date: Mon, 7 Mar 2016 20:45:01 +0100 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: References: Message-ID: I'm sorry to see you step down, Alan. Thanks for all the good work! I would like to suggest Robin Burchell for the role of future Qt Quick maintainer. He is a long time Qt contributor and has repeatedly shown insight and dedication to the project. From various work he has solid experience building complex software stacks in Qt and on top of Qt Quick. He has a good overview over the Qt Quick stack and how it comes together, including the V4 engine, the UI elements, event handling and rendering. He also cares greatly about the overall performance and has been responsible for removing overhead and improving performance in every major Qt release for the last couple of years. Something Qt Quick very much needs. He also keeps a keen eye on the bugtracker and codereview in the Qt Quick area. cheers, Gunnar > On 06 Mar 2016, at 08:40, Alan Alpert <416365416c at gmail.com> wrote: > > Hi all, > > I have been drawn away from Qt Quick at work the past several months, > for even I do not write back-end services with Qt Quick. Consequently > I have not had time to fulfill the responsibilities of Qt Quick > Maintainership and will have to pass the mantle onto someone new. > > Accepting the unfortunate nature of reality means that I must resign > from the QtQuick maintainership position. Accordingly I have removed > my name from the maintainers wiki page. Everyone on gerrit knows I'm > not getting to my reviews anymore, so I can no longer hold a module > maintainer position. > > It would be great if someone else could step up and take over, as I > still believe QtQuick is a key component of the premier native GUI > framework. Any volunteers? > > -- > Alan Alpert > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From mitch.curtis at theqtcompany.com Mon Mar 7 20:55:11 2016 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Mon, 7 Mar 2016 19:55:11 +0000 Subject: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties Message-ID: Recently I noticed this sentence in QObject's documentation [1]: We strongly recommend the use of this macro in all subclasses of QObject regardless of whether or not they actually use signals, slots and properties, since failure to do so may lead certain functions to exhibit strange behavior. Why is this the case? What strange behaviour could result from not doing so? [1] http://doc.qt.io/qt-5/qobject.html#Q_OBJECT From andre at familiesomers.nl Mon Mar 7 20:58:42 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 7 Mar 2016 20:58:42 +0100 Subject: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties In-Reply-To: References: Message-ID: <56DDDD72.7020800@familiesomers.nl> Op 07/03/2016 om 20:55 schreef Curtis Mitch: > Recently I noticed this sentence in QObject's documentation [1]: > > We strongly recommend the use of this macro in all subclasses of QObject regardless of whether or not they actually use signals, slots and properties, since failure to do so may lead certain functions to exhibit strange behavior. > > Why is this the case? What strange behaviour could result from not doing so? > > [1] http://doc.qt.io/qt-5/qobject.html#Q_OBJECT Functions like QObject::inherits come to mind. André From giuseppe.dangelo at kdab.com Mon Mar 7 21:19:19 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 7 Mar 2016 21:19:19 +0100 Subject: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties In-Reply-To: References: Message-ID: <56DDE247.7000202@kdab.com> Il 07/03/2016 20:55, Curtis Mitch ha scritto: > Why is this the case? What strange behaviour could result from not doing so? qobject_cast breaks; the meta object system reports and uses the wrong class name (so things like "inherits", "className" etc. don't work); tr() uses the wrong context; and so on. qobject_cast breakage may be serious enough to justify an automatic -1 to all public QObjects-without-Q_OBJECT classes. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From mitch.curtis at theqtcompany.com Mon Mar 7 21:21:54 2016 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Mon, 7 Mar 2016 20:21:54 +0000 Subject: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties In-Reply-To: <56DDE247.7000202@kdab.com> References: , <56DDE247.7000202@kdab.com> Message-ID: Thanks guys. Is this worth mentioning in the documentation? ________________________________________ From: Development on behalf of Giuseppe D'Angelo Sent: Monday, 7 March 2016 21:19 To: development at qt-project.org Subject: Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties Il 07/03/2016 20:55, Curtis Mitch ha scritto: > Why is this the case? What strange behaviour could result from not doing so? qobject_cast breaks; the meta object system reports and uses the wrong class name (so things like "inherits", "className" etc. don't work); tr() uses the wrong context; and so on. qobject_cast breakage may be serious enough to justify an automatic -1 to all public QObjects-without-Q_OBJECT classes. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts From apoenitz at t-online.de Mon Mar 7 21:29:06 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 7 Mar 2016 21:29:06 +0100 Subject: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties In-Reply-To: References: Message-ID: <20160307202905.GA2464@klara.mpi.htwm.de> On Mon, Mar 07, 2016 at 07:55:11PM +0000, Curtis Mitch wrote: > Recently I noticed this sentence in QObject's documentation [1]: > > We strongly recommend the use of this macro in all subclasses of QObject regardless of whether or > not they actually use signals, slots and properties, since failure to do so may lead certain > functions to exhibit strange behavior. > > Why is this the case? > What strange behaviour could result from not doing so? Behaviour from not adding Q_OBJECT to classes is well-defined. Whether the result can be considered "strange" is subjective. Documenting behaviour as "strange" is what appears strange to me. IMNSHO the advice to add Q_OBJECT to user code even if not needed is plainly bad as doing so adds compile time and code size overhead. For Qt's own classes it makes sense to a certain degree to e.g. allow qobject_cast in potential user code uniformly. For normal applications *using* Qt that know their needs adding unnecessary Q_OBJECTs is likely to be as beneficial as snake oil. Andre' From andre at familiesomers.nl Mon Mar 7 21:26:01 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 7 Mar 2016 21:26:01 +0100 Subject: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties In-Reply-To: References: <56DDE247.7000202@kdab.com> Message-ID: <56DDE3D9.8020706@familiesomers.nl> Op 07/03/2016 om 21:21 schreef Curtis Mitch: > Thanks guys. > > Is this worth mentioning in the documentation? It already says so, right? I don't think it is needed to specify exactly what breaks. André > > ________________________________________ > From: Development on behalf of Giuseppe D'Angelo > Sent: Monday, 7 March 2016 21:19 > To: development at qt-project.org > Subject: Re: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties > > Il 07/03/2016 20:55, Curtis Mitch ha scritto: >> Why is this the case? What strange behaviour could result from not doing so? > qobject_cast breaks; the meta object system reports and uses the wrong > class name (so things like "inherits", "className" etc. don't work); > tr() uses the wrong context; and so on. > > qobject_cast breakage may be serious enough to justify an automatic -1 > to all public QObjects-without-Q_OBJECT classes. > > Cheers, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 > KDAB - The Qt Experts > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From apoenitz at t-online.de Mon Mar 7 21:33:43 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 7 Mar 2016 21:33:43 +0100 Subject: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties In-Reply-To: References: <56DDE247.7000202@kdab.com> Message-ID: <20160307203343.GA2603@klara.mpi.htwm.de> On Mon, Mar 07, 2016 at 08:21:54PM +0000, Curtis Mitch wrote: > Thanks guys. > > Is this worth mentioning in the documentation? I think it would make sense to list the features that are affected so that users can decide whether they actually need one of them, or not, instead of having this unspecific (and untrue) "strange things may happen". Andre' From marc.mutz at kdab.com Mon Mar 7 23:20:43 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 7 Mar 2016 23:20:43 +0100 Subject: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties In-Reply-To: References: Message-ID: <201603072320.43397.marc.mutz@kdab.com> On Monday 07 March 2016 20:55:11 Curtis Mitch wrote: > Recently I noticed this sentence in QObject's documentation [1]: > > We strongly recommend the use of this macro in all subclasses of QObject > regardless of whether or not they actually use signals, slots and > properties, since failure to do so may lead certain functions to exhibit > strange behavior. > > Why is this the case? What strange behaviour could result from not doing > so? > > [1] http://doc.qt.io/qt-5/qobject.html#Q_OBJECT Shameless plug: https://marcmutz.wordpress.com/effective-qt/subclassing/ -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From jpnurmi at theqtcompany.com Tue Mar 8 09:04:21 2016 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Tue, 8 Mar 2016 08:04:21 +0000 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: References: Message-ID: > On 07 Mar 2016, at 20:45, Gunnar Sletta wrote: > > I would like to suggest Robin Burchell for the role of future Qt Quick maintainer. > > He is a long time Qt contributor and has repeatedly shown insight and dedication to the project. From various work he has solid experience building complex software stacks in Qt and on top of Qt Quick. > > He has a good overview over the Qt Quick stack and how it comes together, including the V4 engine, the UI elements, event handling and rendering. He also cares greatly about the overall performance and has been responsible for removing overhead and improving performance in every major Qt release for the last couple of years. Something Qt Quick very much needs. > > He also keeps a keen eye on the bugtracker and codereview in the Qt Quick area. +1 Robin is an ideal candidate to drive the future of Qt Quick. He has a strong track record and a solid understanding of the whole stack, including its strengths and weaknesses. -- J-P Nurmi From edward.welbourne at theqtcompany.com Tue Mar 8 09:09:49 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Tue, 8 Mar 2016 08:09:49 +0000 Subject: [Development] Usage of Q_OBJECT macro in QObject subclasses that don't use signals, slots, or properties In-Reply-To: <20160307203343.GA2603@klara.mpi.htwm.de> References: <56DDE247.7000202@kdab.com> , <20160307203343.GA2603@klara.mpi.htwm.de> Message-ID: Mitch asked: >> Is this worth mentioning in the documentation? Andre' P replied: > I think it would make sense to list the features that are affected so > that users can decide whether they actually need one of them, or not, > instead of having this unspecific (and untrue) "strange things may > happen". The nearest I can get to thinking of a good reason to leave it unspecific is that it leaves open the possibility that later versions of Qt shall exhibit different strangeness due to a change in Q_OBJECT. This is the usual rationale, for example in a standard, for saying that certain usages may lead to "undefined" behaviour. All the same, the phrasing "strange things may happen" is a red flag - too vague to be useful, so it makes Q_OBJECT sound like magic. Prudent programmers mistrust magic. In the present case, I do think it is worth giving at least some idea of what the problem with omitting Q_OBJECT is. That can be phrased in "undefined behaviour" terms to leave open scope for future changes, as long as it gives the user enough information to make an informed decision. After all, a template class that inherits from a QObject class *can't* (at present) use Q_OBJECT, because moc can't cope with templates, so leaving out Q_OBJECT has to be an option. That means the client code's author needs to understand the pros and cons of that option. So we should at least outline which aspects of such inheritance are likely to violate the principle of least surprise - which of the promises that we make for a QObject-based class depend (or might, in a future release, depend) on it using Q_OBJECT ? Eddy. From tor.arne.vestbo at theqtcompany.com Tue Mar 8 13:50:39 2016 From: tor.arne.vestbo at theqtcompany.com (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Tue, 8 Mar 2016 13:50:39 +0100 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: References: Message-ID: <56DECA9F.7090406@theqtcompany.com> On 08/03/16 09:04, Nurmi J-P wrote: >> On 07 Mar 2016, at 20:45, Gunnar Sletta wrote: >> >> I would like to suggest Robin Burchell for the role of future Qt >> Quick maintainer. >> >> He is a long time Qt contributor and has repeatedly shown insight >> and dedication to the project. From various work he has solid >> experience building complex software stacks in Qt and on top of Qt >> Quick. >> >> He has a good overview over the Qt Quick stack and how it comes >> together, including the V4 engine, the UI elements, event handling >> and rendering. He also cares greatly about the overall performance >> and has been responsible for removing overhead and improving >> performance in every major Qt release for the last couple of years. >> Something Qt Quick very much needs. >> >> He also keeps a keen eye on the bugtracker and codereview in the Qt >> Quick area. > > +1 > > Robin is an ideal candidate to drive the future of Qt Quick. He has a > strong track record and a solid understanding of the whole stack, > including its strengths and weaknesses. +1! tor arne From rafael.roquetto at kdab.com Tue Mar 8 18:39:50 2016 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Tue, 8 Mar 2016 14:39:50 -0300 Subject: [Development] QNX broken on 5.7 Message-ID: <20160308173935.GA18570@orion> Hello everyone, I would like to point out that QNX is unable to build the 5.7 branch. The commit that probably triggered the breakage is: d6bb01e1779f1840dfbab57c6ecd615587bbde62 Force inclusion of on QNX systems. This raises my first question: should this not have been reported by the CI? This is not the first time that changes go in and break QNX, in spite of having the CI in place. Would anyone have a clue about what is going on? Now, concerning the issue itself, it seems to be a bigger problem: /usr/include/cpp/xxatomic: In instantiation of 'std::atomic<_Ty*>::atomic(_Ty*) [with _Ty = void(QtMsgType, const char*)]': /usr/include/cpp/xxatomic:336:3: error: invalid conversion from 'void (*)(QtMsgType, const char*)' to 'void*' [-fpermissive] /usr/include/cpp/xxatomic:873:15: error: initializing argument 1 of 'void* std::_Atomic_address::operator=(void*)' [-fpermissive] Caused by the following line inside qlogging.cpp: static QBasicAtomicPointer msgHandler = Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler); The problem can be traced to the Dinkumware's std::atomic implementation. Ultimately, qDefaultMsgHandler will be passed as an argument to std::atomic's default ctor, which looks like this: _CONST_FUN atomic(_Ty *_Right) _NOEXCEPT { // construct from _Right _Atomic_address::operator=(_Right); } _Atomic_address is a base class. As you can see, this ctor is implemented using operator=, which looks like this: inline _ITYPE _ATOMIC_ITYPE::operator=(_ITYPE _Value) _NOEXCEPT { // assign _Value to *this atomic_store(this, _Value); return _Value; } ` where _TYPE expands to (void *), thus effectively causing the conversion from void (*)(QtMsgType, const char*) to (void *), which is the error. Interestingly, Dinkumware's std::atomic does provide operator= in terms of _Ty: _Ty *operator=(_Ty *_Right) _NOEXCEPT { // assign from _Right return static_cast<_Ty *>(_Atomic_address::operator=((void *)_Right)); } which makes me think that the ctor is wrongly implemented, since it bypasses this and calls the base class operator= explicitly. I am not sure how to work around this. QBasicAtomicPointer won't let me initialize it with some ugly (void *) pointer. Does it make sense to revert this patch? Is there a way to fall back to the old non-C++11 implementation? 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 - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4861 bytes Desc: not available URL: From Simon.Hausmann at theqtcompany.com Tue Mar 8 19:31:15 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Tue, 8 Mar 2016 18:31:15 +0000 Subject: [Development] QNX broken on 5.7 In-Reply-To: <20160308173935.GA18570@orion> References: <20160308173935.GA18570@orion> Message-ID: <20160308183115.5931089.32732.63034@theqtcompany.com> Hi, When building Qt 5.7 for QNX a special patch is applied in the CI that fixes the Dinkumware headers. You were CCed when this was discussed (Subject was "‎QNX and Dinkumware support for constexpr and nullptr"). Simon Original Message From: Rafael Roquetto Sent: Tuesday, March 8, 2016 18:39 To: development at qt-project.org Subject: [Development] QNX broken on 5.7 Hello everyone, I would like to point out that QNX is unable to build the 5.7 branch. The commit that probably triggered the breakage is: d6bb01e1779f1840dfbab57c6ecd615587bbde62 Force inclusion of on QNX systems. This raises my first question: should this not have been reported by the CI? This is not the first time that changes go in and break QNX, in spite of having the CI in place. Would anyone have a clue about what is going on? Now, concerning the issue itself, it seems to be a bigger problem: /usr/include/cpp/xxatomic: In instantiation of 'std::atomic<_Ty*>::atomic(_Ty*) [with _Ty = void(QtMsgType, const char*)]': /usr/include/cpp/xxatomic:336:3: error: invalid conversion from 'void (*)(QtMsgType, const char*)' to 'void*' [-fpermissive] /usr/include/cpp/xxatomic:873:15: error: initializing argument 1 of 'void* std::_Atomic_address::operator=(void*)' [-fpermissive] Caused by the following line inside qlogging.cpp: static QBasicAtomicPointer msgHandler = Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler); The problem can be traced to the Dinkumware's std::atomic implementation. Ultimately, qDefaultMsgHandler will be passed as an argument to std::atomic's default ctor, which looks like this: _CONST_FUN atomic(_Ty *_Right) _NOEXCEPT { // construct from _Right _Atomic_address::operator=(_Right); } _Atomic_address is a base class. As you can see, this ctor is implemented using operator=, which looks like this: inline _ITYPE _ATOMIC_ITYPE::operator=(_ITYPE _Value) _NOEXCEPT { // assign _Value to *this atomic_store(this, _Value); return _Value; } ` where _TYPE expands to (void *), thus effectively causing the conversion from void (*)(QtMsgType, const char*) to (void *), which is the error. Interestingly, Dinkumware's std::atomic does provide operator= in terms of _Ty: _Ty *operator=(_Ty *_Right) _NOEXCEPT { // assign from _Right return static_cast<_Ty *>(_Atomic_address::operator=((void *)_Right)); } which makes me think that the ctor is wrongly implemented, since it bypasses this and calls the base class operator= explicitly. I am not sure how to work around this. QBasicAtomicPointer won't let me initialize it with some ugly (void *) pointer. Does it make sense to revert this patch? Is there a way to fall back to the old non-C++11 implementation? 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 - Qt Experts From rafael.roquetto at kdab.com Tue Mar 8 19:48:42 2016 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Tue, 8 Mar 2016 15:48:42 -0300 Subject: [Development] QNX broken on 5.7 In-Reply-To: <20160308183115.5931089.32732.63034@theqtcompany.com> References: <20160308173935.GA18570@orion> <20160308183115.5931089.32732.63034@theqtcompany.com> Message-ID: <20160308184840.GA25045@orion> Hi Simon, You are right, I completely forgot about that thread. Thanks for the feedback. Cheers, Rafael On Tue, Mar 08, 2016 at 06:31:15PM +0000, Hausmann Simon wrote: > Hi, > > When building Qt 5.7 for QNX a special patch is applied in the CI that fixes the Dinkumware headers. You were CCed when this was discussed (Subject was "‎QNX and Dinkumware support for constexpr and nullptr"). > > Simon > > Original Message > From: Rafael Roquetto > Sent: Tuesday, March 8, 2016 18:39 > To: development at qt-project.org > Subject: [Development] QNX broken on 5.7 > > > Hello everyone, > > I would like to point out that QNX is unable to build the 5.7 branch. The > commit that probably triggered the breakage is: > > d6bb01e1779f1840dfbab57c6ecd615587bbde62 > Force inclusion of on QNX systems. > > > This raises my first question: should this not have been reported by the CI? > This is not the first time that changes go in and break QNX, in spite of > having the CI in place. Would anyone have a clue about what is going on? > > > Now, concerning the issue itself, it seems to be a bigger problem: > > /usr/include/cpp/xxatomic: In instantiation of 'std::atomic<_Ty*>::atomic(_Ty*) [with _Ty = void(QtMsgType, const char*)]': > /usr/include/cpp/xxatomic:336:3: error: invalid conversion from 'void (*)(QtMsgType, const char*)' to 'void*' [-fpermissive] > /usr/include/cpp/xxatomic:873:15: error: initializing argument 1 of 'void* std::_Atomic_address::operator=(void*)' [-fpermissive] > > > Caused by the following line inside qlogging.cpp: > > static QBasicAtomicPointer msgHandler = Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler); > > The problem can be traced to the Dinkumware's std::atomic implementation. > Ultimately, qDefaultMsgHandler will be passed as an argument to std::atomic's > default ctor, which looks like this: > > _CONST_FUN atomic(_Ty *_Right) _NOEXCEPT > { // construct from _Right > _Atomic_address::operator=(_Right); > } > > > _Atomic_address is a base class. As you can see, this ctor is implemented > using operator=, which looks like this: > > > inline _ITYPE _ATOMIC_ITYPE::operator=(_ITYPE _Value) _NOEXCEPT > { // assign _Value to *this > atomic_store(this, _Value); > return _Value; > } > ` > > where _TYPE expands to (void *), thus effectively causing the conversion from > void (*)(QtMsgType, const char*) to (void *), which is the error. > > Interestingly, Dinkumware's std::atomic does provide operator= in terms of > _Ty: > > > _Ty *operator=(_Ty *_Right) _NOEXCEPT > { // assign from _Right > return static_cast<_Ty *>(_Atomic_address::operator=((void *)_Right)); > } > > > which makes me think that the ctor is wrongly implemented, since it bypasses > this and calls the base class operator= explicitly. > > > I am not sure how to work around this. QBasicAtomicPointer won't let me > initialize it with some ugly (void *) pointer. > > Does it make sense to revert this patch? Is there a way to fall back to the > old non-C++11 implementation? > > 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 - Qt Experts -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4861 bytes Desc: not available URL: From Simon.Hausmann at theqtcompany.com Tue Mar 8 19:59:51 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Tue, 8 Mar 2016 18:59:51 +0000 Subject: [Development] QNX broken on 5.7 In-Reply-To: <20160308184840.GA25045@orion> References: <20160308173935.GA18570@orion> <20160308183115.5931089.32732.63034@theqtcompany.com>, <20160308184840.GA25045@orion> Message-ID: <20160308185951.5931089.78413.63040@theqtcompany.com> No worries :). The fact that you didn't see a proper configure error message suggests that the follow up patch to verify the qnx installation didn't make it or is buggy. Hmm. Simon Original Message From: Rafael Roquetto Sent: Tuesday, March 8, 2016 19:48 To: Hausmann Simon Cc: development at qt-project.org Subject: Re: [Development] QNX broken on 5.7 Hi Simon, You are right, I completely forgot about that thread. Thanks for the feedback. Cheers, Rafael On Tue, Mar 08, 2016 at 06:31:15PM +0000, Hausmann Simon wrote: > Hi, > > When building Qt 5.7 for QNX a special patch is applied in the CI that fixes the Dinkumware headers. You were CCed when this was discussed (Subject was "‎QNX and Dinkumware support for constexpr and nullptr"). > > Simon > > Original Message > From: Rafael Roquetto > Sent: Tuesday, March 8, 2016 18:39 > To: development at qt-project.org > Subject: [Development] QNX broken on 5.7 > > > Hello everyone, > > I would like to point out that QNX is unable to build the 5.7 branch. The > commit that probably triggered the breakage is: > > d6bb01e1779f1840dfbab57c6ecd615587bbde62 > Force inclusion of on QNX systems. > > > This raises my first question: should this not have been reported by the CI? > This is not the first time that changes go in and break QNX, in spite of > having the CI in place. Would anyone have a clue about what is going on? > > > Now, concerning the issue itself, it seems to be a bigger problem: > > /usr/include/cpp/xxatomic: In instantiation of 'std::atomic<_Ty*>::atomic(_Ty*) [with _Ty = void(QtMsgType, const char*)]': > /usr/include/cpp/xxatomic:336:3: error: invalid conversion from 'void (*)(QtMsgType, const char*)' to 'void*' [-fpermissive] > /usr/include/cpp/xxatomic:873:15: error: initializing argument 1 of 'void* std::_Atomic_address::operator=(void*)' [-fpermissive] > > > Caused by the following line inside qlogging.cpp: > > static QBasicAtomicPointer msgHandler = Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler); > > The problem can be traced to the Dinkumware's std::atomic implementation. > Ultimately, qDefaultMsgHandler will be passed as an argument to std::atomic's > default ctor, which looks like this: > > _CONST_FUN atomic(_Ty *_Right) _NOEXCEPT > { // construct from _Right > _Atomic_address::operator=(_Right); > } > > > _Atomic_address is a base class. As you can see, this ctor is implemented > using operator=, which looks like this: > > > inline _ITYPE _ATOMIC_ITYPE::operator=(_ITYPE _Value) _NOEXCEPT > { // assign _Value to *this > atomic_store(this, _Value); > return _Value; > } > ` > > where _TYPE expands to (void *), thus effectively causing the conversion from > void (*)(QtMsgType, const char*) to (void *), which is the error. > > Interestingly, Dinkumware's std::atomic does provide operator= in terms of > _Ty: > > > _Ty *operator=(_Ty *_Right) _NOEXCEPT > { // assign from _Right > return static_cast<_Ty *>(_Atomic_address::operator=((void *)_Right)); > } > > > which makes me think that the ctor is wrongly implemented, since it bypasses > this and calls the base class operator= explicitly. > > > I am not sure how to work around this. QBasicAtomicPointer won't let me > initialize it with some ugly (void *) pointer. > > Does it make sense to revert this patch? Is there a way to fall back to the > old non-C++11 implementation? > > 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 - Qt Experts -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts From thiago.macieira at intel.com Tue Mar 8 20:37:23 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 08 Mar 2016 11:37:23 -0800 Subject: [Development] QNX broken on 5.7 In-Reply-To: <20160308185951.5931089.78413.63040@theqtcompany.com> References: <20160308173935.GA18570@orion> <20160308184840.GA25045@orion> <20160308185951.5931089.78413.63040@theqtcompany.com> Message-ID: <1910970.81IvUtf4rF@tjmaciei-mobl4> On terça-feira, 8 de março de 2016 18:59:51 PST Hausmann Simon wrote: > No worries :). The fact that you didn't see a proper configure error message > suggests that the follow up patch to verify the qnx installation didn't > make it or is buggy. Hmm. Indeed, it's change I7e6338336dd6468ead24ffff141139c79056922e which isn't submitted because it isn't complete. See the two "WIP" in the commit message. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From frederik.gladhorn at theqtcompany.com Wed Mar 9 10:56:51 2016 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Wed, 9 Mar 2016 10:56:51 +0100 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: References: Message-ID: <7811068.TYrtjBnhy4@frederik-thinkcentre-m93p> We are in the luxury position of having two great candidates. I briefly talked to both Robin and Shawn yesterday and one option would be to have a shared maintainership. This seems to have worked nicely for Qt Networking and dividing the responsibilty will lessen the burden. I'm looking forward to having more direction and vision for the development of the Qt Quick module as well as getting back to a big round of bug fixes which is due in the near future. Cheers, Frederik PS: I briefly checked the rules (http://wiki.qt.io/The_Qt_Governance_Model) and found this bit: "Once seconded, a new Maintainer is appointed unless a community member objects to the Chief Maintainer within 15 work days. If an objection is raised, the Chief Maintainer decides, usually within 15 work days." On Saturday, March 05, 2016 11:40:56 PM Alan Alpert wrote: > Hi all, > > I have been drawn away from Qt Quick at work the past several months, > for even I do not write back-end services with Qt Quick. Consequently > I have not had time to fulfill the responsibilities of Qt Quick > Maintainership and will have to pass the mantle onto someone new. > > Accepting the unfortunate nature of reality means that I must resign > from the QtQuick maintainership position. Accordingly I have removed > my name from the maintainers wiki page. Everyone on gerrit knows I'm > not getting to my reviews anymore, so I can no longer hold a module > maintainer position. > > It would be great if someone else could step up and take over, as I > still believe QtQuick is a key component of the premier native GUI > framework. Any volunteers? > > -- > Alan Alpert > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From enmarantispam at gmail.com Wed Mar 9 14:32:31 2016 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Wed, 9 Mar 2016 16:32:31 +0300 Subject: [Development] Is it possible to make QSettingsPrivate::variantToString and its pair a public interface? Message-ID: QSettings kinda lacks in consistency when you write data to it as in: 1) it loses all comments 2) it randomly reorders values While I understand such things were never in scope for this class, for ppl who need above mentioned things, it is either go away from QSettings (which is ugly, cause why are we using a framework then) or manually solving this problem by writing custom function to re-insert comments and resave the file with correct values. To do this re-inserting we currently utilize QSettingsPrivate::variantToString pulled from qt sources, but we completely understand the compatibility is not promised for private stuff. While we could ofc write tests to make sure our code doesn't break with qt versions and will likely even do so, it would be really nice if we didn't have to copy/paste qt sources and just call functions directly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at theqtcompany.com Wed Mar 9 14:46:25 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 9 Mar 2016 13:46:25 +0000 Subject: [Development] Is it possible to make QSettingsPrivate::variantToString and its pair a public interface? In-Reply-To: References: Message-ID: <74BCF691-7133-45E7-8CA6-627AD684FCCA@theqtcompany.com> Hi, While I understand that this would help you, I don’t think this is a good idea. QSettings has is’s share of implementation issues, and would at some point benefit from cleaning up or (more likely) rewriting the internals. I wouldn’t want to add to it’s public API right now, as that would make this task even harder than it already is. Cheers, Lars On 09/03/16 14:32, "Development on behalf of NIkolai Marchenko" wrote: >QSettings kinda lacks in consistency when you write data to it as in: >1) it loses all comments >2) it randomly reorders values >While I understand such things were never in scope for this class, for ppl who need above mentioned things, it is either go away from QSettings (which is ugly, cause why are we using a framework then) or manually solving this problem by writing custom > function to re-insert comments and resave the file with correct values. > > >To do this re-inserting we currently utilize QSettingsPrivate::variantToString pulled from qt sources, but we completely understand the compatibility is not promised for private stuff. While we could ofc write tests to make sure our code doesn't break > with qt versions and will likely even do so, it would be really nice if we didn't have to copy/paste qt sources and just call functions directly. > From 416365416c at gmail.com Thu Mar 10 08:18:08 2016 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 9 Mar 2016 23:18:08 -0800 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: <7811068.TYrtjBnhy4@frederik-thinkcentre-m93p> References: <7811068.TYrtjBnhy4@frederik-thinkcentre-m93p> Message-ID: On Wed, Mar 9, 2016 at 1:56 AM, Frederik Gladhorn wrote: > We are in the luxury position of having two great candidates. > I briefly talked to both Robin and Shawn yesterday and one option would be to > have a shared maintainership. This seems to have worked nicely for Qt > Networking and dividing the responsibilty will lessen the burden. I agree they would both be great candidates. I have enjoyed working with both on Qt Quick in the past. They also have complementary interests, with Shawn driving key input functionality and Robin looking at the full stack performance. Individually or together, +1 from me. -- Alan Alpert From Lars.Knoll at theqtcompany.com Thu Mar 10 08:37:50 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 10 Mar 2016 07:37:50 +0000 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: References: <7811068.TYrtjBnhy4@frederik-thinkcentre-m93p> Message-ID: <52D67DAD-94DF-433E-B4A4-6E17B7352C1B@theqtcompany.com> On 10/03/16 08:18, "Development on behalf of Alan Alpert" wrote: >On Wed, Mar 9, 2016 at 1:56 AM, Frederik Gladhorn > wrote: >> We are in the luxury position of having two great candidates. >> I briefly talked to both Robin and Shawn yesterday and one option would be to >> have a shared maintainership. This seems to have worked nicely for Qt >> Networking and dividing the responsibilty will lessen the burden. > >I agree they would both be great candidates. I have enjoyed working >with both on Qt Quick in the past. They also have complementary >interests, with Shawn driving key input functionality and Robin >looking at the full stack performance. > >Individually or together, +1 from me. Fully agree with what Alan is saying, so another +1 from me. Cheers, Lars From eskil.abrahamsen-blomfeldt at theqtcompany.com Thu Mar 10 10:43:17 2016 From: eskil.abrahamsen-blomfeldt at theqtcompany.com (Eskil Abrahamsen Blomfeldt) Date: Thu, 10 Mar 2016 10:43:17 +0100 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: <7811068.TYrtjBnhy4@frederik-thinkcentre-m93p> References: <7811068.TYrtjBnhy4@frederik-thinkcentre-m93p> Message-ID: <56E141B5.6060201@theqtcompany.com> Den 09.03.2016 10:56, skrev Frederik Gladhorn: > We are in the luxury position of having two great candidates. > I briefly talked to both Robin and Shawn yesterday and one option would be to > have a shared maintainership. This seems to have worked nicely for Qt > Networking and dividing the responsibilty will lessen the burden. +1 for shared maintainership. -- Eskil From Simon.Hausmann at theqtcompany.com Thu Mar 10 16:44:45 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 10 Mar 2016 15:44:45 +0000 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: <56E141B5.6060201@theqtcompany.com> References: <7811068.TYrtjBnhy4@frederik-thinkcentre-m93p>, <56E141B5.6060201@theqtcompany.com> Message-ID: +alot :) Simon ________________________________________ From: Development on behalf of Eskil Abrahamsen Blomfeldt Sent: Thursday, March 10, 2016 10:43 To: development at qt-project.org Subject: Re: [Development] QtQuick Call for Maintainer Den 09.03.2016 10:56, skrev Frederik Gladhorn: > We are in the luxury position of having two great candidates. > I briefly talked to both Robin and Shawn yesterday and one option would be to > have a shared maintainership. This seems to have worked nicely for Qt > Networking and dividing the responsibilty will lessen the burden. +1 for shared maintainership. -- Eskil _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From shiva.s at rsageventures.com Fri Mar 11 08:15:47 2016 From: shiva.s at rsageventures.com (Shiva sitamraju) Date: Fri, 11 Mar 2016 12:45:47 +0530 Subject: [Development] Programmitcally putting widget on X display Message-ID: Hi, I am trying to put widget on X display from Qt (on display other than primary display) Let me know if this is possible. Tried various approaches http://stackoverflow.com/questions/35498895/qdesktopwidget-for-an-x-display Would be great if I can get some pointers on way forward. Is it required to patch Qt code for this ? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincenthk007 at gmail.com Fri Mar 11 09:09:25 2016 From: vincenthk007 at gmail.com (Vincent Hui) Date: Fri, 11 Mar 2016 16:09:25 +0800 Subject: [Development] QML design patterns implemented by community Message-ID: Hi Qt contributors, Members of Qt community put a lot of effects to improve QML. Some design patterns were proposed by them. Did you have a look at their work? Would you mind giving feedback to them and adopting their proposed design patterns in future? Work done by community members: QSyncable - Synchronize data between models Action-Dispatcher Design Pattern for QML QML Application Architecture Guide with Flux FLUX: QT QUICK WITH UNIDIRECTIONAL DATA FLOW Discussion: https://forum.qt.io/topic/63817/qsyncable-synchronize-data-between-models https://forum.qt.io/topic/55213/writing-qml-application-in-a-flux-way https://forum.qt.io/topic/64701/qml-application-architecture-guide-with-flux/2 Thanks, Vincent -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Fri Mar 11 09:18:09 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 11 Mar 2016 08:18:09 +0000 Subject: [Development] [Announce] Qt 5.7 Alpha released Message-ID: Hi all! Qt 5.7 Alpha release is out, see http://blog.qt.io/blog/2016/03/11/qt-5-7-alpha-released/ As earlier, Alpha is source code delivery only. The plan forward is now to create a beta (including binary packages) during the next few weeks. Big thanks for everyone who were involved to make this happen! Br, Akseli -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From andre at familiesomers.nl Fri Mar 11 10:48:54 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 11 Mar 2016 10:48:54 +0100 Subject: [Development] Programmitcally putting widget on X display In-Reply-To: References: Message-ID: <56E29486.5050907@familiesomers.nl> Hi, I think you are on the wrong list. This one is for the development _of_ Qt. For questions on how to develop _with_ Qt, the interest at qt-project.org list is more suitable. André Op 11/03/2016 om 08:15 schreef Shiva sitamraju: > Hi, > > I am trying to put widget on X display from Qt (on display other than > primary display) > > Let me know if this is possible. Tried various approaches > > http://stackoverflow.com/questions/35498895/qdesktopwidget-for-an-x-display > > Would be great if I can get some pointers on way forward. Is it > required to patch Qt code for this ? > > Regards > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at theqtcompany.com Fri Mar 11 12:38:20 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 11 Mar 2016 12:38:20 +0100 Subject: [Development] ci timeouts In-Reply-To: <2940652.8CSySHLyHu@42> References: <2940652.8CSySHLyHu@42> Message-ID: <3788424.vQ9a3Kyoyu@42> Hi, > Just fast update on the issue. I thought that this is fixed: > http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1456811813.thrift_ > bin Thanks for pointing it out. Time handling in virtualiazed environment is > not reliable, and sometimes source packages are created in future... Anyway > I know how to workaround it a fix is coming hopefully soon. Fix is working in the production. If you ever see it again then ping me. > Another timeout was caused because of a temporary > network failure (https://bugreports.qt.io/browse/QTQAINFRA-969). Workaround for the issue is already done and it will be deployed during the next week, we will see if it helps Cheers, Jędrek From vincenthk007 at gmail.com Fri Mar 11 15:27:38 2016 From: vincenthk007 at gmail.com (Vincent Hui) Date: Fri, 11 Mar 2016 22:27:38 +0800 Subject: [Development] QML design patterns implemented by community In-Reply-To: References: Message-ID: One more A new way for creating QML models from C++ , video On Fri, Mar 11, 2016 at 4:09 PM, Vincent Hui wrote: > Hi Qt contributors, > > Members of Qt community put a lot of effects to improve QML. Some design > patterns were proposed by them. Did you have a look at their work? Would > you mind giving feedback to them and adopting their proposed design > patterns in future? > > Work done by community members: > QSyncable - Synchronize data between models > > Action-Dispatcher Design Pattern for QML > > QML Application Architecture Guide with Flux > > > FLUX: QT QUICK WITH UNIDIRECTIONAL DATA FLOW > > > Discussion: > https://forum.qt.io/topic/63817/qsyncable-synchronize-data-between-models > https://forum.qt.io/topic/55213/writing-qml-application-in-a-flux-way > > https://forum.qt.io/topic/64701/qml-application-architecture-guide-with-flux/2 > > Thanks, > Vincent > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincenthk007 at gmail.com Fri Mar 11 16:01:45 2016 From: vincenthk007 at gmail.com (Vincent Hui) Date: Fri, 11 Mar 2016 23:01:45 +0800 Subject: [Development] QML design patterns implemented by community In-Reply-To: References: Message-ID: Sorry, it is my mistake. I missed one more. Quick Promise - QML Promise Library , discussion Vincent On Fri, Mar 11, 2016 at 10:27 PM, Vincent Hui wrote: > One more > > A new way for creating QML models from C++ > , > video > > On Fri, Mar 11, 2016 at 4:09 PM, Vincent Hui > wrote: > >> Hi Qt contributors, >> >> Members of Qt community put a lot of effects to improve QML. Some design >> patterns were proposed by them. Did you have a look at their work? Would >> you mind giving feedback to them and adopting their proposed design >> patterns in future? >> >> Work done by community members: >> QSyncable - Synchronize data between models >> >> Action-Dispatcher Design Pattern for QML >> >> QML Application Architecture Guide with Flux >> >> >> FLUX: QT QUICK WITH UNIDIRECTIONAL DATA FLOW >> >> >> Discussion: >> https://forum.qt.io/topic/63817/qsyncable-synchronize-data-between-models >> https://forum.qt.io/topic/55213/writing-qml-application-in-a-flux-way >> >> https://forum.qt.io/topic/64701/qml-application-architecture-guide-with-flux/2 >> >> Thanks, >> Vincent >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Fri Mar 11 17:30:58 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 11 Mar 2016 13:30:58 -0300 Subject: [Development] How can Qt 5.6.0 MinGW pass in CI with QTBUG-49971 open? In-Reply-To: References: <178C4D98-A9FF-4962-8A8C-0AAF5245F585@theqtcompany.com> Message-ID: <11312119.Tmk3H5s2pa@tonks> On Sunday 06 March 2016 03:07:57 Kevin Kofler wrote: > Knoll Lars wrote: > > Curtis Mitch wrote: > >>Ferocious Triceratops Baring Fearsome Strength? Phew. I thought we'd > >>gotten rid of all of those! > >> > > Took me two minutes to parse that one as well. Failure to build from > > source. > > FTBFS is an acronym that, as far as I can tell, originated from Debian, but > has since spread to other communities. (E.g., we now use it in Fedora, too.) For the sake of completeness: it was originated from Debian and we read it as "Fails to build from source". -- Q. How did the programmer die in the shower? A. He read the shampoo bottle instructions: Lather. Rinse. Repeat. http://www.devtopics.com/best-programming-jokes/ Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From Stefan.Walter at lisec.com Sun Mar 13 05:47:40 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Sun, 13 Mar 2016 04:47:40 +0000 Subject: [Development] Qt 5.6.0-rc build issues on Windows 7 with VC2015 x86 -target XP Message-ID: <00dbffc8537e48bf926d8ca19b9b2770@ATSE-MAIL4.lisec.internal> Hi, I am receiving the following compilation error and thought I should share it here. I am using the source from: qt-everywhere-opensource-src-5.6.0-rc.7z Is this already solved for the final release? nmake -f Makefile.core_gyp_generator.Debug Microsoft (R) Program Maintenance Utility Version 14.00.23506.0 Copyright (C) Microsoft Corporation. All rights reserved. ( if not exist Makefile.gyp_run C:\Build\qt-5.6.0-rc\qt-build\qtbase\bin\qmake C:\Build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0-rc\qtwebengine\src\core\gyp_run.pro -o Makefile.gyp_run ) && nmake -f Makefile.gyp_run 'git' is not recognized as an internal or external command, operable program or batch file. Project MESSAGE: Running gyp_qtwebengine "C:/Build/qt-5.6.0-rc/qt-build/qtwebengine/src/core" -D qt_cross_compile=0 -D qt_os="win32" -I config/windows.gypi -D qtwe_chromium_obj_dir="C:/Build/qt-5.6.0-rc/qt-build/qtwebengine/src/core/Debug/obj/src/3rdparty/chromium" -D perl_exe="perl.exe" -D bison_exe="bison.exe" -D gperf_exe="gperf.exe" --no-parallel -D qt_egl_library="libEGLd.lib" -D qt_glesv2_library="libGLESv2d.lib" -D qt_gl="angle" -G msvs_version=2015 -D use_qt=1 -D v8_use_external_startup_data=0 -D enable_basic_printing=0 -D enable_print_preview=0 -D enable_web_speech=0 -D disable_nacl=1 -D remoting=0 -D use_ash=0 -D fastbuild=2 -D disable_glibcxx_debug=1 -D remove_webcore_debug_symbols=1 -D remove_v8base_debug_symbols=1 -D disable_fatal_linker_warnings=1 -D target_arch=ia32... using python: C:\Python27\python.exe version: 2.7.10 'git' is not recognized as an internal or external command, operable program or batch file. Using extra options found in c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0-rc\qtwebengine\src\core\qtwebengine_extras.gypi Updating projects from gyp files... Traceback (most recent call last): File "C:/Build/qt-5.6.0-rc/qt-everywhere-opensource-src-5.6.0-rc/qtwebengine/tools/buildscripts/gyp_qtwebengine", line 178, in sys.exit(gyp.main(args)) File "c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0-rc\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\__init__.py", line 538, in main return gyp_main(args) File "c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0-rc\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\__init__.py", line 514, in gyp_main options.duplicate_basename_check) File "c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0-rc\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\__init__.py", line 98, in Load generator.CalculateVariables(default_variables, params) File "c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0-rc\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\generator\ninja.py", line 1682, in CalculateVariables gyp.msvs_emulation.CalculateCommonVariables(default_variables, params) File "c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0-rc\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\msvs_emulation.py", line 1071, in CalculateCommonVariables msvs_version = gyp.msvs_emulation.GetVSVersion(generator_flags) File "c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0-rc\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\msvs_emulation.py", line 924, in GetVSVersion allow_fallback=False) File "c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0-rc\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\MSVSVersion.py", line 437, in SelectVisualStudioVersion raise ValueError('Could not locate Visual Studio installation.') ValueError: Could not locate Visual Studio installation. Project ERROR: -- running gyp_qtwebengine failed -- NMAKE : fatal error U1077: '(' : return code '0x3' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. Best Regards, Stefan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at theqtcompany.com Mon Mar 14 08:09:02 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Mon, 14 Mar 2016 07:09:02 +0000 Subject: [Development] Qt 5.6.0-rc build issues on Windows 7 with VC2015 x86 -target XP In-Reply-To: <00dbffc8537e48bf926d8ca19b9b2770@ATSE-MAIL4.lisec.internal> References: <00dbffc8537e48bf926d8ca19b9b2770@ATSE-MAIL4.lisec.internal> Message-ID: > -----Ursprüngliche Nachricht----- > Von: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] Im Auftrag von > Walter Stefan > Gesendet: Sonntag, 13. März 2016 05:48 > An: development at qt-project.org > Betreff: [Development] Qt 5.6.0-rc build issues on Windows 7 with VC2015 > x86 -target XP > > Hi, > > > > I am receiving the following compilation error and thought I should share it > here. > > I am using the source from: qt-everywhere-opensource-src-5.6.0-rc.7z > > Is this already solved for the final release? I don’t this is a known issue, nor that it has been fixed. > [ ... ] > Project MESSAGE: Running gyp_qtwebengine "C:/Build/qt-5.6.0-rc/qt- > build/qtwebengine/src/core" -D qt_cross_compile=0 -D qt_os="win32" -I > config/windows.gypi -D qtwe_chromium_obj_dir="C:/Build/qt-5.6.0-rc/qt- > build/qtwebengine/src/core/Debug/obj/src/3rdparty/chromium" -D > perl_exe="perl.exe" -D bison_exe="bison.exe" -D gperf_exe="gperf.exe" -- > no-parallel -D qt_egl_library="libEGLd.lib" -D > qt_glesv2_library="libGLESv2d.lib" -D qt_gl="angle" -G msvs_version=2015 - > D use_qt=1 -D v8_use_external_startup_data=0 -D enable_basic_printing=0 > -D enable_print_preview=0 -D enable_web_speech=0 -D disable_nacl=1 -D > remoting=0 -D use_ash=0 -D fastbuild=2 -D disable_glibcxx_debug=1 -D > remove_webcore_debug_symbols=1 -D remove_v8base_debug_symbols=1 > -D disable_fatal_linker_warnings=1 -D target_arch=ia32... > [ ... ] > File "c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0- > rc\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\MSVSVersion. > py", line 437, in SelectVisualStudioVersion > > raise ValueError('Could not locate Visual Studio installation.') > > ValueError: Could not locate Visual Studio installation. Which Visual Studio are you using? Qt thinks it's Visual Studio 2015 (msvs_version=2015). Anyhow, gyp/Chromium does try to find the version in the registry and on the filesystem: It searches for registry key 'InstallDir' in HKLM\Software\Microsoft\VisualStudio\14.0 HKLM\Software\Wow6432Node\Microsoft\VisualStudio\14.0 HKLM\Software\Microsoft\VCExpress\14.0 HKLM\Software\Wow6432Node\Microsoft\VCExpress\14.0 It then searches for devenv.exe, *express.exe in the InstallDir/../../ In addition, it checks for HKLM\Software\Microsoft\VisualStudio\SxS\VC7\14.0, HKLM\Software\Wow6432Node\Microsoft\VisualStudio\SxS\VC7\14.0 registry values. Apparently all these checks fail for you. Would be good if you could open a bug about this, including your relevant registry sections. Regards Kai Koehne From Stefan.Walter at lisec.com Mon Mar 14 08:28:56 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Mon, 14 Mar 2016 07:28:56 +0000 Subject: [Development] Qt 5.6.0-rc build issues on Windows 7 with VC2015 x86 -target XP In-Reply-To: References: <00dbffc8537e48bf926d8ca19b9b2770@ATSE-MAIL4.lisec.internal> Message-ID: <69142e40ddc2498fb193e3bc161586eb@ATSE-MAIL4.lisec.internal> Hi, How can I address it to the right developers? Regards, Stefan -----Original Message----- From: Koehne Kai [mailto:Kai.Koehne at theqtcompany.com] Sent: Montag, 14. März 2016 11:09 To: Walter Stefan ; development at qt-project.org Subject: AW: [Development] Qt 5.6.0-rc build issues on Windows 7 with VC2015 x86 -target XP > -----Ursprüngliche Nachricht----- > Von: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] Im Auftrag von > Walter Stefan > Gesendet: Sonntag, 13. März 2016 05:48 > An: development at qt-project.org > Betreff: [Development] Qt 5.6.0-rc build issues on Windows 7 with > VC2015 > x86 -target XP > > Hi, > > > > I am receiving the following compilation error and thought I should > share it here. > > I am using the source from: qt-everywhere-opensource-src-5.6.0-rc.7z > > Is this already solved for the final release? I don’t this is a known issue, nor that it has been fixed. > [ ... ] > Project MESSAGE: Running gyp_qtwebengine "C:/Build/qt-5.6.0-rc/qt- > build/qtwebengine/src/core" -D qt_cross_compile=0 -D qt_os="win32" -I > config/windows.gypi -D qtwe_chromium_obj_dir="C:/Build/qt-5.6.0-rc/qt- > build/qtwebengine/src/core/Debug/obj/src/3rdparty/chromium" -D > perl_exe="perl.exe" -D bison_exe="bison.exe" -D gperf_exe="gperf.exe" > -- no-parallel -D qt_egl_library="libEGLd.lib" -D > qt_glesv2_library="libGLESv2d.lib" -D qt_gl="angle" -G > msvs_version=2015 - D use_qt=1 -D v8_use_external_startup_data=0 -D > enable_basic_printing=0 -D enable_print_preview=0 -D > enable_web_speech=0 -D disable_nacl=1 -D > remoting=0 -D use_ash=0 -D fastbuild=2 -D disable_glibcxx_debug=1 -D > remove_webcore_debug_symbols=1 -D remove_v8base_debug_symbols=1 -D > disable_fatal_linker_warnings=1 -D target_arch=ia32... > [ ... ] > File "c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0- > rc\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\MSVSVersion. > py", line 437, in SelectVisualStudioVersion > > raise ValueError('Could not locate Visual Studio installation.') > > ValueError: Could not locate Visual Studio installation. Which Visual Studio are you using? Qt thinks it's Visual Studio 2015 (msvs_version=2015). Anyhow, gyp/Chromium does try to find the version in the registry and on the filesystem: It searches for registry key 'InstallDir' in HKLM\Software\Microsoft\VisualStudio\14.0 HKLM\Software\Wow6432Node\Microsoft\VisualStudio\14.0 HKLM\Software\Microsoft\VCExpress\14.0 HKLM\Software\Wow6432Node\Microsoft\VCExpress\14.0 It then searches for devenv.exe, *express.exe in the InstallDir/../../ In addition, it checks for HKLM\Software\Microsoft\VisualStudio\SxS\VC7\14.0, HKLM\Software\Wow6432Node\Microsoft\VisualStudio\SxS\VC7\14.0 registry values. Apparently all these checks fail for you. Would be good if you could open a bug about this, including your relevant registry sections. Regards Kai Koehne From Kai.Koehne at theqtcompany.com Mon Mar 14 08:46:18 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Mon, 14 Mar 2016 07:46:18 +0000 Subject: [Development] Qt 5.6.0-rc build issues on Windows 7 with VC2015 x86 -target XP In-Reply-To: <69142e40ddc2498fb193e3bc161586eb@ATSE-MAIL4.lisec.internal> References: <00dbffc8537e48bf926d8ca19b9b2770@ATSE-MAIL4.lisec.internal> <69142e40ddc2498fb193e3bc161586eb@ATSE-MAIL4.lisec.internal> Message-ID: > -----Ursprüngliche Nachricht----- > Von: Walter Stefan [mailto:Stefan.Walter at lisec.com] > Gesendet: Montag, 14. März 2016 08:29 > An: Koehne Kai ; development at qt- > project.org > Betreff: RE: [Development] Qt 5.6.0-rc build issues on Windows 7 with > VC2015 x86 -target XP > > Hi, > > How can I address it to the right developers? By creating a bug report and providing all information needed :) That is we need to know - which Visual Studio version you have installed - whether the relevant registry paths listed above are right for you If you want to dig into this yourself, the code is in qtwebengine/src/3rdparty/chromium/tools/gyp/pylib/gyp/MSVSVersion.py Regards Kai > Regards, > Stefan > > -----Original Message----- > From: Koehne Kai [mailto:Kai.Koehne at theqtcompany.com] > Sent: Montag, 14. März 2016 11:09 > To: Walter Stefan ; development at qt-project.org > Subject: AW: [Development] Qt 5.6.0-rc build issues on Windows 7 with > VC2015 x86 -target XP > > > > > -----Ursprüngliche Nachricht----- > > Von: Development [mailto:development- > > bounces+kai.koehne=theqtcompany.com at qt-project.org] Im Auftrag von > > Walter Stefan > > Gesendet: Sonntag, 13. März 2016 05:48 > > An: development at qt-project.org > > Betreff: [Development] Qt 5.6.0-rc build issues on Windows 7 with > > VC2015 > > x86 -target XP > > > > Hi, > > > > > > > > I am receiving the following compilation error and thought I should > > share it here. > > > > I am using the source from: qt-everywhere-opensource-src-5.6.0-rc.7z > > > > Is this already solved for the final release? > > I don’t this is a known issue, nor that it has been fixed. > > > [ ... ] > > Project MESSAGE: Running gyp_qtwebengine "C:/Build/qt-5.6.0-rc/qt- > > build/qtwebengine/src/core" -D qt_cross_compile=0 -D qt_os="win32" -I > > config/windows.gypi -D qtwe_chromium_obj_dir="C:/Build/qt-5.6.0-rc/qt- > > build/qtwebengine/src/core/Debug/obj/src/3rdparty/chromium" -D > > perl_exe="perl.exe" -D bison_exe="bison.exe" -D gperf_exe="gperf.exe" > > -- no-parallel -D qt_egl_library="libEGLd.lib" -D > > qt_glesv2_library="libGLESv2d.lib" -D qt_gl="angle" -G > > msvs_version=2015 - D use_qt=1 -D v8_use_external_startup_data=0 -D > > enable_basic_printing=0 -D enable_print_preview=0 -D > > enable_web_speech=0 -D disable_nacl=1 -D > > remoting=0 -D use_ash=0 -D fastbuild=2 -D disable_glibcxx_debug=1 -D > > remove_webcore_debug_symbols=1 -D > remove_v8base_debug_symbols=1 -D > > disable_fatal_linker_warnings=1 -D target_arch=ia32... > > [ ... ] > > File "c:\build\qt-5.6.0-rc\qt-everywhere-opensource-src-5.6.0- > > > rc\qtwebengine\src\3rdparty\chromium\tools\gyp\pylib\gyp\MSVSVersion. > > py", line 437, in SelectVisualStudioVersion > > > > raise ValueError('Could not locate Visual Studio installation.') > > > > ValueError: Could not locate Visual Studio installation. > > Which Visual Studio are you using? > > Qt thinks it's Visual Studio 2015 (msvs_version=2015). Anyhow, > gyp/Chromium does try to find the version in the registry and on the > filesystem: > > It searches for registry key 'InstallDir' in > > HKLM\Software\Microsoft\VisualStudio\14.0 > HKLM\Software\Wow6432Node\Microsoft\VisualStudio\14.0 > HKLM\Software\Microsoft\VCExpress\14.0 > HKLM\Software\Wow6432Node\Microsoft\VCExpress\14.0 > > It then searches for devenv.exe, *express.exe in the InstallDir/../../ > > In addition, it checks for > HKLM\Software\Microsoft\VisualStudio\SxS\VC7\14.0, > HKLM\Software\Wow6432Node\Microsoft\VisualStudio\SxS\VC7\14.0 > registry values. > > Apparently all these checks fail for you. > > Would be good if you could open a bug about this, including your relevant > registry sections. > > Regards > > Kai Koehne > From jani.heikkinen at theqtcompany.com Mon Mar 14 14:22:42 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 14 Mar 2016 13:22:42 +0000 Subject: [Development] Qt 5.6.0 (final) packages available Message-ID: Hi all, We have Qt 5.6.0 (final) packages available: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0/382/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0/367/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0/305/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0/latest_src/ Please check to packages to see if those are still working as expected. If nothing serious found we will release these packages as Qt 5.6.0 this Wed as planned. So please inform me immediately if there is something new which is preventing us to do the release. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From jkt at kde.org Mon Mar 14 17:59:20 2016 From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Mon, 14 Mar 2016 17:59:20 +0100 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: References: Message-ID: <77dcf352-786a-439f-927d-007ed5945840@kde.org> On Monday, 14 March 2016 14:22:42 CET, Heikkinen Jani wrote: > So please inform me > immediately if there is something new which is preventing us to > do the release. Do you consider "Plasma5 deadlocks during startup" as a blocker? If so, https://bugreports.qt.io/browse/QTBUG-51676 . It's a regression in the 5.6 branch ("5.5 works fine. oldish 5.6 works fine, too"), and Thiago is currently AFK when it comes to Gerrit reviews. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From konstantin at podsvirov.pro Mon Mar 14 19:11:39 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 14 Mar 2016 21:11:39 +0300 Subject: [Development] Fwd: [Interest] Qt 5.6.0 (final) packages available In-Reply-To: <3805771457979024@web23m.yandex.ru> Message-ID: <3810201457979099@web23m.yandex.ru> Hello everyone and thank you for the good work! I have a related question. According to this post and the comments: http://blog.qt.io/blog/2016/01/18/qt-charts-2-1-0-release It says that Qt 5.6 gives an open community QtCharts 2.1 and it is wonderful! But... looking at the git tags on code.qt.io I don't find the 2.1 release (2.0.1 only). If I'm wrong, correct me. Else tell me who can push the correct tag? 14.03.2016, 19:59, "Jan Kundrát" : >  On Monday, 14 March 2016 14:22:42 CET, Heikkinen Jani wrote: >>  So please inform me >>  immediately if there is something new which is preventing us to >>  do the release. > >  Do you consider "Plasma5 deadlocks during startup" as a blocker? If so, >  https://bugreports.qt.io/browse/QTBUG-51676 . It's a regression in the 5.6 >  branch ("5.5 works fine. oldish 5.6 works fine, too"), and Thiago is >  currently AFK when it comes to Gerrit reviews. > >  Cheers, >  Jan -- Regards, Konstantin Podsvirov From thiago.macieira at intel.com Mon Mar 14 19:12:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 14 Mar 2016 11:12:13 -0700 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <77dcf352-786a-439f-927d-007ed5945840@kde.org> References: <77dcf352-786a-439f-927d-007ed5945840@kde.org> Message-ID: <2531327.Mqljhk9Z8F@tjmaciei-mobl4> On segunda-feira, 14 de março de 2016 17:59:20 PDT Jan Kundrát wrote: > On Monday, 14 March 2016 14:22:42 CET, Heikkinen Jani wrote: > > So please inform me > > immediately if there is something new which is preventing us to > > do the release. > > Do you consider "Plasma5 deadlocks during startup" as a blocker? If so, > https://bugreports.qt.io/browse/QTBUG-51676 . It's a regression in the 5.6 > branch ("5.5 works fine. oldish 5.6 works fine, too"), and Thiago is > currently AFK when it comes to Gerrit reviews. That's kded/kiod, not Plasma. And I am reacting to the bug reports. I just don't have the time to analyse the issue and verify whether the solution proposed is the correct one. And since we're talking about QtDBus here, there aren't other people to help. So either we release this now or we wait until mid-April, when I can get back to developing code. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jkt at kde.org Mon Mar 14 20:36:57 2016 From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Mon, 14 Mar 2016 20:36:57 +0100 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <2531327.Mqljhk9Z8F@tjmaciei-mobl4> References: <77dcf352-786a-439f-927d-007ed5945840@kde.org> <2531327.Mqljhk9Z8F@tjmaciei-mobl4> Message-ID: <809fcf26-2788-40e1-b057-a12c4236464a@kde.org> > That's kded/kiod, not Plasma. Yes; however, given that kded is used in a default configuration of Plasma 5, the end result is that the Plasma panel (and krunner, and possibly other components) "won't work" with the current version of Qt 5.6. > And I am reacting to the bug reports. It wasn't my intention to judge your responsiveness in any way, sorry that it sounded that way. In fact, I appreciate your swift feedback that you gave me on the relevant bug reports despite your current workload -- thanks a lot! > I just don't have the time to analyse the issue and verify whether the > solution proposed is the correct one. And since we're talking about QtDBus > here, there aren't other people to help. So either we release > this now or we > wait until mid-April, when I can get back to developing code. Understood. What about option three -- applying that patch and investigating later. I understand that there's a risk that it includes other unknown failures to applications other than kded/kiod; however, I think that "KDE works, there may be some failures elsewhere" is a better outcome than "KDE definitely doesn't work, there may be other failures elsewhere". Other people might see it differently, my two cents is that I've been running my Plasma5 desktop with this patch for a few days, and it works. But anyway, I just wanted to respond to a call for known regressions; it's up to the Qt project to evaluate possible impact of various possible actions and determine its priorities here. I don't have much of a horse in this race, really. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From thiago.macieira at intel.com Mon Mar 14 21:41:02 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 14 Mar 2016 13:41:02 -0700 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <809fcf26-2788-40e1-b057-a12c4236464a@kde.org> References: <2531327.Mqljhk9Z8F@tjmaciei-mobl4> <809fcf26-2788-40e1-b057-a12c4236464a@kde.org> Message-ID: <4718570.E8hYs8Esm7@tjmaciei-mobl4> On segunda-feira, 14 de março de 2016 20:36:57 PDT Jan Kundrát wrote: > > That's kded/kiod, not Plasma. > > Yes; however, given that kded is used in a default configuration of Plasma > 5, the end result is that the Plasma panel (and krunner, and possibly other > components) "won't work" with the current version of Qt 5.6. As far as I understand, this is a race condition. So you won't have that problem all the time. > > I just don't have the time to analyse the issue and verify whether the > > solution proposed is the correct one. And since we're talking about QtDBus > > here, there aren't other people to help. So either we release > > this now or we > > wait until mid-April, when I can get back to developing code. > > Understood. What about option three -- applying that patch and > investigating later. Not acceptable. I will only apply the patch if I understand what it does and what the consequences are. I can only do that in April. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Tue Mar 15 00:26:06 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 15 Mar 2016 00:26:06 +0100 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <4718570.E8hYs8Esm7@tjmaciei-mobl4> References: <809fcf26-2788-40e1-b057-a12c4236464a@kde.org> <4718570.E8hYs8Esm7@tjmaciei-mobl4> Message-ID: <201603150026.06785.marc.mutz@kdab.com> On Monday 14 March 2016 21:41:02 Thiago Macieira wrote: > On segunda-feira, 14 de março de 2016 20:36:57 PDT Jan Kundrát wrote: > > > That's kded/kiod, not Plasma. > > > > Yes; however, given that kded is used in a default configuration of > > Plasma 5, the end result is that the Plasma panel (and krunner, and > > possibly other components) "won't work" with the current version of Qt > > 5.6. > > As far as I understand, this is a race condition. So you won't have that > problem all the time. > > > > I just don't have the time to analyse the issue and verify whether the > > > solution proposed is the correct one. And since we're talking about > > > QtDBus here, there aren't other people to help. So either we release > > > this now or we > > > wait until mid-April, when I can get back to developing code. > > > > Understood. What about option three -- applying that patch and > > investigating later. > > Not acceptable. I will only apply the patch if I understand what it does > and what the consequences are. I can only do that in April. I'd say it's the job of the patch *author* to describe all this in the commit message, not the job of the reviewer to go dig out the missing information by himself. If the commit message argued the change convincingly, and contained everything the author learned while developing the patch, other people would have a chance of approving, or Thiago would be able to do it while waiting for the next compile run. Maybe the patch author would even learn something he didn't knew he didn't know. At least that's how *I* feel more often than not. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From jkt at kde.org Mon Mar 14 23:51:40 2016 From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Mon, 14 Mar 2016 23:51:40 +0100 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <4718570.E8hYs8Esm7@tjmaciei-mobl4> References: <2531327.Mqljhk9Z8F@tjmaciei-mobl4> <809fcf26-2788-40e1-b057-a12c4236464a@kde.org> <4718570.E8hYs8Esm7@tjmaciei-mobl4> Message-ID: <3186b91d-9dee-4e40-9db3-039b3c14ae21@kde.org> On Monday, 14 March 2016 21:41:02 CET, Thiago Macieira wrote: > As far as I understand, this is a race condition. So you won't have that > problem all the time. While I was debugging this, it behaved like a very reliable deadlock. I wasn't really running it in a loop, but it happened each and every time at least a dozen times, and there was never a moment where it actually worked. > Not acceptable. I will only apply the patch if I understand > what it does and > what the consequences are. I can only do that in April. I understand that you won't apply that patch unless you fully understand its consequences. Maybe it can be applied by some other Qt maintainer, given that: - the regression was introduced in the 5.6 branch, - the QtDBus maintainer doesn't have time to test it prior to the 5.6's release, - the patch fixes said regression? Anyway, just a suggestion :). Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From thiago.macieira at intel.com Tue Mar 15 06:24:20 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 14 Mar 2016 22:24:20 -0700 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <3186b91d-9dee-4e40-9db3-039b3c14ae21@kde.org> References: <4718570.E8hYs8Esm7@tjmaciei-mobl4> <3186b91d-9dee-4e40-9db3-039b3c14ae21@kde.org> Message-ID: <3473813.2XddHPYClg@tjmaciei-mobl4> On segunda-feira, 14 de março de 2016 23:51:40 PDT Jan Kundrát wrote: > I understand that you won't apply that patch unless you fully understand > its consequences. Maybe it can be applied by some other Qt maintainer, > given that: > > - the regression was introduced in the 5.6 branch, > - the QtDBus maintainer doesn't have time to test it prior to the 5.6's > release, > - the patch fixes said regression? > > Anyway, just a suggestion :). There's no one who understands the code and would be comfortable approving it. I don't have a problem with qualified people approving code -- that's how QtCore is moving in my absence. There's no one like that for QtDBus. The problem is the severity of this bug. You're telling me this is a reliable deadlock. But the changes in question have been in the 5.6 branch for a couple of months, so I'm surprised that no one reported this earlier. I will take a look tomorrow. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 15 06:28:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 14 Mar 2016 22:28:07 -0700 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <201603150026.06785.marc.mutz@kdab.com> References: <4718570.E8hYs8Esm7@tjmaciei-mobl4> <201603150026.06785.marc.mutz@kdab.com> Message-ID: <2000457.USrKQ467U7@tjmaciei-mobl4> On terça-feira, 15 de março de 2016 00:26:06 PDT Marc Mutz wrote: > > Not acceptable. I will only apply the patch if I understand what it does > > and what the consequences are. I can only do that in April. > > I'd say it's the job of the patch *author* to describe all this in the > commit message, not the job of the reviewer to go dig out the missing > information by himself. True, but as a good reviewer and especially as the maintainer, I want to understand what the thing does. If I'm not comfortable with the change, I'm not supposed to approve it. If I'm the maintainer, I'd be stuck with that code. In this specific case, it's brand, new code that I wrote recently, so I'm supposed to know it well. And the way I designed it, deadlocks were not supposed to happen. So I need to investigate why they're happening in the first place. No offence to the patch author, but I have more experience with this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at theqtcompany.com Tue Mar 15 06:34:28 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 15 Mar 2016 05:34:28 +0000 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <3473813.2XddHPYClg@tjmaciei-mobl4> References: <4718570.E8hYs8Esm7@tjmaciei-mobl4> <3186b91d-9dee-4e40-9db3-039b3c14ae21@kde.org> <3473813.2XddHPYClg@tjmaciei-mobl4> Message-ID: Hi all, QTBUG-51676 seems to be p2 and so on cannot block the release. It also have been open >>-----Original Message----- >>From: Development [mailto:development- >>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>Thiago Macieira >>Sent: 15. maaliskuuta 2016 7:24 >>To: development at qt-project.org >>Subject: Re: [Development] Qt 5.6.0 (final) packages available >> >>On segunda-feira, 14 de março de 2016 23:51:40 PDT Jan Kundrát wrote: >>> I understand that you won't apply that patch unless you fully understand >>> its consequences. Maybe it can be applied by some other Qt maintainer, >>> given that: >>> >>> - the regression was introduced in the 5.6 branch, >>> - the QtDBus maintainer doesn't have time to test it prior to the 5.6's >>> release, >>> - the patch fixes said regression? >>> >>> Anyway, just a suggestion :). >> >>There's no one who understands the code and would be comfortable approving >>it. >>I don't have a problem with qualified people approving code -- that's how >>QtCore is moving in my absence. There's no one like that for QtDBus. >> >>The problem is the severity of this bug. You're telling me this is a reliable >>deadlock. But the changes in question have been in the 5.6 branch for a couple >>of months, so I'm surprised that no one reported this earlier. >> >>I will take a look tomorrow. >> >>-- >>Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >>_______________________________________________ >>Development mailing list >>Development at qt-project.org >>http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Mar 15 06:38:10 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 14 Mar 2016 22:38:10 -0700 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: References: <3473813.2XddHPYClg@tjmaciei-mobl4> Message-ID: <1610612.T2qTL4qr8F@tjmaciei-mobl4> On terça-feira, 15 de março de 2016 05:34:28 PDT Heikkinen Jani wrote: > QTBUG-51676 seems to be p2 and so on cannot block the release. It also have > been open The priority was based on my understanding when the reporter reported the bug. Jan is reporting that it happens all the time when Plasma 5 starts, deadlocking a central component. That would make it P1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at theqtcompany.com Tue Mar 15 06:39:26 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 15 Mar 2016 05:39:26 +0000 Subject: [Development] Qt 5.6.0 (final) packages available References: <4718570.E8hYs8Esm7@tjmaciei-mobl4> <3186b91d-9dee-4e40-9db3-039b3c14ae21@kde.org> <3473813.2XddHPYClg@tjmaciei-mobl4> Message-ID: Hi all, TBUG-51676 seems to be p2 and so on cannot block the release. It also have been open a while without anyone indicating it should be fixed before releasing so I wouldn't block the release because of this at this point anymore. I think adding this in known issues page (https://wiki.qt.io/Qt_5.6.0_Known_Issues) & fixing this in 5.6.1 should be ok even this is regression issue Br, Jani >> >>>>-----Original Message----- >>>>From: Development [mailto:development- >>>>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>>>Thiago Macieira >>>>Sent: 15. maaliskuuta 2016 7:24 >>>>To: development at qt-project.org >>>>Subject: Re: [Development] Qt 5.6.0 (final) packages available >>>> >>>>On segunda-feira, 14 de março de 2016 23:51:40 PDT Jan Kundrát wrote: >>>>> I understand that you won't apply that patch unless you fully understand >>>>> its consequences. Maybe it can be applied by some other Qt maintainer, >>>>> given that: >>>>> >>>>> - the regression was introduced in the 5.6 branch, >>>>> - the QtDBus maintainer doesn't have time to test it prior to the 5.6's >>>>> release, >>>>> - the patch fixes said regression? >>>>> >>>>> Anyway, just a suggestion :). >>>> >>>>There's no one who understands the code and would be comfortable >>approving >>>>it. >>>>I don't have a problem with qualified people approving code -- that's how >>>>QtCore is moving in my absence. There's no one like that for QtDBus. >>>> >>>>The problem is the severity of this bug. You're telling me this is a reliable >>>>deadlock. But the changes in question have been in the 5.6 branch for a >>couple >>>>of months, so I'm surprised that no one reported this earlier. >>>> >>>>I will take a look tomorrow. >>>> >>>>-- >>>>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 nospam at vuorela.dk Tue Mar 15 07:35:03 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Tue, 15 Mar 2016 06:35:03 +0000 (UTC) Subject: [Development] Qt 5.6.0 (final) packages available References: <4718570.E8hYs8Esm7@tjmaciei-mobl4> <3186b91d-9dee-4e40-9db3-039b3c14ae21@kde.org> <3473813.2XddHPYClg@tjmaciei-mobl4> Message-ID: > > TBUG-51676 seems to be p2 and so on cannot block the release. It also have been open a while without anyone indicating it should be fixed before releasing so I wouldn't block the release because of this at this point anymore. I think adding this in known issues page (https://wiki.qt.io/Qt_5.6.0_Known_Issues) & fixing this in 5.6.1 should be ok even this is regression issue > If it is reliably deadlocking on launch of KDE Desktop, then P2 is too low. What the KDE people does with Qt is one of the biggest public show-offs of what can be done with Qt technoloy. We should not undermine that. /Sune Qt Contributor KDE Developer Debian Developer From Lars.Knoll at theqtcompany.com Tue Mar 15 08:51:09 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 15 Mar 2016 07:51:09 +0000 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: References: <4718570.E8hYs8Esm7@tjmaciei-mobl4> <3186b91d-9dee-4e40-9db3-039b3c14ae21@kde.org> <3473813.2XddHPYClg@tjmaciei-mobl4> Message-ID: <99E30B12-8974-460E-A240-3F127B60DC18@theqtcompany.com> Hi, The report was marked as a P2, and nobody raised it to be a showstopper for the release. Trying to do this on the day before is unfair to everybody else. I understand that this is an issue for KDE, but since it only happens when using qDBusAddSpyHook I am convinced it’ll hit almost no other user. So while KDE is important, I don’t think this is a good enough reason to block the release. It’s been taking too long in any case already. Let’s rather get this fixed in the 5.6 branch and follow up with a 5.6.1 quickly. We have other important bug fixes already waiting in that branch as well. Cheers, Lars On 15/03/16 07:35, "Development on behalf of Sune Vuorela" wrote: >> >> TBUG-51676 seems to be p2 and so on cannot block the release. It also have been open a while without anyone indicating it should be fixed before releasing so I wouldn't block the release because of this at this point anymore. I think adding this in known issues page (https://wiki.qt.io/Qt_5.6.0_Known_Issues) & fixing this in 5.6.1 should be ok even this is regression issue >> > >If it is reliably deadlocking on launch of KDE Desktop, then P2 is too >low. > >What the KDE people does with Qt is one of the biggest public show-offs >of what can be done with Qt technoloy. We should not undermine that. > >/Sune >Qt Contributor >KDE Developer >Debian Developer > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at theqtcompany.com Tue Mar 15 09:42:15 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 15 Mar 2016 08:42:15 +0000 Subject: [Development] Fwd: [Interest] Qt 5.6.0 (final) packages available In-Reply-To: <3810201457979099@web23m.yandex.ru> References: <3805771457979024@web23m.yandex.ru> <3810201457979099@web23m.yandex.ru> Message-ID: Hi! Release isn't done yet and so on there isn't tag either yet. It should be there when release is officially done Br, Jani >>-----Original Message----- >>From: Development [mailto:development- >>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>Konstantin Podsvirov >>Sent: 14. maaliskuuta 2016 20:12 >>To: development at qt-project.org >>Subject: [Development] Fwd: [Interest] Qt 5.6.0 (final) packages available >> >>Hello everyone and thank you for the good work! >> >>I have a related question. According to this post and the comments: >> >>http://blog.qt.io/blog/2016/01/18/qt-charts-2-1-0-release >> >>It says that Qt 5.6 gives an open community QtCharts 2.1 and it is wonderful! >>But... looking at the git tags on code.qt.io I don't find the 2.1 release (2.0.1 >>only). >>If I'm wrong, correct me. >>Else tell me who can push the correct tag? >> >>14.03.2016, 19:59, "Jan Kundrát" : >>>  On Monday, 14 March 2016 14:22:42 CET, Heikkinen Jani wrote: >>>>  So please inform me >>>>  immediately if there is something new which is preventing us to >>>>  do the release. >>> >>>  Do you consider "Plasma5 deadlocks during startup" as a blocker? If so, >>>  https://bugreports.qt.io/browse/QTBUG-51676 . It's a regression in the 5.6 >>>  branch ("5.5 works fine. oldish 5.6 works fine, too"), and Thiago is >>>  currently AFK when it comes to Gerrit reviews. >>> >>>  Cheers, >>>  Jan >> >>-- >>Regards, >>Konstantin Podsvirov >>_______________________________________________ >>Development mailing list >>Development at qt-project.org >>http://lists.qt-project.org/mailman/listinfo/development From helio at kde.org Tue Mar 15 09:54:46 2016 From: helio at kde.org (Helio Chissini de Castro) Date: Tue, 15 Mar 2016 09:54:46 +0100 Subject: [Development] Fwd: [Interest] Qt 5.6.0 (final) packages available In-Reply-To: References: <3805771457979024@web23m.yandex.ru> <3810201457979099@web23m.yandex.ru> Message-ID: I agreed partially with Lars Is too late *now*, and we can wait for a quick 5.6.1, but is not entirely correct in say that we're not raising this issue from some time. For us in Fedora this issue been happening for a month, since rc releases and the bug was opened 10 days ago so the fact that is passed unattended or the fact that depends indirectly on one person only that understands well the code is that worries more. 5.6.0 is more important than regular releases, as Qt project defined as the LTS release, and this bug do Qt LTS been unusable for the largest showcase of Qt which is really a not good presentation. And can't take the blame away of us packagers and distros as well, that treated the bug as something magic that Qt project would discover as critical and go ahead to fix. Mea culpa too. So, let's take this as a lesson, and maybe try to make a better 5.6.1 release. Regards, Helio KDE Developer Fedora KDE packager On Tue, Mar 15, 2016 at 9:42 AM, Heikkinen Jani < jani.heikkinen at theqtcompany.com> wrote: > Hi! > > Release isn't done yet and so on there isn't tag either yet. It should be > there when release is officially done > > Br, > Jani > > >>-----Original Message----- > >>From: Development [mailto:development- > >>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of > >>Konstantin Podsvirov > >>Sent: 14. maaliskuuta 2016 20:12 > >>To: development at qt-project.org > >>Subject: [Development] Fwd: [Interest] Qt 5.6.0 (final) packages > available > >> > >>Hello everyone and thank you for the good work! > >> > >>I have a related question. According to this post and the comments: > >> > >>http://blog.qt.io/blog/2016/01/18/qt-charts-2-1-0-release > >> > >>It says that Qt 5.6 gives an open community QtCharts 2.1 and it is > wonderful! > >>But... looking at the git tags on code.qt.io I don't find the 2.1 > release (2.0.1 > >>only). > >>If I'm wrong, correct me. > >>Else tell me who can push the correct tag? > >> > >>14.03.2016, 19:59, "Jan Kundrát" : > >>> On Monday, 14 March 2016 14:22:42 CET, Heikkinen Jani wrote: > >>>> So please inform me > >>>> immediately if there is something new which is preventing us to > >>>> do the release. > >>> > >>> Do you consider "Plasma5 deadlocks during startup" as a blocker? If > so, > >>> https://bugreports.qt.io/browse/QTBUG-51676 . It's a regression in > the 5.6 > >>> branch ("5.5 works fine. oldish 5.6 works fine, too"), and Thiago is > >>> currently AFK when it comes to Gerrit reviews. > >>> > >>> Cheers, > >>> Jan > >> > >>-- > >>Regards, > >>Konstantin Podsvirov > >>_______________________________________________ > >>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 Stefan.Walter at lisec.com Tue Mar 15 10:19:12 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Tue, 15 Mar 2016 09:19:12 +0000 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: References: Message-ID: Hi, I am still facing an issue with the mentioned source package on CentOS 6.x with the g++ 4.4.7 in Qt3D. I don't know if that will be solved from your end and I don't know if that would delay the release. For me it is very important because Qt 5.6.0 will be a LTE release and CentOS 6.x is not even old. As we are making use of Qt3D, I can't skip it. The complier issue is that: g++ -c -include .pch/Qt53DRender -pipe -O2 -std=c++0x -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DQT3DRENDER_LIBRARY -DQT_BUILD_3DRENDER_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_3DCORE_LIB -DQT_OPENGLEXTENSIONS_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render -I. -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DRender -I../../include -I../../include/Qt3DRender -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DRender/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DRender/5.6.0/Qt3DRender -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/backend -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/geometry -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/graphicshelpers -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/framegraph -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/frontend -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/jobs -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/lights -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/materialsystem -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/renderstates -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/defaults -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/picking -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/raycasting -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/services -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/texture -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DCore/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DCore/5.6.0/Qt3DCore -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtGui/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtGui/5.6.0/QtGui -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DCore -I../../include/Qt3DCore -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtOpenGLExtensions -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtOpenGLExtensions -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtGui -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtGui -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtCore/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtCore/5.6.0/QtCore -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtConcurrent -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtConcurrent -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtCore -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtCore -I.moc -isystem /usr/include/libdrm -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/mkspecs/linux-g++ -o .obj/scenemanager.o /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp: In constructor âQt3DRender::Render::SceneManager::SceneManager()â: /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: class âQt3DRender::Render::SceneManagerâ does not have any field named âQResourceManagerâ /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: expected â(â before â<â token /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: expected â{â before â<â token /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp: At global scope: /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: expected unqualified-id before â<â token make[3]: *** [.obj/scenemanager.o] Error 1 make[3]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d/src/render' make[2]: *** [sub-render-make_first] Error 2 make[2]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d/src' make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d' make: *** [module-qt3d-make_first] Error 2 [walteste at aedu2-build-qt build-old]$ ^C [walteste at aedu2-build-qt build-old]$ g++ -version g++: unrecognized option '-version' g++: no input files Regards, Stefan From: Development [mailto:development-bounces+stefan.walter=lisec.com at qt-project.org] On Behalf Of Heikkinen Jani Sent: Montag, 14. März 2016 17:23 To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] Qt 5.6.0 (final) packages available Hi all, We have Qt 5.6.0 (final) packages available: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0/382/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0/367/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0/305/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0/latest_src/ Please check to packages to see if those are still working as expected. If nothing serious found we will release these packages as Qt 5.6.0 this Wed as planned. So please inform me immediately if there is something new which is preventing us to do the release. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at theqtcompany.com Tue Mar 15 10:31:35 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 15 Mar 2016 09:31:35 +0000 Subject: [Development] Fwd: [Interest] Qt 5.6.0 (final) packages available In-Reply-To: References: <3805771457979024@web23m.yandex.ru> <3810201457979099@web23m.yandex.ru> Message-ID: <5C754ACB-40BC-4C98-A019-66320125D562@theqtcompany.com> On 15/03/16 09:54, "Development on behalf of Helio Chissini de Castro" wrote: >I agreed partially with Lars > > >Is too late *now*, and we can wait for a quick 5.6.1, but is not entirely correct in say that we're not raising this issue from some time. >For us in Fedora this issue been happening for a month, since rc releases and the bug was opened 10 days ago so the fact that is passed unattended >or the fact that depends indirectly on one person only that understands well the code is that worries more. It’s been marked as a P2, and that means it immediately drops out of the focus of the release team. After the RC, they are only looking at P0 and P1 bugs. > >5.6.0 is more important than regular releases, as Qt project defined as the LTS release, and this bug do Qt LTS been unusable for the largest showcase >of Qt which is really a not good presentation. > >And can't take the blame away of us packagers and distros as well, that treated the bug as something magic that Qt project would discover as critical and go ahead to fix. Mea culpa too. Agree, the word deadlock in the bug report should have caused some warning bells to ring, at the same time the reporters and packagers should raise critical reports for them to the attention of the release team as quickly as possible. > >So, let's take this as a lesson, and maybe try to make a better 5.6.1 release. Agree. But as said, I hope that we can get a 5.6.1 out within a couple of weeks of 5.6.0. Until then, the packagers can apply the patch that fixes/works around the bug on top of 5.6.0. Cheers, Lars > > >Regards, Helio > >KDE Developer > >Fedora KDE packager > > > >On Tue, Mar 15, 2016 at 9:42 AM, Heikkinen Jani > wrote: > >Hi! > >Release isn't done yet and so on there isn't tag either yet. It should be there when release is officially done > >Br, >Jani > >>>-----Original Message----- >>>From: Development [mailto:development- >>>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>>Konstantin Podsvirov >>>Sent: 14. maaliskuuta 2016 20:12 >>>To: development at qt-project.org >>>Subject: [Development] Fwd: [Interest] Qt 5.6.0 (final) packages available >>> >>>Hello everyone and thank you for the good work! >>> >>>I have a related question. According to this post and the comments: >>> >>>http://blog.qt.io/blog/2016/01/18/qt-charts-2-1-0-release >>> >>>It says that Qt 5.6 gives an open community QtCharts 2.1 and it is wonderful! >>>But... looking at the git tags on >code.qt.io I don't find the 2.1 release (2.0.1 >>>only). >>>If I'm wrong, correct me. >>>Else tell me who can push the correct tag? >>> >>>14.03.2016, 19:59, "Jan Kundrát" : >>>> On Monday, 14 March 2016 14:22:42 CET, Heikkinen Jani wrote: >>>>> So please inform me >>>>> immediately if there is something new which is preventing us to >>>>> do the release. >>>> >>>> Do you consider "Plasma5 deadlocks during startup" as a blocker? If so, >>>> https://bugreports.qt.io/browse/QTBUG-51676 . It's a regression in the 5.6 >>>> branch ("5.5 works fine. oldish 5.6 works fine, too"), and Thiago is >>>> currently AFK when it comes to Gerrit reviews. >>>> >>>> Cheers, >>>> Jan >>> >>>-- >>>Regards, >>>Konstantin Podsvirov >>>_______________________________________________ >>>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 sean.harmer at kdab.com Tue Mar 15 10:48:33 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 15 Mar 2016 09:48:33 +0000 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: References: Message-ID: <1517834.Y9ZGpWIh1T@cartman> Hi, On Tuesday 15 Mar 2016 09:19:12 Walter Stefan wrote: > Hi, > > I am still facing an issue with the mentioned source package on CentOS 6.x > with the g++ 4.4.7 in Qt3D. I don't know if that will be solved from your > end and I don't know if that would delay the release. > > For me it is very important because Qt 5.6.0 will be a LTE release and > CentOS 6.x is not even old. As we are making use of Qt3D, I can't skip it. Qt 3D is a Tech Preview in 5.6 so is not subject to the LTS promises and should also not hold up the release. Having said that, does this fix the issue for you? https://codereview.qt-project.org/#/c/152345/ If so, the fix can be in 5.6.1 and you can manually patch it yourself for 5.6.0. Cheers, Sean > > The complier issue is that: > g++ -c -include .pch/Qt53DRender -pipe -O2 -std=c++0x -fvisibility=hidden > -fvisibility-inlines-hidden -fno-exceptions -Wall -W -D_REENTRANT -fPIC > -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB > -DQT3DRENDER_LIBRARY -DQT_BUILD_3DRENDER_LIB -DQT_BUILDING_QT > -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT > -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS > -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS > -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_3DCORE_LIB > -DQT_OPENGLEXTENSIONS_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r -I. > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Q > t3DRender -I../../include -I../../include/Qt3DRender > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Q > t3DRender/5.6.0 > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Q > t3DRender/5.6.0/Qt3DRender > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/backend > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/geometry > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/graphicshelpers > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/framegraph > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/frontend > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/jobs > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/lights > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/materialsystem > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/renderstates > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/io > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/defaults > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/picking > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/raycasting > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/services > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/rende > r/texture > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Q > t3DCore/5.6.0 > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Q > t3DCore/5.6.0/Qt3DCore > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include > /QtGui/5.6.0 > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include > /QtGui/5.6.0/QtGui > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Q > t3DCore -I../../include/Qt3DCore > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include > /QtOpenGLExtensions -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include > -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtOpenGLExtensions > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include > /QtGui -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtGui > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include > /QtCore/5.6.0 > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include > /QtCore/5.6.0/QtCore > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include > /QtConcurrent > -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtConcurrent > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include > /QtCore -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtCore -I.moc > -isystem /usr/include/libdrm > -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/mkspecs > /linux-g++ -o .obj/scenemanager.o > /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/ > io/scenemanager.cpp > /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/ > io/scenemanager.cpp: In constructor > âQt3DRender::Render::SceneManager::SceneManager()â: > /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/ > io/scenemanager.cpp:44: error: class âQt3DRender::Render::SceneManagerâ does > not have any field named âQResourceManagerâ > /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/ > io/scenemanager.cpp:44: error: expected â(â before â<â token > /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/ > io/scenemanager.cpp:44: error: expected â{â before â<â token > /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/ > io/scenemanager.cpp: At global scope: > /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/ > io/scenemanager.cpp:44: error: expected unqualified-id before â<â token > make[3]: *** [.obj/scenemanager.o] Error 1 > make[3]: Leaving directory > `/vol1/build/qt-5.6.0-fc/build-old/qt3d/src/render' make[2]: *** > [sub-render-make_first] Error 2 > make[2]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d/src' > make[1]: *** [sub-src-make_first] Error 2 > make[1]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d' > make: *** [module-qt3d-make_first] Error 2 > [walteste at aedu2-build-qt build-old]$ ^C > [walteste at aedu2-build-qt build-old]$ g++ -version > g++: unrecognized option '-version' > g++: no input files > > Regards, > Stefan > > From: Development > [mailto:development-bounces+stefan.walter=lisec.com at qt-project.org] On > Behalf Of Heikkinen Jani Sent: Montag, 14. März 2016 17:23 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: [Development] Qt 5.6.0 (final) packages available > > > Hi all, > > > > We have Qt 5.6.0 (final) packages available: > > > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0/382/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0/367/ > > Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0/305/ > > src: http://download.qt.io/snapshots/qt/5.6/5.6.0/latest_src/ > > > > Please check to packages to see if those are still working as expected. If > nothing serious found we will release these packages as Qt 5.6.0 this Wed > as planned. So please inform me immediately if there is something new which > is preventing us to do the release. > > > > br, > > Jani -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From jani.heikkinen at theqtcompany.com Tue Mar 15 10:55:56 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 15 Mar 2016 09:55:56 +0000 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: References: , Message-ID: Is there a bug report about this issue? if no please create one in https://bugreports.qt.io/secure/Dashboard.jspa I won't block release because of this any more, let's see if we can fix this for 5.6.1; Qt3D is still TP and it is compiling OK in most cases. Btw, please add as much info as possible in bug report (configure options etc) br, Jani ________________________________ Lähettäjä: Walter Stefan Lähetetty: 15. maaliskuuta 2016 11:19 Vastaanottaja: Heikkinen Jani; development at qt-project.org Kopio: releasing at qt-project.org Aihe: RE: Qt 5.6.0 (final) packages available Hi, I am still facing an issue with the mentioned source package on CentOS 6.x with the g++ 4.4.7 in Qt3D. I don’t know if that will be solved from your end and I don’t know if that would delay the release. For me it is very important because Qt 5.6.0 will be a LTE release and CentOS 6.x is not even old. As we are making use of Qt3D, I can’t skip it. The complier issue is that: g++ -c -include .pch/Qt53DRender -pipe -O2 -std=c++0x -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DQT3DRENDER_LIBRARY -DQT_BUILD_3DRENDER_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_3DCORE_LIB -DQT_OPENGLEXTENSIONS_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render -I. -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DRender -I../../include -I../../include/Qt3DRender -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DRender/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DRender/5.6.0/Qt3DRender -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/backend -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/geometry -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/graphicshelpers -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/framegraph -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/frontend -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/jobs -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/lights -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/materialsystem -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/renderstates -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/defaults -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/picking -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/raycasting -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/services -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/texture -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DCore/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DCore/5.6.0/Qt3DCore -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtGui/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtGui/5.6.0/QtGui -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DCore -I../../include/Qt3DCore -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtOpenGLExtensions -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtOpenGLExtensions -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtGui -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtGui -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtCore/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtCore/5.6.0/QtCore -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtConcurrent -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtConcurrent -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtCore -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtCore -I.moc -isystem /usr/include/libdrm -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/mkspecs/linux-g++ -o .obj/scenemanager.o /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp: In constructor âQt3DRender::Render::SceneManager::SceneManager()â: /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: class âQt3DRender::Render::SceneManagerâ does not have any field named âQResourceManagerâ /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: expected â(â before â<â token /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: expected â{â before â<â token /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp: At global scope: /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: expected unqualified-id before â<â token make[3]: *** [.obj/scenemanager.o] Error 1 make[3]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d/src/render' make[2]: *** [sub-render-make_first] Error 2 make[2]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d/src' make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d' make: *** [module-qt3d-make_first] Error 2 [walteste at aedu2-build-qt build-old]$ ^C [walteste at aedu2-build-qt build-old]$ g++ -version g++: unrecognized option '-version' g++: no input files Regards, Stefan From: Development [mailto:development-bounces+stefan.walter=lisec.com at qt-project.org] On Behalf Of Heikkinen Jani Sent: Montag, 14. März 2016 17:23 To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] Qt 5.6.0 (final) packages available Hi all, We have Qt 5.6.0 (final) packages available: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0/382/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0/367/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0/305/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0/latest_src/ Please check to packages to see if those are still working as expected. If nothing serious found we will release these packages as Qt 5.6.0 this Wed as planned. So please inform me immediately if there is something new which is preventing us to do the release. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at podsvirov.pro Tue Mar 15 11:44:22 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 15 Mar 2016 13:44:22 +0300 Subject: [Development] Fwd: [Interest] Qt 5.6.0 (final) packages available In-Reply-To: References: <3805771457979024@web23m.yandex.ru> <3810201457979099@web23m.yandex.ru> Message-ID: <3773081458038662@web11j.yandex.ru> An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Tue Mar 15 14:07:29 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 15 Mar 2016 14:07:29 +0100 Subject: [Development] Fixing QRect::width() / height() Message-ID: <201603151407.29932.marc.mutz@kdab.com> Hi, No, this is not about the +1. QRect is internally represented as QPoint topLeft, bottomRight, which means it can hold rectangles for which width() and height(), returning ints, may overflow, e.g. QRect{{INT_MIN, INT_MIN}, QPoint{0, 0}} QRect{{INT_MIN, INT_MIN}, QPoint{INT_MAX, INT_MAX}} While these may seem like pathological cases that never occur in practice, the auto-test checks such rectangles, and if it didn't the next attacker would. It is therefore important to provide a fix width() and height(). There are two options I can see: qint64 width64() const; unsigned int width??() const; The first returns the result as a 64-bit quantitiy, preserving the negative widths of unnormalised rectangles, and never overflowing, but possibly penalises 32-bit platforms without 64-bit register support. The second still overflows for left() == INT_MIN, right() == INT_MAX, because of the +1 (don't highjack this thread, you have been warned! :), would only work on normalized rects, but doesn't require a 64-bit quantitiy. Opinions on which one to choose? One? The other? Both? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From bo at vikingsoft.eu Tue Mar 15 13:08:42 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Tue, 15 Mar 2016 13:08:42 +0100 Subject: [Development] Fixing QRect::width() / height() In-Reply-To: <201603151407.29932.marc.mutz@kdab.com> References: <201603151407.29932.marc.mutz@kdab.com> Message-ID: <56E7FB4A.1090001@vikingsoft.eu> Den 15-03-2016 kl. 14:07 skrev Marc Mutz: > Hi, > > No, this is not about the +1. > > QRect is internally represented as QPoint topLeft, bottomRight, which means it > can hold rectangles for which width() and height(), returning ints, may > overflow, e.g. > > QRect{{INT_MIN, INT_MIN}, QPoint{0, 0}} > QRect{{INT_MIN, INT_MIN}, QPoint{INT_MAX, INT_MAX}} > > While these may seem like pathological cases that never occur in practice, the > auto-test checks such rectangles, and if it didn't the next attacker would. > > It is therefore important to provide a fix width() and height(). > > There are two options I can see: > > qint64 width64() const; > unsigned int width??() const; > > The first returns the result as a 64-bit quantitiy, preserving the negative > widths of unnormalised rectangles, and never overflowing, but possibly > penalises 32-bit platforms without 64-bit register support. > > The second still overflows for left() == INT_MIN, right() == INT_MAX, because > of the +1 (don't highjack this thread, you have been warned! :), would only > work on normalized rects, but doesn't require a 64-bit quantitiy. > > Opinions on which one to choose? One? The other? Both? There is another option that doesn't mean a change of signature: Bound the result. So if the real result is > INT_MAX, return INT_MAX. Same for INT_MIN. Yes, it's not the correct result, but I completely agree with you that it's a theoretical problem. As long as it's documented in the width() I really don't see the problem with this solution. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From Stefan.Walter at lisec.com Tue Mar 15 13:18:14 2016 From: Stefan.Walter at lisec.com (Walter Stefan) Date: Tue, 15 Mar 2016 12:18:14 +0000 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: References: , Message-ID: Hi, There is already a code review article: https://codereview.qt-project.org/#/c/152345/ I have also created the bug reference: https://bugreports.qt.io/browse/QTBUG-51879 If I compile with "configure -skip qt3d", then everything compiles. That tells me that only this issue is the actual show stopper. Regards, Stefan From: Heikkinen Jani [mailto:jani.heikkinen at theqtcompany.com] Sent: Dienstag, 15. März 2016 13:56 To: Walter Stefan ; development at qt-project.org Cc: releasing at qt-project.org; Sean Harmer Subject: VS: Qt 5.6.0 (final) packages available Is there a bug report about this issue? if no please create one in https://bugreports.qt.io/secure/Dashboard.jspa I won't block release because of this any more, let's see if we can fix this for 5.6.1; Qt3D is still TP and it is compiling OK in most cases. Btw, please add as much info as possible in bug report (configure options etc) br, Jani ________________________________ Lähettäjä: Walter Stefan > Lähetetty: 15. maaliskuuta 2016 11:19 Vastaanottaja: Heikkinen Jani; development at qt-project.org Kopio: releasing at qt-project.org Aihe: RE: Qt 5.6.0 (final) packages available Hi, I am still facing an issue with the mentioned source package on CentOS 6.x with the g++ 4.4.7 in Qt3D. I don't know if that will be solved from your end and I don't know if that would delay the release. For me it is very important because Qt 5.6.0 will be a LTE release and CentOS 6.x is not even old. As we are making use of Qt3D, I can't skip it. The complier issue is that: g++ -c -include .pch/Qt53DRender -pipe -O2 -std=c++0x -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_XKB -DQT3DRENDER_LIBRARY -DQT_BUILD_3DRENDER_LIB -DQT_BUILDING_QT -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x050000 -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_3DCORE_LIB -DQT_OPENGLEXTENSIONS_LIB -DQT_GUI_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render -I. -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DRender -I../../include -I../../include/Qt3DRender -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DRender/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DRender/5.6.0/Qt3DRender -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/backend -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/geometry -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/graphicshelpers -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/framegraph -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/frontend -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/jobs -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/lights -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/materialsystem -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/renderstates -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/defaults -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/picking -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/raycasting -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/services -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/texture -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DCore/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DCore/5.6.0/Qt3DCore -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtGui/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtGui/5.6.0/QtGui -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/include/Qt3DCore -I../../include/Qt3DCore -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtOpenGLExtensions -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtOpenGLExtensions -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtGui -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtGui -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtCore/5.6.0 -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtCore/5.6.0/QtCore -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtConcurrent -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtConcurrent -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/include/QtCore -I/vol1/build/qt-5.6.0-fc/build-old/qtbase/include/QtCore -I.moc -isystem /usr/include/libdrm -I/vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qtbase/mkspecs/linux-g++ -o .obj/scenemanager.o /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp: In constructor âQt3DRender::Render::SceneManager::SceneManager()â: /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: class âQt3DRender::Render::SceneManagerâ does not have any field named âQResourceManagerâ /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: expected â(â before â<â token /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: expected â{â before â<â token /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp: At global scope: /vol1/build/qt-5.6.0-fc/qt-everywhere-opensource-src-5.6.0/qt3d/src/render/io/scenemanager.cpp:44: error: expected unqualified-id before â<â token make[3]: *** [.obj/scenemanager.o] Error 1 make[3]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d/src/render' make[2]: *** [sub-render-make_first] Error 2 make[2]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d/src' make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory `/vol1/build/qt-5.6.0-fc/build-old/qt3d' make: *** [module-qt3d-make_first] Error 2 [walteste at aedu2-build-qt build-old]$ ^C [walteste at aedu2-build-qt build-old]$ g++ -version g++: unrecognized option '-version' g++: no input files Regards, Stefan From: Development [mailto:development-bounces+stefan.walter=lisec.com at qt-project.org] On Behalf Of Heikkinen Jani Sent: Montag, 14. März 2016 17:23 To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] Qt 5.6.0 (final) packages available Hi all, We have Qt 5.6.0 (final) packages available: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0/382/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0/367/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0/305/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0/latest_src/ Please check to packages to see if those are still working as expected. If nothing serious found we will release these packages as Qt 5.6.0 this Wed as planned. So please inform me immediately if there is something new which is preventing us to do the release. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Tue Mar 15 15:43:46 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 15 Mar 2016 15:43:46 +0100 Subject: [Development] Fixing QRect::width() / height() In-Reply-To: <56E7FB4A.1090001@vikingsoft.eu> References: <201603151407.29932.marc.mutz@kdab.com> <56E7FB4A.1090001@vikingsoft.eu> Message-ID: <201603151543.46417.marc.mutz@kdab.com> On Tuesday 15 March 2016 13:08:42 Bo Thorsen wrote: > Den 15-03-2016 kl. 14:07 skrev Marc Mutz: [...] > There is another option that doesn't mean a change of signature: Bound > the result. So if the real result is > INT_MAX, return INT_MAX. Same for > INT_MIN. > > Yes, it's not the correct result, but I completely agree with you that > it's a theoretical problem. As long as it's documented in the width() I > really don't see the problem with this solution. I like the idea to change width() to return a bounded result to avoid UB for old users, but we need a code path that returns the correct result for new users without everyone of them going quint64(1) + r.right() - r.left() by themselves... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From s.ziming at hotmail.com Tue Mar 15 14:41:01 2016 From: s.ziming at hotmail.com (Ziming Song) Date: Tue, 15 Mar 2016 13:41:01 +0000 Subject: [Development] Possible bug in Qt Text Engine Message-ID: Hi everyone, I have been fighting with this bug for over a year, but till now I can't find a satisfying solution, so I came here. I use QPlainTextEdit to implement my own code editor widget, much like the tutorial does. The widget works fine, except it displays CJK characters with a different line height. If a line contains only English and Latin characters, QPlainTextEdit would displays them just fine. But if a line contains CJK characters, that line height will be a little larger than other lines. [cid:1729d0a7-362d-4eac-95f1-81aab69f3d1e] In the above picture, I put two widget next to each other, and both entered 17 lines. Only the left one has lines with Chinese characters. I browsed through the qt source code, and I think the problem might in the Qt text engine. Since QTextLine gives different height for english and chinese characters. void test(QString s) { QFont f("Courier 10 Pitch", 12); // this font doesn't contain CJK characters QTextLayout textLayout(s, f); textLayout.setCacheEnabled(true); textLayout.beginLayout(); while (1) { QTextLine line = textLayout.createLine(); if (!line.isValid()) { break; } line.setLineWidth(1000); // long enough qDebug() << line.height(); } textLayout.endLayout(); } // in main test("english"); // output 19 test("??"); // output 20 I've tried reimplementing QPlainTextEdit::paintEvent or inherits from QPlainTextDocumentLayout, but those classes are heavily coupled. So is this really a bug in Qt text engine. How can I make lines have same line height? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ed.png Type: image/png Size: 20321 bytes Desc: ed.png URL: From Shawn.Rutledge at theqtcompany.com Tue Mar 15 14:44:12 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Tue, 15 Mar 2016 13:44:12 +0000 Subject: [Development] Fixing QRect::width() / height() In-Reply-To: <201603151543.46417.marc.mutz@kdab.com> References: <201603151407.29932.marc.mutz@kdab.com> <56E7FB4A.1090001@vikingsoft.eu> <201603151543.46417.marc.mutz@kdab.com> Message-ID: <2862319B-A977-454D-8A29-09E1B976DA7D@digia.com> > On 15 Mar 2016, at 15:43, Marc Mutz wrote: > > On Tuesday 15 March 2016 13:08:42 Bo Thorsen wrote: >> Den 15-03-2016 kl. 14:07 skrev Marc Mutz: > [...] >> There is another option that doesn't mean a change of signature: Bound >> the result. So if the real result is > INT_MAX, return INT_MAX. Same for >> INT_MIN. >> >> Yes, it's not the correct result, but I completely agree with you that >> it's a theoretical problem. As long as it's documented in the width() I >> really don't see the problem with this solution. > > I like the idea to change width() to return a bounded result to avoid UB for > old users, but we need a code path that returns the correct result for new > users without everyone of them going quint64(1) + r.right() - r.left() by > themselves… Cluttering up the API doesn’t seem nice. Also not sure what you mean by new users needing such large rectangles… if they do, why don’t they use QRectF? Or is it about a security hole? From Andre.Poenitz at theqtcompany.com Tue Mar 15 14:44:44 2016 From: Andre.Poenitz at theqtcompany.com (Poenitz Andre) Date: Tue, 15 Mar 2016 13:44:44 +0000 Subject: [Development] Fixing QRect::width() / height() In-Reply-To: <201603151543.46417.marc.mutz@kdab.com> References: <201603151407.29932.marc.mutz@kdab.com> <56E7FB4A.1090001@vikingsoft.eu>, <201603151543.46417.marc.mutz@kdab.com> Message-ID: On Tuesday 15 March 2016 13:08:42 Bo Thorsen wrote: > > Den 15-03-2016 kl. 14:07 skrev Marc Mutz: > [...] > > There is another option that doesn't mean a change of signature: Bound > > the result. So if the real result is > INT_MAX, return INT_MAX. Same for > > INT_MIN. > > > > Yes, it's not the correct result, but I completely agree with you that > > it's a theoretical problem. As long as it's documented in the width() I > > really don't see the problem with this solution. > > I like the idea to change width() to return a bounded result to avoid UB for > old users, but we need a code path that returns the correct result for new > users without everyone of them going quint64(1) + r.right() - r.left() by > themselves... You seem to claim that new users would need 64 bit QRects. This is unlikely. Bo's proposal addresses the problem and does not require API changes. Andre' From abbapoh at gmail.com Tue Mar 15 14:48:52 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Tue, 15 Mar 2016 16:48:52 +0300 Subject: [Development] Fixing QRect::width() / height() In-Reply-To: References: <201603151407.29932.marc.mutz@kdab.com> <56E7FB4A.1090001@vikingsoft.eu> <201603151543.46417.marc.mutz@kdab.com> Message-ID: We can also validate rect on construction and allow to create rects no bigger than QRect(*, *, MAX_INT, MAX_INT) rects? 2016-03-15 16:44 GMT+03:00 Poenitz Andre : > > On Tuesday 15 March 2016 13:08:42 Bo Thorsen wrote: > > > Den 15-03-2016 kl. 14:07 skrev Marc Mutz: > > [...] > > > There is another option that doesn't mean a change of signature: Bound > > > the result. So if the real result is > INT_MAX, return INT_MAX. Same > for > > > INT_MIN. > > > > > > Yes, it's not the correct result, but I completely agree with you that > > > it's a theoretical problem. As long as it's documented in the width() I > > > really don't see the problem with this solution. > > > > I like the idea to change width() to return a bounded result to avoid UB > for > > old users, but we need a code path that returns the correct result for > new > > users without everyone of them going quint64(1) + r.right() - r.left() by > > themselves... > > You seem to claim that new users would need 64 bit QRects. > > This is unlikely. > > Bo's proposal addresses the problem and does not require API > changes. > > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Tue Mar 15 16:19:26 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 15 Mar 2016 16:19:26 +0100 Subject: [Development] Fixing QRect::width() / height() In-Reply-To: References: <201603151407.29932.marc.mutz@kdab.com> Message-ID: <201603151619.27971.marc.mutz@kdab.com> On Tuesday 15 March 2016 14:48:52 Иван Комиссаров wrote: > We can also validate rect on construction and allow to create rects no > bigger than QRect(*, *, MAX_INT, MAX_INT) rects? No. The ctors are constexpr nothrow now. We must maintain the wide contract. In Qt 6, I'd normalise on construction, then we can at least assume that x1 >= x1 - 1 in the implementation, which allows to use 32-bit arithmetic in more cases than now, if we want to avoid branches. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Tue Mar 15 16:32:13 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 15 Mar 2016 16:32:13 +0100 Subject: [Development] Fixing QRect::width() / height() In-Reply-To: <2862319B-A977-454D-8A29-09E1B976DA7D@digia.com> References: <201603151407.29932.marc.mutz@kdab.com> <201603151543.46417.marc.mutz@kdab.com> <2862319B-A977-454D-8A29-09E1B976DA7D@digia.com> Message-ID: <201603151632.15111.marc.mutz@kdab.com> On Tuesday 15 March 2016 14:44:12 Rutledge Shawn wrote: > > On 15 Mar 2016, at 15:43, Marc Mutz wrote: > > > > On Tuesday 15 March 2016 13:08:42 Bo Thorsen wrote: > >> Den 15-03-2016 kl. 14:07 skrev Marc Mutz: > > [...] > > > >> There is another option that doesn't mean a change of signature: Bound > >> the result. So if the real result is > INT_MAX, return INT_MAX. Same for > >> INT_MIN. > >> > >> Yes, it's not the correct result, but I completely agree with you that > >> it's a theoretical problem. As long as it's documented in the width() I > >> really don't see the problem with this solution. > > > > I like the idea to change width() to return a bounded result to avoid UB > > for old users, but we need a code path that returns the correct result > > for new users without everyone of them going quint64(1) + r.right() - > > r.left() by themselves… > > Cluttering up the API doesn’t seem nice. Also not sure what you mean by > new users needing such large rectangles… if they do, why don’t they use > QRectF? For one, QRectF has different semantics w.r.t. wdith()/height(), for another, sizeof(QRectF) == 2 * sizeof(QRect). > Or is it about a security hole? Yes, that, too. If you read a rectangle from user input, then an attacker can currently force you to construct a QRect with overflowing bounds. ATM, calling width() on this QRect invokes UB. Bo's idea would fix the UB, but return something other than the width(). It's not impossible that this could be exploited, too, e.g. if the app divides by a non-isNull rect's width and the attacker forges the coordinates such that width() return 0 (which https://codereview.qt-project.org/152354 should already get rid of, i.e that isNull() returns true in such a situation). But it's also about designing an API that's easy to use correctly and hard to use incorrectly. Making width() return a sufficiently large type would make it hard to use QRect incorrectly. We can do that for Qt 6, but we need a solution for Qt 5, too. Thus, whatever clutter is introduced by this change, it will be gone in Qt 6 (except for an inline forwarder), so it's not worse than any other example of deprecating API in favour of a new one. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Andre.Poenitz at theqtcompany.com Tue Mar 15 15:43:09 2016 From: Andre.Poenitz at theqtcompany.com (Poenitz Andre) Date: Tue, 15 Mar 2016 14:43:09 +0000 Subject: [Development] Fixing QRect::width() / height() In-Reply-To: <201603151632.15111.marc.mutz@kdab.com> References: <201603151407.29932.marc.mutz@kdab.com> <201603151543.46417.marc.mutz@kdab.com> <2862319B-A977-454D-8A29-09E1B976DA7D@digia.com>, <201603151632.15111.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > > Cluttering up the API doesn’t seem nice. Also not sure what you mean by > > new users needing such large rectangles… if they do, why don’t they use > > QRectF? > > For one, QRectF has different semantics w.r.t. wdith()/height(), for another, > sizeof(QRectF) == 2 * sizeof(QRect). That does not mean that the needed semantics would not be achievable. > > Or is it about a security hole? > > Yes, that, too. If you read a rectangle from user input, then an attacker can > currently force you to construct a QRect with overflowing bounds. ATM, calling > width() on this QRect invokes UB. Bo's idea would fix the UB, but return > something other than the width(). The return value would be the same before, except for values around INT_MAX. Such values are *not* expected in a legitimate use of QRect ("Screen coordinates"), so a behaviour change there will not affect normal users. The clamping achieves exactly what is wanted: It plug the hole without side-effects for supported uses. > It's not impossible that this could be > exploited, too, e.g. if the app divides by a non-isNull rect's width and the > attacker forges the coordinates such that width() return 0 Please describe how that can happen. width() return will only change around INT_MAX, not around 0. > But it's also about designing an API that's easy to use correctly and hard to > use incorrectly. Adding a second width() version is exactly that: It designs an API that's harder to use ("which version do I need"?), leaves all existing users in the rain, and would trigger major changes in code that wants to adapt. Clamping width() fixes the problem for existing user code automatically, and leaves the API unambiguous. Andre' From Lars.Knoll at theqtcompany.com Tue Mar 15 15:49:54 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 15 Mar 2016 14:49:54 +0000 Subject: [Development] [Releasing] Qt 5.6.0 (final) packages available Message-ID: That’s unfortunate, but the fix for this one will have to wait for 5.6.1 as well. Cheers, Lars On 15/03/16 15:35, "Releasing on behalf of Hernan Martinez via Releasing" wrote: >Hello. > >Thank you for announcing the final packages. > >There’s still a P1 Critical Bug affecting Qt Quick itself, a core feature. >https://bugreports.qt.io/browse/QTBUG-51558 :( > >Thank you, >Hernan Martinez >From: Releasing [mailto:releasing-bounces+hmartinez=malwarebytes.org at qt-project.org] >On Behalf Of Heikkinen Jani >Sent: Monday, March 14, 2016 9:23 AM >To: development at qt-project.org >Cc: releasing at qt-project.org >Subject: [Releasing] Qt 5.6.0 (final) packages available > > > >Hi all, > >We have Qt 5.6.0 (final) packages available: > >Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0/382/ >Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0/367/ >Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0/305/ >src: http://download.qt.io/snapshots/qt/5.6/5.6.0/latest_src/ > >Please check to packages to see if those are still working as expected. If nothing serious found we will release these packages as Qt 5.6.0 this Wed as planned. > So please inform me immediately if there is something new which is preventing us to do the release. > >br, >Jani > > > From thiago.macieira at intel.com Tue Mar 15 16:14:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 15 Mar 2016 08:14:16 -0700 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <99E30B12-8974-460E-A240-3F127B60DC18@theqtcompany.com> References: <99E30B12-8974-460E-A240-3F127B60DC18@theqtcompany.com> Message-ID: <2823200.7M35qITZmi@tjmaciei-mobl4> On terça-feira, 15 de março de 2016 07:51:09 PDT Knoll Lars wrote: > I understand that this is an issue for KDE, but since it only happens when > using qDBusAddSpyHook I am convinced it’ll hit almost no other user. So > while KDE is important, I don’t think this is a good enough reason to block > the release. It’s been taking too long in any case already. qDBusAddSpyHook is used by exactly one application and that's kded/kiod. I will not support any other application using it. Again: when it was reported, it sounded like a race condition that was hit only infrequently, if you were unlucky. Only when Jan reported in this thread that it is happening all the time did it sound more serious. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 15 16:20:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 15 Mar 2016 08:20:30 -0700 Subject: [Development] Fwd: [Interest] Qt 5.6.0 (final) packages available In-Reply-To: References: <3805771457979024@web23m.yandex.ru> Message-ID: <5096406.Hir1aGXJc4@tjmaciei-mobl4> On terça-feira, 15 de março de 2016 09:54:46 PDT Helio Chissini de Castro wrote: > 5.6.0 is more important than regular releases, as Qt project defined as the > LTS release, and this bug do Qt LTS been unusable for the largest showcase > of Qt which is really a not good presentation. 5.6 is the LTS release, not 5.6.0. The fix for bugs in the 5.6.0 release is the release of 5.6.1. We'll do that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From matnares at gmail.com Tue Mar 15 17:43:20 2016 From: matnares at gmail.com (=?UTF-8?B?TWF0w61hcyBOw6lzdG9yIEFyZXM=?=) Date: Tue, 15 Mar 2016 13:43:20 -0300 Subject: [Development] Qt Quick emulation layer crashed (1:0) Message-ID: Hello everybody!!! I have been testing Qt5.6 of course Beta an RC releases have some bugs as expected. But in all recent linux releases including the final 5.6.0 release the QML design view is completely unusable. Even the most simple qml led to "Qt Quick emulation layer crashed (1:0)" I have been working in complex QML layouts and *the designer was never really as useful* as expected. it is very buggy across all releases from it first appearance. But now it can't handle even something as simple as this example: import QtQuick 2.5 import QtQuick.Controls 1.4 ApplicationWindow { id: applicationWindow1 visible: true width: 640 height: 480 title: qsTr("Testing") Timer{ id:testiTimer interval: 1500; running: true; repeat: true onTriggered: { console.log("message") } } Rectangle { id: testRectangle1 width: 383 height: 86 color: "#c2c2c2" } } This code runs ok but can't be edited in design mode because "Qt Quick emulation layer crashed (1:0)" shows up. is there a workaround? or some alternative? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Tue Mar 15 19:06:50 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 15 Mar 2016 19:06:50 +0100 Subject: [Development] Fixing QRect::width() / height() In-Reply-To: References: <201603151407.29932.marc.mutz@kdab.com> <201603151632.15111.marc.mutz@kdab.com> Message-ID: <201603151906.50697.marc.mutz@kdab.com> On Tuesday 15 March 2016 15:43:09 Poenitz Andre wrote: > > It's not impossible that this could be > > exploited, too, e.g. if the app divides by a non-isNull rect's width and > > the attacker forges the coordinates such that width() return 0 > > Please describe how that can happen. Run tst_qrect, isNull(LargestCoordQRect) produces true even though the rect is definitely not null. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Tue Mar 15 18:26:15 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 15 Mar 2016 10:26:15 -0700 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <2823200.7M35qITZmi@tjmaciei-mobl4> References: <99E30B12-8974-460E-A240-3F127B60DC18@theqtcompany.com> <2823200.7M35qITZmi@tjmaciei-mobl4> Message-ID: <3335158.TYKkN6rLcp@tjmaciei-mobl4> On terça-feira, 15 de março de 2016 08:14:16 PDT Thiago Macieira wrote: > Again: when it was reported, it sounded like a race condition that was hit > only infrequently, if you were unlucky. Only when Jan reported in this > thread that it is happening all the time did it sound more serious. I've just investigated the issue and it's not that simple to fix. The problem is the loopback delivery of messages. When QtDBus notices that an outgoing call's destination is the local application, it has an optimisation path that bypasses going through the bus. That was added in Qt 4.2 to specifically avoid a deadlock: the application would be waiting for a reply and would not be processing the incoming call. Unfortunately, there's something wrong with the new threaded solution. I'm still investigating whether there's only one bug or if there are two. The semaphore that was hit should never have been hit, but it's only getting hit because a previous outgoing local call wasn't delivered properly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From krnekit at gmail.com Tue Mar 15 20:08:12 2016 From: krnekit at gmail.com (Nikita Krupenko) Date: Tue, 15 Mar 2016 21:08:12 +0200 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <809fcf26-2788-40e1-b057-a12c4236464a@kde.org> References: <77dcf352-786a-439f-927d-007ed5945840@kde.org> <2531327.Mqljhk9Z8F@tjmaciei-mobl4> <809fcf26-2788-40e1-b057-a12c4236464a@kde.org> Message-ID: 2016-03-14 21:36 GMT+02:00 Jan Kundrát : >> That's kded/kiod, not Plasma. > > > Yes; however, given that kded is used in a default configuration of Plasma > 5, the end result is that the Plasma panel (and krunner, and possibly other > components) "won't work" with the current version of Qt 5.6. Just note here, that this bug broke heavily the whole Plasma DE on my system (Mageia): https://ml.mageia.org/l/arc/dev/2016-03/msg00069.html After I applied the patch to lib64qt5dbus5, this problems gone. I hope, this problem would be highlighted in the known issues. From ritt.ks at gmail.com Tue Mar 15 20:57:02 2016 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Tue, 15 Mar 2016 23:57:02 +0400 Subject: [Development] Possible bug in Qt Text Engine In-Reply-To: References: Message-ID: Hi, Did you file a bug report? ML is not really the right place for reporting bugs. Briefly, the CJK characters in your text are covered by some fallback font for which the font metrics are slightly different, so that the line height is the sum of a max ascent, max descent, and max leading (see QTextEngine::shapeText). Regards, Konstantin 2016-03-15 17:41 GMT+04:00 Ziming Song : > Hi everyone, > > > I have been fighting with this bug for over a year, but till now I can't > find a satisfying solution, so I came here. > > > I use QPlainTextEdit to implement my own code editor widget, much like > the tutorial does. The widget works fine, except it displays CJK characters > with a different line height. > > > If a line contains only English and Latin characters, QPlainTextEdit would > displays them just fine. But if a line contains CJK characters, that line > height will be a little larger than other lines. > > > > > In the above picture, I put two widget next to each other, and both > entered 17 lines. Only the left one has lines with Chinese characters. > > > I browsed through the qt source code, and I think the problem might in the > Qt text engine. Since QTextLine gives different height for english and > chinese characters. > > > void test(QString s) { > QFont f("Courier 10 Pitch", 12); // this font doesn't contain CJK > characters > QTextLayout textLayout(s, f); > textLayout.setCacheEnabled(true); > textLayout.beginLayout(); > while (1) { > QTextLine line = textLayout.createLine(); > if (!line.isValid()) { break; } > line.setLineWidth(1000); // long enough > qDebug() << line.height(); > } > textLayout.endLayout(); > } > > // in main > test("english"); // output 19 > test("中文"); // output 20 > > I've tried reimplementing QPlainTextEdit::paintEvent or inherits from > QPlainTextDocumentLayout, but those classes are heavily coupled. > > > So is this really a bug in Qt text engine. How can I make lines have same > line height? > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ed.png Type: image/png Size: 20321 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Mar 15 22:01:10 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 15 Mar 2016 14:01:10 -0700 Subject: [Development] Qt 5.6.0 (final) packages available In-Reply-To: <3335158.TYKkN6rLcp@tjmaciei-mobl4> References: <2823200.7M35qITZmi@tjmaciei-mobl4> <3335158.TYKkN6rLcp@tjmaciei-mobl4> Message-ID: <2449470.C8e97jDD6j@tjmaciei-mobl4> On terça-feira, 15 de março de 2016 10:26:15 PDT Thiago Macieira wrote: > Unfortunately, there's something wrong with the new threaded solution. I'm > still investigating whether there's only one bug or if there are two. The > semaphore that was hit should never have been hit, but it's only getting > hit because a previous outgoing local call wasn't delivered properly. Patch posted. It was a one-liner and is now just a couple of lines. The risk is minimal for any application that isn't kded, but I'd rather that Linux distros simply backport the patch on top of 5.6.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 16 07:09:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 15 Mar 2016 23:09:07 -0700 Subject: [Development] Is DirectFB dead? Message-ID: <19012436.GgXnARiVH2@tjmaciei-mobl4> DirectFB.org is down and has been down since at August 1, 2015. The last commit on the GitHub mirror is actually from 2014. Our last non-buildsystem change there prior to my compile fix is from September 2015. I'd like to turn off the automatic detection in the Unix configure for Qt 5.6. This will solve the problem of the failure to compile (with a hammer). Holger: do you know any more details about the project? Is it dead? Is there an active fork of it anywhere? Even archives of past releases? If there's no action to revive the project, we should declare it deprecated in Qt 5.7, with the note that we aren't testing at all, not even to see if it compiles, and later remove in Qt 5.8. See: https://www.phoronix.com/scan.php?page=news_item&px=DirectFB-Is-It-Gone https://plus.google.com/+ThomasPetazzoni/posts/ZMGW8w1yBfN Wikipedia too -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From holger at freyther.de Wed Mar 16 09:13:23 2016 From: holger at freyther.de (Holger Freyther) Date: Wed, 16 Mar 2016 09:13:23 +0100 Subject: [Development] Is DirectFB dead? In-Reply-To: <19012436.GgXnARiVH2@tjmaciei-mobl4> References: <19012436.GgXnARiVH2@tjmaciei-mobl4> Message-ID: > On 16 Mar 2016, at 07:09, Thiago Macieira wrote: > > I'd like to turn off the automatic detection in the Unix configure for Qt 5.6. > This will solve the problem of the failure to compile (with a hammer). sure > Holger: do you know any more details about the project? Is it dead? Is there > an active fork of it anywhere? Even archives of past releases? the FOSS development of DirectFB seems to be dead but I don't know the details or reasons. I think it is unlikely that (git.)directfb.org will be back online and the code on github is also only an old version of it. > If there's no action to revive the project, we should declare it deprecated in > Qt 5.7, with the note that we aren't testing at all, not even to see if it > compiles, and later remove in Qt 5.8. I was wondering what it means for the Qt project. The reality (at least two years ago) in the Set-Top-Box market was that the SoC vendors would (heavily) modify DirectFB and ship it to their customers. Given their general lack of upstream involvement I would be surprised if they drop DirectFB just because directfb.org and the development behind it is dead. But your approach seems fine, deprecate it in 5.7 (and print a big warning on configure?) and see if any of the users are willing to invest in the maintenance. kind regards holger From jturcotte at woboq.com Wed Mar 16 09:24:07 2016 From: jturcotte at woboq.com (Jocelyn Turcotte) Date: Wed, 16 Mar 2016 09:24:07 +0100 Subject: [Development] Is DirectFB dead? In-Reply-To: References: <19012436.GgXnARiVH2@tjmaciei-mobl4> Message-ID: > On 16 Mar 2016, at 09:13, Holger Freyther wrote: > >> Holger: do you know any more details about the project? Is it dead? Is there >> an active fork of it anywhere? Even archives of past releases? > > the FOSS development of DirectFB seems to be dead but I don't know the details or reasons. I think it is unlikely that (git.)directfb.org will be back online and the code on github is also only an old version of it. FWIW, the maintainer pushed a more recent tree at https://github.com/deniskropp/DirectFB and even accepted one pull request, but this one also doesn’t have all of the 1.7 branch as it was and hasn’t move since October 2015. I had to use https://github.com/lancebaiyouview/DirectFB which at least got that branch up to the 1.7.7 tag. Cheers, Jocelyn From Thomas.Hartmann at theqtcompany.com Wed Mar 16 10:24:54 2016 From: Thomas.Hartmann at theqtcompany.com (Hartmann Thomas) Date: Wed, 16 Mar 2016 09:24:54 +0000 Subject: [Development] Qt Quick emulation layer crashed (1:0) In-Reply-To: References: Message-ID: Hi, The Timer element is not officially supported in the designer. The designer does show an error message, that you can ignore though. There are work arrounds for your isse: 1) Use .ui.qml files and decouple the logic that requires the Timer from the pure form (see: http://doc.qt.io/qtcreator/creator-quick-ui-forms.html). 2) If you need a quick solution than you can move the Timer into a component (e.g. MyTimer). That does work. We do not regularly test unsupported elements and documents containing those. We concetrate on the QML subset we support for ui.qml files and that we can guarantee to work. We do accept bugreports for issues like yours and we will fix them, but our focus is on UI elements. Kind Regards, Thomas Hartmann ________________________________ From: Development on behalf of Matías Néstor Ares Sent: Tuesday, March 15, 2016 5:43 PM To: Subject: [Development] Qt Quick emulation layer crashed (1:0) Hello everybody!!! I have been testing Qt5.6 of course Beta an RC releases have some bugs as expected. But in all recent linux releases including the final 5.6.0 release the QML design view is completely unusable. Even the most simple qml led to "Qt Quick emulation layer crashed (1:0)" I have been working in complex QML layouts and the designer was never really as useful as expected. it is very buggy across all releases from it first appearance. But now it can't handle even something as simple as this example: import QtQuick 2.5 import QtQuick.Controls 1.4 ApplicationWindow { id: applicationWindow1 visible: true width: 640 height: 480 title: qsTr("Testing") Timer{ id:testiTimer interval: 1500; running: true; repeat: true onTriggered: { console.log("message") } } Rectangle { id: testRectangle1 width: 383 height: 86 color: "#c2c2c2" } } This code runs ok but can't be edited in design mode because "Qt Quick emulation layer crashed (1:0)" shows up. is there a workaround? or some alternative? Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From announce at qt-project.org Wed Mar 16 12:58:51 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 16 Mar 2016 11:58:51 +0000 Subject: [Development] [Announce] Qt 5.6 released Message-ID: Hi, Just wanted to let you all know that Qt 5.6 has been released today. For details, check out http://www.qt.io/qt5-6/ and the blog post at http://blog.qt.io/blog/2016/03/16/qt-5-6-released/ . Cheers, Lars _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From Kai.Koehne at theqtcompany.com Wed Mar 16 16:14:24 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Wed, 16 Mar 2016 15:14:24 +0000 Subject: [Development] Qt Coding Guidelines Message-ID: Hi there, We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but if there has been a consensus (which is sometimes hard to find out), it was often buried pretty deep in the mailing thread. IMO it would be good to make decisions more explicit, and write them down also somewhere outside of this list. We already have the coding conventions page: https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at keeping it up to date - and one reason is IMO that, given that it's a wiki everybody can edit, people in a twist of irony stay away from editing it to avoid editing wars. I've been contemplating whether we should instead use some more formalized decision process. We could have a document uploaded in git, and every change needs to be reviewed and approved by Lars. While at it, this fresh start would also be a good opportunity to check whether all the rules in above wiki page, and the structure of the document in general, can be improved. As sort of a demo I created https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidelines.md What do you think? If nobody sees the value in this, I'll refrain from sinking more time into it. Regards Kai -- Kai Köhne, Senior Manager R&D - The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From edward.welbourne at theqtcompany.com Wed Mar 16 16:48:50 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Wed, 16 Mar 2016 15:48:50 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: Message-ID: Kai Koehne said: > I've been contemplating whether we should instead use some more > formalized decision process. We could have a document uploaded in git, > and every change needs to be reviewed and approved by Lars. This sounds like an eminently sensible way to document a consensus: we can have our long rambling discussions (and, when they arise, flame wars) in the review comments; yet produce a single document that one can read to get the current accepted (however grudgingly by some) status quo. Furthermore, the coding style document would be part of what I've got checked out locally, so I can even read it when I'm without network, Eddy. From dimitar.asenov at gmail.com Wed Mar 16 16:51:27 2016 From: dimitar.asenov at gmail.com (Dimitar Asenov) Date: Wed, 16 Mar 2016 16:51:27 +0100 Subject: [Development] Making QWebEngineView work inside a QGraphicsView Message-ID: <56E980FF.4040306@gmail.com> Hi all, Now that QWebKit is no longer included with Qt, I need a new way of using a web renderer inside a QGraphicsView. Previously I used QGraphicsWebView but the official porting guide pretty much says that QGraphicsWebView will have no WebEngine-based equivalent: http://doc.qt.io/qt-5/qtwebenginewidgets-qtwebkitportingguide.html So I tried using QGraphicsProxyWidget as a way to get QWebEngineView in a QGraphicsView, expecting a total failure (the porting doc made it sound highly unlikely that this might work). To my surprise the QWebEngineView was correctly rendered inside the QGraphicsView and even transformations like scaling seem to work. The one problem seems to be that the QGraphicsView is not repainted when the image displayed by the proxied QWebEngineView changes. For example if I click on a link, nothing changes on the screen (it appears frozen). However, if I update the QGraphicsView (e.g. by scrolling/resizing it) the new content of the QWebEngineView is again displayed. So this setup is almost working properly. Does anyone have an idea of a way to get the QGraphicsProxyWidget to automatically repaint itself when the content of the QWebEngineView changes? Cheers, Dimitar From samuel.gaist at edeltech.ch Wed Mar 16 16:53:53 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Wed, 16 Mar 2016 16:53:53 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: Message-ID: <6FA0977B-325D-493E-875E-6974D403FC80@edeltech.ch> On 16 mars 2016, at 16:14, Koehne Kai wrote: > Hi there, > > We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but if there has been a consensus (which is sometimes hard to find out), it was often buried pretty deep in the mailing thread. IMO it would be good to make decisions more explicit, and write them down also somewhere outside of this list. > > We already have the coding conventions page: https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at keeping it up to date - and one reason is IMO that, given that it's a wiki everybody can edit, people in a twist of irony stay away from editing it to avoid editing wars. > > I've been contemplating whether we should instead use some more formalized decision process. We could have a document uploaded in git, and every change needs to be reviewed and approved by Lars. While at it, this fresh start would also be a good opportunity to check whether all the rules in above wiki page, and the structure of the document in general, can be improved. > > As sort of a demo I created > > https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidelines.md > > What do you think? If nobody sees the value in this, I'll refrain from sinking more time into it. > > Regards > > Kai > > -- > Kai Köhne, Senior Manager R&D - The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Hi, +1 It could go in the qtqa repository or maybe qtbase so no need for additional online resources when coding (always nice when on battery) Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From matnares at gmail.com Wed Mar 16 16:54:47 2016 From: matnares at gmail.com (=?UTF-8?B?TWF0w61hcyBOw6lzdG9yIEFyZXM=?=) Date: Wed, 16 Mar 2016 12:54:47 -0300 Subject: [Development] Qt Quick emulation layer crashed (1:0) In-Reply-To: References: Message-ID: Thank you very much for so useful information Thomas. I will proceed as you recommend. Best Regards. 2016-03-16 6:24 GMT-03:00 Hartmann Thomas : > Hi, > > > The Timer element is not officially supported in the designer. The > designer does show an error message, that you can ignore though. > > There are work arrounds for your isse: > > > 1) Use .ui.qml files and decouple the logic that requires the Timer from > the pure form (see: http://doc.qt.io/qtcreator/creator-quick-ui-forms.html > ). > > 2) If you need a quick solution than you can move the Timer into a > component (e.g. MyTimer). That does work. > > > We do not regularly test unsupported elements and documents containing > those. We concetrate on the QML subset we support for ui.qml files and > that we can guarantee to work. > > We do accept bugreports for issues like yours and we will fix them, but > our focus is on UI elements. > > > Kind Regards, > > Thomas Hartmann > > > ------------------------------ > *From:* Development theqtcompany.com at qt-project.org> on behalf of Matías Néstor Ares < > matnares at gmail.com> > *Sent:* Tuesday, March 15, 2016 5:43 PM > *To:* > *Subject:* [Development] Qt Quick emulation layer crashed (1:0) > > Hello everybody!!! > > I have been testing Qt5.6 > > of course Beta an RC releases have some bugs as expected. > > But in all recent linux releases including the final 5.6.0 release the QML > design view is completely unusable. > > Even the most simple qml led to "Qt Quick emulation layer crashed (1:0)" > > I have been working in complex QML layouts and *the designer was never > really as useful* as expected. it is very buggy across all releases from > it first appearance. > > But now it can't handle even something as simple as this example: > > import QtQuick 2.5 > import QtQuick.Controls 1.4 > > ApplicationWindow { > id: applicationWindow1 > visible: true > width: 640 > height: 480 > title: qsTr("Testing") > > Timer{ > id:testiTimer > interval: 1500; running: true; repeat: true > onTriggered: { > console.log("message") > } > } > > Rectangle { > id: testRectangle1 > width: 383 > height: 86 > color: "#c2c2c2" > } > > } > > This code runs ok but can't be edited in design mode because "Qt Quick > emulation layer crashed (1:0)" shows up. > > is there a workaround? or some alternative? > > Regards > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Mar 16 18:17:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 Mar 2016 10:17:01 -0700 Subject: [Development] Is DirectFB dead? In-Reply-To: References: <19012436.GgXnARiVH2@tjmaciei-mobl4> Message-ID: <2727141.SGAePnMyrS@tjmaciei-mobl4> On quarta-feira, 16 de março de 2016 09:13:23 PDT Holger Freyther wrote: > But your approach seems fine, deprecate it in 5.7 (and print a big warning > on configure?) and see if any of the users are willing to invest in the > maintenance. https://codereview.qt-project.org/152522 ChangeLog note only, no configure output. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 16 18:24:25 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 Mar 2016 10:24:25 -0700 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: Message-ID: <4920311.7k8v6GXZnk@tjmaciei-mobl4> On quarta-feira, 16 de março de 2016 15:14:24 PDT Koehne Kai wrote: > Hi there, > > We have had quite some discussions about the use of C++11 features and right > API in the past on this mailing list - but if there has been a consensus > (which is sometimes hard to find out), it was often buried pretty deep in > the mailing thread. IMO it would be good to make decisions more explicit, > and write them down also somewhere outside of this list. There's a Git Commit by Marc that would add it to the source code. There were a couple of problems with that commit, including philosophical differences. So it didn't go through. It's still open, though. > https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidel > ines.md It should be in qtbase and it should be a .qdoc file. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Wed Mar 16 18:37:24 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 16 Mar 2016 18:37:24 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: Message-ID: <56E999D4.7070902@kdab.com> Il 16/03/2016 16:14, Koehne Kai ha scritto: > We already have the coding conventions page:https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at keeping it up to date - and one reason is IMO that, given that it's a wiki everybody can edit, people in a twist of irony stay away from editing it to avoid editing wars. IMO the reason is that this wiki content has been moved a gazillion of times in the last 3 years, every time requiring a new login procedure of some sort, etc. Moreover, being a community wiki, I don't think it is the right place to host official information. qdoc files into qtbase (which turn into documentation pages) seems way better. My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From mandeepsandhu.chd at gmail.com Wed Mar 16 19:44:55 2016 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Wed, 16 Mar 2016 11:44:55 -0700 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: Message-ID: +1 to this idea. -mandeep On Wed, Mar 16, 2016 at 8:14 AM, Koehne Kai wrote: > Hi there, > > We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but if there has been a consensus (which is sometimes hard to find out), it was often buried pretty deep in the mailing thread. IMO it would be good to make decisions more explicit, and write them down also somewhere outside of this list. > > We already have the coding conventions page: https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at keeping it up to date - and one reason is IMO that, given that it's a wiki everybody can edit, people in a twist of irony stay away from editing it to avoid editing wars. > > I've been contemplating whether we should instead use some more formalized decision process. We could have a document uploaded in git, and every change needs to be reviewed and approved by Lars. While at it, this fresh start would also be a good opportunity to check whether all the rules in above wiki page, and the structure of the document in general, can be improved. > > As sort of a demo I created > > https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidelines.md > > What do you think? If nobody sees the value in this, I'll refrain from sinking more time into it. > > Regards > > Kai > > -- > Kai Köhne, Senior Manager R&D - The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Wed Mar 16 19:53:45 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 16 Mar 2016 19:53:45 +0100 Subject: [Development] tarball fetches from code.qt.io? Message-ID: <2000886.r6WD1beTJ9@patux> Hi, Is there a way to do tarball fetches from code.qt.io that correspond to a specific commit, tag or release (for QtWebKit; purely for convenience in a distribution/packaging script)? Thanks, René From filippocucchetto at gmail.com Wed Mar 16 19:57:58 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Wed, 16 Mar 2016 19:57:58 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: Message-ID: +1 Il 16/mar/2016 16:14, "Koehne Kai" ha scritto: > Hi there, > > We have had quite some discussions about the use of C++11 features and > right API in the past on this mailing list - but if there has been a > consensus (which is sometimes hard to find out), it was often buried pretty > deep in the mailing thread. IMO it would be good to make decisions more > explicit, and write them down also somewhere outside of this list. > > We already have the coding conventions page: > https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at > keeping it up to date - and one reason is IMO that, given that it's a wiki > everybody can edit, people in a twist of irony stay away from editing it to > avoid editing wars. > > I've been contemplating whether we should instead use some more formalized > decision process. We could have a document uploaded in git, and every > change needs to be reviewed and approved by Lars. While at it, this fresh > start would also be a good opportunity to check whether all the rules in > above wiki page, and the structure of the document in general, can be > improved. > > As sort of a demo I created > > > https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidelines.md > > What do you think? If nobody sees the value in this, I'll refrain from > sinking more time into it. > > Regards > > Kai > > -- > Kai Köhne, Senior Manager R&D - The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From filippocucchetto at gmail.com Wed Mar 16 19:59:39 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Wed, 16 Mar 2016 19:59:39 +0100 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: <2000886.r6WD1beTJ9@patux> References: <2000886.r6WD1beTJ9@patux> Message-ID: Maybe https://git-scm.com/docs/git-archive Il 16/mar/2016 19:54, "René J.V." ha scritto: > Hi, > > Is there a way to do tarball fetches from code.qt.io that correspond to a > specific commit, tag or release (for QtWebKit; purely for convenience in a > distribution/packaging script)? > > Thanks, > René > > > _______________________________________________ > 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 Wed Mar 16 20:09:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 Mar 2016 12:09:36 -0700 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: References: <2000886.r6WD1beTJ9@patux> Message-ID: <1856371.zXPc59Bamk@tjmaciei-mobl4> On quarta-feira, 16 de março de 2016 19:59:39 PDT Filippo Cucchetto wrote: > Maybe https://git-scm.com/docs/git-archive The git-archive extension is not enabled on code.qt.io. $ git archive --remote=git://code.qt.io/qt/qtbase.git HEAD fatal: remote error: service not enabled: /qt/qtbase.git > > Is there a way to do tarball fetches from code.qt.io that correspond to a > > specific commit, tag or release (for QtWebKit; purely for convenience in a > > distribution/packaging script)? Tags are releases and are available in http://download.qt.io/. They are also transformed by adding the generated headers and removing Git-specific files. You should use that. If you need to test arbitrary commits, you should be using Git. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Wed Mar 16 20:33:01 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 16 Mar 2016 20:33:01 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: Message-ID: <56E9B4ED.2000204@familiesomers.nl> Op 16/03/2016 om 16:14 schreef Koehne Kai: > Hi there, > > We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but if there has been a consensus (which is sometimes hard to find out), it was often buried pretty deep in the mailing thread. IMO it would be good to make decisions more explicit, and write them down also somewhere outside of this list. > > We already have the coding conventions page: https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at keeping it up to date - and one reason is IMO that, given that it's a wiki everybody can edit, people in a twist of irony stay away from editing it to avoid editing wars. > > I've been contemplating whether we should instead use some more formalized decision process. We could have a document uploaded in git, and every change needs to be reviewed and approved by Lars. While at it, this fresh start would also be a good opportunity to check whether all the rules in above wiki page, and the structure of the document in general, can be improved. > > As sort of a demo I created > > https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidelines.md > > What do you think? If nobody sees the value in this, I'll refrain from sinking more time into it. > Could work I think. But how do you propose these changes get announced? Who will be added to review such changes? André From Eike.Ziller at theqtcompany.com Wed Mar 16 20:47:14 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Wed, 16 Mar 2016 19:47:14 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56E9B4ED.2000204@familiesomers.nl> References: <56E9B4ED.2000204@familiesomers.nl> Message-ID: > On Mar 16, 2016, at 20:33, André Somers wrote: > > > > Op 16/03/2016 om 16:14 schreef Koehne Kai: >> Hi there, >> >> We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but if there has been a consensus (which is sometimes hard to find out), it was often buried pretty deep in the mailing thread. IMO it would be good to make decisions more explicit, and write them down also somewhere outside of this list. >> >> We already have the coding conventions page: https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at keeping it up to date - and one reason is IMO that, given that it's a wiki everybody can edit, people in a twist of irony stay away from editing it to avoid editing wars. >> >> I've been contemplating whether we should instead use some more formalized decision process. We could have a document uploaded in git, and every change needs to be reviewed and approved by Lars. While at it, this fresh start would also be a good opportunity to check whether all the rules in above wiki page, and the structure of the document in general, can be improved. >> >> As sort of a demo I created >> >> https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidelines.md >> >> What do you think? If nobody sees the value in this, I'll refrain from sinking more time into it. >> > Could work I think. But how do you propose these changes get announced? Who will be added to review such changes? Changes should still be discussed on this mailing list first (if they are not cosmetic). These discussions can result with a change on code review (also posted here). As something that effects the whole of Qt, it must be reviewed by the Chief Maintainer == Lars. (My 2c, we do it similar with Qt Creator, seemed to have worked fine enough so far.) Br, Eike > André > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From andre at familiesomers.nl Wed Mar 16 20:56:42 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 16 Mar 2016 20:56:42 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: <56E9B4ED.2000204@familiesomers.nl> Message-ID: <56E9BA7A.9070504@familiesomers.nl> Op 16/03/2016 om 20:47 schreef Ziller Eike: >> On Mar 16, 2016, at 20:33, André Somers wrote: >> >> >> >> Op 16/03/2016 om 16:14 schreef Koehne Kai: >>> Hi there, >>> >>> We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but if there has been a consensus (which is sometimes hard to find out), it was often buried pretty deep in the mailing thread. IMO it would be good to make decisions more explicit, and write them down also somewhere outside of this list. >>> >>> We already have the coding conventions page: https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at keeping it up to date - and one reason is IMO that, given that it's a wiki everybody can edit, people in a twist of irony stay away from editing it to avoid editing wars. >>> >>> I've been contemplating whether we should instead use some more formalized decision process. We could have a document uploaded in git, and every change needs to be reviewed and approved by Lars. While at it, this fresh start would also be a good opportunity to check whether all the rules in above wiki page, and the structure of the document in general, can be improved. >>> >>> As sort of a demo I created >>> >>> https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidelines.md >>> >>> What do you think? If nobody sees the value in this, I'll refrain from sinking more time into it. >>> >> Could work I think. But how do you propose these changes get announced? Who will be added to review such changes? > Changes should still be discussed on this mailing list first (if they are not cosmetic). These discussions can result with a change on code review (also posted here). > As something that effects the whole of Qt, it must be reviewed by the Chief Maintainer == Lars. > > (My 2c, we do it similar with Qt Creator, seemed to have worked fine enough so far.) > Doesn't that lead to having the discussion twice: first once in the ML, then again in the MR for the change? André From thiago.macieira at intel.com Wed Mar 16 21:57:53 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 Mar 2016 13:57:53 -0700 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56E9BA7A.9070504@familiesomers.nl> References: <56E9BA7A.9070504@familiesomers.nl> Message-ID: <2695597.l8lRJa435y@tjmaciei-mobl4> On quarta-feira, 16 de março de 2016 20:56:42 PDT André Somers wrote: > Doesn't that lead to having the discussion twice: first once in the ML, > then again in the MR for the change? The ML is the ultimate decider, so if we had consensus on the list, that's that. The discussion in the change may be on the wording, but not on the content. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Wed Mar 16 22:06:28 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 16 Mar 2016 22:06:28 +0100 Subject: [Development] tarball fetches from code.qt.io? References: <2000886.r6WD1beTJ9@patux> <1856371.zXPc59Bamk@tjmaciei-mobl4> Message-ID: <1784737.znae0EUkVN@portia.local> Thiago Macieira wrote: > The git-archive extension is not enabled on code.qt.io. Indeed, sadly. > Tags are releases and are available in http://download.qt.io/. They are also > transformed by adding the generated headers and removing Git-specific files. > You should use that. > > If you need to test arbitrary commits, you should be using Git. Or the 5.6.0 version of QtWebKit, apparently. I didn't find it on download.qt.io . R. From Lars.Knoll at theqtcompany.com Wed Mar 16 22:43:00 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 16 Mar 2016 21:43:00 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: <56E9B4ED.2000204@familiesomers.nl> Message-ID: <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> Good initiative. I think this is the right idea. Let's put the coding guidelines into .qdoc files after having a decision on the ML. We should actually consider having a section about contributing to Qt in our documentation. Coding guidelines would fit nicely into that. But I think the .qdoc files should rather live in qtdoc instead of qtbase as most of the overview documentation is there. Cheers, Lars On 16/03/16 20:47, "Development on behalf of Ziller Eike" wrote: > >> On Mar 16, 2016, at 20:33, André Somers wrote: >> >> >> >> Op 16/03/2016 om 16:14 schreef Koehne Kai: >>> Hi there, >>> >>> We have had quite some discussions about the use of C++11 features and right API in the past on this mailing list - but if there has been a consensus (which is sometimes hard to find out), it was often buried pretty deep in the mailing thread. IMO it would be good to make decisions more explicit, and write them down also somewhere outside of this list. >>> >>> We already have the coding conventions page: https://wiki.qt.io/Coding_Conventions . But we haven't done a good job at keeping it up to date - and one reason is IMO that, given that it's a wiki everybody can edit, people in a twist of irony stay away from editing it to avoid editing wars. >>> >>> I've been contemplating whether we should instead use some more formalized decision process. We could have a document uploaded in git, and every change needs to be reviewed and approved by Lars. While at it, this fresh start would also be a good opportunity to check whether all the rules in above wiki page, and the structure of the document in general, can be improved. >>> >>> As sort of a demo I created >>> >>> https://github.com/kkoehne/qt-coding-guidelines/blob/master/qt-coding-guidelines.md >>> >>> What do you think? If nobody sees the value in this, I'll refrain from sinking more time into it. >>> >> Could work I think. But how do you propose these changes get announced? Who will be added to review such changes? > >Changes should still be discussed on this mailing list first (if they are not cosmetic). These discussions can result with a change on code review (also posted here). >As something that effects the whole of Qt, it must be reviewed by the Chief Maintainer == Lars. > >(My 2c, we do it similar with Qt Creator, seemed to have worked fine enough so far.) > >Br, Eike > >> André >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > >-- >Eike Ziller, Principle Software Engineer - The Qt Company GmbH > >The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin >Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja >Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From rich at kde.org Wed Mar 16 22:55:15 2016 From: rich at kde.org (Richard Moore) Date: Wed, 16 Mar 2016 21:55:15 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> References: <56E9B4ED.2000204@familiesomers.nl> <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> Message-ID: On 16 March 2016 at 21:43, Knoll Lars wrote: > Good initiative. I think this is the right idea. Let's put the coding > guidelines into .qdoc files after having a decision on the ML. > > We should actually consider having a section about contributing to Qt in > our documentation. Coding guidelines would fit nicely into that. But I > think the .qdoc files should rather live in qtdoc instead of qtbase as most > of the overview documentation is there. > ​Personally I think markdown as Kai's used is better since we can link to that in git and have it rendered sensibly. Rich.​ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Mar 17 00:14:10 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 Mar 2016 16:14:10 -0700 Subject: [Development] Qt Coding Guidelines In-Reply-To: <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> References: <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> Message-ID: <5006041.xXVyO60gH4@tjmaciei-mobl4> On quarta-feira, 16 de março de 2016 21:43:00 PDT Knoll Lars wrote: > Good initiative. I think this is the right idea. Let's put the coding > guidelines into .qdoc files after having a decision on the ML. As I said, there is already a change by Marc that adds this file (it was an .md instead of a .qdoc). I can't find it, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Mar 17 00:14:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 16 Mar 2016 16:14:44 -0700 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: <1784737.znae0EUkVN@portia.local> References: <2000886.r6WD1beTJ9@patux> <1856371.zXPc59Bamk@tjmaciei-mobl4> <1784737.znae0EUkVN@portia.local> Message-ID: <23615250.ps6K5Qji8Q@tjmaciei-mobl4> On quarta-feira, 16 de março de 2016 22:06:28 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > The git-archive extension is not enabled on code.qt.io. > > Indeed, sadly. > > > Tags are releases and are available in http://download.qt.io/. They are > > also transformed by adding the generated headers and removing > > Git-specific files. You should use that. > > > > If you need to test arbitrary commits, you should be using Git. > > Or the 5.6.0 version of QtWebKit, apparently. I didn't find it on > download.qt.io . We agreed that we would create a tarball. Release team, where is it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at theqtcompany.com Thu Mar 17 06:38:43 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Thu, 17 Mar 2016 05:38:43 +0000 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: <23615250.ps6K5Qji8Q@tjmaciei-mobl4> References: <2000886.r6WD1beTJ9@patux> <1856371.zXPc59Bamk@tjmaciei-mobl4> <1784737.znae0EUkVN@portia.local> <23615250.ps6K5Qji8Q@tjmaciei-mobl4> Message-ID: Hi! Webkit packages can be found from here: http://download.qt.io/community_releases/5.6/5.6.0/ Br, Jani >>-----Original Message----- >>From: Development [mailto:development- >>bounces+jani.heikkinen=theqtcompany.com at qt-project.org] On Behalf Of >>Thiago Macieira >>Sent: 17. maaliskuuta 2016 1:15 >>To: development at qt-project.org >>Cc: Releasing >>Subject: Re: [Development] tarball fetches from code.qt.io? >> >>On quarta-feira, 16 de março de 2016 22:06:28 PDT René J. V. Bertin wrote: >>> Thiago Macieira wrote: >>> > The git-archive extension is not enabled on code.qt.io. >>> >>> Indeed, sadly. >>> >>> > Tags are releases and are available in http://download.qt.io/. They are >>> > also transformed by adding the generated headers and removing >>> > Git-specific files. You should use that. >>> > >>> > If you need to test arbitrary commits, you should be using Git. >>> >>> Or the 5.6.0 version of QtWebKit, apparently. I didn't find it on >>> download.qt.io . >> >>We agreed that we would create a tarball. >> >>Release team, where is it? >> >>-- >>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 Simon.Hausmann at theqtcompany.com Thu Mar 17 08:19:11 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 17 Mar 2016 07:19:11 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: <56E9B4ED.2000204@familiesomers.nl> <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com>, Message-ID: <20160317071910.5935185.90802.63905@theqtcompany.com> I agree with Rich. This isn't documentation our users are facing. We don't need to extract from cpp files or use a particular style sheet. +1 for Kai's initiative. Simon From: Richard Moore Sent: Wednesday, March 16, 2016 22:55 To: Knoll Lars Cc: development at qt-project.org Subject: Re: [Development] Qt Coding Guidelines On 16 March 2016 at 21:43, Knoll Lars > wrote: Good initiative. I think this is the right idea. Let's put the coding guidelines into .qdoc files after having a decision on the ML. We should actually consider having a section about contributing to Qt in our documentation. Coding guidelines would fit nicely into that. But I think the .qdoc files should rather live in qtdoc instead of qtbase as most of the overview documentation is there. ?Personally I think markdown as Kai's used is better since we can link to that in git and have it rendered sensibly. Rich.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at theqtcompany.com Thu Mar 17 08:37:38 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 17 Mar 2016 07:37:38 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <5006041.xXVyO60gH4@tjmaciei-mobl4> References: <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> <5006041.xXVyO60gH4@tjmaciei-mobl4> Message-ID: <84B8CC81-CFAF-48DA-A6E3-E1B0026A13FA@theqtcompany.com> On 17/03/16 00:14, "Development on behalf of Thiago Macieira" wrote: >On quarta-feira, 16 de março de 2016 21:43:00 PDT Knoll Lars wrote: >> Good initiative. I think this is the right idea. Let's put the coding >> guidelines into .qdoc files after having a decision on the ML. > >As I said, there is already a change by Marc that adds this file (it was an .md >instead of a .qdoc). > >I can't find it, though. https://codereview.qt-project.org/#/c/142782/ Cheers, Lars From Morten.Sorvig at theqtcompany.com Thu Mar 17 10:01:49 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Thu, 17 Mar 2016 09:01:49 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> References: <56E9B4ED.2000204@familiesomers.nl> <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> Message-ID: > On 16 Mar 2016, at 22:43, Knoll Lars wrote: > > We should actually consider having a section about contributing to Qt in our documentation. Coding guidelines would fit nicely into that. But I think the .qdoc files should rather live in qtdoc instead of qtbase as most of the overview documentation is there. How about treating the coding guidelines as \internal documentation? We could then at some point build and publish it together with the rest of the \internal's. (suitably separated from the public user documentation) Morten From marc.mutz at kdab.com Thu Mar 17 11:18:00 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 17 Mar 2016 11:18:00 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <84B8CC81-CFAF-48DA-A6E3-E1B0026A13FA@theqtcompany.com> References: <5006041.xXVyO60gH4@tjmaciei-mobl4> <84B8CC81-CFAF-48DA-A6E3-E1B0026A13FA@theqtcompany.com> Message-ID: <201603171118.01001.marc.mutz@kdab.com> On Thursday 17 March 2016 08:37:38 Knoll Lars wrote: > On 17/03/16 00:14, "Development on behalf of Thiago Macieira" wrote: > >On quarta-feira, 16 de março de 2016 21:43:00 PDT Knoll Lars wrote: > >> Good initiative. I think this is the right idea. Let's put the coding > >> guidelines into .qdoc files after having a decision on the ML. > > > >As I said, there is already a change by Marc that adds this file (it was > >an .md instead of a .qdoc). > > > >I can't find it, though. > > https://codereview.qt-project.org/#/c/142782/ This document is about the level of C++ support required by that release of Qt. I don't want it to be about formatting, too, other than pointing out bugs in implementation that we need to work around. Formatting could/should be a separate document, because it's more stable. I still plan to put all of the prose in that change into a config test for 5.7, so we also programmatically check it. If qdoc would start looking into config.tests, too, that might be a reson to change from markdown (which others have preferred independently, too, incidentally) to qdoc format and create the list from the config test. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From rjvbertin at gmail.com Thu Mar 17 10:26:04 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2E__V=2E?= Bertin) Date: Thu, 17 Mar 2016 10:26:04 +0100 Subject: [Development] tarball fetches from code.qt.io? References: <2000886.r6WD1beTJ9@patux> <1856371.zXPc59Bamk@tjmaciei-mobl4> <1784737.znae0EUkVN@portia.local> <23615250.ps6K5Qji8Q@tjmaciei-mobl4> Message-ID: <4138032.HxjhFM9p1P@patux.local> Heikkinen Jani wrote: > Hi! > > Webkit packages can be found from here: > http://download.qt.io/community_releases/5.6/5.6.0/ Indeed, thanks! R. From mathias at taschenorakel.de Thu Mar 17 11:24:10 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 17 Mar 2016 11:24:10 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: <56E9B4ED.2000204@familiesomers.nl> <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> Message-ID: <56EA85CA.4040109@taschenorakel.de> Am 17.03.2016 um 10:01 schrieb Sorvig Morten: > How about treating the coding guidelines as \internal documentation? > We could then at some point build and publish it together with the > rest of the \internal's. (suitably separated from the public user > documentation) Actually having the Qt code style as public document proved to be extremely useful in the past to quickly shutdown this inevitable and highly annoying bike shed discussion about code style that happens at the start of every other project. Also in the future I'd like to say: "We do a Qt based project and for consistency I propose to follow the Qt code style: It's a good and proven style guide. Just read it http://wiki.qt.io/Coding_Conventions and then focus on real problems." Thank you, Mathias From bstottle at ford.com Thu Mar 17 11:55:18 2016 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Thu, 17 Mar 2016 10:55:18 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56EA85CA.4040109@taschenorakel.de> References: <56E9B4ED.2000204@familiesomers.nl> <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> <56EA85CA.4040109@taschenorakel.de> Message-ID: On 3/17/16, 6:24 AM, "Development on behalf of Mathias Hasselmann" wrote: > >Actually having the Qt code style as public document proved to be >extremely useful in the past to quickly shutdown this inevitable and >highly annoying bike shed discussion about code style that happens at >the start of every other project. Also in the future I'd like to say: > >"We do a Qt based project and for consistency I propose to follow the Qt >code style: It's a good and proven style guide. Just read it >http://wiki.qt.io/Coding_Conventions and then focus on real problems." +1 From andre at familiesomers.nl Thu Mar 17 12:29:46 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 17 Mar 2016 12:29:46 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56EA85CA.4040109@taschenorakel.de> References: <56E9B4ED.2000204@familiesomers.nl> <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> <56EA85CA.4040109@taschenorakel.de> Message-ID: <56EA952A.1000300@familiesomers.nl> Op 17/03/2016 om 11:24 schreef Mathias Hasselmann: > > > Am 17.03.2016 um 10:01 schrieb Sorvig Morten: >> How about treating the coding guidelines as \internal documentation? >> We could then at some point build and publish it together with the >> rest of the \internal's. (suitably separated from the public user >> documentation) > > Actually having the Qt code style as public document proved to be > extremely useful in the past to quickly shutdown this inevitable and > highly annoying bike shed discussion about code style that happens at > the start of every other project. Also in the future I'd like to say: > > "We do a Qt based project and for consistency I propose to follow the > Qt code style: It's a good and proven style guide. Just read it > http://wiki.qt.io/Coding_Conventions and then focus on real problems." I actually prefer to just delegate the actual formatting style to clang format now and apply that automagically. Perhaps it is not perfect in everyones eyes, but it is better that having differences all over the place or wasting time on discussing tabs, spaces or the location of * or &. But that's layout mostly, and there is a lot more to say than that (naming conventions, patterns to use or avoid, etc.) You still have to decide on what format to use, but the default is fine by me. So in any style guide, I'd probably not waste any more time on the formatting aspects any more, and just refer to something like "we use clang format with the LLVM style" or something like that. André From sergio.martins at kdab.com Thu Mar 17 13:14:33 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 17 Mar 2016 13:14:33 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56EA85CA.4040109@taschenorakel.de> References: <56EA85CA.4040109@taschenorakel.de> Message-ID: <1693371.I4IGfneXjZ@desktop-ga45d22> On Thursday, March 17, 2016 11:24:10 AM Mathias Hasselmann wrote: > Am 17.03.2016 um 10:01 schrieb Sorvig Morten: > > How about treating the coding guidelines as \internal documentation? > > We could then at some point build and publish it together with the > > rest of the \internal's. (suitably separated from the public user > > documentation) > > Actually having the Qt code style as public document proved to be > extremely useful in the past to quickly shutdown this inevitable and > highly annoying bike shed discussion about code style that happens at > the start of every other project. Also in the future I'd like to say: > > "We do a Qt based project and for consistency I propose to follow the Qt > code style: It's a good and proven style guide. Just read it > http://wiki.qt.io/Coding_Conventions and then focus on real problems." I like this, public .qdoc makes it easier to make a case for Qt coding style among our customers. Regards, -- Sérgio Martins | sergio.martins 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 Experts From Kai.Koehne at theqtcompany.com Thu Mar 17 15:30:03 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 17 Mar 2016 14:30:03 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <1693371.I4IGfneXjZ@desktop-ga45d22> References: <56EA85CA.4040109@taschenorakel.de> <1693371.I4IGfneXjZ@desktop-ga45d22> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Sergio Martins > Sent: Thursday, March 17, 2016 1:15 PM > To: development at qt-project.org > Subject: Re: [Development] Qt Coding Guidelines > > On Thursday, March 17, 2016 11:24:10 AM Mathias Hasselmann wrote: > > Am 17.03.2016 um 10:01 schrieb Sorvig Morten: > > > How about treating the coding guidelines as \internal documentation? > > > We could then at some point build and publish it together with the > > > rest of the \internal's. (suitably separated from the public user > > > documentation) > > > > Actually having the Qt code style as public document proved to be > > extremely useful in the past to quickly shutdown this inevitable and > > highly annoying bike shed discussion about code style that happens at > > the start of every other project. Also in the future I'd like to say: > > > > "We do a Qt based project and for consistency I propose to follow the > > Qt code style: It's a good and proven style guide. Just read it > > http://wiki.qt.io/Coding_Conventions and then focus on real problems." > > I like this, public .qdoc makes it easier to make a case for Qt coding style > among our customers. The current Coding Conventions are right now a mixture of code _style_ (which http://wiki.qt.io/Qt_Coding_Style covers, too), and coding guidelines. IMO they should be (again) split up: Basically the first one is about whitespace, naming conventions etc, while the second one is higher-level stuff like which C++ features to use. In addition, I was thinking about whether it makes sense to split up stuff of general interest ("Use Q_DECLARE_TYPEINFO") from advice pretty specific to the Qt libraries itself (BC advice, namespace awareness ...). Anyhow, the line is probably somewhat blurry there, so I wouldn't go for this from the beginning. Completely orthogonal to this is though in which format the documents are. You're specifically mentioning .qdoc, but I assume it wouldn't really matter if it's Markdown (from the 'reusability' perspective)? Regards Kai From sergio.martins at kdab.com Thu Mar 17 15:15:56 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 17 Mar 2016 15:15:56 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: <1693371.I4IGfneXjZ@desktop-ga45d22> Message-ID: <1556922.j7q4PTgklR@desktop-ga45d22> On Thursday, March 17, 2016 02:30:03 PM Koehne Kai wrote: (snip) > Completely orthogonal to this is though in which format the documents > are. You're specifically mentioning .qdoc, but I assume it wouldn't really > matter if it's Markdown (from the 'reusability' perspective)? If we keep these documents private then I would say .qdoc vs .md is a bikeshed and whoever is doing the hard work of writing and maintaining it should decide. But for public distribution I don't think it's fine. If I recommend the Qt coding style to a customer, he'll come back and say "How do I open this?". Afaik, you can't just point your browser to it and open it while offline, you have to go to a gitweb site and view it there, otherwise no pretty formatting. Regards, -- Sérgio Martins | sergio.martins 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 Experts From Kai.Koehne at theqtcompany.com Thu Mar 17 16:57:23 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 17 Mar 2016 15:57:23 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <1556922.j7q4PTgklR@desktop-ga45d22> References: <1693371.I4IGfneXjZ@desktop-ga45d22> <1556922.j7q4PTgklR@desktop-ga45d22> Message-ID: > -----Original Message----- > From: sergio On Behalf Of Sergio Martins > Sent: Thursday, March 17, 2016 3:16 PM > To: Koehne Kai > Cc: development at qt-project.org > Subject: Re: [Development] Qt Coding Guidelines > > On Thursday, March 17, 2016 02:30:03 PM Koehne Kai wrote: > > (snip) > > > Completely orthogonal to this is though in which format the documents > > are. You're specifically mentioning .qdoc, but I assume it wouldn't > > really matter if it's Markdown (from the 'reusability' perspective)? > > If we keep these documents private then I would say .qdoc vs .md is a > bikeshed and whoever is doing the hard work of writing and maintaining it > should decide. > > But for public distribution I don't think it's fine. > > If I recommend the Qt coding style to a customer, he'll come back and say > "How do I open this?". How do they open a .qdoc file? They probably don't, but browse the generated .html documentation. The same can be done with markdown. > Afaik, you can't just point your browser to it and > open it while offline, you have to go to a gitweb site and view it there, > otherwise no pretty formatting. Well ... it's becoming increasingly popular, and there's countless ways nowadays to render markdown. It's so easy in fact that we ship one with Qt :) https://doc.qt.io/qt-5/qtwebengine-webenginewidgets-markdowneditor-example.html That being said, I'm not fixed on using the .md format. I was just surprised you considered .qdoc more 'reusable' than Markdown. Regards Kai From thiago.macieira at intel.com Thu Mar 17 17:50:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 17 Mar 2016 09:50:36 -0700 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: <1556922.j7q4PTgklR@desktop-ga45d22> Message-ID: <4182839.Edbz7sJSMD@tjmaciei-mobl4> On quinta-feira, 17 de março de 2016 15:57:23 PDT Koehne Kai wrote: > > If I recommend the Qt coding style to a customer, he'll come back and say > > "How do I open this?". > > How do they open a .qdoc file? They probably don't, but browse the > generated .html documentation. The same can be done with markdown. We have a qdoc generator. We don't have a markdown generator. More importantly, we know how to write qdoc syntax. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at theqtcompany.com Thu Mar 17 18:09:04 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 17 Mar 2016 17:09:04 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <4182839.Edbz7sJSMD@tjmaciei-mobl4> References: <1556922.j7q4PTgklR@desktop-ga45d22> , <4182839.Edbz7sJSMD@tjmaciei-mobl4> Message-ID: Thiago Macieira said: > We have a qdoc generator. We don't have a markdown generator. > > More importantly, we know how to write qdoc syntax. There is also an "eat our own dog-food" argument somewhere here: we ask developers to document their code in qdoc, so we should be happy to use it ourselves, even for not-quite-code things. Eddy. From giuseppe.dangelo at kdab.com Thu Mar 17 18:23:27 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 17 Mar 2016 18:23:27 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: <1556922.j7q4PTgklR@desktop-ga45d22> <4182839.Edbz7sJSMD@tjmaciei-mobl4> Message-ID: <56EAE80F.3070503@kdab.com> Il 17/03/2016 18:09, Welbourne Edward ha scritto: > There is also an "eat our own dog-food" argument somewhere here: we ask > developers to document their code in qdoc, so we should be happy to use > it ourselves, even for not-quite-code things. The question is, can/should we get the HTML output of these documents published somewhere, for ease of access? Do they need their own repository to get them updated daily? Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From mandeepsandhu.chd at gmail.com Thu Mar 17 18:53:31 2016 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Thu, 17 Mar 2016 10:53:31 -0700 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56EA85CA.4040109@taschenorakel.de> References: <56E9B4ED.2000204@familiesomers.nl> <4C7B67F1-7DC2-4C4A-B71B-D509642D8479@theqtcompany.com> <56EA85CA.4040109@taschenorakel.de> Message-ID: On Thu, Mar 17, 2016 at 3:24 AM, Mathias Hasselmann wrote: > > > Am 17.03.2016 um 10:01 schrieb Sorvig Morten: >> >> How about treating the coding guidelines as \internal documentation? >> We could then at some point build and publish it together with the >> rest of the \internal's. (suitably separated from the public user >> documentation) > > > Actually having the Qt code style as public document proved to be extremely > useful in the past to quickly shutdown this inevitable and highly annoying > bike shed discussion about code style that happens at the start of every > other project. Also in the future I'd like to say: > > "We do a Qt based project and for consistency I propose to follow the Qt > code style: It's a good and proven style guide. Just read it > http://wiki.qt.io/Coding_Conventions and then focus on real problems." +1. I'm going to be proposing this soon in my project. -mandeep > > Thank you, > Mathias > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Thu Mar 17 18:58:44 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 17 Mar 2016 20:58:44 +0300 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56EAE80F.3070503@kdab.com> References: <1556922.j7q4PTgklR@desktop-ga45d22> <4182839.Edbz7sJSMD@tjmaciei-mobl4> <56EAE80F.3070503@kdab.com> Message-ID: <1203241458237524@web4j.yandex.ru> 17.03.2016, 20:23, "Giuseppe D'Angelo" : > Il 17/03/2016 18:09, Welbourne Edward ha scritto: >>  There is also an "eat our own dog-food" argument somewhere here: we ask >>  developers to document their code in qdoc, so we should be happy to use >>  it ourselves, even for not-quite-code things. > > The question is, can/should we get the HTML output of these documents > published somewhere, for ease of access? Do they need their own > repository to get them updated daily? What's wrong with reading them as plain text? -- Regards, Konstantin From giuseppe.dangelo at kdab.com Thu Mar 17 20:28:35 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 17 Mar 2016 20:28:35 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <1203241458237524@web4j.yandex.ru> References: <1556922.j7q4PTgklR@desktop-ga45d22> <4182839.Edbz7sJSMD@tjmaciei-mobl4> <56EAE80F.3070503@kdab.com> <1203241458237524@web4j.yandex.ru> Message-ID: <56EB0563.3050205@kdab.com> Il 17/03/2016 18:58, Konstantin Tokarev ha scritto: > What's wrong with reading them as plain text? What's the point at using a markup format then? (And cf. the proposal of having the guidelines available somewhere easily, to point people to them.) Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Thu Mar 17 21:45:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 17 Mar 2016 13:45:44 -0700 Subject: [Development] RFD: Removing environment variable support from configure Message-ID: <2163271.d5uSufSx7L@tjmaciei-mobl4> See below for more details. Summary: if CXXFLAGS is set on the environment when you run configure, the OS X build breaks. This happened because we don't test the building while those flags are set. I'm proposing we drop even checking them (configure lines 556 to 580). If you disagree and you want to keep environment variables supported, we'll need a volunteer to test and maintain this functionality, on all OSes in which the configure script is run. And don't forget the cross-compilation permutations. ---------- Forwarded Message ---------- Subject: Re: [Interest] [OS X] Qt 5.6.0 minimal build configuration (error compiling qlatincodec.cpp) Date: quinta-feira, 17 de março de 2016, 20:48:19 PDT From: René J. V. Bertin To: interest at qt-project.org Thiago Macieira wrote: > The proper way of adding options is to modify the mkspec's qmake.conf file qmake.conf or .qmake.conf? >> Checking my build scripts, I can confirm that CFLAGS and CXXFLAGS are set >> *through the environment*, not by any direct action of mine. > > Yeah, not tested. This is the cause of your problem. A bit easy, no? I'd say either you simply ignore settings from the environment, or else you do things correctly. And that would probably mean adding settings from the environment to whatever flags you set yourself as I think that's the accepted or at least usual way to do it (even CMake does). Anyway, I see that I had been missing a qmodule.pri edit. For some reason Qt 5.5.1 built fine with QMAKE_CXXFLAGS="-O3 -march=native -g". After replacing that with QMAKE_CXXFLAGS+=etc the build now appears to be happy. Shouldn't be too hard to generate that file using += instead of a simple = ? > On quinta-feira, 17 de março de 2016 11:38:58 PDT Thiago Macieira wrote: >> > - -stdlib=libc++ appear to be missing only from CXXFLAGS in the Makefiles >> > under qtbase/src/tools >> >> Hmm... those are "bootstrapped" tools. But I can't find anything that >> overrides QMAKE_CXXFLAGS. > > Can you confirm that it *is* present in src/corelib/Makefile? When is that file supposed to be created? I don't have it immediately after running configure (and now of course it *will* contain the option that was missing). R. _______________________________________________ Interest mailing list Interest at qt-project.org http://lists.qt-project.org/mailman/listinfo/interest ----------------------------------------- -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at theqtcompany.com Thu Mar 17 22:31:27 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 17 Mar 2016 21:31:27 +0000 Subject: [Development] RFD: Removing environment variable support from configure In-Reply-To: <2163271.d5uSufSx7L@tjmaciei-mobl4> References: <2163271.d5uSufSx7L@tjmaciei-mobl4> Message-ID: Yes, let's drop this. Btw, I'm currently anyway working on changing how configuration handling is done for Qt, so there will be some changes in this area coming for Qt 5.8. Cheers, Lars On 17/03/16 21:45, "Development on behalf of Thiago Macieira" wrote: >See below for more details. > >Summary: if CXXFLAGS is set on the environment when you run configure, the OS X >build breaks. > >This happened because we don't test the building while those flags are set. > >I'm proposing we drop even checking them (configure lines 556 to 580). > >If you disagree and you want to keep environment variables supported, we'll >need a volunteer to test and maintain this functionality, on all OSes in which >the configure script is run. And don't forget the cross-compilation >permutations. > >---------- Forwarded Message ---------- > >Subject: Re: [Interest] [OS X] Qt 5.6.0 minimal build configuration (error >compiling qlatincodec.cpp) >Date: quinta-feira, 17 de março de 2016, 20:48:19 PDT >From: René J. V. Bertin >To: interest at qt-project.org > >Thiago Macieira wrote: > >> The proper way of adding options is to modify the mkspec's qmake.conf file > >qmake.conf or .qmake.conf? > >>> Checking my build scripts, I can confirm that CFLAGS and CXXFLAGS are set >>> *through the environment*, not by any direct action of mine. >> >> Yeah, not tested. This is the cause of your problem. > >A bit easy, no? I'd say either you simply ignore settings from the >environment, >or else you do things correctly. And that would probably mean adding settings >from the environment to whatever flags you set yourself as I think that's the >accepted or at least usual way to do it (even CMake does). > >Anyway, I see that I had been missing a qmodule.pri edit. For some reason Qt >5.5.1 built fine with QMAKE_CXXFLAGS="-O3 -march=native -g". After replacing >that with QMAKE_CXXFLAGS+=etc the build now appears to be happy. > >Shouldn't be too hard to generate that file using += instead of a simple = ? > >> On quinta-feira, 17 de março de 2016 11:38:58 PDT Thiago Macieira wrote: >>> > - -stdlib=libc++ appear to be missing only from CXXFLAGS in the Makefiles >>> > under qtbase/src/tools >>> >>> Hmm... those are "bootstrapped" tools. But I can't find anything that >>> overrides QMAKE_CXXFLAGS. >> >> Can you confirm that it *is* present in src/corelib/Makefile? > >When is that file supposed to be created? I don't have it immediately after >running configure (and now of course it *will* contain the option that was >missing). > >R. > >_______________________________________________ >Interest mailing list >Interest at qt-project.org >http://lists.qt-project.org/mailman/listinfo/interest > >----------------------------------------- >-- >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 jedrzej.nowacki at theqtcompany.com Fri Mar 18 08:48:52 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 18 Mar 2016 08:48:52 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56EA952A.1000300@familiesomers.nl> References: <56EA85CA.4040109@taschenorakel.de> <56EA952A.1000300@familiesomers.nl> Message-ID: <3198644.MSAbKBEonO@42> On Thursday 17 of March 2016 12:29:46 André Somers wrote: > Op 17/03/2016 om 11:24 schreef Mathias Hasselmann: > > Am 17.03.2016 um 10:01 schrieb Sorvig Morten: > >> How about treating the coding guidelines as \internal documentation? > >> We could then at some point build and publish it together with the > >> rest of the \internal's. (suitably separated from the public user > >> documentation) > > > > Actually having the Qt code style as public document proved to be > > extremely useful in the past to quickly shutdown this inevitable and > > highly annoying bike shed discussion about code style that happens at > > the start of every other project. Also in the future I'd like to say: > > > > "We do a Qt based project and for consistency I propose to follow the > > Qt code style: It's a good and proven style guide. Just read it > > http://wiki.qt.io/Coding_Conventions and then focus on real problems." > > I actually prefer to just delegate the actual formatting style to clang > format now and apply that automagically. Perhaps it is not perfect in > everyones eyes, but it is better that having differences all over the > place or wasting time on discussing tabs, spaces or the location of * or > &. But that's layout mostly, and there is a lot more to say than that > (naming conventions, patterns to use or avoid, etc.) You still have to > decide on what format to use, but the default is fine by me. So in any > style guide, I'd probably not waste any more time on the formatting > aspects any more, and just refer to something like "we use clang format > with the LLVM style" or something like that. > > > André > +1 Every time someone discuss coding style issues my blood boils. I understand that it is important to have consistent coding style, but discussing where to put braces or spaces is just waste of developing time. I'm totally for an automated solution. I would even say that every rule formatting related which is not expressed in some tooling aware code should disappear. In addition, I really do not like that sanity bot is complaining about typos after I pushed patches to gerrit and even worse it is commenting on my code instead of proposing a fix. As you said coding convention are a bit bigger topic, but it also should be automated. Seriously, rules about where to place Q_DECLARE_METATYPE or a check if an include is missing are quite easy to express. So I think, that we should not discuss what is better qdoc or md. The real discussion is about tooling, what is the best tool to sanitize Qt code. We need something that: 1. Can work as a sanity bot 2. Can re-format the code by applying changes (git hook?) 3. Rules are easy to express and they can be exported (qdoc, html, fooBar) 4. Works on diff level (so it doesn't complain about the whole world being broken) Bonus: 5. C++, js, qml awareness Cheers, Jędrek From jani.heikkinen at theqtcompany.com Fri Mar 18 09:02:54 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Fri, 18 Mar 2016 08:02:54 +0000 Subject: [Development] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool versions Message-ID: Hi all, Currently used tools & versions in ci and packaging are listed in http://wiki.qt.io/Qt-5.7.0-tools-and-versions. 'dev' is also using same set. Now when Qt 5.6.0 is out we are planning to do some updates. We are planning to: - Update MinGW to i686-5.3.0-release-posix-dwarf-rt_v4-rev0 * first test build already done by Kai, full test build to be done in coin really soon - Update Android NDK to r11 * Some build issue reported (QTBUG-51859), fix https://codereview.qt-project.org/#/c/153212/ Please inform me immediately if you see some problem with this. Also inform me immediately if you know something else to be updated (for 5.7 or for 5.8). For 5.7 we are already quite late and we need to get needed updates done before beta release. For 5.8 it is actually correct time to do those ;) br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri Mar 18 10:26:14 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 18 Mar 2016 10:26:14 +0100 Subject: [Development] Fwd: Change in qt/qtbase[5.6]: Move QButtonGroup implementation from qabstractbutton.cpp to... Message-ID: <201603181026.14642.marc.mutz@kdab.com> Hi, Compiler upgraded in the CI without checking Qt compiles with it first? :) Fix: https://codereview.qt-project.org/153309 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- An embedded message was scrubbed... From: "Qt CI Bot (Code Review)" Subject: Change in qt/qtbase[5.6]: Move QButtonGroup implementation from qabstractbutton.cpp to... Date: Fri, 18 Mar 2016 06:03:58 +0000 Size: 4185 URL: From Shawn.Rutledge at theqtcompany.com Fri Mar 18 09:24:41 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Fri, 18 Mar 2016 08:24:41 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <3198644.MSAbKBEonO@42> References: <56EA85CA.4040109@taschenorakel.de> <56EA952A.1000300@familiesomers.nl> <3198644.MSAbKBEonO@42> Message-ID: <50A4BC7A-337A-4117-8802-A3D94067BAC4@digia.com> On 18 Mar 2016, at 08:48, Jędrzej Nowacki > wrote: Every time someone discuss coding style issues my blood boils. I understand that it is important to have consistent coding style, but discussing where to put braces or spaces is just waste of developing time. Agreed, but that’s what code review is all about, as it turns out. I'm totally for an automated solution. I would even say that every rule formatting related which is not expressed in some tooling aware code should disappear. In addition, I really do not like that sanity bot is complaining about typos after I pushed patches to gerrit and even worse it is commenting on my code instead of proposing a fix. Well, it would be nice if gerrit allowed reviewers to propose fixes too, so that you can just accept or reject individual proposed diff lines without having to do a git checkout to get exactly back the same state (which means you first need to commit or stash whatever you were doing, because it will be interrupted by fixing nitpicks), fixing the nits and pushing again. Just like you can edit the commit message right on gerrit. But, who’s going to implement it... As you said coding convention are a bit bigger topic, but it also should be automated. Seriously, rules about where to place Q_DECLARE_METATYPE or a check if an include is missing are quite easy to express. So I think, that we should not discuss what is better qdoc or md. The real discussion is about tooling, what is the best tool to sanitize Qt code. We need something that: 1. Can work as a sanity bot 2. Can re-format the code by applying changes (git hook?) Forcing it on everyone that way will be controversial, because there is still some leeway in formatting, whereas automation would remove any chance of personal preference, and probably screw up in some cases. But we could at least start by adding the clang-format config file to git so that it’s available for doing this manually. Then in a few years maybe everybody will get used to it enough, and it can be refined enough, to become near-universal. Otherwise there is the problem of running it for the first time, which the nitpicking reviewers would insist should be a separate commit. So somebody would probably want to run clang-format on the whole repo, and make one big formatting-fix commit, which brings up said opportunity for clang-format to screw up alignment of code and comments in ways that will piss people off. So I guess it would have to rather be done one file at a time, but due to the rule that we can’t fix whitespace and code at the same time, that would result in lots of extra noise in the commit logs: clang-format this.cpp, clang-format that.h and so on. Not fixing code and whitespace in the same patch is a stupid rule of ours IMO. (It’s OK to fix the copyright header at the same time, but never dare to remove or add a single misplaced space at the same time.) I think we should abandon that rule and allow formatting fixes at the same time as code fixes, especially if the formatting fixes are being done by some tool anyway. Especially if gerrit could have a checkbox to ignore whitespace changes, like most offline diff viewers do. Then when reviewing you look twice: once to see the code changes, and once to ensure that the whitespace changes are sane. (But the sanity bot already does that.) 3. Rules are easy to express and they can be exported (qdoc, html, fooBar) 4. Works on diff level (so it doesn't complain about the whole world being broken) Bonus: 5. C++, js, qml awareness Cheers, Jędrek _______________________________________________ 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 heikki.halmet at theqtcompany.com Fri Mar 18 09:34:07 2016 From: heikki.halmet at theqtcompany.com (Halmet Heikki) Date: Fri, 18 Mar 2016 08:34:07 +0000 Subject: [Development] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool versions In-Reply-To: References: Message-ID: Hi, I think we also need to update at least these to 5.7 Xcode 7.2.1 to OSX 10.10.5 & 10.11.2 Xcode 6.2 to OSX 10.9.4 Android sdk 24.4.1 Visual Studio 2015 Update 1 to Windows 10 Latest openssl 1.0.2g Should we use beta OSX and beta Xcode in dev? Xcode 7.3 beta 5 to OS X v10.11.4 beta - Heikki From: Development [mailto:development-bounces+heikki.halmet=theqtcompany.com at qt-project.org] On Behalf Of Heikkinen Jani Sent: 18. maaliskuuta 2016 10:03 To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool versions Hi all, Currently used tools & versions in ci and packaging are listed in http://wiki.qt.io/Qt-5.7.0-tools-and-versions. 'dev' is also using same set. Now when Qt 5.6.0 is out we are planning to do some updates. We are planning to: - Update MinGW to i686-5.3.0-release-posix-dwarf-rt_v4-rev0 * first test build already done by Kai, full test build to be done in coin really soon - Update Android NDK to r11 * Some build issue reported (QTBUG-51859), fix https://codereview.qt-project.org/#/c/153212/ Please inform me immediately if you see some problem with this. Also inform me immediately if you know something else to be updated (for 5.7 or for 5.8). For 5.7 we are already quite late and we need to get needed updates done before beta release. For 5.8 it is actually correct time to do those ;) br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Fri Mar 18 09:40:13 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 18 Mar 2016 09:40:13 +0100 Subject: [Development] Fwd: Change in qt/qtbase[5.6]: Move QButtonGroup implementation from qabstractbutton.cpp to... In-Reply-To: <201603181026.14642.marc.mutz@kdab.com> References: <201603181026.14642.marc.mutz@kdab.com> Message-ID: <10492948.8rPbEKJQWX@finn> Am Freitag, 18. März 2016, 10:26:14 CET schrieb Marc Mutz: > Hi, > > Compiler upgraded in the CI without checking Qt compiles with it first? :) > > Fix: https://codereview.qt-project.org/153309 I think the error is caused by your patch "QtWidgets: includemocs" clang can only warns about this kind of stuff if all the method of a class are deined. Including QWindowsStyle::metaObject() and such things that are only defined in the moc generated code. If you include them in the same translation unit clang sees that none of the functions uses the private member. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From olivier at woboq.com Fri Mar 18 09:51:38 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 18 Mar 2016 09:51:38 +0100 Subject: [Development] RFD: Removing environment variable support from configure In-Reply-To: References: <2163271.d5uSufSx7L@tjmaciei-mobl4> Message-ID: <1701290.1bE7tNmUnr@finn> Am Donnerstag, 17. März 2016, 21:31:27 CET schrieb Knoll Lars: > Yes, let's drop this. Btw, I'm currently anyway working on changing how > configuration handling is done for Qt, so there will be some changes in > this area coming for Qt 5.8. How then are we going to insert custom compiler flags? Inserting custom compiler flags is usefull tu test new compiler features or such. For example testing C++11 before it was supported by Qt, testing analyzer toolr. Using clang plugin such as clazy or other ctatic analyzers. Or trying out afl (the fuzzer, ok, IIRC this was only changing $CXX and $CC). There should be an alternative. And i don't think editing the configure script is a good one. (Unless there is already an alternative which I don't know of.) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Fri Mar 18 11:01:15 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 18 Mar 2016 11:01:15 +0100 Subject: [Development] Fwd: Change in qt/qtbase[5.6]: Move QButtonGroup implementation from qabstractbutton.cpp to... In-Reply-To: <201603181026.14642.marc.mutz@kdab.com> References: <201603181026.14642.marc.mutz@kdab.com> Message-ID: <201603181101.15826.marc.mutz@kdab.com> On Friday 18 March 2016 10:26:14 Marc Mutz wrote: > Hi, > > Compiler upgraded in the CI without checking Qt compiles with it first? :) Sorry for accusing the CI team. It turns out to be cause by one of my patches. It's triggered by running includemocs in src/widgets. Clang now sees all the functions in the class, including moc-generated ones, and is able to emit this warning. Another reason (besides the executable size savings) to always include the generated code into the class' cpp file. Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Morten.Sorvig at theqtcompany.com Fri Mar 18 09:52:50 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Fri, 18 Mar 2016 08:52:50 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <3198644.MSAbKBEonO@42> References: <56EA85CA.4040109@taschenorakel.de> <56EA952A.1000300@familiesomers.nl> <3198644.MSAbKBEonO@42> Message-ID: > On 18 Mar 2016, at 08:48, Jędrzej Nowacki wrote: > > So I think, that we should not discuss what is better qdoc or md. The real > discussion is about tooling, what is the best tool to sanitize Qt code. We > need something that: > 1. Can work as a sanity bot > 2. Can re-format the code by applying changes (git hook?) > 3. Rules are easy to express and they can be exported (qdoc, html, fooBar) > 4. Works on diff level (so it doesn't complain about the whole world being > broken) > > Bonus: > 5. C++, js, qml awareness I’ve used clang-format on wip/nacl, with the following workflow: git add git-clang-format git commit Where git-clang-format looks at staged content only, and does not touch files with unstaged changes. This would allow us to incrementally adopt it on a per-commit, per-developer basis. As a matter of policy, “I ran clang-format!” should then be an acceptable response to style remarks on gerrit. (within reason) Morten Qt-like .clang.format: http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/pepper/.clang-format?h=wip/nacl git-clang-format script: https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/git-clang-format From Lars.Knoll at theqtcompany.com Fri Mar 18 10:13:13 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 18 Mar 2016 09:13:13 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: <56EA85CA.4040109@taschenorakel.de> <56EA952A.1000300@familiesomers.nl> <3198644.MSAbKBEonO@42> Message-ID: <3B421366-DAF4-4CC5-B0A0-07C82624E088@theqtcompany.com> I’m all for an automated solution for code formatting, so we can remove discussions/comments about wrongly placed braces or spaces from code review and can rather focus more on the content. But there will be still a need for some coding guidelines in other places (like auto usage, foreach and many other things). Cheers, Lars On 18/03/16 09:52, "Development on behalf of Sorvig Morten" wrote: > >> On 18 Mar 2016, at 08:48, Jędrzej Nowacki wrote: >> >> So I think, that we should not discuss what is better qdoc or md. The real >> discussion is about tooling, what is the best tool to sanitize Qt code. We >> need something that: >> 1. Can work as a sanity bot >> 2. Can re-format the code by applying changes (git hook?) >> 3. Rules are easy to express and they can be exported (qdoc, html, fooBar) >> 4. Works on diff level (so it doesn't complain about the whole world being >> broken) >> >> Bonus: >> 5. C++, js, qml awareness > > >I’ve used clang-format on wip/nacl, with the following workflow: > > >git add >git-clang-format > >git commit > >Where git-clang-format looks at staged content only, and does not touch files >with unstaged changes. > >This would allow us to incrementally adopt it on a per-commit, per-developer >basis. As a matter of policy, “I ran clang-format!” should then be an acceptable >response to style remarks on gerrit. (within reason) > >Morten > >Qt-like .clang.format: http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/platforms/pepper/.clang-format?h=wip/nacl >git-clang-format script: https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/git-clang-format > > > > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Martin.Smith at theqtcompany.com Fri Mar 18 10:43:55 2016 From: Martin.Smith at theqtcompany.com (Smith Martin) Date: Fri, 18 Mar 2016 09:43:55 +0000 Subject: [Development] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool versions In-Reply-To: References: , Message-ID: I have Xcode 7.2.1 and OSX 10.11.3 installed, but my Xcode isn't allowing me to compile qdoc. The compiler says it can't find things like #include , which means it isn't installed correctly. But I have no idea what's wrong. martin ________________________________ From: Development on behalf of Halmet Heikki Sent: Friday, March 18, 2016 9:34 AM To: Heikkinen Jani; development at qt-project.org Cc: releasing at qt-project.org Subject: Re: [Development] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool versions Hi, I think we also need to update at least these to 5.7 Xcode 7.2.1 to OSX 10.10.5 & 10.11.2 Xcode 6.2 to OSX 10.9.4 Android sdk 24.4.1 Visual Studio 2015 Update 1 to Windows 10 Latest openssl 1.0.2g Should we use beta OSX and beta Xcode in dev? Xcode 7.3 beta 5 to OS X v10.11.4 beta - Heikki From: Development [mailto:development-bounces+heikki.halmet=theqtcompany.com at qt-project.org] On Behalf Of Heikkinen Jani Sent: 18. maaliskuuta 2016 10:03 To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool versions Hi all, Currently used tools & versions in ci and packaging are listed in http://wiki.qt.io/Qt-5.7.0-tools-and-versions. 'dev' is also using same set. Now when Qt 5.6.0 is out we are planning to do some updates. We are planning to: - Update MinGW to i686-5.3.0-release-posix-dwarf-rt_v4-rev0 * first test build already done by Kai, full test build to be done in coin really soon - Update Android NDK to r11 * Some build issue reported (QTBUG-51859), fix https://codereview.qt-project.org/#/c/153212/ Please inform me immediately if you see some problem with this. Also inform me immediately if you know something else to be updated (for 5.7 or for 5.8). For 5.7 we are already quite late and we need to get needed updates done before beta release. For 5.8 it is actually correct time to do those ;) br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at theqtcompany.com Fri Mar 18 10:55:24 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Fri, 18 Mar 2016 09:55:24 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56EB0563.3050205@kdab.com> References: <1556922.j7q4PTgklR@desktop-ga45d22> <4182839.Edbz7sJSMD@tjmaciei-mobl4> <56EAE80F.3070503@kdab.com> <1203241458237524@web4j.yandex.ru>,<56EB0563.3050205@kdab.com> Message-ID: Giuseppe D'Angelo: >>> The question is, can/should we get the HTML output of these documents >>> published somewhere, for ease of access? All the HTML generated from QDoc in all of our code should be visible in some public way. This would just be one more page of that. >>> Do they need their own repository to get them updated daily? There are also "snapshot" versions of the HTML available [0], that change often, as well as the per-release official versions. [0] http://doc-snapshots.qt.io/ It remains that this document is expected to be quite stable, so there would be some sense to having a stable URL to which we routinely copy the new version once a change to the source has been accepted. The effort involved would be minor, I must suppose. Konstantin Tokarev: >> What's wrong with reading them as plain text? Putting them in the source lets developers read them as plain text. As we're fluent in QDoc format, that works for us. The rest of the world likes the web browsing presentation better. (Also: following links - even we like the web better for that.) In particular, when someone on a team is trying to persuade the rest of the team to adopt our style, that team isn't necessarily all coding with Qt or using QDoc; so it's important to give them a nice reading experience as they learn about our style. *After* we've brought them round to our way of seeing things, we might coax them into learning QDoc as well, but we need to make it easy for them to agree to the first step, if we're to have a chance at that. Giuseppe D'Angelo: > What's the point at using a markup format then? Markup plays well with code review (line-structured, plain text) but can be turned into a form that displays nicely (good for advocacy). Eddy. From Kai.Koehne at theqtcompany.com Fri Mar 18 11:46:41 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Fri, 18 Mar 2016 10:46:41 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: <1556922.j7q4PTgklR@desktop-ga45d22> <4182839.Edbz7sJSMD@tjmaciei-mobl4> <56EAE80F.3070503@kdab.com> <1203241458237524@web4j.yandex.ru>,<56EB0563.3050205@kdab.com> Message-ID: > -----Original Message----- > From: Development [mailto:development- > [...] > It remains that this document is expected to be quite stable, so there would > be some sense to having a stable URL to which we routinely copy the new > version once a change to the source has been accepted. The effort involved > would be minor, I must suppose. We'd avoid this problem if we put it into a repository that doesn't follow the Qt branching model. If things change for specific Qt versions, that should be noted explicitly in the documentation. So far following locations have been proposed: qtbase.git qtdoc.git qtqa.git qt5.git I dislike qtbase.git, just because getting stuff in there is so much work. Lars suggested qtdoc.git because much of the general documentation is there, but it follows the branching model. So I'm personally leaning to either qtqa.git or qt5.git directly. Regards Kai From sergio.martins at kdab.com Fri Mar 18 11:07:16 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Fri, 18 Mar 2016 11:07:16 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: Message-ID: <2831481.kuq3hxG9ER@desktop-ga45d22> On Friday, March 18, 2016 10:46:41 AM Koehne Kai wrote: > > -----Original Message----- > > From: Development [mailto:development- > > [...] > > It remains that this document is expected to be quite stable, so there > > would be some sense to having a stable URL to which we routinely copy the > > new version once a change to the source has been accepted. The effort > > involved would be minor, I must suppose. > > We'd avoid this problem if we put it into a repository that doesn't follow > the Qt branching model. If things change for specific Qt versions, that > should be noted explicitly in the documentation. > > So far following locations have been proposed: > > qtbase.git > qtdoc.git > qtqa.git > qt5.git > > I dislike qtbase.git, just because getting stuff in there is so much work. > Lars suggested qtdoc.git because much of the general documentation is > there, but it follows the branching model. So I'm personally leaning to > either qtqa.git or qt5.git directly. Note that there are two diferent types of documentation in this thread: - "C++11 features we can/should use in Qt" - "code formatting style and such" For the C++11 features doc we definitely want it pegged to a branch, so when you checkout qtbase 5.X you know what you can use. For the code style doc I guess you're right, since it's orthogonal to versioning. Regards, -- Sérgio Martins | sergio.martins 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 Experts From rjvbertin at gmail.com Fri Mar 18 12:54:25 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2E__V=2E?= Bertin) Date: Fri, 18 Mar 2016 12:54:25 +0100 Subject: [Development] tarball fetches from code.qt.io? References: <2000886.r6WD1beTJ9@patux> <1856371.zXPc59Bamk@tjmaciei-mobl4> <1784737.znae0EUkVN@portia.local> <23615250.ps6K5Qji8Q@tjmaciei-mobl4> Message-ID: <2265755.l1Kp7gGy0M@portia.local> Heikkinen Jani wrote: > Hi! > > Webkit packages can be found from here: > http://download.qt.io/community_releases/5.6/5.6.0/ So apparently this package is designed to be built in a separate step. The toplevel qt.pro and .gitmodules file from the monolithic source tarball suggests that it still might be possible to build a Webkit tree as part of a single-build approach, which would suit me. Is that correct? Trying this currently fails because at some point headers are not found that are expected in a QtWebkit framework: In file included from qt-everywhere-opensource- src-5.6.0/qtwebkit/Source/WebKit/qt/WidgetApi/qgraphicswebview.cpp:22: qt-everywhere-opensource- src-5.6.0/qtwebkit/Source/WebKit/qt/WidgetApi/qgraphicswebview.h:23:10: fatal error: 'QtWebKit/qwebkitglobal.h' file not found #include ^ In the meantime I'll be trying with the qtwebkit suddir from Qt 5.5.1 but without expecting much out of it ... R. From charleyb123 at gmail.com Fri Mar 18 14:09:04 2016 From: charleyb123 at gmail.com (charleyb123 .) Date: Fri, 18 Mar 2016 07:09:04 -0600 Subject: [Development] [Releasing] HEADS UP: Updates to Qt 5.7 (and Qt 5.8) tool versions In-Reply-To: References: Message-ID: > > Visual Studio 2015 Update 1 to Windows 10 > > Please let’s keep in mind that Visual Studio 2015 Update 2 is coming out, > I don’t think that it will be ready for Qt 5.7, but we should be prepared > for Qt 5.8 indeed. > > Regards, > Diego > +1 --charley -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Fri Mar 18 14:52:42 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 18 Mar 2016 14:52:42 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? References: <1466246.T2YiNlAlqL@portia.local> <2990358.uyNBeULEkV@portia.local> <2622193.bgRTmrMSP5@tjmaciei-mobl4> <9231592.A7IvxZEBeG@portia.local> <41365CB4-BBD3-4DAB-9D61-BEF79FC0C15B@gmail.com> Message-ID: <2068458.X1XyrHk62x@portia.local> Till Oliver Knoll wrote: > According to > > https://wiki.qt.io/New_Features_in_Qt_5.6 > > "Optional support for using FreeType on Mac OS X" is now available. Yeah, but apparently not exactly as planned: %> Assistant.app/Contents/MacOS/Assistant --fontengine=freetype QCocoaIntegration::Options parseOptions(const QStringList &) paramList= () Unknown option: --fontengine=freetype Usage: assistant [Options] %> Qt\ Creator.app/Contents/MacOS/Qt\ Creator --fontengine=freetype QCocoaIntegration::Options parseOptions(const QStringList &) paramList= () Unknown option --fontengine=freetype Usage: Qt Creator [OPTION]... [FILE]... Options: IOW: QCocoaIntegration::QCocoaIntegration() is called with an empty paramList (or --fontengine is not accepted into that list), and whoever else does the fallback option parsing doesn't support --fontengine either. R. From oswald.buddenhagen at theqtcompany.com Fri Mar 18 15:10:12 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Fri, 18 Mar 2016 15:10:12 +0100 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: <2265755.l1Kp7gGy0M@portia.local> References: <2000886.r6WD1beTJ9@patux> <1856371.zXPc59Bamk@tjmaciei-mobl4> <1784737.znae0EUkVN@portia.local> <23615250.ps6K5Qji8Q@tjmaciei-mobl4> <2265755.l1Kp7gGy0M@portia.local> Message-ID: <20160318141012.GA32445@troll08.it.local> On Fri, Mar 18, 2016 at 12:54:25PM +0100, René J. V. Bertin wrote: > Is that correct? Trying this currently fails because at some point headers are > not found that are expected in a QtWebkit framework: > that means that the packagers failed to run syncqt. what a totally non-surprising effect of insisting on doing things differently because we want to get rid of the repo *so badly* ... From sergio.martins at kdab.com Fri Mar 18 14:15:32 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Fri, 18 Mar 2016 14:15:32 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? In-Reply-To: <2068458.X1XyrHk62x@portia.local> References: <1466246.T2YiNlAlqL@portia.local> <41365CB4-BBD3-4DAB-9D61-BEF79FC0C15B@gmail.com> <2068458.X1XyrHk62x@portia.local> Message-ID: <2452149.EIisSZMbR1@desktop-ga45d22> On Friday, March 18, 2016 02:52:42 PM René J. V. Bertin wrote: > Till Oliver Knoll wrote: > > According to > > > > https://wiki.qt.io/New_Features_in_Qt_5.6 > > > > "Optional support for using FreeType on Mac OS X" is now available. > > Yeah, but apparently not exactly as planned: Where was --fontengine=freetype planed, or where did you see it would work ? > > %> Assistant.app/Contents/MacOS/Assistant --fontengine=freetype > QCocoaIntegration::Options parseOptions(const QStringList &) paramList= () > Unknown option: --fontengine=freetype > > > Usage: assistant [Options] > > > %> Qt\ Creator.app/Contents/MacOS/Qt\ Creator --fontengine=freetype > QCocoaIntegration::Options parseOptions(const QStringList &) paramList= () > Unknown option --fontengine=freetype > Usage: Qt Creator [OPTION]... [FILE]... > Options: > > > IOW: QCocoaIntegration::QCocoaIntegration() is called with an empty > paramList (or --fontengine is not accepted into that list), and whoever > else does the fallback option parsing doesn't support --fontengine either. To get parameters passed to QCocoaIntegration::QCocoaIntegration(), you should use -platform cocoa:fontengine=freetype, which I haven't tried, but similar works for me on Windows. Also double check your Qt was built with FreeType support. Regards, -- Sérgio Martins | sergio.martins 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 Experts From jedrzej.nowacki at theqtcompany.com Fri Mar 18 13:36:18 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 18 Mar 2016 13:36:18 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <3B421366-DAF4-4CC5-B0A0-07C82624E088@theqtcompany.com> References: <3B421366-DAF4-4CC5-B0A0-07C82624E088@theqtcompany.com> Message-ID: <1546971.SrI2XLxADm@42> On Friday 18 of March 2016 09:13:13 Knoll Lars wrote: > I’m all for an automated solution for code formatting, so we can remove > discussions/comments about wrongly placed braces or spaces from code review > and can rather focus more on the content. But there will be still a need > for some coding guidelines in other places (like auto usage, foreach and > many other things). That was my point. It starts to be really arbitrary. If we can not express a rule in an algorithmic way then it is not a rule it is just a hint, which should not end up as a -1 in code review. Auto usage is exactly one of these cases, some people thinks it is fine to use it almost everywhere some thinks it is better to avoid it. I really want to have an algorithm, I don't want to have slightly different coding style depending on the reviewer. Same with foreach, it seems that we prefer range loops now, therefore foreach should not be used which is easy to express as an algorithm ;-) Cheers, Jędrek From rjvbertin at gmail.com Fri Mar 18 15:37:05 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 18 Mar 2016 15:37:05 +0100 Subject: [Development] tarball fetches from code.qt.io? References: <2000886.r6WD1beTJ9@patux> <1856371.zXPc59Bamk@tjmaciei-mobl4> <1784737.znae0EUkVN@portia.local> <23615250.ps6K5Qji8Q@tjmaciei-mobl4> <2265755.l1Kp7gGy0M@portia.local> <20160318141012.GA32445@troll08.it.local> Message-ID: <1838910.BUofn3Gdjr@portia.local> Oswald Buddenhagen wrote: > On Fri, Mar 18, 2016 at 12:54:25PM +0100, René J. V. Bertin wrote: >> Is that correct? Trying this currently fails because at some point headers >> are not found that are expected in a QtWebkit framework: >> > that means that the packagers failed to run syncqt. They probably also forgot to ensure that users can run that tool themselves (= update sync.profile or something like that)? > > what a totally non-surprising effect of insisting on doing things > differently because we want to get rid of the repo *so badly* ... Not differently, but "as much as possible like before". There's still too much software out there that requires QtWebkit, whether you like it or not. The replacement module can already be built in the same kind of deployment/distribution procedure (configure/make/install), so why make it (deliberately) obligatory to make invasive, temporary changes to that procedure that go beyond grabbing an additional tarball and unpacking it at the right location? R From andre at familiesomers.nl Fri Mar 18 15:37:40 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 18 Mar 2016 15:37:40 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <50A4BC7A-337A-4117-8802-A3D94067BAC4@digia.com> References: <56EA85CA.4040109@taschenorakel.de> <56EA952A.1000300@familiesomers.nl> <3198644.MSAbKBEonO@42> <50A4BC7A-337A-4117-8802-A3D94067BAC4@digia.com> Message-ID: <56EC12B4.40704@familiesomers.nl> Op 18/03/2016 om 09:24 schreef Rutledge Shawn: > Forcing it on everyone that way will be controversial, because there > is still some leeway in formatting, whereas automation would remove > any chance of personal preference, and probably screw up in some > cases. But we could at least start by adding the clang-format config > file to git so that it’s available for doing this manually. Then in a > few years maybe everybody will get used to it enough, and it can be > refined enough, to become near-universal. > That's the point: remove the personal preference. Or, make it irrelevant. You can format your own code localy on your own system however you like. As soon as it gets integrated, it will formatted following whatever the standard is anyway. So no, I do not think there should be leeway for personal differences here. Code formatting matters for readability, but it doesn't merrit long discussions or wasting time fixing -1's because of wrongly placed spaces. If the formatting needs improvement, improve the script doing the work, don't do it manually. André From rjvbertin at gmail.com Fri Mar 18 15:42:06 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 18 Mar 2016 15:42:06 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? References: <1466246.T2YiNlAlqL@portia.local> <41365CB4-BBD3-4DAB-9D61-BEF79FC0C15B@gmail.com> <2068458.X1XyrHk62x@portia.local> <2452149.EIisSZMbR1@desktop-ga45d22> Message-ID: <1565472.RYW2AbKsG0@portia.local> Sergio Martins wrote: > -platform cocoa:fontengine=freetype Ahh, right, thanks! I was already quite certain that Freetype support was built in (it appears to be the default). I can now confirm that Freetype works, even the Infinality patches (bohoomil's fontconfig ultimate variant). I'm not certain though if those make any sense without also using fontconfig . R. From oswald.buddenhagen at theqtcompany.com Fri Mar 18 15:44:14 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Fri, 18 Mar 2016 15:44:14 +0100 Subject: [Development] RFD: Removing environment variable support from configure In-Reply-To: <1701290.1bE7tNmUnr@finn> <2163271.d5uSufSx7L@tjmaciei-mobl4> Message-ID: <20160318144414.GB32445@troll08.it.local> On Thu, Mar 17, 2016 at 01:45:44PM -0700, Thiago Macieira wrote: > Summary: if CXXFLAGS is set on the environment when you run configure, the OS X > build breaks. > > This happened because we don't test the building while those flags are set. > > I'm proposing we drop even checking them (configure lines 556 to 580). > we (that is, you and me) already decided that we should drop that code. i was just reluctant to proceed now, knowing that users will see major buildsystem-related changes soonish anyway. https://bugreports.qt.io/browse/QTBUG-42962 is closest to a direct indictment of this misfeature, though there are other tasks where this is mentioned peripherally. https://bugreports.qt.io/browse/QTBUG-32530 shows that it is implemented incorrectly as well. https://codereview.qt-project.org/151857 forms the basis for fixing this. there are also some tasks which stem from this not taking cross-builds into account. On Fri, Mar 18, 2016 at 09:51:38AM +0100, Olivier Goffart wrote: > How then are we going to insert custom compiler flags? > as always: fork/hack the makespec. well, actually ... as it happens, that (mis-)feature was implemented a long time ago upon my explicit request - unsurprisingly, to solve some very real problems. back then, there was no git to make hacking the makespec as painless as it can be now. not to mention that the approach isn't all that nice to start with. so the idea was to be autoconf-like, as that's customary on unix systems. however, it turns out that it has "side effect" ... instead, configure needs to be fed these options explicitly. after all, we already do it for a bunch of specific options: -I/-L/-l/-F/-fw. we could add some more options like that, or alternatively parse variable assignments like CXXFLAGS= and HOST_CXXFLAGS= on the command line - the windows configure already does (or at least did) it for some things (openssl paths, etc). note that the approach still doesn't mix that well with the makespec concept, which tries to be somewhat property-based (specialized variables for particular purposes). there isn't much we can do about that with qmake. From marc.mutz at kdab.com Fri Mar 18 16:02:22 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 18 Mar 2016 16:02:22 +0100 Subject: [Development] RFD: Removing environment variable support from configure In-Reply-To: <20160318144414.GB32445@troll08.it.local> References: <20160318144414.GB32445@troll08.it.local> Message-ID: <201603181602.23135.marc.mutz@kdab.com> On Friday 18 March 2016 15:44:14 Oswald Buddenhagen wrote: > instead, configure needs to be fed these options explicitly. after all, > we already do it for a bunch of specific options: -I/-L/-l/-F/-fw. we > could add some more options like that, or alternatively parse variable > assignments like CXXFLAGS= and HOST_CXXFLAGS= on the command line - the > windows configure already does (or at least did) it for some things > (openssl paths, etc). Why parse CXXFLAGS= on the command line if you can do MY_CXXFLAGS="$CXXFLAGS" unset CXXFLAGS ? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Fri Mar 18 16:03:12 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 18 Mar 2016 16:03:12 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56EC12B4.40704@familiesomers.nl> References: <50A4BC7A-337A-4117-8802-A3D94067BAC4@digia.com> <56EC12B4.40704@familiesomers.nl> Message-ID: <201603181603.12711.marc.mutz@kdab.com> On Friday 18 March 2016 15:37:40 André Somers wrote: > Op 18/03/2016 om 09:24 schreef Rutledge Shawn: > > Forcing it on everyone that way will be controversial, because there > > is still some leeway in formatting, whereas automation would remove > > any chance of personal preference, and probably screw up in some > > cases. But we could at least start by adding the clang-format config > > file to git so that it’s available for doing this manually. Then in a > > few years maybe everybody will get used to it enough, and it can be > > refined enough, to become near-universal. > > That's the point: remove the personal preference. Or, make it > irrelevant. You can format your own code localy on your own system > however you like. As soon as it gets integrated, it will formatted > following whatever the standard is anyway. > > So no, I do not think there should be leeway for personal differences > here. Code formatting matters for readability, but it doesn't merrit > long discussions or wasting time fixing -1's because of wrongly placed > spaces. If the formatting needs improvement, improve the script doing > the work, don't do it manually. Amen. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Fri Mar 18 16:44:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 18 Mar 2016 08:44:08 -0700 Subject: [Development] Qt Coding Guidelines In-Reply-To: References: Message-ID: <4311470.mmnUdyWm7v@tjmaciei-mobl4> On sexta-feira, 18 de março de 2016 10:46:41 PDT Koehne Kai wrote: > > It remains that this document is expected to be quite stable, so there > > would be some sense to having a stable URL to which we routinely copy the > > new version once a change to the source has been accepted. The effort > > involved would be minor, I must suppose. > > We'd avoid this problem if we put it into a repository that doesn't follow > the Qt branching model. I'd say we *want* it to follow the branching model, so that we can keep it linked to the version in which it applies. Maybe I'm saying this only because of the current circumstances, as the policy for 5.6 differs quite a lot from 5.7. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at theqtcompany.com Fri Mar 18 16:45:53 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Fri, 18 Mar 2016 16:45:53 +0100 Subject: [Development] RFD: Removing environment variable support from configure In-Reply-To: <201603181602.23135.marc.mutz@kdab.com> References: <20160318144414.GB32445@troll08.it.local> <201603181602.23135.marc.mutz@kdab.com> Message-ID: <20160318154553.GC32445@troll08.it.local> On Fri, Mar 18, 2016 at 04:02:22PM +0100, Marc Mutz wrote: > On Friday 18 March 2016 15:44:14 Oswald Buddenhagen wrote: > > instead, configure needs to be fed these options explicitly. after all, > > we already do it for a bunch of specific options: -I/-L/-l/-F/-fw. we > > could add some more options like that, or alternatively parse variable > > assignments like CXXFLAGS= and HOST_CXXFLAGS= on the command line - the > > windows configure already does (or at least did) it for some things > > (openssl paths, etc). > > Why parse CXXFLAGS= on the command line if you can do > > MY_CXXFLAGS="$CXXFLAGS" > unset CXXFLAGS > > ? > because using real env variables for that is just plain wrong, no matter how they are named. the variable assignment syntax is "inspired" by what you can do with qmake itself. From Lars.Knoll at theqtcompany.com Fri Mar 18 17:04:12 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 18 Mar 2016 16:04:12 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <4311470.mmnUdyWm7v@tjmaciei-mobl4> References: <4311470.mmnUdyWm7v@tjmaciei-mobl4> Message-ID: On 18/03/16 16:44, "Development on behalf of Thiago Macieira" wrote: >On sexta-feira, 18 de março de 2016 10:46:41 PDT Koehne Kai wrote: >> > It remains that this document is expected to be quite stable, so there >> > would be some sense to having a stable URL to which we routinely copy the >> > new version once a change to the source has been accepted. The effort >> > involved would be minor, I must suppose. >> >> We'd avoid this problem if we put it into a repository that doesn't follow >> the Qt branching model. > >I'd say we *want* it to follow the branching model, so that we can keep it >linked to the version in which it applies. Maybe I'm saying this only because >of the current circumstances, as the policy for 5.6 differs quite a lot from >5.7. +1. Things do evolve, and I've seen issues whenever we tried to define such things independent of the Qt version. Cheers, Lars From Lars.Knoll at theqtcompany.com Fri Mar 18 17:05:37 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 18 Mar 2016 16:05:37 +0000 Subject: [Development] Qt Coding Guidelines In-Reply-To: <201603181603.12711.marc.mutz@kdab.com> References: <50A4BC7A-337A-4117-8802-A3D94067BAC4@digia.com> <56EC12B4.40704@familiesomers.nl> <201603181603.12711.marc.mutz@kdab.com> Message-ID: <4C80D3DE-8056-4EE0-8F6E-B818BF344367@theqtcompany.com> On 18/03/16 16:03, "Development on behalf of Marc Mutz" wrote: >On Friday 18 March 2016 15:37:40 André Somers wrote: >> Op 18/03/2016 om 09:24 schreef Rutledge Shawn: >> > Forcing it on everyone that way will be controversial, because there >> > is still some leeway in formatting, whereas automation would remove >> > any chance of personal preference, and probably screw up in some >> > cases. But we could at least start by adding the clang-format config >> > file to git so that it’s available for doing this manually. Then in a >> > few years maybe everybody will get used to it enough, and it can be >> > refined enough, to become near-universal. >> >> That's the point: remove the personal preference. Or, make it >> irrelevant. You can format your own code localy on your own system >> however you like. As soon as it gets integrated, it will formatted >> following whatever the standard is anyway. >> >> So no, I do not think there should be leeway for personal differences >> here. Code formatting matters for readability, but it doesn't merrit >> long discussions or wasting time fixing -1's because of wrongly placed >> spaces. If the formatting needs improvement, improve the script doing >> the work, don't do it manually. > >Amen. Fully agree as well. So how do we get to some tool that we can use for the purpose? Lars From kde at carewolf.com Fri Mar 18 18:54:31 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 18 Mar 2016 18:54:31 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <56EC12B4.40704@familiesomers.nl> References: <50A4BC7A-337A-4117-8802-A3D94067BAC4@digia.com> <56EC12B4.40704@familiesomers.nl> Message-ID: <201603181854.31485.kde@carewolf.com> On Friday 18 March 2016, André Somers wrote: > Op 18/03/2016 om 09:24 schreef Rutledge Shawn: > > Forcing it on everyone that way will be controversial, because there > > is still some leeway in formatting, whereas automation would remove > > any chance of personal preference, and probably screw up in some > > cases. But we could at least start by adding the clang-format config > > file to git so that it’s available for doing this manually. Then in a > > few years maybe everybody will get used to it enough, and it can be > > refined enough, to become near-universal. > > That's the point: remove the personal preference. Or, make it > irrelevant. You can format your own code localy on your own system > however you like. As soon as it gets integrated, it will formatted > following whatever the standard is anyway. > > So no, I do not think there should be leeway for personal differences > here. Code formatting matters for readability, but it doesn't merrit > long discussions or wasting time fixing -1's because of wrongly placed > spaces. If the formatting needs improvement, improve the script doing > the work, don't do it manually. > There isn't any single unique formatting that follows the rule. Please don't correct code that already follows existing rules, an automatic crappifier would not be a good thing. And people should always edit in the final result, otherwise they can't pre- format the code, which means we only get automatically crappified formatting. `Allan From andre at familiesomers.nl Fri Mar 18 19:01:09 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 18 Mar 2016 19:01:09 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <201603181854.31485.kde@carewolf.com> References: <50A4BC7A-337A-4117-8802-A3D94067BAC4@digia.com> <56EC12B4.40704@familiesomers.nl> <201603181854.31485.kde@carewolf.com> Message-ID: <56EC4265.2000803@familiesomers.nl> Op 18/03/2016 om 18:54 schreef Allan Sandfeld Jensen: > On Friday 18 March 2016, André Somers wrote: >> Op 18/03/2016 om 09:24 schreef Rutledge Shawn: >>> Forcing it on everyone that way will be controversial, because there >>> is still some leeway in formatting, whereas automation would remove >>> any chance of personal preference, and probably screw up in some >>> cases. But we could at least start by adding the clang-format config >>> file to git so that it’s available for doing this manually. Then in a >>> few years maybe everybody will get used to it enough, and it can be >>> refined enough, to become near-universal. >> That's the point: remove the personal preference. Or, make it >> irrelevant. You can format your own code localy on your own system >> however you like. As soon as it gets integrated, it will formatted >> following whatever the standard is anyway. >> >> So no, I do not think there should be leeway for personal differences >> here. Code formatting matters for readability, but it doesn't merrit >> long discussions or wasting time fixing -1's because of wrongly placed >> spaces. If the formatting needs improvement, improve the script doing >> the work, don't do it manually. >> > There isn't any single unique formatting that follows the rule. Follows what rule? > Please don't > correct code that already follows existing rules, an automatic crappifier > would not be a good thing. If the rules for 5.8 would be "formatted using clang-format using LLVM formatting" (to give an example), existing code would not be following the rule and the output would be exactly what was mandated by the rule. > And people should always edit in the final result, otherwise they can't pre- > format the code, which means we only get automatically crappified formatting. No, they should not. They should not need to nor want to, and they should not be bothered about it either. Even if the result is not as pretty as they think they can make it look, leave it. If you really feel the need to fix formatting for some case, fix the formatter, not the result. You may call it crappified formatting all you want, at least it is both consistent and something none of us would have to spend time on anymore caring about. You'll get used to it. Or not. André From rjvbertin at gmail.com Fri Mar 18 19:25:06 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 18 Mar 2016 19:25:06 +0100 Subject: [Development] tarball fetches from code.qt.io? References: <2000886.r6WD1beTJ9@patux> <1856371.zXPc59Bamk@tjmaciei-mobl4> <1784737.znae0EUkVN@portia.local> <23615250.ps6K5Qji8Q@tjmaciei-mobl4> <2265755.l1Kp7gGy0M@portia.local> <20160318141012.GA32445@troll08.it.local> Message-ID: <7347780.CP7BdC7Lnk@portia.local> Oswald Buddenhagen wrote: > On Fri, Mar 18, 2016 at 12:54:25PM +0100, René J. V. Bertin wrote: >> Is that correct? Trying this currently fails because at some point headers >> are not found that are expected in a QtWebkit framework: >> > that means that the packagers failed to run syncqt. So, building qtwebkit using qmake 5.6.0 I get In file included from work/qtwebkit-opensource- src-5.6.0/Source/JavaScriptCore/runtime/JSGlobalObject.cpp:72: work/qtwebkit-opensource- src-5.6.0/Source/JavaScriptCore/API/ObjCCallbackFunction.h:32:9: fatal error: 'JavaScriptCore/JSCallbackFunction.h' file not found #import ^ 1 error generated. I must add I'm running a shadow build, i.e. in a build directory parallel to qtwebkit-opensource-src-5.6.0 . Related? R. From sergio.martins at kdab.com Fri Mar 18 18:59:30 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Fri, 18 Mar 2016 18:59:30 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <3198644.MSAbKBEonO@42> References: <56EA952A.1000300@familiesomers.nl> <3198644.MSAbKBEonO@42> Message-ID: <2062199.xijucalWWQ@desktop-ga45d22> (snip) On Friday, March 18, 2016 08:48:52 AM Jedrzej Nowacki wrote: > So I think, that we should not discuss what is better qdoc or md. The real > discussion is about tooling, what is the best tool to sanitize Qt code. This thread is derailing. Kai wants to move a few wiki documents to git, therefore qdoc vs md *is* ontopic, while tooling is not. With or without clang-format you'll always have these documents, because you can't automate barely anything from https://wiki.qt.io/Coding_Conventions and maybe only 50% And https://wiki.qt.io/Qt_Coding_Style Tooling is IMO a separate topic which should not slow down Kai's initiative. Regards, -- Sérgio Martins | sergio.martins 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 Experts From scott at towel42.com Fri Mar 18 20:08:03 2016 From: scott at towel42.com (Scott Aron Bloom) Date: Fri, 18 Mar 2016 19:08:03 +0000 Subject: [Development] QChart 2.0 Message-ID: In working with QChart (which overall I LOVE btw) I have hit some issues.. First, I would love to see/learn the proper way to reload a chart. If I have a chart with a data, but due to user option to set what data is shown, and the user changes an option, I need to recompute the data and then re-setup the graph. However, Im finding that while the initial load is very fast, the reloading of the X and Y series data, is very slow. What is the best way to "reset" the data? Second. I found a crash, that unfortunately, the minimal example "fixes" but the code IMO is still a problem. In LineChartItem::updateGeometry() QChart::ChartType chartType = m_chartType; if (chartType == QChart::ChartTypeUndefined ) chartType = m_series->chart()->chartType(); Its possible, (and admittedly it could be because I am reloading the data wrong see above) that the chartType is undefined AND the m_series->chart is nullptr. Checking for nullptr for m_series->chart() fixes the bug Third- I want to have two sets of "stacked bars" or "bar series" is that possible? Right now the data from the two series gets stacked on opt of each other. I would prefer to see them all presented as "a bar series of bars"? Possible? Fourth - Im trying to modify the "zoom" to only allow X zoom and NOT Y based zoom. Its just the nature of how what my data represents. The only way I have figured out how to do it, is to derive from XYDomain ( which I know is private) and override the zoomIn and Zoom out functions. It works. I can see other types of domains I would want to create, and not being able to derive from the base class or any of the domain classes seem wrong. But it brings up the issue, why are the domains private? Would you consider making them public APIs? Second setDomain currently does NOT exist on the QAbstractSeries class (though it does exist on the prvate implementation class. Is there a reason? Thanks in advance. Scott thanks Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri Mar 18 23:45:22 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 18 Mar 2016 23:45:22 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <4C80D3DE-8056-4EE0-8F6E-B818BF344367@theqtcompany.com> References: <201603181603.12711.marc.mutz@kdab.com> <4C80D3DE-8056-4EE0-8F6E-B818BF344367@theqtcompany.com> Message-ID: <201603182345.23412.marc.mutz@kdab.com> On Friday 18 March 2016 17:05:37 Knoll Lars wrote: > On 18/03/16 16:03, "Development on behalf of Marc Mutz" wrote: > >On Friday 18 March 2016 15:37:40 André Somers wrote: > >> Op 18/03/2016 om 09:24 schreef Rutledge Shawn: > >> > Forcing it on everyone that way will be controversial, because there > >> > is still some leeway in formatting, whereas automation would remove > >> > any chance of personal preference, and probably screw up in some > >> > cases. But we could at least start by adding the clang-format config > >> > file to git so that it’s available for doing this manually. Then in a > >> > few years maybe everybody will get used to it enough, and it can be > >> > refined enough, to become near-universal. > >> > >> That's the point: remove the personal preference. Or, make it > >> irrelevant. You can format your own code localy on your own system > >> however you like. As soon as it gets integrated, it will formatted > >> following whatever the standard is anyway. > >> > >> So no, I do not think there should be leeway for personal differences > >> here. Code formatting matters for readability, but it doesn't merrit > >> long discussions or wasting time fixing -1's because of wrongly placed > >> spaces. If the formatting needs improvement, improve the script doing > >> the work, don't do it manually. > > > >Amen. > > Fully agree as well. So how do we get to some tool that we can use for the > purpose? Let's start with Morton's config file and ask people to use git-clang-format before submitting? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Sat Mar 19 01:31:12 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 19 Mar 2016 01:31:12 +0100 Subject: [Development] Qt Coding Guidelines In-Reply-To: <201603182345.23412.marc.mutz@kdab.com> References: <4C80D3DE-8056-4EE0-8F6E-B818BF344367@theqtcompany.com> <201603182345.23412.marc.mutz@kdab.com> Message-ID: <201603190131.12642.marc.mutz@kdab.com> On Friday 18 March 2016 23:45:22 Marc Mutz wrote: > On Friday 18 March 2016 17:05:37 Knoll Lars wrote: > > On 18/03/16 16:03, "Development on behalf of Marc Mutz" > bounces+lars.knoll=theqtcompany.com at qt-project.org on behalf of > > marc.mutz at kdab.com> wrote: > > >On Friday 18 March 2016 15:37:40 André Somers wrote: > > >> Op 18/03/2016 om 09:24 schreef Rutledge Shawn: > > >> > Forcing it on everyone that way will be controversial, because there > > >> > is still some leeway in formatting, whereas automation would remove > > >> > any chance of personal preference, and probably screw up in some > > >> > cases. But we could at least start by adding the clang-format > > >> > config file to git so that it’s available for doing this manually. > > >> > Then in a few years maybe everybody will get used to it enough, and > > >> > it can be refined enough, to become near-universal. > > >> > > >> That's the point: remove the personal preference. Or, make it > > >> irrelevant. You can format your own code localy on your own system > > >> however you like. As soon as it gets integrated, it will formatted > > >> following whatever the standard is anyway. > > >> > > >> So no, I do not think there should be leeway for personal differences > > >> here. Code formatting matters for readability, but it doesn't merrit > > >> long discussions or wasting time fixing -1's because of wrongly placed > > >> spaces. If the formatting needs improvement, improve the script doing > > >> the work, don't do it manually. > > > > > >Amen. > > > > Fully agree as well. So how do we get to some tool that we can use for > > the purpose? > > Let's start with Morton's config file and ask people to use > git-clang-format before submitting? To counter objections raised in PM: Of course, this would be an as-if rule: if you manually format your code the way clang-format would had you run it, there's no point in actually running it. As for keeping clang around: moc, qdoc and QtC are being ported to clang. At some point, it will be a build requirement, and possibly bundled with Qt (shudder), so it will not be an additional dependency. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From rjvbertin at gmail.com Sat Mar 19 09:58:34 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 19 Mar 2016 09:58:34 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <863471457289949@web19j.yandex.ru> Message-ID: <1710566.s11deKyAXW@patux.local> Konstantin Tokarev wrote: > > > 06.03.2016, 21:40, "Dmitry Shachnev" : >> Hi all, >> >> I am currently packaging Qt 5.6 release candidate for Debian and I have >> encountered some problems with QtWebKit. >> >> 1. Looks like the tarballs were build without calling syncqt. That issue was >> easy to work-around and we are now calling syncqt before the build. However >> it would be nice to have the final tarballs built properly. Second that! Can you please post the correct way to invoke syncqt? The incantations I tried didn't change my errors : Source/WebKit/qt/WidgetSupport/QtFallbackWebPopup.cpp:29: Source/WebKit/qt/WidgetApi/qgraphicswebview.h:23:10: fatal error: 'QtWebKit/qwebkitglobal.h' file not found #include ^ 1 error generated. make[2]: *** [.obj/WebKit/qt/WidgetApi/qwebinspector.o] Error 1 According to Thiago (20151203): > Because we decided not to. We should not even have created the 5.6 branch on > that repository, because there will be no 5.6.0 release. The changes that > landed on that branch will remain forever unreleased. > > Instead, you should build this: > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.zip > http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.tar.gz Is that still "official"? How does one build this package against Qt 5.6.0 (preferably calling qmake and make rather than using the build script)? Thanks, René From aj at elane2k.com Sat Mar 19 11:53:26 2016 From: aj at elane2k.com (=?UTF-8?Q?Adrian_J=c3=a4kel?=) Date: Sat, 19 Mar 2016 11:53:26 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <1710566.s11deKyAXW@patux.local> References: <20160306184038.GA1823@mitya57.me> <863471457289949@web19j.yandex.ru> <1710566.s11deKyAXW@patux.local> Message-ID: <56ED2FA6.8040807@elane2k.com> Just wanted to second (third?) that. I tried to adapt the webkit package for mxe to Qt 5.6 but ran into the known errors. Which is the "official" source package we are about to use when building webkit for/against Qt 5.6? Regards, Adrian Am 19.03.2016 um 09:58 schrieb René J. V. Bertin: > Konstantin Tokarev wrote: > >> >> 06.03.2016, 21:40, "Dmitry Shachnev" : >>> Hi all, >>> >>> I am currently packaging Qt 5.6 release candidate for Debian and I have >>> encountered some problems with QtWebKit. >>> >>> 1. Looks like the tarballs were build without calling syncqt. That issue was >>> easy to work-around and we are now calling syncqt before the build. However >>> it would be nice to have the final tarballs built properly. > Second that! > > Can you please post the correct way to invoke syncqt? The incantations I tried > didn't change my errors : > > Source/WebKit/qt/WidgetSupport/QtFallbackWebPopup.cpp:29: > Source/WebKit/qt/WidgetApi/qgraphicswebview.h:23:10: fatal error: > 'QtWebKit/qwebkitglobal.h' file not found > #include > ^ > 1 error generated. > make[2]: *** [.obj/WebKit/qt/WidgetApi/qwebinspector.o] Error 1 > > > According to Thiago (20151203): >> Because we decided not to. We should not even have created the 5.6 branch on >> that repository, because there will be no 5.6.0 release. The changes that >> landed on that branch will remain forever unreleased. >> >> Instead, you should build this: >> http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.zip >> http://download.qt.io/official_releases/qt/5.5/5.5.1/submodules/qtwebkit-opensource-src-5.5.1.tar.gz > Is that still "official"? How does one build this package against Qt 5.6.0 > (preferably calling qmake and make rather than using the build script)? > > Thanks, > René > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Sat Mar 19 12:50:26 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 19 Mar 2016 12:50:26 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? In-Reply-To: <2452149.EIisSZMbR1@desktop-ga45d22> References: <1466246.T2YiNlAlqL@portia.local> <2068458.X1XyrHk62x@portia.local> <2452149.EIisSZMbR1@desktop-ga45d22> Message-ID: <42924179.yrlI9tVzgi@patux> On Friday March 18 2016 14:15:32 Sergio Martins wrote: >Where was --fontengine=freetype planed, or where did you see it would work ? My bad, given the lack of information I had no previous knowledge to infer the argument sequence that does work. >To get parameters passed to QCocoaIntegration::QCocoaIntegration(), you should >use -platform cocoa:fontengine=freetype, which I haven't tried, but similar >works for me on Windows. Indeed that works. What about fontconfig, is that library used on OS X when Qt is configured with -fontconfig? R. From denis.shienkov at gmail.com Sat Mar 19 13:25:17 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sat, 19 Mar 2016 15:25:17 +0300 Subject: [Development] [QtMultimedia] The customvideosurface/customvideowidget example is very slow Message-ID: <56ED452D.60205@gmail.com> Hi developers, I use Qt 5.6.0 on Windowd (with DS plugin). I faced with the problem that the example: qtmultimedia\examples\multimediawidgets\customvideosurface\customvideowidget\ is very-very-very slow. For example if I play any video file, then my CPU loading is 40%, and I see that the video is displayed jerkily, and if I want to drag the window by the mouse, then it happens also jerkily. I suspect that it happens due to there are not used the OpenGL rendering (yes?)... Because if I use the QVideoWidget, I see that my CPU load is 0%, and all fine. Or, maybe the internal QtMultimedia's implementation has a bug when is used the custom QAbstractVideoSurface (instead of QVideoWidget) to show the video content... So, my question is: is there are any tricks or examples how to implement the high-perfomanced video application with the QAbstractVideoSurface ? BR, Denis From thiago.macieira at intel.com Sat Mar 19 13:27:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 19 Mar 2016 05:27:38 -0700 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <1710566.s11deKyAXW@patux.local> References: <20160306184038.GA1823@mitya57.me> <863471457289949@web19j.yandex.ru> <1710566.s11deKyAXW@patux.local> Message-ID: <6662734.fBvtamcyqx@tjmaciei-mobl4> On sábado, 19 de março de 2016 09:58:34 PDT René J. V. Bertin wrote: > Can you please post the correct way to invoke syncqt? The incantations I > tried didn't change my errors : mkdir .git; qmake -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Sat Mar 19 13:50:54 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 19 Mar 2016 13:50:54 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <863471457289949@web19j.yandex.ru> <1710566.s11deKyAXW@patux.local> <6662734.fBvtamcyqx@tjmaciei-mobl4> Message-ID: <2895616.hELZig6gvc@patux.local> Thiago Macieira wrote: > On sábado, 19 de março de 2016 09:58:34 PDT René J. V. Bertin wrote: >> Can you please post the correct way to invoke syncqt? The incantations I >> tried didn't change my errors : > > mkdir .git; qmake Should I understand that when using the qtwebkit 5.6.0 tarball from community_releases : - it is not necessary to run syncqt (knowing there's no include directory in the tarball) - the presence of a .git directory makes a difference even when empty? Answer: apparently syncqt been rolled into qmake, to be triggered by the presence of a .git directory. That's nice. We'll see if the build goes through now.. Out of curiosity: what happens with 3rd party projects with a .git directory, how does qmake know when not to run syncqt? R. From sergio.martins at kdab.com Sat Mar 19 13:20:57 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Sat, 19 Mar 2016 13:20:57 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? In-Reply-To: <42924179.yrlI9tVzgi@patux> References: <1466246.T2YiNlAlqL@portia.local> <2452149.EIisSZMbR1@desktop-ga45d22> <42924179.yrlI9tVzgi@patux> Message-ID: <2360567.IoMSICyGHq@desktop-ga45d22> On Saturday, March 19, 2016 12:50:26 PM René J.V. Bertin wrote: > What about fontconfig, is that library used on OS X when Qt is configured > with -fontconfig? I don't think so, see QCocoaIntegration::fontDatabase(), it returns QCoreTextFontDatabase inconditionally. Doesn't seem like much work to support fontconfig though. Regards, -- Sérgio Martins | sergio.martins 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 Experts From rjvbertin at gmail.com Sat Mar 19 17:20:57 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 19 Mar 2016 17:20:57 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? References: <1466246.T2YiNlAlqL@portia.local> <2452149.EIisSZMbR1@desktop-ga45d22> <42924179.yrlI9tVzgi@patux> <2360567.IoMSICyGHq@desktop-ga45d22> Message-ID: <1833132.xgC4GQ2zSA@patux.local> Sergio Martins wrote: > I don't think so, see QCocoaIntegration::fontDatabase(), it returns > QCoreTextFontDatabase inconditionally. > > Doesn't seem like much work to support fontconfig though. And it could make sense if the goal is indeed to provide identical font rendering across platforms, even more if the goal (of certain applications I've seen cited in this context) is to get the best possible rendering quality. I don't have any direct experience using the fontconfig API, so I won't be playing with this myself anytime soon I fear. R. From rjvbertin at gmail.com Sat Mar 19 17:29:36 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 19 Mar 2016 17:29:36 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <863471457289949@web19j.yandex.ru> <1710566.s11deKyAXW@patux.local> <6662734.fBvtamcyqx@tjmaciei-mobl4> Message-ID: <97257376.dh9IcJYvef@patux.local> Thiago Macieira wrote: > mkdir .git; qmake > Followed by make -j4 at least I now get a different error (about 37 min in, at a stage that used to build AFAICT): Platform/CoreIPC/Connection.cpp:29:10: fatal error: 'WebCore/RunLoop.h' file not found #include ^ 1 error generated. Has qtwebkit been test-built on OS X at all? R. From steveire at gmail.com Sat Mar 19 19:02:08 2016 From: steveire at gmail.com (Stephen Kelly) Date: Sat, 19 Mar 2016 19:02:08 +0100 Subject: [Development] What qtbase looks like with extensive use of auto Message-ID: Hi, In case you missed it, I wrote an auto-modernizer https://steveire.wordpress.com/2016/03/19/aaargh It is not quite AAA, as it doesn't convert QString s; into auto s = QString(); I used it to port qtbase to an extensive use of auto: https://github.com/steveire/qtbase/commits/aaa This isn't something I want to push for Qt to apply, but it's something I did and you might find the outcome interesting. If you think Qt should use auto not-at-all, not-a-lot, or almost-always, I'm sure you'll find lots of reasons in the commits to support your position. Thanks, Steve. From thiago.macieira at intel.com Sat Mar 19 18:37:21 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 19 Mar 2016 12:37:21 -0500 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <2895616.hELZig6gvc@patux.local> References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <2895616.hELZig6gvc@patux.local> Message-ID: <1723238.3Mm95X17ag@tjmaciei-mobl4> On sábado, 19 de março de 2016 13:50:54 CDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > On sábado, 19 de março de 2016 09:58:34 PDT René J. V. Bertin wrote: > >> Can you please post the correct way to invoke syncqt? The incantations I > > > >> tried didn't change my errors : > > mkdir .git; qmake > > Should I understand that when using the qtwebkit 5.6.0 tarball from > community_releases : > > - it is not necessary to run syncqt (knowing there's no include directory in > the tarball) It should not be necessary, if the tarball were correct. The includes should not be missing. As a workaround, you need to run syncqt. > - the presence of a .git directory makes a difference even when empty? Yes. That triggers the buildsystem running syncqt for you. > Answer: apparently syncqt been rolled into qmake, to be triggered by the > presence of a .git directory. That's nice. We'll see if the build goes > through now.. It's been a year or two already... > Out of curiosity: what happens with 3rd party projects with a .git > directory, how does qmake know when not to run syncqt? If those projects do load(qt_module), they had better follow the Qt Project repository rules. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Sat Mar 19 22:24:58 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 19 Mar 2016 22:24:58 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <2895616.hELZig6gvc@patux.local> <1723238.3Mm95X17ag@tjmaciei-mobl4> Message-ID: <2090269.zF8DAqrvpv@portia.local> Thiago Macieira wrote: > It should not be necessary, if the tarball were correct. The includes should > not be missing. Yeah, and I guess errors like the one I keep getting (following your instructions) shouldn't occur either... Platform/CoreIPC/Connection.cpp:29:10: fatal error: 'WebCore/RunLoop.h' file not found #include ^ 1 error generated. R. From annulen at yandex.ru Sat Mar 19 22:34:41 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 20 Mar 2016 00:34:41 +0300 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <2090269.zF8DAqrvpv@portia.local> References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <2895616.hELZig6gvc@patux.local> <1723238.3Mm95X17ag@tjmaciei-mobl4> <2090269.zF8DAqrvpv@portia.local> Message-ID: <1995111458423281@web13m.yandex.ru> 20.03.2016, 00:25, "René J. V. Bertin" : > Thiago Macieira wrote: > >>  It should not be necessary, if the tarball were correct. The includes should >>  not be missing. > > Yeah, and I guess errors like the one I keep getting (following your > instructions) shouldn't occur either... > > Platform/CoreIPC/Connection.cpp:29:10: fatal error: 'WebCore/RunLoop.h' file > not > found > #include >          ^ > 1 error generated. Look in build log for generate-forwarding-headers.pl invocation. Does it produce any errors? -- Regards, Konstantin From kde at carewolf.com Sat Mar 19 23:54:50 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 19 Mar 2016 23:54:50 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <97257376.dh9IcJYvef@patux.local> References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <97257376.dh9IcJYvef@patux.local> Message-ID: <201603192354.50579.kde@carewolf.com> On Saturday 19 March 2016, René J. V. Bertin wrote: > Thiago Macieira wrote: > > mkdir .git; qmake > > Followed by make -j4 at least I now get a different error (about 37 min in, > at a stage that used to build AFAICT): > > Platform/CoreIPC/Connection.cpp:29:10: fatal error: 'WebCore/RunLoop.h' > file not found > #include > ^ > 1 error generated. > > > Has qtwebkit been test-built on OS X at all? > Yes, it is automatically build on several OS X versions in different configurations as part of the CI system, but that is from git, not from the source packages. I don't think anyone tested the final packages of qtwebkit. Regards `Allan From rjvbertin at gmail.com Sun Mar 20 10:09:26 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 20 Mar 2016 10:09:26 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <97257376.dh9IcJYvef@patux.local> <201603192354.50579.kde@carewolf.com> Message-ID: <8484973.YNcBDJ6xYq@patux.local> Allan Sandfeld Jensen wrote: >> Has qtwebkit been test-built on OS X at all? >> > Yes, it is automatically build on several OS X versions in different > configurations as part of the CI system, but that is from git, not from the > source packages. I don't think anyone tested the final packages of qtwebkit. So it might even be that if I check out the repo as "qtwebkit" in the monolithic source tree, qtwebkit will build just fine as it always did? Thanks, René From rjvbertin at gmail.com Sun Mar 20 10:31:13 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 20 Mar 2016 10:31:13 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <2895616.hELZig6gvc@patux.local> <1723238.3Mm95X17ag@tjmaciei-mobl4> <2090269.zF8DAqrvpv@portia.local> <1995111458423281@web13m.yandex.ru> Message-ID: <1613536.Z5Gc7QXsoK@patux.local> Konstantin Tokarev wrote: >> #include >> ^ >> 1 error generated. > > Look in build log for generate-forwarding-headers.pl invocation. Does it > produce any errors? I don't think I noticed any errors in the output from syncqt, but I'll double check. I'm not seeing this kind of errors on headers that appear to be Mac-specific in any way. The way they're included does correspond to the OS X framework set-up; here, RunLoop.h could be a public header of a WebCore framework (WebCore.framework/Headers/RunLoop.h). It doesn't seem impossible that syncqt.pl somehow takes that into consideration, which would be a valid assumption for dependencies that are supposed to be installed already. BTW: no, I'm not trying to build qtwebkit 5.6.0 with an older version already installed in the target location. Ultimately I'd want that to work too (but it always did for qtwebkit so, first things first). R. From rjvbertin at gmail.com Sun Mar 20 11:13:23 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sun, 20 Mar 2016 11:13:23 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <1995111458423281@web13m.yandex.ru> References: <20160306184038.GA1823@mitya57.me> <2090269.zF8DAqrvpv@portia.local> <1995111458423281@web13m.yandex.ru> Message-ID: <9815555.fpN1KClF9a@portia.local> > Look in build log for generate-forwarding-headers.pl invocation. Does it produce any errors? > > Does this look OK? %> (cd qt-everywhere-opensource-src-5.6.0/qtwebkit ; /opt/local/libexec/qt5/bin/syncqt.pl Source -version 5.6.0) = /Users/bertin/work/src/new/Qt/qt-everywhere-opensource-src-5.6.0/qtwebkit/Source = /Users/bertin/work/src/new/Qt/qt-everywhere-opensource-src-5.6.0/qtwebkit QtWebKit: created fwd-include header(s) for /WebKit/qt/Api/ { qhttpheader_p.h (1), qwebdatabase.h (2), qwebdatabase_p.h (1), qwebelement.h (3), qwebelement_p.h (1), qwebhistory.h (3), qwebhistory_p.h (1), qwebhistoryinterface.h (2), qwebkitglobal.h (1), qwebkitplatformplugin.h (10), qwebplugindatabase_p.h (1), qwebpluginfactory.h (2), qwebscriptworld.h (1), qwebscriptworld_p.h (1), qwebsecurityorigin.h (2), qwebsecurityorigin_p.h (1), qwebsettings.h (2) } QtWebKit: created fwd-include header(s) for /WebKit2/UIProcess/API/qt/ { qquicknetworkreply_p.h (1), qquicknetworkrequest_p.h (1), qquickurlschemedelegate_p.h (1), qquickwebpage_p.h (1), qquickwebpage_p_p.h (1), qquickwebview_p.h (1), qquickwebview_p_p.h (1), qtwebsecurityorigin_p.h (1), qwebchannelwebkittransport_p.h (1), qwebdownloaditem_p.h (1), qwebdownloaditem_p_p.h (1), qwebiconimageprovider_p.h (1), qwebkittest_p.h (1), qwebloadrequest_p.h (1), qwebnavigationhistory_p.h (1), qwebnavigationhistory_p_p.h (1), qwebnavigationrequest_p.h (1), qwebpermissionrequest_p.h (1), qwebpreferences_p.h (1), qwebpreferences_p_p.h (1) } QtWebKit: created fwd-include header(s) for /WebKit2/UIProcess/API/qt/raw/ { qrawwebview_p.h (1), qrawwebview_p_p.h (1) } QtWebKit: created fwd-include header(s) for /WebKit2/UIProcess/API/qt/tests/ { bytearraytestdata.h (1), testwindow.h (1), util.h (1) } QtWebKit: created version header QtWebKit: created master header QtWebKit: created headers.pri file QtWebKitWidgets: created fwd-include header(s) for /WebKit/qt/WidgetApi/ { qgraphicswebview.h (2), qwebframe.h (3), qwebframe_p.h (1), qwebinspector.h (2), qwebinspector_p.h (1), qwebpage.h (2), qwebpage_p.h (1), qwebview.h (2), qwebviewaccessible_p.h (1) } QtWebKitWidgets: created version header QtWebKitWidgets: created master header QtWebKitWidgets: created headers.pri file (that's in a check-out from git, commit 81f43efbb2112b693b21d8f95cd627e9fd1032b9) R -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Sun Mar 20 12:13:11 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 20 Mar 2016 14:13:11 +0300 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <9815555.fpN1KClF9a@portia.local> References: <20160306184038.GA1823@mitya57.me> <2090269.zF8DAqrvpv@portia.local> <1995111458423281@web13m.yandex.ru> <9815555.fpN1KClF9a@portia.local> Message-ID: <1383721458472391@web28o.yandex.ru> 20.03.2016, 13:13, "René J.V. Bertin" : >> Look in build log for generate-forwarding-headers.pl invocation. Does it produce any errors? > >> > >> > > Does this look OK? It's output from syncqt, and I've asked you about generate-forwarding-headers.pl > > %> (cd qt-everywhere-opensource-src-5.6.0/qtwebkit ; /opt/local/libexec/qt5/bin/syncqt.pl Source -version 5.6.0) > > = /Users/bertin/work/src/new/Qt/qt-everywhere-opensource-src-5.6.0/qtwebkit/Source > > = /Users/bertin/work/src/new/Qt/qt-everywhere-opensource-src-5.6.0/qtwebkit > > QtWebKit: created fwd-include header(s) for /WebKit/qt/Api/ { qhttpheader_p.h (1), qwebdatabase.h (2), qwebdatabase_p.h (1), qwebelement.h (3), qwebelement_p.h (1), qwebhistory.h (3), qwebhistory_p.h (1), qwebhistoryinterface.h (2), qwebkitglobal.h (1), qwebkitplatformplugin.h (10), qwebplugindatabase_p.h (1), qwebpluginfactory.h (2), qwebscriptworld.h (1), qwebscriptworld_p.h (1), qwebsecurityorigin.h (2), qwebsecurityorigin_p.h (1), qwebsettings.h (2) } > > QtWebKit: created fwd-include header(s) for /WebKit2/UIProcess/API/qt/ { qquicknetworkreply_p.h (1), qquicknetworkrequest_p.h (1), qquickurlschemedelegate_p.h (1), qquickwebpage_p.h (1), qquickwebpage_p_p.h (1), qquickwebview_p.h (1), qquickwebview_p_p.h (1), qtwebsecurityorigin_p.h (1), qwebchannelwebkittransport_p.h (1), qwebdownloaditem_p.h (1), qwebdownloaditem_p_p.h (1), qwebiconimageprovider_p.h (1), qwebkittest_p.h (1), qwebloadrequest_p.h (1), qwebnavigationhistory_p.h (1), qwebnavigationhistory_p_p.h (1), qwebnavigationrequest_p.h (1), qwebpermissionrequest_p.h (1), qwebpreferences_p.h (1), qwebpreferences_p_p.h (1) } > > QtWebKit: created fwd-include header(s) for /WebKit2/UIProcess/API/qt/raw/ { qrawwebview_p.h (1), qrawwebview_p_p.h (1) } > > QtWebKit: created fwd-include header(s) for /WebKit2/UIProcess/API/qt/tests/ { bytearraytestdata.h (1), testwindow.h (1), util.h (1) } > > QtWebKit: created version header > > QtWebKit: created master header > > QtWebKit: created headers.pri file > > QtWebKitWidgets: created fwd-include header(s) for /WebKit/qt/WidgetApi/ { qgraphicswebview.h (2), qwebframe.h (3), qwebframe_p.h (1), qwebinspector.h (2), qwebinspector_p.h (1), qwebpage.h (2), qwebpage_p.h (1), qwebview.h (2), qwebviewaccessible_p.h (1) } > > QtWebKitWidgets: created version header > > QtWebKitWidgets: created master header > > QtWebKitWidgets: created headers.pri file > > (that's in a check-out from git, commit 81f43efbb2112b693b21d8f95cd627e9fd1032b9) > > R -- Regards, Konstantin From rjvbertin at gmail.com Sun Mar 20 12:48:08 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 20 Mar 2016 12:48:08 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <2090269.zF8DAqrvpv@portia.local> <1995111458423281@web13m.yandex.ru> <9815555.fpN1KClF9a@portia.local> <1383721458472391@web28o.yandex.ru> Message-ID: <38473332.kWL8iRUYHX@portia.local> Konstantin Tokarev wrote: > > > 20.03.2016, 13:13, "René J.V. Bertin" : >>> Look in build log for generate-forwarding-headers.pl invocation. Does it >>> produce any errors? >> >>> >> >>> >> >> Does this look OK? > > > It's output from syncqt, and I've asked you about > generate-forwarding-headers.pl But you didn't say that's a script which is NOT called by syncqt, and syncqt does output "created fwd-include header(s)". Anyway, a legacy-style monolithic *shadow* build with qtwebkit alongside the other Qt5 components just completed OK so at least now we know that this is still possible. R From annulen at yandex.ru Sun Mar 20 13:01:01 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 20 Mar 2016 15:01:01 +0300 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <38473332.kWL8iRUYHX@portia.local> References: <20160306184038.GA1823@mitya57.me> <2090269.zF8DAqrvpv@portia.local> <1995111458423281@web13m.yandex.ru> <9815555.fpN1KClF9a@portia.local> <1383721458472391@web28o.yandex.ru> <38473332.kWL8iRUYHX@portia.local> Message-ID: <376581458475261@web21m.yandex.ru> 20.03.2016, 14:48, "René J. V. Bertin" : > Konstantin Tokarev wrote: > >>  20.03.2016, 13:13, "René J.V. Bertin" : >>>>  Look in build log for generate-forwarding-headers.pl invocation. Does it >>>>  produce any errors? >>> >>>> >>> >>>> >>> >>>  Does this look OK? >> >>  It's output from syncqt, and I've asked you about >>  generate-forwarding-headers.pl > > But you didn't say that's a script which is NOT called by syncqt, and syncqt > does output "created fwd-include header(s)". > > Anyway, a legacy-style monolithic *shadow* build with qtwebkit alongside the > other Qt5 components just completed OK so at least now we know that this is > still possible. Do I understand correctly that you were trying to build QtWebKit in non-shadow way? This is not supported. -- Regards, Konstantin From sean.harmer at kdab.com Sun Mar 20 13:07:01 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Sun, 20 Mar 2016 12:07:01 +0000 Subject: [Development] MSVC2012 in CI Message-ID: Hi, Can MSVC 2012 configurations be removed from the CI please? My understanding is that this compiler was only kept around to support Windows EC but that this is now removed from 5.7. In particular this compiler is a blocker to using a using declaration such as: template using QNodeCreatedChangePtr = QSharedPointer>; Kind regards, Sean From rjvbertin at gmail.com Sun Mar 20 14:10:43 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sun, 20 Mar 2016 14:10:43 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <376581458475261@web21m.yandex.ru> References: <20160306184038.GA1823@mitya57.me> <38473332.kWL8iRUYHX@portia.local> <376581458475261@web21m.yandex.ru> Message-ID: <1608251.UfflzlCZiD@patux> On Sunday March 20 2016 15:01:01 Konstantin Tokarev wrote: >> Anyway, a legacy-style monolithic *shadow* build with qtwebkit alongside the >> other Qt5 components just completed OK so at least now we know that this is >> still possible. > >Do I understand correctly that you were trying to build QtWebKit in non-shadow way? >This is not supported. Until now both approaches failed for me. However, from what Thiago showed me yesterday one can (probably) infer that QtWebKit is supposed to be built inside its source tree - that's how qmake can see the .git directory and invoke syncqt as it should be invoked. But indeed the standalone in-tree build just failed again for me, using the same git checkout :-/ R. From rjvbertin at gmail.com Sun Mar 20 16:31:42 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 20 Mar 2016 16:31:42 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <38473332.kWL8iRUYHX@portia.local> <376581458475261@web21m.yandex.ru> <1608251.UfflzlCZiD@patux> Message-ID: <2537620.Ob6bVDynMi@patux.local> René J.V. Bertin wrote: > On Sunday March 20 2016 15:01:01 Konstantin Tokarev wrote: >>Do I understand correctly that you were trying to build QtWebKit in non-shadow >>way? This is not supported. > But indeed the standalone in-tree build just failed again for me, using the > same git checkout :-/ And so did the shadow build: qtwebkit-opensource- src-5.6.0/Source/WebKit2/Platform/CoreIPC/Connection.cpp:29:10: fatal error: 'WebCore/RunLoop.h' file not found #include ^ 1 error generated. So how am I supposed to invoke generate-forwarding-headers.pl ? Am I right that I should find this command name in at least one Makefile, or is it invoked by qmake when included the DerivedSources.pri files in which I traced the string? R From annulen at yandex.ru Sun Mar 20 16:50:28 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 20 Mar 2016 18:50:28 +0300 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <2537620.Ob6bVDynMi@patux.local> References: <20160306184038.GA1823@mitya57.me> <38473332.kWL8iRUYHX@portia.local> <376581458475261@web21m.yandex.ru> <1608251.UfflzlCZiD@patux> <2537620.Ob6bVDynMi@patux.local> Message-ID: <2017801458489028@web25j.yandex.ru> 20.03.2016, 18:32, "René J. V. Bertin" : > René J.V. Bertin wrote: > >>  On Sunday March 20 2016 15:01:01 Konstantin Tokarev wrote: > >>> Do I understand correctly that you were trying to build QtWebKit in non-shadow >>> way? This is not supported. > >>  But indeed the standalone in-tree build just failed again for me, using the >>  same git checkout :-/ > > And so did the shadow build: > > qtwebkit-opensource- > src-5.6.0/Source/WebKit2/Platform/CoreIPC/Connection.cpp:29:10: fatal error: > 'WebCore/RunLoop.h' file not found > #include >          ^ > 1 error generated. > > So how am I supposed to invoke generate-forwarding-headers.pl ? No, it should be execute as a part of build process > Am I right that > I should find this command name in at least one Makefile ./Source/WebKit2/Makefile.WebKit2.DerivedSources in build dir , or is it invoked by > qmake when included the DerivedSources.pri files in which I traced the string? > > R > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From rjvbertin at gmail.com Sun Mar 20 17:55:23 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 20 Mar 2016 17:55:23 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <38473332.kWL8iRUYHX@portia.local> <376581458475261@web21m.yandex.ru> <1608251.UfflzlCZiD@patux> <2537620.Ob6bVDynMi@patux.local> <2017801458489028@web25j.yandex.ru> Message-ID: <5934357.xNsIlKhuDS@patux.local> Konstantin Tokarev wrote: >> So how am I supposed to invoke generate-forwarding-headers.pl ? > > No, it should be execute as a part of build process Apparently the one from Makefile.WebKit2.DerivedSources hasn't been executed at the time the error occurs. Nor has the one from WebCore, btw. When I build the fwheader_generator target from each of those Makefiles manually I don't get any errors. And after that the build continues beyond the previously cited error, only to halt on qtwebkit-opensource- src-5.6.0/Source/WebKit2/WebProcess/InjectedBundle/DOM/InjectedBundleNodeHandle.cpp:42:10: fatal error: 'WebCore/HTMLNames.h' file not found #include ^ 1 error generated. Why on earth does this have to be so difficult, while the way qtwebkit is no longer supposed to be built worked just fine?! From jkt at kde.org Sun Mar 20 18:26:20 2016 From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Sun, 20 Mar 2016 18:26:20 +0100 Subject: [Development] =?iso-8859-1?q?Problems_with_QtWebKit_5=2E6_/_Pleas?= =?iso-8859-1?q?e_do_not_remove_QtWebkit_from_5=2E6_official_binari?= =?iso-8859-1?q?es?= In-Reply-To: <5934357.xNsIlKhuDS@patux.local> References: <20160306184038.GA1823@mitya57.me> <38473332.kWL8iRUYHX@portia.local> <376581458475261@web21m.yandex.ru> <1608251.UfflzlCZiD@patux> <2537620.Ob6bVDynMi@patux.local> <2017801458489028@web25j.yandex.ru> <5934357.xNsIlKhuDS@patux.local> Message-ID: <96470c6c-9dc1-42ac-b0c4-aca1359b4701@kde.org> On Sunday, 20 March 2016 17:55:23 CET, René J. V. Bertin wrote: > Why on earth does this have to be so difficult For the record, this is how my CI system builds its copy of Qt 5.6: git clone https://code.qt.io/qt/qt5.git cd qt5 git checkout ${QT5_TAG:-${QT5_BRANCH}} git submodule update --init ./configure ${DEBUG_RELEASE} -confirm-license -opensource -dbus -xcb -nomake examples -nomake tests -prefix ${PREFIX} make -j12 make install Consulting the list of resulting binaries, it built QtWebKit, but skipped QtWebEngine for some reason :). Anyway, this is just another anecdote that it was actually pretty easy to get QtWebKit from the 5.6 branch (on Linux, though). Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From rjvbertin at gmail.com Sun Mar 20 18:52:16 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 20 Mar 2016 18:52:16 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <38473332.kWL8iRUYHX@portia.local> <376581458475261@web21m.yandex.ru> <1608251.UfflzlCZiD@patux> <2537620.Ob6bVDynMi@patux.local> <2017801458489028@web25j.yandex.ru> <5934357.xNsIlKhuDS@patux.local> <96470c6c-9dc1-42ac-b0c4-aca1359b4701@kde.org> Message-ID: <4827806.mZbR23YGZK@portia.local> Jan Kundrát wrote: > Anyway, this is just another anecdote that it was actually pretty easy to > get QtWebKit from the 5.6 branch (on Linux, though). Great, so if and when I get around to repeating all this on a Linux host it should be easy as cake... Anyway, I've been suspicious at the fact that the WebKit.pro qmake parsing shows that the process picks up the presence of X11 headers on my system (and thus glx). I'm repeating the build that succeeded earlier today (comparable with yours, i.e. qtwebkit alongside qtbase and all the other components). We'll see if it succeeds again, but I can already confirm that this build also picked up the presence of X11. Maybe that confuses the build system somewhere, unless it's invoked from the Makefile created by configure. R From aj at elane2k.com Sun Mar 20 18:59:52 2016 From: aj at elane2k.com (=?UTF-8?Q?Adrian_J=c3=a4kel?=) Date: Sun, 20 Mar 2016 18:59:52 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <1723238.3Mm95X17ag@tjmaciei-mobl4> References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <2895616.hELZig6gvc@patux.local> <1723238.3Mm95X17ag@tjmaciei-mobl4> Message-ID: <56EEE518.1090509@elane2k.com> Out of curiosity and because it has not been said in the discussion afaik: Is it planned to correct the current tarball or at least the next one for the upcoming Qt 5.6.1 ? It seems like an easy fix to me and im wondering why it hasnt been done yet? Or am i missing something? Regards, Adrian Am 19.03.2016 um 18:37 schrieb Thiago Macieira: > It should not be necessary, if the tarball were correct. The includes > should not be missing. As a workaround, you need to run syncqt. From dangelog at gmail.com Sun Mar 20 19:19:11 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Sun, 20 Mar 2016 19:19:11 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <56EEE518.1090509@elane2k.com> References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <2895616.hELZig6gvc@patux.local> <1723238.3Mm95X17ag@tjmaciei-mobl4> <56EEE518.1090509@elane2k.com> Message-ID: On Sun, Mar 20, 2016 at 6:59 PM, Adrian Jäkel wrote: > Out of curiosity and because it has not been said in the discussion afaik: > Is it planned to correct the current tarball or at least the next one for > the upcoming Qt 5.6.1 ? Technically speaking it could also just means getting new tarballs for qtwebkit 5.6.0 (as it's merely a packaging issue; there are no code changes required)... -- Giuseppe D'Angelo From thiago.macieira at intel.com Sun Mar 20 19:28:37 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 20 Mar 2016 18:28:37 +0000 Subject: [Development] MSVC2012 in CI In-Reply-To: References: Message-ID: <7844806.6JuhqCG4NL@tjmaciei-mobl4> On domingo, 20 de março de 2016 12:07:01 GMT Sean Harmer wrote: > Hi, > > Can MSVC 2012 configurations be removed from the CI please? My understanding > is that this compiler was only kept around to support Windows EC but that > this is now removed from 5.7. In particular this compiler is a blocker to > using a using declaration such as: > > template > using QNodeCreatedChangePtr = QSharedPointer>; We haven't yet done a re-evaluation of which C++11 features are allowed in our code without #ifndef. For the moment, template aliases are not permitted. Or, put another way, can someone do that evaluation and post to the list? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Sun Mar 20 20:58:18 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 20 Mar 2016 20:58:18 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <2895616.hELZig6gvc@patux.local> <1723238.3Mm95X17ag@tjmaciei-mobl4> <56EEE518.1090509@elane2k.com> Message-ID: <1886401.QxFHqzDD2L@portia.local> Giuseppe D'Angelo wrote: > Technically speaking it could also just means getting new tarballs for > qtwebkit 5.6.0 (as it's merely a packaging issue; there are no code > changes required)... Maybe to the some of the build system code, if the build issues I'm seeing are the result of something wrong in there and not because I am myself doing something completely wrong. R From rjvbertin at gmail.com Sun Mar 20 22:50:02 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sun, 20 Mar 2016 22:50:02 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <2895616.hELZig6gvc@patux.local> <1723238.3Mm95X17ag@tjmaciei-mobl4> <56EEE518.1090509@elane2k.com> Message-ID: <3112118.DGkOS7pMUx@portia.local> I think I have a lead on my issue, but I don't really know yet how to follow it. As it turns out, the following sequence succeeds: - checkout qtwebkit.git - (cd qtwebkit.git ; syncqt.pl Source -version 5.6.0) - mkdir build ; cd build - qmake ../qtwebkit.git/WebKit.pro - make -j4 The goal is to run this sequence as part of a MacPorts build script ("Portfile"). Portfiles are written in Tcl and run with a specific, restricted environment designed to reduce the likelihood of finding stuff outside the MacPorts prefix that also exists under that prefix. The last 2 commands above were run with basically the same environment, except for a few compiler flags MacPorts adds. The qtwebkit build as part of "monolithic" build I mentioned earlier was run from a Portfile and thus subject to the same environment as the failing standalone builds. I guess I'll have to do some more test builds (@ over 45 min a piece...) and compare full logs if I want to get to the bottom of this. R. From thiago.macieira at intel.com Sun Mar 20 19:29:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 20 Mar 2016 18:29:16 +0000 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <8484973.YNcBDJ6xYq@patux.local> References: <20160306184038.GA1823@mitya57.me> <201603192354.50579.kde@carewolf.com> <8484973.YNcBDJ6xYq@patux.local> Message-ID: <2247260.2adyN4HlgO@tjmaciei-mobl4> On domingo, 20 de março de 2016 10:09:26 GMT René J. V. Bertin wrote: > So it might even be that if I check out the repo as "qtwebkit" in the > monolithic source tree, qtwebkit will build just fine as it always did? Yes, very likely. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at theqtcompany.com Mon Mar 21 08:03:02 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Mon, 21 Mar 2016 07:03:02 +0000 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: <56EEE518.1090509@elane2k.com> References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <2895616.hELZig6gvc@patux.local> <1723238.3Mm95X17ag@tjmaciei-mobl4> <56EEE518.1090509@elane2k.com> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Adrian Jakel > Sent: Sunday, March 20, 2016 7:00 PM > To: development at qt-project.org > Subject: Re: [Development] Problems with QtWebKit 5.6 / Please do not > remove QtWebkit from 5.6 official binaries > > Out of curiosity and because it has not been said in the discussion > afaik: Is it planned to correct the current tarball or at least the next one for > the upcoming Qt 5.6.1 ? It seems like an easy fix to me and im wondering > why it hasnt been done yet? Or am i missing something? I guess we'll try to fix it. Could you create a bug report about this? Kai PS: Everyone: Please create bug reports for (serious) issues! A mail to the mailing list isn't a proper replacement ... From sean.harmer at kdab.com Mon Mar 21 10:46:40 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 21 Mar 2016 09:46:40 +0000 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: <7844806.6JuhqCG4NL@tjmaciei-mobl4> References: <7844806.6JuhqCG4NL@tjmaciei-mobl4> Message-ID: <3124472.u1ImAFM2Q1@titan> On Sunday 20 March 2016 18:28:37 Thiago Macieira wrote: > On domingo, 20 de março de 2016 12:07:01 GMT Sean Harmer wrote: > > Hi, > > > > Can MSVC 2012 configurations be removed from the CI please? My > > understanding is that this compiler was only kept around to support > > Windows EC but that this is now removed from 5.7. In particular this > > compiler is a blocker to using a using declaration such as: > > > > template > > using QNodeCreatedChangePtr = QSharedPointer>; > > We haven't yet done a re-evaluation of which C++11 features are allowed in > our code without #ifndef. For the moment, template aliases are not > permitted. > > Or, put another way, can someone do that evaluation and post to the list? Dropping MSVC2012 as per http://lists.qt-project.org/pipermail/development/2016-March/025129.html would remove the block from being able to use template aliases according to https://msdn.microsoft.com/en-us/library/hh567368.aspx I don't have ready access to all the other compilers and versions we support but I think this would allow potential use of: * template aliases * raw string literals * delegating ctors Marc, you likely know compiler limitations much better than I do, do you have any inputs on this please? Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions From marc.mutz at kdab.com Mon Mar 21 11:57:53 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 21 Mar 2016 11:57:53 +0100 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: <3124472.u1ImAFM2Q1@titan> References: <7844806.6JuhqCG4NL@tjmaciei-mobl4> <3124472.u1ImAFM2Q1@titan> Message-ID: <201603211157.53715.marc.mutz@kdab.com> On Monday 21 March 2016 10:46:40 Sean Harmer wrote: > On Sunday 20 March 2016 18:28:37 Thiago Macieira wrote: > > On domingo, 20 de março de 2016 12:07:01 GMT Sean Harmer wrote: > > > Hi, > > > > > > Can MSVC 2012 configurations be removed from the CI please? My > > > understanding is that this compiler was only kept around to support > > > Windows EC but that this is now removed from 5.7. In particular this > > > compiler is a blocker to using a using declaration such as: > > > > > > template > > > using QNodeCreatedChangePtr = QSharedPointer>; > > > > We haven't yet done a re-evaluation of which C++11 features are allowed > > in our code without #ifndef. For the moment, template aliases are not > > permitted. > > > > Or, put another way, can someone do that evaluation and post to the list? > > Dropping MSVC2012 as per > > http://lists.qt-project.org/pipermail/development/2016-March/025129.html > > would remove the block from being able to use template aliases according to > > https://msdn.microsoft.com/en-us/library/hh567368.aspx > > I don't have ready access to all the other compilers and versions we > support but I think this would allow potential use of: > > * template aliases > * raw string literals > * delegating ctors > > Marc, you likely know compiler limitations much better than I do, do you > have any inputs on this please? This has been discussed in the context of 5.8 already: Thiago's list of additional features that dropping MSVS 2012 would enable: http://lists.qt-project.org/pipermail/development/2016-February/024902.html And my quick evaluation of each: http://lists.qt-project.org/pipermail/development/2016-February/024910.html I said then and I repeat it now that imho template aliases are not interesting for library development. In particular, I don't think something like > > > template > > > using QNodeCreatedChangePtr = QSharedPointer>; should be part of an API of a library. We have auto to avoid having to type this type. The typedefs just hide the (essential) fact that this is a shared pointer type. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Andre.Poenitz at theqtcompany.com Mon Mar 21 12:07:24 2016 From: Andre.Poenitz at theqtcompany.com (Poenitz Andre) Date: Mon, 21 Mar 2016 11:07:24 +0000 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: <201603211157.53715.marc.mutz@kdab.com> References: <7844806.6JuhqCG4NL@tjmaciei-mobl4> <3124472.u1ImAFM2Q1@titan>,<201603211157.53715.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > I said then and I repeat it now that imho template aliases are not interesting > for library development. In particular, I don't think something like > > > > > template > > > > using QNodeCreatedChangePtr = QSharedPointer>; > > should be part of an API of a library. We have auto to avoid having to type > this type. The typedefs just hide the (essential) fact that this is a shared > pointer type. Do I understand correctly that you argue that the fact that the actual type is a shared pointer is so important that it shall not be hidden by a template alias whereas it would be completely fine to hide everything related to type by using auto? Andre' From marc.mutz at kdab.com Mon Mar 21 12:44:34 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 21 Mar 2016 12:44:34 +0100 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: References: <201603211157.53715.marc.mutz@kdab.com> Message-ID: <201603211244.35124.marc.mutz@kdab.com> On Monday 21 March 2016 12:07:24 Poenitz Andre wrote: > Marc Mutz wrote: > > I said then and I repeat it now that imho template aliases are not > > interesting for library development. In particular, I don't think > > something like > > > > > > > template > > > > > using QNodeCreatedChangePtr = > > > > > QSharedPointer>; > > > > should be part of an API of a library. We have auto to avoid having to > > type this type. The typedefs just hide the (essential) fact that this is > > a shared pointer type. > > Do I understand correctly that you argue that the fact that the actual > type is a shared pointer is so important that it shall not be hidden by > a template alias whereas it would be completely fine to hide everything > related to type by using auto? Yes, you understood me correctly. And to answer your implied objection, too: No, there's no contradiction, because auto is for use in implementations and I was talking explicitly about APIs (which implies API documentation, too). It's one thing to write auto o = factory->create(); and quite another to have QNodeCreatedChangePtr create() [virtual] (to make up a plausible, but nonsensical example) in the docs. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From sean.harmer at kdab.com Mon Mar 21 13:18:18 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 21 Mar 2016 12:18:18 +0000 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: <201603211244.35124.marc.mutz@kdab.com> References: <201603211244.35124.marc.mutz@kdab.com> Message-ID: <5930347.7CiVhOsJMU@titan> On Monday 21 March 2016 12:44:34 Marc Mutz wrote: > On Monday 21 March 2016 12:07:24 Poenitz Andre wrote: > > Marc Mutz wrote: > > > I said then and I repeat it now that imho template aliases are not > > > interesting for library development. In particular, I don't think > > > something like > > > > > > > > > template > > > > > > using QNodeCreatedChangePtr = > > > > > > QSharedPointer>; > > > > > > should be part of an API of a library. We have auto to avoid having to > > > type this type. The typedefs just hide the (essential) fact that this is > > > a shared pointer type. > > > > Do I understand correctly that you argue that the fact that the actual > > type is a shared pointer is so important that it shall not be hidden by > > a template alias whereas it would be completely fine to hide everything > > related to type by using auto? > > Yes, you understood me correctly. > > And to answer your implied objection, too: > > No, there's no contradiction, because auto is for use in implementations and > I was talking explicitly about APIs (which implies API documentation, too). > It's one thing to write > > auto o = factory->create(); > > and quite another to have > > QNodeCreatedChangePtr create() [virtual] > > (to make up a plausible, but nonsensical example) in the docs. I'm actually after the implementation case here so I can write: auto creationChange = QNodeCreatedChangePtr::create(this); rather than: auto creationChange = QSharedPointer >::create(this); Of course it would also be a convenience to the user when they need to do similar. I guess I'll redo my changes if I can't use template aliases like this unconditionally. Cheers, Sean From rjvbertin at gmail.com Mon Mar 21 13:22:48 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 21 Mar 2016 13:22:48 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? In-Reply-To: <2452149.EIisSZMbR1@desktop-ga45d22> References: <1466246.T2YiNlAlqL@portia.local> <2068458.X1XyrHk62x@portia.local> <2452149.EIisSZMbR1@desktop-ga45d22> Message-ID: <5264639.Z3621hNos5@portia.local> On Friday March 18 2016 14:15:32 Sergio Martins wrote: > To get parameters passed to QCocoaIntegration::QCocoaIntegration(), you should > use -platform cocoa:fontengine=freetype, which I haven't tried, but similar > works for me on Windows. FWIW, here's a small preview of CoreText vs. Freetype rendering and font name/weight/style representation. R. -------------- next part -------------- A non-text attachment was scrubbed... Name: Qt56mac-CoreText-vs-Freetype.png Type: image/png Size: 60982 bytes Desc: not available URL: From Andre.Poenitz at theqtcompany.com Mon Mar 21 13:23:44 2016 From: Andre.Poenitz at theqtcompany.com (Poenitz Andre) Date: Mon, 21 Mar 2016 12:23:44 +0000 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: <201603211244.35124.marc.mutz@kdab.com> References: <201603211157.53715.marc.mutz@kdab.com> , <201603211244.35124.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > On Monday 21 March 2016 12:07:24 Poenitz Andre wrote: > > Marc Mutz wrote: > > > I said then and I repeat it now that imho template aliases are not > > > interesting for library development. In particular, I don't think > > > something like > > > > > > > > > template > > > > > > using QNodeCreatedChangePtr = > > > > > > QSharedPointer>; > > > > > > should be part of an API of a library. We have auto to avoid having to > > > type this type. The typedefs just hide the (essential) fact that this is > > > a shared pointer type. > > > > Do I understand correctly that you argue that the fact that the actual > > type is a shared pointer is so important that it shall not be hidden by > > a template alias whereas it would be completely fine to hide everything > > related to type by using auto? > > Yes, you understood me correctly. > > And to answer your implied objection, too: > > No, there's no contradiction, because auto is for use in implementations and I > was talking explicitly about APIs (which implies API documentation, too). It's > one thing to write > > auto o = factory->create(); > > and quite another to have > > QNodeCreatedChangePtr create() [virtual] > > (to make up a plausible, but nonsensical example) in the docs. > > Thanks, > Marc I will argue that if user code looks ugly by default, or needs one specific, controversial coding style when using an API, the API is bad. A possible question here is why there's a need to have the QSharedPointer show up in the API at all. Is it meant to be a vehicle to provide value semantics? If so, why isn't the sharing hidden in the implementation of the object? Is it meant to hide unclear ownership and object lifetime? If so, shouldn't ownership and lifetime better be clear? Andre' From sean.harmer at kdab.com Mon Mar 21 13:38:43 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 21 Mar 2016 12:38:43 +0000 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: References: <201603211244.35124.marc.mutz@kdab.com> Message-ID: <1508011.5xYLNNX2AO@titan> On Monday 21 March 2016 12:23:44 Poenitz Andre wrote: > Marc Mutz wrote: > > On Monday 21 March 2016 12:07:24 Poenitz Andre wrote: > > > Marc Mutz wrote: > > > > I said then and I repeat it now that imho template aliases are not > > > > interesting for library development. In particular, I don't think > > > > something like > > > > > > > > > > > template > > > > > > > using QNodeCreatedChangePtr = > > > > > > > QSharedPointer>; > > > > > > > > should be part of an API of a library. We have auto to avoid having to > > > > type this type. The typedefs just hide the (essential) fact that this > > > > is > > > > a shared pointer type. > > > > > > Do I understand correctly that you argue that the fact that the actual > > > type is a shared pointer is so important that it shall not be hidden by > > > a template alias whereas it would be completely fine to hide everything > > > related to type by using auto? > > > > Yes, you understood me correctly. > > > > And to answer your implied objection, too: > > > > No, there's no contradiction, because auto is for use in implementations > > and I was talking explicitly about APIs (which implies API documentation, > > too). It's one thing to write > > > > auto o = factory->create(); > > > > and quite another to have > > > > QNodeCreatedChangePtr create() [virtual] > > > > (to make up a plausible, but nonsensical example) in the docs. > > > > Thanks, > > Marc > > I will argue that if user code looks ugly by default, or needs one specific, > controversial coding style when using an API, the API is bad. > > A possible question here is why there's a need to have the QSharedPointer > show up in the API at all. > > Is it meant to be a vehicle to provide value semantics? If so, why isn't > the sharing hidden in the implementation of the object? > > Is it meant to hide unclear ownership and object lifetime? If so, shouldn't > ownership and lifetime better be clear? It's to support one-to-many delivery of an event-like object to backends potentially running on multiple threads concurrently. The type is not a QObject so can't be managed by the QObject parent-child relationship. Using a naked pointer goes against modern C++ recommendations and would mean having to put in place code to delete the objects after all consumers are done with it. A QSharedPointer to a QNodeCreatedChange which is a templated type works well here and I'm using the create() static to avoid having two allocations instead of one per event. If I can't use the template alias syntax, so be it, I can use the more verbose alternative. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions From marc.mutz at kdab.com Mon Mar 21 14:25:42 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 21 Mar 2016 14:25:42 +0100 Subject: [Development] =?utf-8?q?Allowed_C++11_features_=5Bwas=3A_Re=3A_Re?= =?utf-8?q?=3A_MSVC2012_in=09CI=5D?= In-Reply-To: <1508011.5xYLNNX2AO@titan> References: <1508011.5xYLNNX2AO@titan> Message-ID: <201603211425.42128.marc.mutz@kdab.com> On Monday 21 March 2016 13:38:43 Sean Harmer wrote: > On Monday 21 March 2016 12:23:44 Poenitz Andre wrote: > > Marc Mutz wrote: > > > On Monday 21 March 2016 12:07:24 Poenitz Andre wrote: > > > > Marc Mutz wrote: > > > > > I said then and I repeat it now that imho template aliases are not > > > > > interesting for library development. In particular, I don't think > > > > > something like > > > > > > > > > > > > > template > > > > > > > > using QNodeCreatedChangePtr = > > > > > > > > QSharedPointer>; > > > > > > > > > > should be part of an API of a library. We have auto to avoid having > > > > > to type this type. The typedefs just hide the (essential) fact > > > > > that this is > > > > > a shared pointer type. > > > > > > > > Do I understand correctly that you argue that the fact that the > > > > actual type is a shared pointer is so important that it shall not be > > > > hidden by a template alias whereas it would be completely fine to > > > > hide everything related to type by using auto? > > > > > > Yes, you understood me correctly. > > > > > > And to answer your implied objection, too: > > > > > > No, there's no contradiction, because auto is for use in > > > implementations and I was talking explicitly about APIs (which implies > > > API documentation, too). It's one thing to write > > > > > > auto o = factory->create(); > > > > > > and quite another to have > > > > > > QNodeCreatedChangePtr create() [virtual] > > > > > > (to make up a plausible, but nonsensical example) in the docs. > > > > > > Thanks, > > > Marc > > > > I will argue that if user code looks ugly by default, or needs one > > specific, controversial coding style when using an API, the API is bad. > > > > A possible question here is why there's a need to have the QSharedPointer > > show up in the API at all. > > > > Is it meant to be a vehicle to provide value semantics? If so, why isn't > > the sharing hidden in the implementation of the object? > > > > Is it meant to hide unclear ownership and object lifetime? If so, > > shouldn't ownership and lifetime better be clear? > > It's to support one-to-many delivery of an event-like object to backends > potentially running on multiple threads concurrently. The type is not a > QObject so can't be managed by the QObject parent-child relationship. Using > a naked pointer But QSharedPointer *is* a naked pointer. That is, if you're referring to Sean Parent's definition in his goal of "No raw pointers". > goes against modern C++ recommendations and would mean > having to put in place code to delete the objects after all consumers are > done with it. If you follow Sean Parent, then you should hide the naked shared pointer in an object with value semantics. In Qt we'd say a CoW type, but the type may not need to allow writing. > A QSharedPointer to a QNodeCreatedChange which is a templated type works > well here and I'm using the create() static to avoid having two > allocations instead of one per event. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Andre.Poenitz at theqtcompany.com Mon Mar 21 14:35:49 2016 From: Andre.Poenitz at theqtcompany.com (Poenitz Andre) Date: Mon, 21 Mar 2016 13:35:49 +0000 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: <1508011.5xYLNNX2AO@titan> References: <201603211244.35124.marc.mutz@kdab.com> , <1508011.5xYLNNX2AO@titan> Message-ID: Sean Harmer wrote: > On Monday 21 March 2016 12:23:44 Poenitz Andre wrote: > > I will argue that if user code looks ugly by default, or needs one specific, > > controversial coding style when using an API, the API is bad. > > > > A possible question here is why there's a need to have the QSharedPointer > > show up in the API at all. > > > > Is it meant to be a vehicle to provide value semantics? If so, why isn't > > the sharing hidden in the implementation of the object? > > > > Is it meant to hide unclear ownership and object lifetime? If so, shouldn't > > ownership and lifetime better be clear? > > It's to support one-to-many delivery of an event-like object to backends > potentially running on multiple threads concurrently. Is a receiver of this "event-like object" meant to be able modify the shared data while the other receiver keep hold of their "copy", i.e. is this effectively as shared_thing or is it a conscious decision to let receivers modify object state behind other receivers' back? In the first case, the shared ptr should be an implementation detail of the class and the class itself made appear to have value semantics. No need for the user to worry about ownership at all. The second case should be banned to start with. Making something modifiable, creating multiple ways to access it, and relying on distant parts of an application to cooperate when modifying that state is calling for trouble. > > The type is not a QObject so can't be managed by the QObject > > parent-child relationship. Using a naked pointer goes against modern > > C++ recommendations and would mean having to put in place code > > to delete the objects after all consumers are done with it. Just replacing a naked pointer by a shared pointer does not solve the ownership problem. At best, it addresses part of the lifetime aspect. "Being modern for the sake of being modern" is also no a good enough reason here. The trend seems to go towards value semantics lately. Andre' From marc.mutz at kdab.com Mon Mar 21 14:53:34 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 21 Mar 2016 14:53:34 +0100 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: <5930347.7CiVhOsJMU@titan> References: <201603211244.35124.marc.mutz@kdab.com> <5930347.7CiVhOsJMU@titan> Message-ID: <201603211453.34164.marc.mutz@kdab.com> On Monday 21 March 2016 13:18:18 Sean Harmer wrote: > On Monday 21 March 2016 12:44:34 Marc Mutz wrote: > > On Monday 21 March 2016 12:07:24 Poenitz Andre wrote: > > > Marc Mutz wrote: > > > > I said then and I repeat it now that imho template aliases are not > > > > interesting for library development. In particular, I don't think > > > > something like > > > > > > > > > > > template > > > > > > > using QNodeCreatedChangePtr = > > > > > > > QSharedPointer>; > > > > > > > > should be part of an API of a library. We have auto to avoid having > > > > to type this type. The typedefs just hide the (essential) fact that > > > > this is a shared pointer type. > > > > > > Do I understand correctly that you argue that the fact that the actual > > > type is a shared pointer is so important that it shall not be hidden by > > > a template alias whereas it would be completely fine to hide everything > > > related to type by using auto? > > > > Yes, you understood me correctly. > > > > And to answer your implied objection, too: > > > > No, there's no contradiction, because auto is for use in implementations > > and I was talking explicitly about APIs (which implies API > > documentation, too). It's one thing to write > > > > auto o = factory->create(); > > > > and quite another to have > > > > QNodeCreatedChangePtr create() [virtual] > > > > (to make up a plausible, but nonsensical example) in the docs. > > I'm actually after the implementation case here so I can write: > > auto creationChange = QNodeCreatedChangePtr::create(this); > > rather than: > > auto creationChange = QSharedPointer > >::create(this); In this case, my argument is moot, of course. If you don't want to wait for the CI to drop MSVC 2012, you can just use a struct: template struct QNodeCreatedChangePtr { static QSharedPointer > create() { return QSharedPointer >::create(); } }; > Of course it would also be a convenience to the user when they need to do > similar. I guess I'll redo my changes if I can't use template aliases like > this unconditionally. > > Cheers, > > Sean -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From andre at familiesomers.nl Mon Mar 21 15:01:15 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 21 Mar 2016 15:01:15 +0100 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: <201603211425.42128.marc.mutz@kdab.com> References: <1508011.5xYLNNX2AO@titan> <201603211425.42128.marc.mutz@kdab.com> Message-ID: <56EFFEAB.4060503@familiesomers.nl> Op 21/03/2016 om 14:25 schreef Marc Mutz: > On Monday 21 March 2016 13:38:43 Sean Harmer wrote: >> On Monday 21 March 2016 12:23:44 Poenitz Andre wrote: >> It's to support one-to-many delivery of an event-like object to backends >> potentially running on multiple threads concurrently. The type is not a >> QObject so can't be managed by the QObject parent-child relationship. Using >> a naked pointer > But QSharedPointer *is* a naked pointer. That is, if you're referring to Sean > Parent's definition in his goal of "No raw pointers". > >> goes against modern C++ recommendations and would mean >> having to put in place code to delete the objects after all consumers are >> done with it. > If you follow Sean Parent, then you should hide the naked shared pointer in an > object with value semantics. In Qt we'd say a CoW type, but the type may not > need to allow writing. Are we following Sean Parent though? Because if we are, we better start thinking about also replacing our QObject parent/child stuff with some external forest data structure in the future... André From dangelog at gmail.com Mon Mar 21 15:31:24 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Mon, 21 Mar 2016 15:31:24 +0100 Subject: [Development] Allowed C++11 features [was: Re: Re: MSVC2012 in CI] In-Reply-To: <56EFFEAB.4060503@familiesomers.nl> References: <1508011.5xYLNNX2AO@titan> <201603211425.42128.marc.mutz@kdab.com> <56EFFEAB.4060503@familiesomers.nl> Message-ID: On Mon, Mar 21, 2016 at 3:01 PM, André Somers wrote: > Are we following Sean Parent though? Because if we are, we better start > thinking about also replacing our QObject parent/child stuff with some > external forest data structure in the future... Please, can we avoid thread derailment again? :) This is about allowing unrestricted usage of template aliases (and other C++11 features) given we're dropping MSVC2012 support. Building good APIs with those features is totally orthogonal (for instance we might simply want to use those features in the implementation). Cheers, -- Giuseppe D'Angelo From rjvbertin at gmail.com Mon Mar 21 16:24:04 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 21 Mar 2016 16:24:04 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries References: <20160306184038.GA1823@mitya57.me> <38473332.kWL8iRUYHX@portia.local> <376581458475261@web21m.yandex.ru> <1608251.UfflzlCZiD@patux> <2537620.Ob6bVDynMi@patux.local> <2017801458489028@web25j.yandex.ru> Message-ID: <1596119.IosDq1tZIg@patux.local> Konstantin Tokarev wrote: >> So how am I supposed to invoke generate-forwarding-headers.pl ? > > No, it should be execute as a part of build process So, it is as I feared. When I execute qmake and then make manually from a terminal generate-forwarding-headers.pl is called as it apparently should. When I do the same calls from the build/packaging scripts called through the "port" command, generate-forwarding-headers.pl is NOT called. What difference can explain this? Can it something that's set (or not set) in the environment that causes the corresponding fwheader_generator target to be skipped? I see there's one difference I still need to address : the build scripts call qmake with the -r option. Could that be the explanation? (I'll have my own answer in about 50 minutes at best ...) R. From kde at carewolf.com Mon Mar 21 17:20:54 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 21 Mar 2016 17:20:54 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? In-Reply-To: <5264639.Z3621hNos5@portia.local> References: <1466246.T2YiNlAlqL@portia.local> <2452149.EIisSZMbR1@desktop-ga45d22> <5264639.Z3621hNos5@portia.local> Message-ID: <201603211720.54287.kde@carewolf.com> On Monday 21 March 2016, René J.V. Bertin wrote: > On Friday March 18 2016 14:15:32 Sergio Martins wrote: > > To get parameters passed to QCocoaIntegration::QCocoaIntegration(), you > > should use -platform cocoa:fontengine=freetype, which I haven't tried, > > but similar works for me on Windows. > > FWIW, here's a small preview of CoreText vs. Freetype rendering and font > name/weight/style representation. > If the right one is freetype, it looks like it didn't disable font gamma- correction. We usually disable that when using freetype, since they don't have stem darkening, and thus gets must paler text-colors when fonts are antialiased. `Allan From rjvbertin at gmail.com Mon Mar 21 17:59:28 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 21 Mar 2016 17:59:28 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? References: <1466246.T2YiNlAlqL@portia.local> <2452149.EIisSZMbR1@desktop-ga45d22> <5264639.Z3621hNos5@portia.local> <201603211720.54287.kde@carewolf.com> Message-ID: <243188943.cvkmfOEJvU@portia.local> Allan Sandfeld Jensen wrote: > If the right one is freetype, it looks like it didn't disable font gamma- It is. > correction. We usually disable that when using freetype, since they don't have > stem darkening, and thus gets must paler text-colors when fonts are > antialiased. Do you disable it in the Freetype code, or in the Freetype fontengine? This snap was made with Freetype 2.6.2 with Bohoomil's Infinality patches. It is not impossible that part of the paler colour is due to the fact that optimal rendering with Infinality is obtained through dedicated fontconfig profiles, and from what I understand there's no support for those yet in the cocoa QPA. Infinality sets INFINALITY_FT_GAMMA_CORRECTION="0 100" by default, if that means anything to you. R. From mwoehlke.floss at gmail.com Mon Mar 21 18:17:59 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 21 Mar 2016 13:17:59 -0400 Subject: [Development] What qtbase looks like with extensive use of auto In-Reply-To: References: Message-ID: On 2016-03-19 14:02, Stephen Kelly wrote: > In case you missed it, I wrote an auto-modernizer > > https://steveire.wordpress.com/2016/03/19/aaargh Thanks for sharing. I admiringly adore all the abounding (and artistic) alliteration adorning the article. (Sorry, couldn't think how to avoid "the" in that ;-). And "I" *is* alliterative, darn it :-), at least in pronunciation.) Also, this looks like an interesting tool that I may wish to use myself... I do wonder why your tool doesn't convert this...? // old QStringList middleStrings = sl.mid(1, 500); // new auto middleStrings = QStringList{sl.mid(1, 500)}; -- Matthew From mstormo at gmail.com Mon Mar 21 18:19:36 2016 From: mstormo at gmail.com (MrMstormo .) Date: Mon, 21 Mar 2016 12:19:36 -0500 Subject: [Development] http://testresults.qt.io/ci/status/ stale? Message-ID: Looks like http://testresults.qt.io/ci/status/ is stale? All reports are erroring out, and there's no reports for 5.6, 5.7 etc? Is the CI system on an early Easter break? :) -- .marius -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Mon Mar 21 22:46:44 2016 From: steveire at gmail.com (Stephen Kelly) Date: Mon, 21 Mar 2016 22:46:44 +0100 Subject: [Development] What qtbase looks like with extensive use of auto References: Message-ID: Matthew Woehlke wrote: > On 2016-03-19 14:02, Stephen Kelly wrote: >> In case you missed it, I wrote an auto-modernizer >> >> https://steveire.wordpress.com/2016/03/19/aaargh > > Thanks for sharing. I admiringly adore all the abounding (and artistic) > alliteration adorning the article. (Sorry, couldn't think how to avoid > "the" in that ;-). And "I" *is* alliterative, darn it :-), at least in > pronunciation.) Thanks :). And > admiringly adore all abounding (and artistic) > alliteration adorning articles ?? > Also, this looks like an interesting tool that I may wish to use myself... > > I do wonder why your tool doesn't convert this...? > > // old > QStringList middleStrings = sl.mid(1, 500); > > // new > auto middleStrings = QStringList{sl.mid(1, 500)}; I leave all decisions like that to humans. The conversion to QStringList may be 'wrong', so the tool leaves it behind so that it stands out. That is, a human might decide this is right for the code in question: auto middleStrings = sl.mid(1, 500); Thanks, Steve. From rich at kde.org Mon Mar 21 22:57:25 2016 From: rich at kde.org (Richard Moore) Date: Mon, 21 Mar 2016 21:57:25 +0000 Subject: [Development] What qtbase looks like with extensive use of auto In-Reply-To: References: Message-ID: There are certainly quite a few areas of the qtnetwork patch that I think make the code significantly easier to read. I don't think I'd apply everything from it, eg. some of the changes from int to auto just make things less clear in my eyes, but other parts are a massive win. Thanks for sharing this, it certainly make me think we should be actively using it. Cheers Rich. On 19 March 2016 at 18:02, Stephen Kelly wrote: > Hi, > > In case you missed it, I wrote an auto-modernizer > > https://steveire.wordpress.com/2016/03/19/aaargh > > It is not quite AAA, as it doesn't convert > > QString s; > > into > > auto s = QString(); > > I used it to port qtbase to an extensive use of auto: > > https://github.com/steveire/qtbase/commits/aaa > > This isn't something I want to push for Qt to apply, but it's something I > did and you might find the outcome interesting. > > If you think Qt should use auto not-at-all, not-a-lot, or almost-always, > I'm > sure you'll find lots of reasons in the commits to support your position. > > Thanks, > > Steve. > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Mon Mar 21 23:04:23 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 21 Mar 2016 23:04:23 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? In-Reply-To: <243188943.cvkmfOEJvU@portia.local> References: <1466246.T2YiNlAlqL@portia.local> <201603211720.54287.kde@carewolf.com> <243188943.cvkmfOEJvU@portia.local> Message-ID: <201603212304.23186.kde@carewolf.com> On Monday 21 March 2016, René J. V. Bertin wrote: > Allan Sandfeld Jensen wrote: > > If the right one is freetype, it looks like it didn't disable font gamma- > > It is. > > > correction. We usually disable that when using freetype, since they don't > > have stem darkening, and thus gets must paler text-colors when fonts are > > antialiased. > > Do you disable it in the Freetype code, or in the Freetype fontengine? > No, it is a technically a platform setting in Qt for our font-rendering gamma. When I first fixed the issue of pale text colors on Linux with Qt5, I just forced the gamma value for the xcb-plugin to 1.0, but when freetype support was added for Windows, there was also added another way of disabling font gamma correction when freetype was used on Windows. Something similar could potentially be missing for OS X, which is why I commented on the color. Regards `Allan From rjvbertin at gmail.com Mon Mar 21 23:26:55 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Mon, 21 Mar 2016 23:26:55 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? References: <1466246.T2YiNlAlqL@portia.local> <2452149.EIisSZMbR1@desktop-ga45d22> <5264639.Z3621hNos5@portia.local> <201603211720.54287.kde@carewolf.com> Message-ID: <1989174.lC5d7xj5v5@portia.local> For further comparison, here's a screenshot showing CoreText vs Cocoa+Freetype vs XCB+Freetype+Fontconfig all on OS X, using a theme & style based on QtCurve. The XCB+Freetype rendering is hands-down the easiest on the eyes for me, though that's of course all in the eye of the beholder. It'd be nice if the same quality could be attained with the Cocoa QPA. I'd be interested in testing different ways to get the text colour right (backported to 5.6 though ;)). R. -------------- next part -------------- A non-text attachment was scrubbed... Name: CoreText-vs-Freetype.png Type: image/png Size: 87968 bytes Desc: not available URL: From mandeepsandhu.chd at gmail.com Mon Mar 21 23:41:40 2016 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Mon, 21 Mar 2016 15:41:40 -0700 Subject: [Development] What qtbase looks like with extensive use of auto In-Reply-To: References: Message-ID: On Sat, Mar 19, 2016 at 11:02 AM, Stephen Kelly wrote: > Hi, > > In case you missed it, I wrote an auto-modernizer > > https://steveire.wordpress.com/2016/03/19/aaargh Thanks for this blog post. It made me smile...and also auto aware! (yes!! I did it too!) :) -mandeep > > It is not quite AAA, as it doesn't convert > > QString s; > > into > > auto s = QString(); > > I used it to port qtbase to an extensive use of auto: > > https://github.com/steveire/qtbase/commits/aaa > > This isn't something I want to push for Qt to apply, but it's something I > did and you might find the outcome interesting. > > If you think Qt should use auto not-at-all, not-a-lot, or almost-always, I'm > sure you'll find lots of reasons in the commits to support your position. > > Thanks, > > Steve. > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From apoenitz at t-online.de Tue Mar 22 00:00:29 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 22 Mar 2016 00:00:29 +0100 Subject: [Development] What qtbase looks like with extensive use of auto In-Reply-To: References: Message-ID: <20160321230029.GA2196@klara.mpi.htwm.de> On Sat, Mar 19, 2016 at 07:02:08PM +0100, Stephen Kelly wrote: > It is not quite AAA, as it doesn't convert > > QString s; > > into > > auto s = QString(); > I used it to port qtbase to an extensive use of auto: > > https://github.com/steveire/qtbase/commits/aaa > > This isn't something I want to push for Qt to apply, Good that you don't want to push that for Qt to apply. It would be too bad see Qt end up as a staging ground for code style experiments. But of course this can't happen, as the Qt Project is a consensus-based community, and nobody has the intention to introduce an AAA policy without consensus, correct? Andre' From thiago.macieira at intel.com Tue Mar 22 00:00:26 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 21 Mar 2016 23:00:26 +0000 Subject: [Development] What qtbase looks like with extensive use of auto In-Reply-To: References: Message-ID: <2097200.BF9RQ2U5Wa@tjmaciei-mobl4> On sábado, 19 de março de 2016 19:02:08 GMT Stephen Kelly wrote: > Hi, > > In case you missed it, I wrote an auto-modernizer > > https://steveire.wordpress.com/2016/03/19/aaargh > > It is not quite AAA, as it doesn't convert > > QString s; > > into > > auto s = QString(); Thanks Stephen The post is very informative. Thanks for the tool too. I'd just like to add a bit of a drawback. Take this code, for instance: QString s = tr("%1 (%2)").arg(someString()).arg(42); As we all know, currently arg() returns a QString. So your tool would replace that declaration with "auto". This would prevent future source-compatible changes we've done in the past like that of QStringBuilder. Note that the code actually has 3 QStrings in-flight at the same time, due to tr() and each arg() returning a QString. Wouldn't it be dandy if we had rvalue overloads for the above? But we already have 18 overloads for arg(): do we want to double that? So I implemented that about two years ago (patches never pushed). The solution was to add one pair a variadic template arg() to QString that forwarded the actual arg() code to a QStringArgBuilder, which in turn returns *this by reference (it always modifies in-place). Unlike QStringBuilder, QStringArgBuilder *is* a QString (derives from it), so all members are still present. But if the code above were auto, s would be a QStringArgBuilder. And if you had later: someFunction(s.arg(M_PI)); We'd have a behaviour change... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kde at carewolf.com Tue Mar 22 00:30:11 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Tue, 22 Mar 2016 00:30:11 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? In-Reply-To: <1989174.lC5d7xj5v5@portia.local> References: <1466246.T2YiNlAlqL@portia.local> <201603211720.54287.kde@carewolf.com> <1989174.lC5d7xj5v5@portia.local> Message-ID: <201603220030.11770.kde@carewolf.com> On Monday 21 March 2016, René J. V. Bertin wrote: > For further comparison, here's a screenshot showing > > CoreText vs Cocoa+Freetype vs XCB+Freetype+Fontconfig > > all on OS X, using a theme & style based on QtCurve. > > The XCB+Freetype rendering is hands-down the easiest on the eyes for me, > though that's of course all in the eye of the beholder. It'd be nice if > the same quality could be attained with the Cocoa QPA. > > I'd be interested in testing different ways to get the text colour right > (backported to 5.6 though ;)). > I would suggest trying to change QCocoaIntegration::styleHint and return 1.0 for QPlatformIntegration::FontSmoothingGamma instead of 2.0. `Allan -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Tue Mar 22 03:01:44 2016 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 22 Mar 2016 03:01:44 +0100 Subject: [Development] Source compatibility for third parties using auto (Was: What qtbase looks like with extensive use of auto) Message-ID: <56F0A788.7020902@gmail.com> Thiago Macieira wrote: > On sábado, 19 de março de 2016 19:02:08 GMT Stephen Kelly wrote: >> Hi, >> >> In case you missed it, I wrote an auto-modernizer >> >> https://steveire.wordpress.com/2016/03/19/aaargh >> >> It is not quite AAA, as it doesn't convert >> >> QString s; >> >> into >> >> auto s = QString(); > > Thanks Stephen > > The post is very informative. Thanks for the tool too. Great, thanks! > But if the code above were auto, s would be a QStringArgBuilder. And if > you had later: > > someFunction(s.arg(M_PI)); > > We'd have a behaviour change... Note that this is nothing to do with the tool, so I've broken out a different thread. 3rd party code is already using auto s = tr("%1 (%2)").arg(someString()).arg(42); someFunction(s.arg(M_PI)); so your proposal is not as source compatible as you think. It is about as source compatible as QStringBuilder is when introduced to code which already uses auto. QStringBuilder is not on-by-default for operator+, or wasn't the last I checked, so a user could enable it today for a codebase which already uses auto extensively with a result of strange runtime behavior. Presumably your proposal is either Qt6 material or something to be enabled by the user with a compile definition similar to QStringBuilder. Problems like you describe could similarly be found with a clazy check. At least for Qt 6 you could consider what kind of (clang based) tooling to make available for 5-6 ports to make this kind of change more visible to people porting. Thanks, Steve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Tue Mar 22 07:17:53 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Mar 2016 07:17:53 +0100 Subject: [Development] Source compatibility for third parties using auto (Was: What qtbase looks like with extensive use of auto) In-Reply-To: <56F0A788.7020902@gmail.com> References: <56F0A788.7020902@gmail.com> Message-ID: <201603220717.53897.marc.mutz@kdab.com> On Tuesday 22 March 2016 03:01:44 Stephen Kelly wrote: > Thiago Macieira wrote: > > On sábado, 19 de março de 2016 19:02:08 GMT Stephen Kelly wrote: > >> Hi, > >> > >> > >> > >> In case you missed it, I wrote an auto-modernizer > >> > >> https://steveire.wordpress.com/2016/03/19/aaargh > >> > >> It is not quite AAA, as it doesn't convert > >> > >> QString s; > >> > >> into > >> > >> auto s = QString(); > > > > Thanks Stephen > > > > > > > > The post is very informative. Thanks for the tool too. > > Great, thanks! > > > But if the code above were auto, s would be a QStringArgBuilder. And if > > > > you had later: > > > > > > > > someFunction(s.arg(M_PI)); > > > > > > > > We'd have a behaviour change... > > Note that this is nothing to do with the tool, so I've broken out a > different thread. > > 3rd party code is already using > > auto s = tr("%1 (%2)").arg(someString()).arg(42); > > someFunction(s.arg(M_PI)); > > so your proposal is not as source compatible as you think. > > It is about as source compatible as QStringBuilder is when introduced to > code which already uses auto. QStringBuilder is not on-by-default for > operator+, or wasn't the last I checked, so a user could enable it today > for a codebase which already uses auto extensively with a result of > strange runtime behavior. > > Presumably your proposal is either Qt6 material or something to be > enabled by the user with a compile definition similar to QStringBuilder. > Problems like you describe could similarly be found with a clazy check. This is a general issue in C++ and should be solved generally: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From cavendish.qi at gmail.com Tue Mar 22 07:32:45 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Tue, 22 Mar 2016 07:32:45 +0100 Subject: [Development] http://testresults.qt.io/ci/status/ stale? In-Reply-To: References: Message-ID: The status of new CI: http://testresults.qt.io/coin/ On 21 March 2016 at 18:19, MrMstormo . wrote: > > Looks like > http://testresults.qt.io/ci/status/ > is stale? All reports are erroring out, and there's no reports for 5.6, > 5.7 etc? > > Is the CI system on an early Easter break? :) > > -- > .marius > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- http://www.qiliang.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Tue Mar 22 08:59:56 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Mar 2016 08:59:56 +0100 Subject: [Development] http://testresults.qt.io/ci/status/ stale? In-Reply-To: References: Message-ID: <201603220859.56932.marc.mutz@kdab.com> On Tuesday 22 March 2016 07:32:45 Liang Qi wrote: > The status of new CI: http://testresults.qt.io/coin/ About that: it always shows "no integrations running", while clearly there are active integrations according to Gerrit. Bug or feature? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Simon.Hausmann at theqtcompany.com Tue Mar 22 08:52:11 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Tue, 22 Mar 2016 07:52:11 +0000 Subject: [Development] http://testresults.qt.io/ci/status/ stale? In-Reply-To: <201603220859.56932.marc.mutz@kdab.com> References: , <201603220859.56932.marc.mutz@kdab.com> Message-ID: <20160322075210.5935185.91033.64439@theqtcompany.com> Not implemented feature. That site is a mirror of the internal system and we do not mirror running integrations currently. Simon Original Message From: Marc Mutz Sent: Tuesday, March 22, 2016 08:50 To: development at qt-project.org Subject: Re: [Development] http://testresults.qt.io/ci/status/ stale? On Tuesday 22 March 2016 07:32:45 Liang Qi wrote: > The status of new CI: http://testresults.qt.io/coin/ About that: it always shows "no integrations running", while clearly there are active integrations according to Gerrit. Bug or feature? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Tue Mar 22 09:26:06 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Mar 2016 09:26:06 +0100 Subject: [Development] qtfeedback and qtdocgallery: status? Message-ID: <201603220926.06667.marc.mutz@kdab.com> Hi, what, exactly, is the status of the QtFeedback and QtDocGallery modules? They are submodules of qt5/5.6, but they accept no integrations due to the license header check failing, cf. https://codereview.qt-project.org/151189 (qtfeedback) https://codereview.qt-project.org/151253 (qtdocgallery) Can we either fix these modules so integrations succeed again, or else drop them from the list of submodules, please? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Simon.Hausmann at theqtcompany.com Tue Mar 22 09:19:26 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Tue, 22 Mar 2016 08:19:26 +0000 Subject: [Development] qtfeedback and qtdocgallery: status? In-Reply-To: <201603220926.06667.marc.mutz@kdab.com> References: <201603220926.06667.marc.mutz@kdab.com> Message-ID: Hi, I see no reason for dropping them from qt5.git as long as they are in status = ignore (http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules?h=5.6.0 ). What harm does it cause? Simon ________________________________________ From: Development on behalf of Marc Mutz Sent: Tuesday, March 22, 2016 9:26 To: development at qt-project.org Subject: [Development] qtfeedback and qtdocgallery: status? Hi, what, exactly, is the status of the QtFeedback and QtDocGallery modules? They are submodules of qt5/5.6, but they accept no integrations due to the license header check failing, cf. https://codereview.qt-project.org/151189 (qtfeedback) https://codereview.qt-project.org/151253 (qtdocgallery) Can we either fix these modules so integrations succeed again, or else drop them from the list of submodules, please? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Tue Mar 22 09:37:53 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Mar 2016 09:37:53 +0100 Subject: [Development] qtfeedback and qtdocgallery: status? In-Reply-To: References: <201603220926.06667.marc.mutz@kdab.com> Message-ID: <201603220937.53306.marc.mutz@kdab.com> On Tuesday 22 March 2016 09:19:26 Hausmann Simon wrote: > Hi, > > I see no reason for dropping them from qt5.git as long as they are in > status = ignore > (http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules?h=5.6.0 ). What harm > does it cause? You mean other than failing integrations? None. Specifically, I'l like to enable -Wzero-as-null-pointer-constant in headercheck and those are the only modules that have not integrated the respective fixes. What about the other option, then? Fixing them? I have no idea how to fix them so that both 5.6 and 5.7 are happy, and they don't follow the Qt branching, it seems. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Simon.Hausmann at theqtcompany.com Tue Mar 22 09:58:48 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Tue, 22 Mar 2016 08:58:48 +0000 Subject: [Development] qtfeedback and qtdocgallery: status? In-Reply-To: <201603220937.53306.marc.mutz@kdab.com> References: <201603220926.06667.marc.mutz@kdab.com> , <201603220937.53306.marc.mutz@kdab.com> Message-ID: As the modules are not part of any release of Qt and unmaintained, I don't think they need fixing. Simon ________________________________________ From: marc at kdab.com on behalf of Marc Mutz Sent: Tuesday, March 22, 2016 9:37 To: Hausmann Simon Cc: development at qt-project.org Subject: Re: [Development] qtfeedback and qtdocgallery: status? On Tuesday 22 March 2016 09:19:26 Hausmann Simon wrote: > Hi, > > I see no reason for dropping them from qt5.git as long as they are in > status = ignore > (http://code.qt.io/cgit/qt/qt5.git/tree/.gitmodules?h=5.6.0 ). What harm > does it cause? You mean other than failing integrations? None. Specifically, I'l like to enable -Wzero-as-null-pointer-constant in headercheck and those are the only modules that have not integrated the respective fixes. What about the other option, then? Fixing them? I have no idea how to fix them so that both 5.6 and 5.7 are happy, and they don't follow the Qt branching, it seems. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Tue Mar 22 10:38:45 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Mar 2016 10:38:45 +0100 Subject: [Development] qtfeedback and qtdocgallery: status? In-Reply-To: References: <201603220926.06667.marc.mutz@kdab.com> <201603220937.53306.marc.mutz@kdab.com> Message-ID: <201603221038.46041.marc.mutz@kdab.com> On Tuesday 22 March 2016 09:58:48 Hausmann Simon wrote: > As the modules are not part of any release of Qt and unmaintained, I don't > think they need fixing. C'mon — FTBFS without the possibility to submit a fix? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Simon.Hausmann at theqtcompany.com Tue Mar 22 10:37:20 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Tue, 22 Mar 2016 09:37:20 +0000 Subject: [Development] qtfeedback and qtdocgallery: status? In-Reply-To: <201603221038.46041.marc.mutz@kdab.com> References: <201603220926.06667.marc.mutz@kdab.com> <201603220937.53306.marc.mutz@kdab.com> , <201603221038.46041.marc.mutz@kdab.com> Message-ID: I'm not sure what you'd like me to answer at this point. I think that it is possible to fix the build of these modules, the CI system is in place for that. However it requires a fair bit of work (ask Robin about qtmessagingframework ;-). However fixing the modules appears to me to be orthogonal to the question about whether they should be mentioned in .gitmodules or not. It is my opinion that them being listed in the file does not cause any harm because they have the status "ignore", which excludes them from init-repository, the CI system and consequently the release of Qt. Simon ________________________________________ From: Development on behalf of Marc Mutz Sent: Tuesday, March 22, 2016 10:38 To: development at qt-project.org Subject: Re: [Development] qtfeedback and qtdocgallery: status? On Tuesday 22 March 2016 09:58:48 Hausmann Simon wrote: > As the modules are not part of any release of Qt and unmaintained, I don't > think they need fixing. C'mon — FTBFS without the possibility to submit a fix? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From robin+qt at viroteck.net Tue Mar 22 10:50:40 2016 From: robin+qt at viroteck.net (Robin Burchell) Date: Tue, 22 Mar 2016 10:50:40 +0100 Subject: [Development] qtfeedback and qtdocgallery: status? In-Reply-To: References: <201603220926.06667.marc.mutz@kdab.com> <201603220937.53306.marc.mutz@kdab.com> <201603221038.46041.marc.mutz@kdab.com> Message-ID: <1458640240.2178618.556195578.3D5EB9D7@webmail.messagingengine.com> On Tue, Mar 22, 2016, at 10:37 AM, Hausmann Simon wrote: > I'm not sure what you'd like me to answer at this point. I think that it > is possible to fix the > build of these modules, the CI system is in place for that. However it > requires a fair bit of > work (ask Robin about qtmessagingframework ;-). Assuming that the problems are *just* limited to license tests, and the tests in the package itself are in good shape, then it's probably not *too* hard. It'll still require playing a few rounds of CI ping-pong, and mass-staging changes (and headdesking when it fails again). I'll readily admit that it's an annoying process, but it was a manageable one. I'm not sure it's a productive use of time in the case of these "smaller"/pseudo-abandonware codebases, but it's certainly possible. For the practicalities of how to do it (Simon or someone, please correct me if I'm wrong here): * You'll want to edit sync.profile in the module and make sure they don't have "stale" dependencies (I see for instance that qtfeedback is pointing to refs/heads/stable, which is probably not a good idea at this point). I forget what the default is (no specific version listed) -- I believe it points to the origin branch (e.g. 5.6 branch of module -> 5.6 of dependency), or dev if there's not a direct match. * You can run the license test locally (from qtqa, see ./tests/prebuild/license/tst_licenses.pl) to check that it will be satisfied with a given module Robin From thiago.macieira at intel.com Tue Mar 22 11:20:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Mar 2016 10:20:44 +0000 Subject: [Development] Source compatibility for third parties using auto (Was: What qtbase looks like with extensive use of auto) In-Reply-To: <201603220717.53897.marc.mutz@kdab.com> References: <56F0A788.7020902@gmail.com> <201603220717.53897.marc.mutz@kdab.com> Message-ID: <3137095.ULAAOpsmeJ@tjmaciei-mobl4> On terça-feira, 22 de março de 2016 07:17:53 GMT Marc Mutz wrote: > This is a general issue in C++ and should be solved generally: > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf Do you know the status of this proposal? It's not in the latest language draft available (N4567). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Mar 22 11:33:57 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Mar 2016 10:33:57 +0000 Subject: [Development] C++11 initializer lists in Qt 5.7 Message-ID: <4705972.xU7Xntb79T@tjmaciei-mobl4> [This is why I asked for an analysis of the features now possible, but it hasn't happened. So we're doing it piecemeal] Sean wrote: > I don't have ready access to all the other compilers and versions we support > but I think this would allow potential use of: > > * template aliases > * raw string literals > * delegating ctors I'd written: > This buys us: > > - delegating constructors > - "explicit operator" member funcvtions > - nsdmi > - initializer_list (not uniform initialisation!) > - raw strings > - template alias (using ... = ...) > - variadic templates In specific for initializer_lists, the only compilers now with problems is M MSVC 2013 RTM and SP1. SP2 contains a fix that allows us to enable the functionality. But since MSVC does not keep binary compatibility between versions, we should be allowed to use initializer_lists in our ABI. Any disagreements? cf https://codereview.qt-project.org/107373 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Tue Mar 22 12:00:35 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Mar 2016 12:00:35 +0100 Subject: [Development] C++11 initializer lists in Qt 5.7 In-Reply-To: <4705972.xU7Xntb79T@tjmaciei-mobl4> References: <4705972.xU7Xntb79T@tjmaciei-mobl4> Message-ID: <201603221200.35087.marc.mutz@kdab.com> On Tuesday 22 March 2016 11:33:57 Thiago Macieira wrote: > [This is why I asked for an analysis of the features now possible, but it > hasn't happened. So we're doing it piecemeal] > > Sean wrote: > > I don't have ready access to all the other compilers and versions we > > support but I think this would allow potential use of: > > > > * template aliases > > * raw string literals > > * delegating ctors > > I'd written: > > This buys us: > > > > - delegating constructors > > - "explicit operator" member funcvtions > > - nsdmi > > - initializer_list (not uniform initialisation!) > > - raw strings > > - template alias (using ... = ...) > > - variadic templates > > In specific for initializer_lists, the only compilers now with problems is > M MSVC 2013 RTM and SP1. SP2 contains a fix that allows us to enable the > functionality. > > But since MSVC does not keep binary compatibility between versions, we > should be allowed to use initializer_lists in our ABI. > > Any disagreements? > > cf https://codereview.qt-project.org/107373 The same old problem: std::_1::initializer_list vs. std:.initializer_list ? Or is std::initializer_list one of those types (like std::exception) compatible between libc++ and libstdc++? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Tue Mar 22 12:03:40 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Mar 2016 12:03:40 +0100 Subject: [Development] Source compatibility for third parties using auto (Was: What qtbase looks like with extensive use of auto) In-Reply-To: <3137095.ULAAOpsmeJ@tjmaciei-mobl4> References: <56F0A788.7020902@gmail.com> <201603220717.53897.marc.mutz@kdab.com> <3137095.ULAAOpsmeJ@tjmaciei-mobl4> Message-ID: <201603221203.40466.marc.mutz@kdab.com> On Tuesday 22 March 2016 11:20:44 Thiago Macieira wrote: > On terça-feira, 22 de março de 2016 07:17:53 GMT Marc Mutz wrote: > > This is a general issue in C++ and should be solved generally: > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf > > Do you know the status of this proposal? It's not in the latest language > draft available (N4567). No, but I've asked on std-proposals now. Let's see. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Tue Mar 22 12:03:37 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Mar 2016 11:03:37 +0000 Subject: [Development] C++11 initializer lists in Qt 5.7 In-Reply-To: <201603221200.35087.marc.mutz@kdab.com> References: <4705972.xU7Xntb79T@tjmaciei-mobl4> <201603221200.35087.marc.mutz@kdab.com> Message-ID: <14130005.o1tTdC26SK@tjmaciei-mobl4> On terça-feira, 22 de março de 2016 12:00:35 GMT Marc Mutz wrote: > The same old problem: > > std::_1::initializer_list vs. std:.initializer_list ? Or is > std::initializer_list one of those types (like std::exception) compatible > between libc++ and libstdc++? Good question. The layout of std::initializer_list is mandated by the compiler ABI. But the actual type name does not necessarily have to be... Checking libc++ sources... ====8<----- namespace std // purposefully not versioned { #ifndef _LIBCPP_HAS_NO_GENERALIZED_INITIALIZERS template class _LIBCPP_TYPE_VIS_ONLY initializer_list ====8<----- There you go, the name is the same too (St16initializer_list). Very likely, this is required by the compilers themselves. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexander.blasche at theqtcompany.com Tue Mar 22 12:12:52 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Tue, 22 Mar 2016 11:12:52 +0000 Subject: [Development] qtfeedback and qtdocgallery: status? In-Reply-To: <1458640240.2178618.556195578.3D5EB9D7@webmail.messagingengine.com> References: <201603220926.06667.marc.mutz@kdab.com> <201603220937.53306.marc.mutz@kdab.com> <201603221038.46041.marc.mutz@kdab.com> , <1458640240.2178618.556195578.3D5EB9D7@webmail.messagingengine.com> Message-ID: The problem seem purely license related (other failures currently not visible). I would argue that we should fix integrations errors due to such issues. I would favor another option though. We should disable the license check for modules which are ignored by .gitmodules. -- Alex ________________________________________ From: Development on behalf of Robin Burchell Sent: Tuesday, March 22, 2016 10:50 To: development at qt-project.org Subject: Re: [Development] qtfeedback and qtdocgallery: status? On Tue, Mar 22, 2016, at 10:37 AM, Hausmann Simon wrote: > I'm not sure what you'd like me to answer at this point. I think that it > is possible to fix the > build of these modules, the CI system is in place for that. However it > requires a fair bit of > work (ask Robin about qtmessagingframework ;-). Assuming that the problems are *just* limited to license tests, and the tests in the package itself are in good shape, then it's probably not *too* hard. It'll still require playing a few rounds of CI ping-pong, and mass-staging changes (and headdesking when it fails again). I'll readily admit that it's an annoying process, but it was a manageable one. I'm not sure it's a productive use of time in the case of these "smaller"/pseudo-abandonware codebases, but it's certainly possible. For the practicalities of how to do it (Simon or someone, please correct me if I'm wrong here): * You'll want to edit sync.profile in the module and make sure they don't have "stale" dependencies (I see for instance that qtfeedback is pointing to refs/heads/stable, which is probably not a good idea at this point). I forget what the default is (no specific version listed) -- I believe it points to the origin branch (e.g. 5.6 branch of module -> 5.6 of dependency), or dev if there's not a direct match. * You can run the license test locally (from qtqa, see ./tests/prebuild/license/tst_licenses.pl) to check that it will be satisfied with a given module Robin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Tue Mar 22 12:13:30 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 22 Mar 2016 12:13:30 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? In-Reply-To: <201603220030.11770.kde@carewolf.com> References: <1466246.T2YiNlAlqL@portia.local> <1989174.lC5d7xj5v5@portia.local> <201603220030.11770.kde@carewolf.com> Message-ID: <5070741.xJkuHEYzEq@portia.local> On Tuesday March 22 2016 00:30:11 Allan Sandfeld Jensen wrote: > I would suggest trying to change QCocoaIntegration::styleHint > and return 1.0 for QPlatformIntegration::FontSmoothingGamma instead of 2.0. You'd have to return mOptions.testFlag(UseFreeTypeFontEngine)? 1.0 : 2.0 for that stylehint because otherwise text rendering becomes really bad using CoreText. Some quick testing suggests that QPlatformIntegration::FontSmoothingGamma is queried only once, is that correct (typically)? Anyway, using a gamma of 1 gives this result, again CoreText vs. Freetype vs. FreeType+FontConfig using XCB in the 1st snap, CoreText vs. Freetype in the 2nd using the native Mac theme/style. That looks almost perfectly usable, making one wonder if there's a way to activate the Freetype engine through some form of global option, possibly programmatically? The rendering difference in Lucida Grande between CoreText and Freetype is surprising but corresponds to what I'm used to (sadly it makes UI text look even larger when set at 13pt). Font purists may notice the slightly wide stem of the F in the Cocoa/Freetype rendering of Novarese BQ in the 1st snap, compared to the XCB/Freetype+Fontconfig rendering. That is *probably* a result of the lack of use of Fontconfig under Cocoa. Are there plans to add Fontconfig support? R. -------------- next part -------------- A non-text attachment was scrubbed... Name: CoreText-vs-Freetype-Gamma1.png Type: image/png Size: 77659 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CoreText-vs-Freetype-Gamma1-native.png Type: image/png Size: 73686 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Mar 22 12:25:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 22 Mar 2016 11:25:01 +0000 Subject: [Development] qtfeedback and qtdocgallery: status? In-Reply-To: References: <201603220926.06667.marc.mutz@kdab.com> <1458640240.2178618.556195578.3D5EB9D7@webmail.messagingengine.com> Message-ID: <25253643.tDUra6Jec7@tjmaciei-mobl4> On terça-feira, 22 de março de 2016 11:12:52 GMT Blasche Alexander wrote: > The problem seem purely license related (other failures currently not > visible). I would argue that we should fix integrations errors due to such > issues. > > I would favor another option though. We should disable the license check for > modules which are ignored by .gitmodules. How about disabling the CI completely and allowing direct staging like for Qt Creator and Qt 4.8? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kollix at aon.at Tue Mar 22 14:24:47 2016 From: kollix at aon.at (Martin Koller) Date: Tue, 22 Mar 2016 14:24:47 +0100 Subject: [Development] QWidget and sizePolicy Message-ID: <6672576.GOuajt7e9E@lapi.koller> In the docs I find: "If there is a QLayout that manages this widget's children, the size policy specified by that layout is used. If there is no such QLayout, the result of this function is used." However in the code I can not find a relation between the sizePolicy and a layout. QWidget::sizePolicy() simply returns what it was given in QWidget::setSizePolicy() A layout itself has no sizePolicy, so this also is strange. Is this probably a leftover and the documentation was not updated or do I miss something ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From marc.mutz at kdab.com Tue Mar 22 20:33:08 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 22 Mar 2016 20:33:08 +0100 Subject: [Development] Source compatibility for third parties using auto (Was: What qtbase looks like with extensive use of auto) In-Reply-To: <201603221203.40466.marc.mutz@kdab.com> References: <56F0A788.7020902@gmail.com> <3137095.ULAAOpsmeJ@tjmaciei-mobl4> <201603221203.40466.marc.mutz@kdab.com> Message-ID: <201603222033.08707.marc.mutz@kdab.com> On Tuesday 22 March 2016 12:03:40 Marc Mutz wrote: > On Tuesday 22 March 2016 11:20:44 Thiago Macieira wrote: > > On terça-feira, 22 de março de 2016 07:17:53 GMT Marc Mutz wrote: > > > This is a general issue in C++ and should be solved generally: > > > > > > http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4035.pdf > > > > Do you know the status of this proposal? It's not in the latest language > > draft available (N4567). > > No, but I've asked on std-proposals now. Let's see. https://cplusplus.github.io/EWG/ewg-active.html#76 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From rjvbertin at gmail.com Tue Mar 22 22:00:10 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 22 Mar 2016 22:00:10 +0100 Subject: [Development] [OS X] next Qt 5.6.0 question : Freetype (building with -fontconfig)? References: <1466246.T2YiNlAlqL@portia.local> <1989174.lC5d7xj5v5@portia.local> <201603220030.11770.kde@carewolf.com> <5070741.xJkuHEYzEq@portia.local> Message-ID: <19541501.t4T5FkQ53M@portia.local> René J.V. Bertin wrote: Hi again, > mOptions.testFlag(UseFreeTypeFontEngine)? 1.0 : 2.0 In fact, 0.95 may work even better than 1.0 . R. From rjvbertin at gmail.com Tue Mar 22 22:17:28 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 22 Mar 2016 22:17:28 +0100 Subject: [Development] [OS X] green/welcome page disappears but widgets remain functional Message-ID: <3453447.BHLE91QtHt@portia.local> Kevin Funk wrote: > The latter, yes. Just try. Took me a while because I was upgrading to Qt 5.6.0. Running %> QT_LOGGING_RULES="*=true;qt.scenegraph*.debug=false" kdevelop5 Here's what I get when opening a 1st document over the welcome page: kdevplatform.sublime: view added in Sublime::Area(0x7ff1128e42d0, name = "code") kdevplatform.shell: added view in Sublime::Area(0x7ff1128e42d0, name = "code") , id "code_8168181" kdevplatform.shell: recording change done to "code_8168181" kdevplatform.shell: saving "code_8168181" from area kdevplatform.shell: setting "code_8168181" persistent: false kdevplatform.shell: loading working-set "code_8168181" into area Sublime::Area(0x7ff1128dbc60, name = "debug") kdevplatform.shell: recycling 0 old views kdevplatform.plugins.contextbrowser: new doc: 0x7ff114d5afb0 new cursor: (0, 0) kdevplatform.plugins.contextbrowser: updating jump target kdevplatform.plugins.contextbrowser: updating history kdevplatform.plugins.contextbrowser: not updating box kdevplatform.sublime: view added in Sublime::Area(0x7ff1128dbc60, name = "debug") kdevplatform.shell: added view in Sublime::Area(0x7ff1128dbc60, name = "debug") , id "code_8168181" kdevplatform.shell: doing nothing because loading kdevplatform.shell: deleting 0 old views kdevplatform.language: highlighting du chain QUrl("file:///Users/bertin/work/src/new/KDE/KF5/kded-git/CMakeLists.txt") kdevplatform.language: highlighted QUrl("file:///Users/bertin/work/src/new/KDE/KF5/kded-git/CMakeLists.txt") in foreground kdevplatform.language: Creating change tracker for QUrl("file:///Users/bertin/work/src/new/KDE/KF5/kded-git/CMakeLists.txt") kdevplatform.language: Registered completion model kdevplatform.plugins.documentswitcher: got signal from mainwindow: KDevelop::MainWindow(0x7ff1128f5790, name = "MainWindow") "5:KF5 projects: kded-git" its area is: Sublime::Area(0x7ff1128e42d0, name = "code") "Code" adding view: KDevelop::TextView(0x7ff110410df0) "CMakeLists.txt" kdevplatform.shell: changing active view to KDevelop::TextView(0x7ff110410df0) doc KDevelop::TextDocument(0x7ff114d5af90, name = "CMakeLists.txt") mw KDevelop::MainWindow(0x7ff1128f5790, name = "MainWindow") kdevplatform.shell: setting new XMLGUI client KTextEditor::ViewPrivate(0x7ff119357fc0) kdevplatform.shell: Attempting to load "kdevastyle" - name: "AStyle Formatter Backend" kdevplatform.shell: Successfully loaded plugin "kdevastyle" from "/opt/local/share/qt5/plugins/kdevplatform/25/kdevastyle.so" - took: 3 ms kdevplatform.shell: add plugin AStylePlugin(0x7ff119531df0) "kdevastyle" kdevplatform.shell: Attempting to load "kdevcustomscript" - name: "Custom Script Formatter Backend" kdevplatform.shell: Successfully loaded plugin "kdevcustomscript" from "/opt/local/share/qt5/plugins/kdevplatform/25/kdevcustomscript.so" - took: 2 ms kdevplatform.shell: add plugin CustomScriptPlugin(0x7ff1194a6af0) "kdevcustomscript" kdevplatform.plugins.documentswitcher: moving view to front, list should now not contain this view anymore KDevelop::TextView(0x7ff110410df0) "CMakeLists.txt" kdevplatform.plugins.documentswitcher: current area is: Sublime::Area(0x7ff1128e42d0, name = "code") "Code" mainwnidow: KDevelop::MainWindow(0x7ff1128f5790, name = "MainWindow") "file:///Users/bertin/work/src/new/KDE/KF5/kded-git/CMakeLists.txt" kdevplatform.plugins.documentswitcher: idx of this view in list: -1 kdevplatform.plugins.contextbrowser: new doc: 0x7ff114d5afb0 new cursor: (0, 0) kdevplatform.plugins.contextbrowser: updating jump target kdevplatform.plugins.contextbrowser: updating history kdevplatform.plugins.contextbrowser: not updating box kdevplatform.plugins.contextbrowser: updating history kdevplatform.plugins.contextbrowser: not updating box Notice the "mainwnidow" ;) Then, closing that document (take a deep breath): kdevplatform.sublime: Closing view for "file:///Users/bertin/work/src/new/KDE/KF5/kded-git/CMakeLists.txt" views 3 in area Sublime::Area(0x7ff1128e42d0, name = "code") kdevplatform.sublime: index 0x7ff112879cf0 root 0x7ff112879cf0 kdevplatform.sublime: splitter QSplitter(0x7ff112c2cb50) container Sublime::Container(0x7ff1150580d0) kdevplatform.sublime: structure: "CMakeLists.txt" whole structure: "CMakeLists.txt" kdevplatform.plugins.documentswitcher: removing view, list should now not contain this view anymore KDevelop::TextView(0x7ff110410df0) "CMakeLists.txt" kdevplatform.plugins.documentswitcher: current area is: Sublime::Area(0x7ff1128e42d0, name = "code") "Code" mainwnidow: KDevelop::MainWindow(0x7ff1128f5790, name = "MainWindow") "5:KF5 projects: kded-git - [ kded-git:CMakeLists.txt ]" kdevplatform.plugins.documentswitcher: idx of this view in list: -1 kdevplatform.shell: clearing last XML GUI client KTextEditor::ViewPrivate(0x7ff119357fc0) kdevplatform.shell: removed view in Sublime::Area(0x7ff1128e42d0, name = "code") , id "code_8168181" kdevplatform.shell: recording change done to "code_8168181" kdevplatform.shell: saving "code_8168181" from area kdevplatform.shell: setting "code_8168181" persistent: false kdevplatform.shell: loading working-set "code_8168181" into area Sublime::Area(0x7ff1128dbc60, name = "debug") kdevplatform.shell: removed view in Sublime::Area(0x7ff1128dbc60, name = "debug") , id "code_8168181" kdevplatform.shell: doing nothing because loading kdevplatform.shell: recycling 1 old views kdevplatform.shell: deleting 1 old views qt.quick.dirty: QQuickWindowPrivate::updateDirtyNodes(): qt.quick.dirty: QSGNode: QQuickItem(0x7ff112cf2880, parent=0x7ff1190bdb10, geometry=0,0 632x30) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff112c47670, parent=0x7ff112c4d4d0, geometry=5,0 614x28) Content|Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff112c4a030, parent=0x7ff112c4d4d0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff112d037f0, parent=0x7ff112d037d0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff112d037d0, parent=0x7ff112d00d80, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff112d024c0, parent=0x7ff112d00d80, geometry=0,0 0x16) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff112d01340, parent=0x7ff112d00d80, geometry=0,1 14x14) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff112d00d80, parent=0x7ff112d00ae0, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112d00ae0, parent=0x7ff112d0c1a0, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112d0c1a0, parent=0x7ff112d093c0, geometry=6,6 612x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112cefbe0, parent=0x7ff11938a500, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112cec450, parent=0x7ff11938a500, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112cd7090, parent=0x7ff112cd2fb0, geometry=-1,-1 626x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112cd3d80, parent=0x7ff112cd2fb0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff112cd2fb0, parent=0x7ff11938a500, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff11938a500, parent=0x7ff112d093e0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112d093e0, parent=0x7ff112d093c0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112d093c0, parent=0x7ff112c4de20, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112c4de20, parent=0x7ff112c4d4d0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff112c4d930, parent=0x7ff112c4d4d0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff112c4d4d0, parent=0x7ff112c50170, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112c50170, parent=0x7ff112c53a90, geometry=4,6 624x18) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_61(0x7ff112c53a90, parent=0x7ff112c684f0, geometry=0,0 632x30) Window qt.quick.dirty: QSGNode: Plasma::SvgItem(0x7ff112c55f00, parent=0x7ff112c684f0, geometry=0,0 632x1) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem_QML_60(0x7ff112c59e80, parent=0x7ff112c684f0, geometry=0,0 632x30) Content|Window qt.quick.dirty: QSGNode: ListItem_QMLTYPE_59(0x7ff112c684f0, parent=0x7ff1190bdb10, geometry=0,240 632x30, z=1) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff112c8c940, parent=0x7ff112c93310, geometry=5,0 614x28) Content|Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff112c901b0, parent=0x7ff112c93310, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff112c7eef0, parent=0x7ff112c7f660, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff112c7f660, parent=0x7ff112c82100, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff112c80ce0, parent=0x7ff112c82100, geometry=0,0 0x16) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff112c811c0, parent=0x7ff112c82100, geometry=0,1 14x14) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff112c82100, parent=0x7ff112c81e60, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112c81e60, parent=0x7ff112c83640, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112c83640, parent=0x7ff112c85e00, geometry=6,6 612x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c67c10, parent=0x7ff112c785a0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c6c7a0, parent=0x7ff112c785a0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c70e70, parent=0x7ff112c75850, geometry=-1,-1 626x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c74540, parent=0x7ff112c75850, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff112c75850, parent=0x7ff112c785a0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff112c785a0, parent=0x7ff112c84500, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112c84500, parent=0x7ff112c85e00, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112c85e00, parent=0x7ff112c91700, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112c91700, parent=0x7ff112c93310, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff112c92740, parent=0x7ff112c93310, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff112c93310, parent=0x7ff112c94f20, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112c94f20, parent=0x7ff112c95df0, geometry=4,6 624x18) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_61(0x7ff112c95df0, parent=0x7ff112c1b140, geometry=0,0 632x30) Window qt.quick.dirty: QSGNode: Plasma::SvgItem(0x7ff112c97040, parent=0x7ff112c1b140, geometry=0,0 632x1) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem_QML_60(0x7ff112c9a440, parent=0x7ff112c1b140, geometry=0,0 632x30) Content|Window qt.quick.dirty: QSGNode: ListItem_QMLTYPE_59(0x7ff112c1b140, parent=0x7ff1190bdb10, geometry=0,210 632x30, z=1) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1128ea7d0, parent=0x7ff112c02a30, geometry=5,0 614x28) Content|Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff1128f8880, parent=0x7ff112c02a30, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff11289cc30, parent=0x7ff1128a7590, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff1128a7590, parent=0x7ff1128b9e90, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1128b1400, parent=0x7ff1128b9e90, geometry=0,0 0x16) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff1128b06b0, parent=0x7ff1128b9e90, geometry=0,1 14x14) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff1128b9e90, parent=0x7ff1128b9cb0, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1128b9cb0, parent=0x7ff1128c2fd0, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1128c2fd0, parent=0x7ff1128c9bd0, geometry=6,6 612x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112ca0ea0, parent=0x7ff112cb0e60, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112ca4170, parent=0x7ff112cb0e60, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112ca89a0, parent=0x7ff112cb0210, geometry=-1,-1 626x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112caf0f0, parent=0x7ff112cb0210, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff112cb0210, parent=0x7ff112cb0e60, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff112cb0e60, parent=0x7ff1128c9bf0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1128c9bf0, parent=0x7ff1128c9bd0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1128c9bd0, parent=0x7ff112c03380, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112c03380, parent=0x7ff112c02a30, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff112c02e90, parent=0x7ff112c02a30, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff112c02a30, parent=0x7ff112c10640, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112c10640, parent=0x7ff112c10420, geometry=4,6 624x18) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_61(0x7ff112c10420, parent=0x7ff1128bebe0, geometry=0,0 632x30) Window qt.quick.dirty: QSGNode: Plasma::SvgItem(0x7ff112c15e10, parent=0x7ff1128bebe0, geometry=0,0 632x1) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem_QML_60(0x7ff112c205f0, parent=0x7ff1128bebe0, geometry=0,0 632x30) Content|Window qt.quick.dirty: QSGNode: ListItem_QMLTYPE_59(0x7ff1128bebe0, parent=0x7ff1190bdb10, geometry=0,180 632x30, z=1) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff112c0e260, parent=0x7ff1128e7f20, geometry=5,0 614x28) Content|Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff1128dff10, parent=0x7ff1128e7f20, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff1128abe90, parent=0x7ff1128abe70, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff1128abe70, parent=0x7ff1128b70a0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1128b3010, parent=0x7ff1128b70a0, geometry=0,0 0x16) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff1128b5af0, parent=0x7ff1128b70a0, geometry=0,1 14x14) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff1128b70a0, parent=0x7ff1128b7080, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1128b7080, parent=0x7ff1128be7f0, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1128be7f0, parent=0x7ff1128c8220, geometry=6,6 612x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c2e700, parent=0x7ff1128903f0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c36c50, parent=0x7ff1128903f0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff11287c010, parent=0x7ff1128872c0, geometry=-1,-1 626x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112885e00, parent=0x7ff1128872c0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff1128872c0, parent=0x7ff1128903f0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff1128903f0, parent=0x7ff1128c8240, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1128c8240, parent=0x7ff1128c8220, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1128c8220, parent=0x7ff1128e45c0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1128e45c0, parent=0x7ff1128e7f20, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff1128e82c0, parent=0x7ff1128e7f20, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff1128e7f20, parent=0x7ff1128f4330, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1128f4330, parent=0x7ff1128f3f90, geometry=4,6 624x18) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_61(0x7ff1128f3f90, parent=0x7ff114c17330, geometry=0,0 632x30) Window qt.quick.dirty: QSGNode: Plasma::SvgItem(0x7ff112868aa0, parent=0x7ff114c17330, geometry=0,0 632x1) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem_QML_60(0x7ff112c0b390, parent=0x7ff114c17330, geometry=0,0 632x30) Content|Window qt.quick.dirty: QSGNode: ListItem_QMLTYPE_59(0x7ff114c17330, parent=0x7ff1190bdb10, geometry=0,150 632x30, z=1) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1128d5fa0, parent=0x7ff1193c4850, geometry=5,0 614x28) Content|Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff11288bd80, parent=0x7ff1193c4850, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff1128e6260, parent=0x7ff1128663e0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff1128663e0, parent=0x7ff112c4bc40, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1128b4330, parent=0x7ff112c4bc40, geometry=0,0 0x16) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff112c44b70, parent=0x7ff112c4bc40, geometry=0,1 14x14) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff112c4bc40, parent=0x7ff112c31630, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112c31630, parent=0x7ff119381180, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff119381180, parent=0x7ff11284dea0, geometry=6,6 612x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c27350, parent=0x7ff112ca98b0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c38db0, parent=0x7ff112ca98b0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c4b250, parent=0x7ff112c65960, geometry=-1,-1 626x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c622f0, parent=0x7ff112c65960, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff112c65960, parent=0x7ff112ca98b0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff112ca98b0, parent=0x7ff112c59dd0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112c59dd0, parent=0x7ff11284dea0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff11284dea0, parent=0x7ff112881880, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112881880, parent=0x7ff1193c4850, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff1128f54f0, parent=0x7ff1193c4850, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff1193c4850, parent=0x7ff1128a1370, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1128a1370, parent=0x7ff1128a12b0, geometry=4,6 624x18) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_61(0x7ff1128a12b0, parent=0x7ff1128f5d80, geometry=0,0 632x30) Window qt.quick.dirty: QSGNode: Plasma::SvgItem(0x7ff1128cd930, parent=0x7ff1128f5d80, geometry=0,0 632x1) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem_QML_60(0x7ff112c12c60, parent=0x7ff1128f5d80, geometry=0,0 632x30) Content|Window qt.quick.dirty: QSGNode: ListItem_QMLTYPE_59(0x7ff1128f5d80, parent=0x7ff1190bdb10, geometry=0,120 632x30, z=1) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff116345f60, parent=0x7ff116341700, geometry=5,0 614x28) Content|Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff1163435f0, parent=0x7ff116341700, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff1128ecb30, parent=0x7ff1128ecb10, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff1128ecb10, parent=0x7ff1128b24a0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff112cb1cd0, parent=0x7ff1128b24a0, geometry=0,0 0x16) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff112c36090, parent=0x7ff1128b24a0, geometry=0,1 14x14) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff1128b24a0, parent=0x7ff112cae8c0, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112cae8c0, parent=0x7ff112d08870, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112d08870, parent=0x7ff112c25ef0, geometry=6,6 612x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1128b1670, parent=0x7ff1128ae0a0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c2c610, parent=0x7ff1128ae0a0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1128b3d70, parent=0x7ff1128adab0, geometry=-1,-1 626x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff11287a870, parent=0x7ff1128adab0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff1128adab0, parent=0x7ff1128ae0a0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff1128ae0a0, parent=0x7ff1128dc940, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1128dc940, parent=0x7ff112c25ef0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112c25ef0, parent=0x7ff116342050, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff116342050, parent=0x7ff116341700, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff116341b60, parent=0x7ff116341700, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff116341700, parent=0x7ff11633ee60, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff11633ee60, parent=0x7ff11633e7e0, geometry=4,6 624x18) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_61(0x7ff11633e7e0, parent=0x7ff11630b960, geometry=0,0 632x30) Window qt.quick.dirty: QSGNode: Plasma::SvgItem(0x7ff11633cfd0, parent=0x7ff11630b960, geometry=0,0 632x1) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem_QML_60(0x7ff116339a50, parent=0x7ff11630b960, geometry=0,0 632x30) Content|Window qt.quick.dirty: QSGNode: ListItem_QMLTYPE_59(0x7ff11630b960, parent=0x7ff1190bdb10, geometry=0,90 632x30, z=1) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff116315b40, parent=0x7ff1163112d0, geometry=5,0 614x28) Content|Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff1163131d0, parent=0x7ff1163112d0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff116321960, parent=0x7ff1163220d0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff1163220d0, parent=0x7ff11631f5f0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff116320d90, parent=0x7ff11631f5f0, geometry=0,0 0x16) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff11631fbd0, parent=0x7ff11631f5f0, geometry=0,1 14x14) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff11631f5f0, parent=0x7ff11631f330, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff11631f330, parent=0x7ff11631e010, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff11631e010, parent=0x7ff11631b0f0, geometry=6,6 612x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1163348d0, parent=0x7ff116328870, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff116331160, parent=0x7ff116328870, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff11632dbe0, parent=0x7ff116329a30, geometry=-1,-1 626x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff11632a8c0, parent=0x7ff116329a30, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff116329a30, parent=0x7ff116328870, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff116328870, parent=0x7ff11631dad0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff11631dad0, parent=0x7ff11631b0f0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff11631b0f0, parent=0x7ff116311c20, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff116311c20, parent=0x7ff1163112d0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff116311730, parent=0x7ff1163112d0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff1163112d0, parent=0x7ff11630ea30, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff11630ea30, parent=0x7ff11630e3b0, geometry=4,6 624x18) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_61(0x7ff11630e3b0, parent=0x7ff116308cf0, geometry=0,0 632x30) Window qt.quick.dirty: QSGNode: Plasma::SvgItem(0x7ff11630cba0, parent=0x7ff116308cf0, geometry=0,0 632x1) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem_QML_60(0x7ff1163093e0, parent=0x7ff116308cf0, geometry=0,0 632x30) Content|Window qt.quick.dirty: QSGNode: ListItem_QMLTYPE_59(0x7ff116308cf0, parent=0x7ff1190bdb10, geometry=0,60 632x30, z=1) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1190eb7e0, parent=0x7ff1190e70e0, geometry=5,0 614x28) Content|Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff1190e8f60, parent=0x7ff1190e70e0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff1190f7b80, parent=0x7ff1190f7b60, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff1190f7b60, parent=0x7ff1190f5260, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1190f69a0, parent=0x7ff1190f5260, geometry=0,0 0x16) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff1190f5820, parent=0x7ff1190f5260, geometry=0,1 14x14) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff1190f5260, parent=0x7ff1190f4fc0, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1190f4fc0, parent=0x7ff1190f3d20, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1190f3d20, parent=0x7ff1190f0f20, geometry=6,6 612x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff11940e300, parent=0x7ff119402300, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff11940aba0, parent=0x7ff119402300, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff119407560, parent=0x7ff119403440, geometry=-1,-1 626x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff119404210, parent=0x7ff119403440, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff119403440, parent=0x7ff119402300, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff119402300, parent=0x7ff1190f0f40, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1190f0f40, parent=0x7ff1190f0f20, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1190f0f20, parent=0x7ff1190e7a30, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1190e7a30, parent=0x7ff1190e70e0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff1190e7540, parent=0x7ff1190e70e0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff1190e70e0, parent=0x7ff1190e4840, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1190e4840, parent=0x7ff1190e41c0, geometry=4,6 624x18) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_61(0x7ff1190e41c0, parent=0x7ff1190deb70, geometry=0,0 632x30) Window qt.quick.dirty: QSGNode: Plasma::SvgItem(0x7ff1190e29b0, parent=0x7ff1190deb70, geometry=0,0 632x1) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem_QML_60(0x7ff1190df260, parent=0x7ff1190deb70, geometry=0,0 632x30) Content|Window qt.quick.dirty: QSGNode: ListItem_QMLTYPE_59(0x7ff1190deb70, parent=0x7ff1190bdb10, geometry=0,30 632x30, z=1) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1170da3a0, parent=0x7ff1170d5ca0, geometry=5,0 614x28) Content|Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff1170d7b20, parent=0x7ff1170d5ca0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff1170e80f0, parent=0x7ff1170e7a70, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff1170e7a70, parent=0x7ff1170e5680, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1170e6dc0, parent=0x7ff1170e5680, geometry=0,0 0x16) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff1170e5c40, parent=0x7ff1170e5680, geometry=0,1 14x14) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff1170e5680, parent=0x7ff1170e53e0, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1170e53e0, parent=0x7ff1170e4140, geometry=0,0 612x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1170e4140, parent=0x7ff1170e14b0, geometry=6,6 612x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1190d9480, parent=0x7ff1170ee790, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1170f7030, parent=0x7ff1170ee790, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1170f39f0, parent=0x7ff1170ef8d0, geometry=-1,-1 626x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1170f06a0, parent=0x7ff1170ef8d0, geometry=0,0 624x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff1170ef8d0, parent=0x7ff1170ee790, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff1170ee790, parent=0x7ff1170e14d0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1170e14d0, parent=0x7ff1170e14b0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1170e14b0, parent=0x7ff1170d65f0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1170d65f0, parent=0x7ff1170d5ca0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff1170d6100, parent=0x7ff1170d5ca0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff1170d5ca0, parent=0x7ff1170d34c0, geometry=0,0 624x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1170d34c0, parent=0x7ff1170d31e0, geometry=4,6 624x18) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_61(0x7ff1170d31e0, parent=0x7ff1170cc700, geometry=0,0 632x30) Window qt.quick.dirty: QSGNode: Plasma::SvgItem(0x7ff1170d1360, parent=0x7ff1170cc700, geometry=0,0 632x1) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem_QML_60(0x7ff1170ccdf0, parent=0x7ff1170cc700, geometry=0,0 632x30) Content|Window qt.quick.dirty: QSGNode: ListItem_QMLTYPE_59(0x7ff1170cc700, parent=0x7ff1190bdb10, geometry=0,0 632x30, z=1) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1170c0f10, parent=0x7ff1190bdb10, geometry=0,-42 67.1406x42, z=1) Content|Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1190bdb10, parent=0x7ff1190bdaf0, geometry=0,42 632x312) Window qt.quick.dirty: QSGNode: QQuickListView(0x7ff1190bdaf0, parent=0x7ff1190a9e20, geometry=30,57 632x852) Size|Window qt.quick.dirty: QSGNode: QQuickItem_QML_58(0x7ff1190761d0, parent=0x7ff119099370, geometry=-319,0 638x28) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff1190bace0, parent=0x7ff11909fe70, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff112cd9c30, parent=0x7ff112cd9c10, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff112cd9c10, parent=0x7ff112cf9730, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff112cfae90, parent=0x7ff112cf9730, geometry=19,1 113x14) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff112cf9cf0, parent=0x7ff112cf9730, geometry=0,0 16x16) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff112cf9730, parent=0x7ff112cf9490, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112cf9490, parent=0x7ff112cf81e0, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112cf81e0, parent=0x7ff112cf54d0, geometry=6,6 132x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112cb36e0, parent=0x7ff112cc1630, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112cbb0b0, parent=0x7ff112cc1630, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112cb7b30, parent=0x7ff112cbc540, geometry=-1,-1 146x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112cbd310, parent=0x7ff112cbc540, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff112cbc540, parent=0x7ff112cc1630, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff112cc1630, parent=0x7ff112cf54f0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112cf54f0, parent=0x7ff112cf54d0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112cf54d0, parent=0x7ff1190b97b0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1190b97b0, parent=0x7ff11909fe70, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff11909fc30, parent=0x7ff11909fe70, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff11909fe70, parent=0x7ff11909cbe0, geometry=432,0 144x28) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff1190b59c0, parent=0x7ff1190b3b40, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff112cc55c0, parent=0x7ff112cc55a0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff112cc55a0, parent=0x7ff112ce4ab0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff112cc19c0, parent=0x7ff112ce4ab0, geometry=19,1 113x14) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff112ce33b0, parent=0x7ff112ce4ab0, geometry=0,0 16x16) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff112ce4ab0, parent=0x7ff112ce4810, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112ce4810, parent=0x7ff112cebb00, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112cebb00, parent=0x7ff112cf7840, geometry=6,6 132x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112d172b0, parent=0x7ff112cccc30, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112d13b40, parent=0x7ff112cccc30, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112cd1e60, parent=0x7ff112ccdd70, geometry=-1,-1 146x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112cceb50, parent=0x7ff112ccdd70, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff112ccdd70, parent=0x7ff112cccc30, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff112cccc30, parent=0x7ff112cf7860, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112cf7860, parent=0x7ff112cf7840, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112cf7840, parent=0x7ff1190b4490, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1190b4490, parent=0x7ff1190b3b40, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff1190b3fa0, parent=0x7ff1190b3b40, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff1190b3b40, parent=0x7ff11909cbe0, geometry=288,0 144x28) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff1190b06c0, parent=0x7ff11909ff10, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff112d22b60, parent=0x7ff112d22b40, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff112d22b40, parent=0x7ff112d20090, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff112d217d0, parent=0x7ff112d20090, geometry=19,1 113x14) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff112d20650, parent=0x7ff112d20090, geometry=0,0 16x16) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff112d20090, parent=0x7ff112d1fdf0, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112d1fdf0, parent=0x7ff112d1eb50, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112d1eb50, parent=0x7ff112ceb090, geometry=6,6 132x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c2b090, parent=0x7ff112d29d10, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112c4be30, parent=0x7ff112d29d10, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112858790, parent=0x7ff112d2b320, geometry=-1,-1 146x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112d2c0f0, parent=0x7ff112d2b320, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff112d2b320, parent=0x7ff112d29d10, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff112d29d10, parent=0x7ff112ceb0b0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112ceb0b0, parent=0x7ff112ceb090, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112ceb090, parent=0x7ff1190af190, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1190af190, parent=0x7ff11909ff10, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff1190aeca0, parent=0x7ff11909ff10, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff11909ff10, parent=0x7ff11909cbe0, geometry=144,0 144x28) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff11909f740, parent=0x7ff11909cda0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff1193c07b0, parent=0x7ff1193c0790, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff1193c0790, parent=0x7ff112c00670, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1128f16a0, parent=0x7ff112c00670, geometry=19,1 113x14) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff1128f6500, parent=0x7ff112c00670, geometry=0,0 16x16) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff112c00670, parent=0x7ff112c00650, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112c00650, parent=0x7ff112d1e060, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112d1e060, parent=0x7ff112c01400, geometry=6,6 132x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1193af9e0, parent=0x7ff1128f9b00, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1193b1fb0, parent=0x7ff1128f9b00, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1128e7370, parent=0x7ff119391020, geometry=-1,-1 146x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff119398820, parent=0x7ff119391020, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff119391020, parent=0x7ff1128f9b00, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff1128f9b00, parent=0x7ff112c01420, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112c01420, parent=0x7ff112c01400, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112c01400, parent=0x7ff119076730, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff119076730, parent=0x7ff11909cda0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff119078ed0, parent=0x7ff11909cda0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff11909cda0, parent=0x7ff11909cbe0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickFlow(0x7ff11909cbe0, parent=0x7ff11909c910, geometry=0,0 638x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_57(0x7ff11909c910, parent=0x7ff119099370, geometry=0,0 638x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff119099370, parent=0x7ff11909df70, geometry=2,2 638x28) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff119079800, parent=0x7ff11909df70, geometry=-2,-1 646x34) Content|Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1190a0600, parent=0x7ff11909df70, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolBar_QMLTYPE_55(0x7ff11909df70, parent=0x7ff1190a9e20, geometry=25,25 642x32, z=1000) Window qt.quick.dirty: QSGNode: IconItem(0x7ff1190a0a00, parent=0x7ff1190a9e20, geometry=559,806 128x128) Position|Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1190a9e20, parent=0x7ff11638f730, geometry=0,0 692x939) Size|Content|Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff11638f730, parent=0x7ff117071d10, geometry=194,5 692x939) Size|Window qt.quick.dirty: QSGNode: IconItem(0x7ff11639c510, parent=0x7ff117071d10, geometry=5,880 64x64) Position|Content|Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff11719f5d0, parent=0x7ff116391d20, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff1178e7880, parent=0x7ff1162912b0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff1162912b0, parent=0x7ff11626cd40, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff11628fcc0, parent=0x7ff11626cd40, geometry=19,1 113x14) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff11626ee20, parent=0x7ff11626cd40, geometry=0,0 16x16) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff11626cd40, parent=0x7ff11626cd20, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff11626cd20, parent=0x7ff11629a190, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff11629a190, parent=0x7ff1162626b0, geometry=6,6 132x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112bd7940, parent=0x7ff11779f690, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1178eb2a0, parent=0x7ff11779f690, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff119010b30, parent=0x7ff11900b3d0, geometry=-1,-1 146x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff11900c160, parent=0x7ff11900b3d0, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff11900b3d0, parent=0x7ff11779f690, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff11779f690, parent=0x7ff116269280, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff116269280, parent=0x7ff1162626b0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1162626b0, parent=0x7ff11719e010, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff11719e010, parent=0x7ff116391d20, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff11719db00, parent=0x7ff116391d20, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff116391d20, parent=0x7ff11639f1a0, geometry=0,38 144x28) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff11719a0e0, parent=0x7ff117145790, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff1178f96d0, parent=0x7ff1178f96b0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff1178f96b0, parent=0x7ff1178c4930, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff1178f8340, parent=0x7ff1178c4930, geometry=19,1 113x14) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff117cbade0, parent=0x7ff1178c4930, geometry=0,0 16x16) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff1178c4930, parent=0x7ff1178c4690, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1178c4690, parent=0x7ff1178c33f0, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1178c33f0, parent=0x7ff1178a6260, geometry=6,6 132x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112b5a900, parent=0x7ff112bcf4a0, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112b7a3c0, parent=0x7ff112bcf4a0, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112b6e8a0, parent=0x7ff112bc6bd0, geometry=-1,-1 146x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff112bc79a0, parent=0x7ff112bc6bd0, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff112bc6bd0, parent=0x7ff112bcf4a0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff112bcf4a0, parent=0x7ff1178de430, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1178de430, parent=0x7ff1178a6260, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff1178a6260, parent=0x7ff117198b20, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff117198b20, parent=0x7ff117145790, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff117198610, parent=0x7ff117145790, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff117145790, parent=0x7ff11639f1a0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickMouseArea_QML_39(0x7ff1163a7c80, parent=0x7ff1163a6830, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_46(0x7ff112b55070, parent=0x7ff112b55050, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ConditionalLoader_QMLTYPE_45(0x7ff112b55050, parent=0x7ff112b53ad0, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: QQuickText(0x7ff112b62590, parent=0x7ff112b53ad0, geometry=19,1 113x14) Content|Window qt.quick.dirty: QSGNode: IconItem(0x7ff112b54090, parent=0x7ff112b53ad0, geometry=0,0 16x16) Content|Window qt.quick.dirty: QSGNode: QQuickRowLayout_QML_49(0x7ff112b53ad0, parent=0x7ff112b53830, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112b53830, parent=0x7ff112b52590, geometry=0,0 132x16) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112b52590, parent=0x7ff112b600d0, geometry=6,6 132x16) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff119085900, parent=0x7ff119094ac0, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff119082190, parent=0x7ff119094ac0, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1190928b0, parent=0x7ff119091790, geometry=-1,-1 146x30) Content|Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff119095e60, parent=0x7ff119091790, geometry=0,0 144x28) Content|Window qt.quick.dirty: QSGNode: ButtonShadow_QMLTYPE_47(0x7ff119091790, parent=0x7ff119094ac0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem_QML_53(0x7ff119094ac0, parent=0x7ff112b600f0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff112b600f0, parent=0x7ff112b600d0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickItem(0x7ff112b600d0, parent=0x7ff1163a7180, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader(0x7ff1163a7180, parent=0x7ff1163a6830, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_37(0x7ff1163a6cb0, parent=0x7ff1163a6830, geometry=0,0 0x0) Window qt.quick.dirty: QSGNode: ToolButton_QMLTYPE_54(0x7ff1163a6830, parent=0x7ff11639f1a0, geometry=0,0 144x28) Window qt.quick.dirty: QSGNode: ButtonColumn_QMLTYPE_3(0x7ff11639f1a0, parent=0x7ff11638e0c0, geometry=0,0 144x66) Window qt.quick.dirty: QSGNode: QQuickLoader_QML_5(0x7ff11638e0c0, parent=0x7ff117061620, geometry=20,20 144x66) Window qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff117061620, parent=0x7ff117071d10, geometry=5,5 184x106) Content|Window qt.quick.dirty: QSGNode: StandardBackground_QMLTYPE_4(0x7ff117071d10, parent=0x7ff117ba94e0, geometry=0,0 891x949) Size|Content|Window qt.quick.dirty: QSGNode: QQuickLoader_QML_2(0x7ff117ba94e0, parent=0x7ff117ba8eb0, geometry=0,0 891x949) Size|Window qt.quick.dirty: QSGNode: QQuickRectangle(0x7ff117ba8eb0, parent=0x7ff117d45de0, geometry=0,0 891x949) Size|Content|Window qt.quick.dirty: QSGNode: QQuickRootItem(0x7ff117d45de0, parent=0x0, geometry=0,0 0x0) Window qt.quick.mouse: QQuickWindow::mouseMoveEvent() QPointF(131,4) 0 QFlags(NoButton) qt.quick.dirty: QQuickWindowPrivate::updateDirtyNodes(): qt.quick.dirty: QSGNode: IconItem(0x7ff11639c510, parent=0x7ff117071d10, geometry=5,886 64x64) Position qt.quick.dirty: QSGNode: IconItem(0x7ff1190a0a00, parent=0x7ff1190a9e20, geometry=559,812 128x128) Position qt.quick.dirty: QSGNode: QQuickListView(0x7ff1190bdaf0, parent=0x7ff1190a9e20, geometry=30,57 632x858) Size qt.quick.dirty: QSGNode: Plasma::FrameSvgItem(0x7ff1190a9e20, parent=0x7ff11638f730, geometry=0,0 692x945) Size qt.quick.dirty: QSGNode: QQuickLoader(0x7ff11638f730, parent=0x7ff117071d10, geometry=194,5 692x945) Size qt.quick.dirty: QSGNode: StandardBackground_QMLTYPE_4(0x7ff117071d10, parent=0x7ff117ba94e0, geometry=0,0 891x955) Size qt.quick.dirty: QSGNode: QQuickLoader_QML_2(0x7ff117ba94e0, parent=0x7ff117ba8eb0, geometry=0,0 891x955) Size qt.quick.dirty: QSGNode: QQuickRectangle(0x7ff117ba8eb0, parent=0x7ff117d45de0, geometry=0,0 891x955) Size qt.quick.dirty: QQuickWindowPrivate::updateDirtyNodes(): qt.quick.mouse: QQuickWindow::mouseMoveEvent() QPointF(118,10) 0 QFlags(NoButton) qt.quick.mouse: QQuickWindow::mouseMoveEvent() QPointF(97,10) 0 QFlags(NoButton) qt.quick.mouse: QQuickWindow::mouseMoveEvent() QPointF(20,4) 0 QFlags(NoButton) Enjoy! R. From announce at qt-project.org Wed Mar 23 12:35:33 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 23 Mar 2016 11:35:33 +0000 Subject: [Development] [Announce] Qt Creator 4.0 Beta released Message-ID: We are happy to announce the release of Qt Creator 4.0 Beta1! https://blog.qt.io/blog/2016/03/23/qt-creator-4-0-beta-released/ -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From BCheng at intercalleurope.com Wed Mar 23 13:08:33 2016 From: BCheng at intercalleurope.com (Cheng, Bobber) Date: Wed, 23 Mar 2016 12:08:33 +0000 Subject: [Development] Cannot compile Qt 5.7 alpha with MSVC 2013/2015 Message-ID: <0606501861F0A446AC23CAD47518E5B916CC1465A3@lon01cexmbx01.us.intercall.com> Hi team, Did anyone compile Qt 5.7 alpha with MSVC 2013/2015? I got following error just when compiling qlatincodec.cpp. d:\qt\5.7.0\qtbase\include\qtcore\../../src/corelib/global/qflags.h(58): error C2220: warning treated as error - no 'object' file generated (compiling source fi le ..\..\corelib\codecs\qlatincodec.cpp) d:\qt\5.7.0\qtbase\include\qtcore\../../src/corelib/global/qflags.h(58): warning C4577: 'noexcept' used with no exception handling mode specified; termination o n exception is not guaranteed. Specify /EHsc (compiling source file ..\..\corelib\codecs\qlatincodec.cpp) d:\qt\5.7.0\qtbase\include\qtcore\../../src/corelib/global/qflags.h(58): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings (compiling source file ..\..\corelib\codecs\qlatincodec.cpp) d:\qt\5.7.0\qtbase\include\qtcore\../../src/corelib/global/qflags.h(58): error C2220: warning treated as error - no 'object' file generated (compiling source fi le ..\..\corelib\codecs\qutfcodec.cpp) d:\qt\5.7.0\qtbase\include\qtcore\../../src/corelib/global/qflags.h(58): warning C4577: 'noexcept' used with no exception handling mode specified; termination o n exception is not guaranteed. Specify /EHsc (compiling source file ..\..\corelib\codecs\qutfcodec.cpp) d:\qt\5.7.0\qtbase\include\qtcore\../../src/corelib/global/qflags.h(58): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings (compiling source file ..\..\corelib\codecs\qutfcodec.cpp) d:\qt\5.7.0\qtbase\include\qtcore\../../src/corelib/global/qflags.h(58): error C2220: warning treated as error - no 'object' file generated (compiling source fi le ..\..\corelib\codecs\qtextcodec.cpp) d:\qt\5.7.0\qtbase\include\qtcore\../../src/corelib/global/qflags.h(58): warning C4577: 'noexcept' used with no exception handling mode specified; termination o n exception is not guaranteed. Specify /EHsc (compiling source file ..\..\corelib\codecs\qtextcodec.cpp) d:\qt\5.7.0\qtbase\include\qtcore\../../src/corelib/global/qflags.h(58): note: to simplify migration, consider the temporary use of /Wv:18 flag with the version of the compiler with which you used to build without warnings (compiling source file ..\..\corelib\codecs\qtextcodec.cpp) NMAKE : fatal error U1077: '"D:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\cl.EXE"' : return code '0x2' Stop. NMAKE : fatal error U1077: '"D:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. Did I missed anything? I used following configure options: D:\Qt\5.7.0>configure -confirm-license -opensource -qt-sql-sqlite -debug-and-release -nomake tests -nomake examples -openssl -I D:\dev_ium5\common\ThirdParty\openssl_1.0.1\include -L D:\dev_ium5\common\ThirdParty\openssl_1.0.1\lib -mp -I D:\dev_ium5\common\ThirdParty\ICU\include -L D:\dev_ium5\common\ThirdParty\ICU\lib -opengl desktop -no-qml-debug -developer-build Thanks, Bobber -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Mar 23 15:01:56 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 23 Mar 2016 14:01:56 +0000 Subject: [Development] Cannot compile Qt 5.7 alpha with MSVC 2013/2015 In-Reply-To: <0606501861F0A446AC23CAD47518E5B916CC1465A3@lon01cexmbx01.us.intercall.com> References: <0606501861F0A446AC23CAD47518E5B916CC1465A3@lon01cexmbx01.us.intercall.com> Message-ID: <2797483.roaC5eekuZ@tjmaciei-mobl4> On quarta-feira, 23 de março de 2016 12:08:33 GMT Cheng, Bobber wrote: > Did anyone compile Qt 5.7 alpha with MSVC 2013/2015? I got following error > just when compiling qlatincodec.cpp. Is that corelib or is that the bootstrap lib? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From BCheng at intercalleurope.com Wed Mar 23 16:38:07 2016 From: BCheng at intercalleurope.com (Cheng, Bobber) Date: Wed, 23 Mar 2016 15:38:07 +0000 Subject: [Development] Cannot compile Qt 5.7 alpha with MSVC 2013/2015 In-Reply-To: <2797483.roaC5eekuZ@tjmaciei-mobl4> References: <0606501861F0A446AC23CAD47518E5B916CC1465A3@lon01cexmbx01.us.intercall.com>, <2797483.roaC5eekuZ@tjmaciei-mobl4> Message-ID: <0606501861F0A446AC23CAD47518E5B916CB4B7B57@lon01cexmbx01.us.intercall.com> It's corelib. Thanks, Bobber ________________________________________ From: Development [development-bounces+bcheng=intercalleurope.com at qt-project.org] On Behalf Of Thiago Macieira [thiago.macieira at intel.com] Sent: Wednesday, March 23, 2016 10:01 PM To: development at qt-project.org Subject: Re: [Development] Cannot compile Qt 5.7 alpha with MSVC 2013/2015 On quarta-feira, 23 de março de 2016 12:08:33 GMT Cheng, Bobber wrote: > Did anyone compile Qt 5.7 alpha with MSVC 2013/2015? I got following error > just when compiling qlatincodec.cpp. Is that corelib or is that the bootstrap lib? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Mar 23 21:22:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 23 Mar 2016 16:22:14 -0400 Subject: [Development] Cannot compile Qt 5.7 alpha with MSVC 2013/2015 In-Reply-To: <0606501861F0A446AC23CAD47518E5B916CB4B7B57@lon01cexmbx01.us.intercall.com> References: <0606501861F0A446AC23CAD47518E5B916CC1465A3@lon01cexmbx01.us.intercall.com> <2797483.roaC5eekuZ@tjmaciei-mobl4> <0606501861F0A446AC23CAD47518E5B916CB4B7B57@lon01cexmbx01.us.intercall.com> Message-ID: <2325832.5NXFritjjo@tjmaciei-mobl4> On quarta-feira, 23 de março de 2016 15:38:07 EDT Cheng, Bobber wrote: > It's corelib. Corelib is compiled with exceptions enabled. The compiler should not be complaining about the lack of compiler options. Please paste the command-line for the compiler that nmake/jom printed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Yves.Bailly at verosoftware.com Thu Mar 24 11:10:16 2016 From: Yves.Bailly at verosoftware.com (Yves Bailly) Date: Thu, 24 Mar 2016 10:10:16 +0000 Subject: [Development] Can't login on bugreports.qt.io Message-ID: Hello all, Asking here, as I'm not sure where to ask. I want to login on https://bugreports.qt.io I'm redirected to a page on https://login.qt.io asking me to approve, two buttons "Allow" and "Deny" - I click "Allow" Then a page ask me to choose a username, suggesting two, with a button "Set username". I click on it... ... then I get a blank page showing nothing else than "Internal Server Error". Any help is welcome... -- Yves Bailly Software developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From aj at elane2k.com Thu Mar 24 12:10:48 2016 From: aj at elane2k.com (=?UTF-8?Q?Adrian_J=c3=a4kel?=) Date: Thu, 24 Mar 2016 12:10:48 +0100 Subject: [Development] Problems with QtWebKit 5.6 / Please do not remove QtWebkit from 5.6 official binaries In-Reply-To: References: <20160306184038.GA1823@mitya57.me> <6662734.fBvtamcyqx@tjmaciei-mobl4> <2895616.hELZig6gvc@patux.local> <1723238.3Mm95X17ag@tjmaciei-mobl4> <56EEE518.1090509@elane2k.com> Message-ID: <56F3CB38.8090608@elane2k.com> Sorry, i wasnt able to do it earlier. https://bugreports.qt.io/browse/QTBUG-52113 Regards, Adrian Am 21.03.2016 um 08:03 schrieb Koehne Kai: > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of >> Adrian Jakel >> Sent: Sunday, March 20, 2016 7:00 PM >> To: development at qt-project.org >> Subject: Re: [Development] Problems with QtWebKit 5.6 / Please do not >> remove QtWebkit from 5.6 official binaries >> >> Out of curiosity and because it has not been said in the discussion >> afaik: Is it planned to correct the current tarball or at least the next one for >> the upcoming Qt 5.6.1 ? It seems like an easy fix to me and im wondering >> why it hasnt been done yet? Or am i missing something? > I guess we'll try to fix it. Could you create a bug report about this? > > Kai > > PS: Everyone: Please create bug reports for (serious) issues! A mail to the mailing list isn't a proper replacement ... From tero.kojo at theqtcompany.com Thu Mar 24 12:11:47 2016 From: tero.kojo at theqtcompany.com (Kojo Tero) Date: Thu, 24 Mar 2016 11:11:47 +0000 Subject: [Development] Can't login on bugreports.qt.io In-Reply-To: References: Message-ID: Hi, I’ll get you in contact with the Qt Account people. Sounds like some mixup with the username. Best, Tero From: Development [mailto:development-bounces+tero.kojo=theqtcompany.com at qt-project.org] On Behalf Of Yves Bailly Sent: 24. maaliskuuta 2016 12:10 To: development at qt-project.org Subject: [Development] Can't login on bugreports.qt.io Hello all, Asking here, as I'm not sure where to ask. I want to login on https://bugreports.qt.io I'm redirected to a page on https://login.qt.io asking me to approve, two buttons "Allow" and "Deny" - I click "Allow" Then a page ask me to choose a username, suggesting two, with a button "Set username". I click on it... ... then I get a blank page showing nothing else than "Internal Server Error". Any help is welcome... -- Yves Bailly Software developer -------------- next part -------------- An HTML attachment was scrubbed... URL: From BCheng at intercalleurope.com Thu Mar 24 12:34:50 2016 From: BCheng at intercalleurope.com (Cheng, Bobber) Date: Thu, 24 Mar 2016 11:34:50 +0000 Subject: [Development] Cannot compile Qt 5.7 alpha with MSVC 2013/2015 In-Reply-To: <2325832.5NXFritjjo@tjmaciei-mobl4> References: <0606501861F0A446AC23CAD47518E5B916CC1465A3@lon01cexmbx01.us.intercall.com> <2797483.roaC5eekuZ@tjmaciei-mobl4> <0606501861F0A446AC23CAD47518E5B916CB4B7B57@lon01cexmbx01.us.intercall.com> <2325832.5NXFritjjo@tjmaciei-mobl4> Message-ID: <0606501861F0A446AC23CAD47518E5B916CC146600@lon01cexmbx01.us.intercall.com> The issue went away once I installed MSVC 2013 update 5. However, I still get lots of encode error like: ..\..\corelib\tools\qstring.cpp(1650) : warning C4819: The file contains a character that cannot be represented in the current code page (936). Save the file in Unicode format to prevent data loss. I have to save qstring.cpp as Unicode format to remove this warning. Any suggestion for it? Thanks, Bobber -----Original Message----- From: Development [mailto:development-bounces+bcheng=intercalleurope.com at qt-project.org] On Behalf Of Thiago Macieira Sent: Thursday, March 24, 2016 4:22 AM To: development at qt-project.org Subject: Re: [Development] Cannot compile Qt 5.7 alpha with MSVC 2013/2015 On quarta-feira, 23 de março de 2016 15:38:07 EDT Cheng, Bobber wrote: > It's corelib. Corelib is compiled with exceptions enabled. The compiler should not be complaining about the lack of compiler options. Please paste the command-line for the compiler that nmake/jom printed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Mar 24 17:13:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 24 Mar 2016 09:13:50 -0700 Subject: [Development] Cannot compile Qt 5.7 alpha with MSVC 2013/2015 In-Reply-To: <0606501861F0A446AC23CAD47518E5B916CC146600@lon01cexmbx01.us.intercall.com> References: <0606501861F0A446AC23CAD47518E5B916CC1465A3@lon01cexmbx01.us.intercall.com> <2325832.5NXFritjjo@tjmaciei-mobl4> <0606501861F0A446AC23CAD47518E5B916CC146600@lon01cexmbx01.us.intercall.com> Message-ID: <7012085.PY7sNEW3VE@tjmaciei-mobl4> On quinta-feira, 24 de março de 2016 11:34:50 PDT Cheng, Bobber wrote: > The issue went away once I installed MSVC 2013 update 5. However, I still > get lots of encode error like: > > > > ..\..\corelib\tools\qstring.cpp(1650) : warning C4819: The file contains a > character that cannot be represented in the current code page (936). Save > the file in > > Unicode format to prevent data loss. I've never seen that error before. Can you tell us what's on that line for you? The current line 1650 in oigin/5.7 is in the middle of a comment and is US- ASCII only 0000000 e x t e n d e d t o 0000020 m a k e i t \ a s i z e 0000040 c h a r a c t e r s l o n g 0000060 w i t h t h e e x t r a \n 0000077 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Fri Mar 25 04:28:25 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 25 Mar 2016 04:28:25 +0100 Subject: [Development] tarball fetches from code.qt.io? References: <2000886.r6WD1beTJ9@patux> Message-ID: René J.V. Bertin wrote: > Is there a way to do tarball fetches from code.qt.io that correspond to a > specific commit, tag or release (for QtWebKit; purely for convenience in a > distribution/packaging script)? You can use the GitHub mirror: wget https://github.com/qtproject/qtwebkit/archive/7205faf1a546a690f68176989100109e9a3335b7/qtwebkit-snapshot.tar.gz I'm no fan of the proprietary GitHub infrastructure, but in this case it does what you want. Kevin Kofler From rjvbertin at gmail.com Fri Mar 25 12:57:44 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 25 Mar 2016 12:57:44 +0100 Subject: [Development] tarball fetches from code.qt.io? References: <2000886.r6WD1beTJ9@patux> Message-ID: <1654428.Azk8g7Is4t@portia.local> Kevin Kofler wrote: > https://github.com/qtproject/qtwebkit/archive/7205faf1a546a690f68176989100109e9a3335b7/qtwebkit-snapshot.tar.gz > > I'm no fan of the proprietary GitHub infrastructure, but in this case it > does what you want. Great, thanks! Somehow I missed that mirror, I only found a fork. R. From armagvvg at gmail.com Fri Mar 25 20:58:10 2016 From: armagvvg at gmail.com (Vyacheslav Grigoryev) Date: Fri, 25 Mar 2016 22:58:10 +0300 Subject: [Development] Fix for QTBUG-50171: should I put it in 5.6 or 5.7 branch for review Message-ID: <000a01d186d0$a88dcd40$f9a967c0$@gmail.com> Hi, 9 March I’ve fixed a bug QTBUG-50171 (review at https://codereview.qt-project.org/151861). It is related to fixing broken selection of rows or columns in a QTableView after user reordered them. And I still have no any progress with a review process. May somebody advise me what should I do to propagate it into main branch? I’ve submitted it into 5.6 branch but after that the branch was released recently. Does it mean that all patches for 5.6 aren’t actual anymore? Maybe I should resubmit it for 5.7? Best wishes, Vyacheslav -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Fri Mar 25 22:52:10 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 25 Mar 2016 22:52:10 +0100 Subject: [Development] Fix for QTBUG-50171: should I put it in 5.6 or 5.7 branch for review In-Reply-To: <000a01d186d0$a88dcd40$f9a967c0$@gmail.com> References: <000a01d186d0$a88dcd40$f9a967c0$@gmail.com> Message-ID: <56F5B30A.9040106@kdab.com> Hi, Il 25/03/2016 20:58, Vyacheslav Grigoryev ha scritto: > 9 March I’ve fixed a bug QTBUG-50171 (review at > https://codereview.qt-project.org/151861). It is related to fixing > broken selection of rows or columns in a QTableView after user reordered > them. And I still have no any progress with a review process. > > May somebody advise me what should I do to propagate it into main > branch? I’ve submitted it into 5.6 branch but after that the branch was > released recently. Does it mean that all patches for 5.6 aren’t actual > anymore? Maybe I should resubmit it for 5.7? Thank you for your patch! For ordinary bugfixes 5.6 is the right branch to target. It will get merged forward (in 5.7, etc.) automatically. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From armagvvg at gmail.com Mon Mar 28 10:57:17 2016 From: armagvvg at gmail.com (Vyacheslav Grigoryev) Date: Mon, 28 Mar 2016 11:57:17 +0300 Subject: [Development] Fix for QTBUG-50171: should I put it in 5.6 or 5.7 branch for review In-Reply-To: <56F5B30A.9040106@kdab.com> References: <000a01d186d0$a88dcd40$f9a967c0$@gmail.com> <56F5B30A.9040106@kdab.com> Message-ID: Hi Giuseppe, Unfortunatelly the patch still has not been reviewed. So without further steps it will not be propagated anywhere. May you advise how to pass this step? Maybe some other reviewer with more free time could take a look on it? Who it can be? Best regards, Vyacheslav. 26 Мар 2016 г. 0:52 пользователь "Giuseppe D'Angelo" < giuseppe.dangelo at kdab.com> написал: > Hi, > > Il 25/03/2016 20:58, Vyacheslav Grigoryev ha scritto: > >> 9 March I’ve fixed a bug QTBUG-50171 (review at >> https://codereview.qt-project.org/151861). It is related to fixing >> broken selection of rows or columns in a QTableView after user reordered >> them. And I still have no any progress with a review process. >> >> May somebody advise me what should I do to propagate it into main >> branch? I’ve submitted it into 5.6 branch but after that the branch was >> released recently. Does it mean that all patches for 5.6 aren’t actual >> anymore? Maybe I should resubmit it for 5.7? >> > > Thank you for your patch! For ordinary bugfixes 5.6 is the right branch to > target. It will get merged forward (in 5.7, etc.) automatically. > > Cheers, > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 > KDAB - The Qt Experts > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From partha1b at gmail.com Mon Mar 28 15:28:14 2016 From: partha1b at gmail.com (Partha Bagchi) Date: Mon, 28 Mar 2016 09:28:14 -0400 Subject: [Development] Compiling QT 5.7 Windows 64-bit Message-ID: Hi, My first post here. I am trying to compile QT 5.7 with my toolchain. I must be doing something silly and wrong: I get the following error: jit\qv4regalloc.cpp:648:8: error: missing binary operator before token "(" #if CPU(X86) || CPU(X86_64) ^ Makefile.Release:16312: recipe for target '.obj/release/qv4regalloc.o' failed Almost all such directives seem to give an error. I can get past the above by simply commenting out stuff not required by my environment but there must be a simpler way. All I need is a couple of pointers. Hope you can help. Thanks in advance, Partha PS: I am building using a Windows command-line since ./configure chokes on directory separators. For example, I cannot get glib support if I use the Msys shell. My configuration statement: configure -prefix Z:\opts\opt64-kde -opensource -confirm-license -optimized-tools -shared -nomake tests -nomake examples -release -opengl desktop -openssl -glib -qt-style-windows -I Z:\opts\opt64-kde\include -I Z:\opts\opt64-kde\include/freetype2 -I Z:\opts\opt64-kde\include/glib-2.0 -L Z:\opts\opt64-kde\lib -l glib-2.0 -l intl -l fontconfig -l freetype -l harfbuzz -fontconfig -system-zlib -system-libpng -system-harfbuzz -system-freetype -system-libjpeg -icu -largefile -wmf-backend My GCC version: gcc 5.3.0 posix-seh 64-bit: gcc -v Using built-in specs. COLLECT_GCC=Z:\foss\gcc\64bit\gcc-posix-5.3.0\bin\gcc.exe COLLECT_LTO_WRAPPER=Z:/foss/gcc/64bit/gcc-posix-5.3.0/bin/../libexec/gcc/x86_64-w64-mingw32/5.3.0/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: ../../../src/gcc-5.3.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw530/x86_64-530-posix-seh-rt_v4-rev0/mingw64 --with-gxx-include-dir=/mingw64/x86_64-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw530/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh-rev0, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw530/x86_64-530-posix-seh-rt_v4-rev0/mingw64/opt/include -I/c/mingw530/prerequisites/x86_64-zlib-static/include -I/c/mingw530/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw530/x86_64-530-posix-seh-rt_v4-rev0/mingw64/opt/include -I/c/mingw530/prerequisites/x86_64-zlib-static/include -I/c/mingw530/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw530/x86_64-530-posix-seh-rt_v4-rev0/mingw64/opt/lib -L/c/mingw530/prerequisites/x86_64-zlib-static/lib -L/c/mingw530/prerequisites/x86_64-w64-mingw32-static/lib ' Thread model: posix gcc version 5.3.0 (x86_64-posix-seh-rev0, Built by MinGW-W64 project) -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Mar 28 17:41:22 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 28 Mar 2016 08:41:22 -0700 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: References: Message-ID: <58375765.b7jQYxtaDW@tjmaciei-mobl4> On segunda-feira, 28 de março de 2016 09:28:14 PDT Partha Bagchi wrote: > I am building using a Windows command-line since ./configure chokes on > directory separators. For example, I cannot get glib support if I use the > Msys shell. Use forward slashes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From partha1b at gmail.com Mon Mar 28 18:34:38 2016 From: partha1b at gmail.com (Partha Bagchi) Date: Mon, 28 Mar 2016 12:34:38 -0400 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <58375765.b7jQYxtaDW@tjmaciei-mobl4> References: <58375765.b7jQYxtaDW@tjmaciei-mobl4> Message-ID: On Mon, Mar 28, 2016 at 11:41 AM, Thiago Macieira wrote: > On segunda-feira, 28 de março de 2016 09:28:14 PDT Partha Bagchi wrote: > > I am building using a Windows command-line since ./configure chokes on > > directory separators. For example, I cannot get glib support if I use the > > Msys shell. > > Use forward slashes. > I do. for instance, here is the output from my glib-2.0 libs: $ pkg-config --libs glib-2.0 -LZ:/opts/opt64-kde/lib -lglib-2.0 -lintl However, during configuration, I get errors like C:optsopt64-kdeincludeglibconfig.h unknown command. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Mar 28 19:09:22 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 28 Mar 2016 10:09:22 -0700 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: References: <58375765.b7jQYxtaDW@tjmaciei-mobl4> Message-ID: <1938716.zmEmxcoJjI@tjmaciei-mobl4> On segunda-feira, 28 de março de 2016 12:34:38 PDT Partha Bagchi wrote: > However, during configuration, I get errors like > C:optsopt64-kdeincludeglibconfig.h unknown command. Show the entire command that failed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From partha1b at gmail.com Mon Mar 28 21:00:04 2016 From: partha1b at gmail.com (Partha Bagchi) Date: Mon, 28 Mar 2016 15:00:04 -0400 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <1938716.zmEmxcoJjI@tjmaciei-mobl4> References: <58375765.b7jQYxtaDW@tjmaciei-mobl4> <1938716.zmEmxcoJjI@tjmaciei-mobl4> Message-ID: On Mon, Mar 28, 2016 at 1:09 PM, Thiago Macieira wrote: > On segunda-feira, 28 de março de 2016 12:34:38 PDT Partha Bagchi wrote: > > However, during configuration, I get errors like > > C:optsopt64-kdeincludeglibconfig.h unknown command. > > Show the entire command that failed. > > 5.7 does not reach even glib. My command line: $ ./configure --prefix=/opt -opensource -confirm-license -nomake tests -nomake examples -no-separate-debug-info -release -force-debug-info -reduce-relocations -optimized-qmake -platform win32-g++ -I /opt/include -I /opt/include/freetype2 -I /opt/include/glib-2.0 -L /opt/lib -lglib-2.0 -lintl -fontconfig -pkg-config - openssl -glib -gtk -v I get the following error In file included from ../include/QtCore/qglobal.h:1:0, from Z:/src/qt5/qtbase/qmake/library/qmake_global.h:32, from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:32, from Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, from Z:/src/qt5/qtbase/qmake/project.h:32, from Z:/src/qt5/qtbase/qmake/project.cpp:29: Z:/src/qt5/qtbase/src/corelib/global/qglobal.h:1123:23: error: expected ',' or '...' before '&&' token void qAsConst(const T &&) Q_DECL_EQ_DELETE; ^ In file included from ../include/QtCore/qhash.h:1:0, from Z:/src/qt5/qtbase/qmake/library/proitems.h:36, from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:33, from Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, from Z:/src/qt5/qtbase/qmake/project.h:32, from Z:/src/qt5/qtbase/qmake/project.cpp:29: Z:/src/qt5/qtbase/src/corelib/tools/qhash.h: In member function 'QPair::iterator, QHash::iterator> QHash::equal_range(const Key&)': Z:/src/qt5/qtbase/src/corelib/tools/qhash.h:953:10: error: 'pair' does not name a type auto pair = qAsConst(*this).equal_range(akey); ^ Z:/src/qt5/qtbase/src/corelib/tools/qhash.h:954:31: error: 'pair' was not declared in this scope return qMakePair(iterator(pair.first.i), iterator(pair.second.i)); ^ Z:/src/qt5/qtbase/src/corelib/tools/qhash.h:954:31: note: suggested alternative: In file included from Z:/foss/gcc/64bit/gcc-posix-5.3.0/x86_64-w64-mingw32/include/c++/utility:70:0, from Z:/src/qt5/qtbase/src/corelib/global/qcompilerdetection.h:939, from ../include/QtCore/qcompilerdetection.h:1, from Z:/src/qt5/qtbase/src/corelib/global/qglobal.h:80, from ../include/QtCore/qglobal.h:1, from Z:/src/qt5/qtbase/qmake/library/qmake_global.h:32, from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:32, from Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, from Z:/src/qt5/qtbase/qmake/project.h:32, from Z:/src/qt5/qtbase/qmake/project.cpp:29: Z:/foss/gcc/64bit/gcc-posix-5.3.0/x86_64-w64-mingw32/include/c++/bits/stl_pair.h:96:12: note: 'std::pair' struct pair ^ In file included from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:33:0, from Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, from Z:/src/qt5/qtbase/qmake/project.h:32, from Z:/src/qt5/qtbase/qmake/project.cpp:29: Z:/src/qt5/qtbase/qmake/library/proitems.h: At global scope: Z:/src/qt5/qtbase/qmake/library/proitems.h:367:35: error: expected ',' or '...' before '&&' token ProFunctionDef(ProFunctionDef &&other) Q_DECL_NOTHROW etc. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rafael.roquetto at kdab.com Mon Mar 28 22:13:56 2016 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Mon, 28 Mar 2016 17:13:56 -0300 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: References: <58375765.b7jQYxtaDW@tjmaciei-mobl4> Message-ID: <20160328201354.GA5540@orion> Hey, 1. don't use msys shell. 2. make sure stuff like sh.exe is not on your path 3. use configure.bat (not the configure shell script) 4. use backslashes for -I and -L when passing arguments to configure configure (...) -I C:\ICU\include -L C:\ICU\lib 5. for everything else, use forward-slashes without the drive letter configure -prefix /qt/560 -examplesdir /qt/examples/560 (...) 6. use mingw32-make 7. make sure the Makefile generator qmake is used matches mingw32-make. Item #2 may cause qmake to generate wrong Makefiles for your system. Hope that helps. Rafael On Mon, Mar 28, 2016 at 12:34:38PM -0400, Partha Bagchi wrote: > On Mon, Mar 28, 2016 at 11:41 AM, Thiago Macieira > wrote: > > > On segunda-feira, 28 de março de 2016 09:28:14 PDT Partha Bagchi wrote: > > > I am building using a Windows command-line since ./configure chokes on > > > directory separators. For example, I cannot get glib support if I use the > > > Msys shell. > > > > Use forward slashes. > > > I do. for instance, here is the output from my glib-2.0 libs: > $ pkg-config --libs glib-2.0 > -LZ:/opts/opt64-kde/lib -lglib-2.0 -lintl > > However, during configuration, I get errors like > C:optsopt64-kdeincludeglibconfig.h unknown command. > > > > > > -- > > 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 -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4861 bytes Desc: not available URL: From thiago.macieira at intel.com Mon Mar 28 22:37:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 28 Mar 2016 13:37:59 -0700 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: References: <1938716.zmEmxcoJjI@tjmaciei-mobl4> Message-ID: <5664382.lmtlsEfOUK@tjmaciei-mobl4> On segunda-feira, 28 de março de 2016 15:00:04 PDT Partha Bagchi wrote: > On Mon, Mar 28, 2016 at 1:09 PM, Thiago Macieira > wrote: > > On segunda-feira, 28 de março de 2016 12:34:38 PDT Partha Bagchi wrote: > > > However, during configuration, I get errors like > > > C:optsopt64-kdeincludeglibconfig.h unknown command. > > > > Show the entire command that failed. > > > 5.7 does not reach even glib. Please paste the full output. > In file included from ../include/QtCore/qglobal.h:1:0, > from Z:/src/qt5/qtbase/qmake/library/qmake_global.h:32, > from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:32, > from Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, > from Z:/src/qt5/qtbase/qmake/project.h:32, > from Z:/src/qt5/qtbase/qmake/project.cpp:29: > Z:/src/qt5/qtbase/src/corelib/global/qglobal.h:1123:23: error: expected ',' > or '...' before '&&' token > void qAsConst(const T &&) Q_DECL_EQ_DELETE; > ^ Looks like it's not compiling as C++11. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Mar 28 22:44:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 28 Mar 2016 13:44:07 -0700 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <20160328201354.GA5540@orion> References: <20160328201354.GA5540@orion> Message-ID: <4201675.V7MkygiQxE@tjmaciei-mobl4> On segunda-feira, 28 de março de 2016 17:13:56 PDT Rafael Roquetto wrote: > Hey, > > 1. don't use msys shell. > 2. make sure stuff like sh.exe is not on your path Doesn't match my recommendation. I do use the msys shell and I do have sh.exe on PATH. > 3. use configure.bat (not the configure shell script) However, I do use configure.bat. To run it from the msys shell, I need to run: cmd \ /c configure.bat [args] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From partha1b at gmail.com Tue Mar 29 00:30:22 2016 From: partha1b at gmail.com (Partha Bagchi) Date: Mon, 28 Mar 2016 18:30:22 -0400 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <5664382.lmtlsEfOUK@tjmaciei-mobl4> References: <1938716.zmEmxcoJjI@tjmaciei-mobl4> <5664382.lmtlsEfOUK@tjmaciei-mobl4> Message-ID: On Mon, Mar 28, 2016 at 4:37 PM, Thiago Macieira wrote: > On segunda-feira, 28 de março de 2016 15:00:04 PDT Partha Bagchi wrote: > > On Mon, Mar 28, 2016 at 1:09 PM, Thiago Macieira < > thiago.macieira at intel.com> > > wrote: > > > On segunda-feira, 28 de março de 2016 12:34:38 PDT Partha Bagchi wrote: > > > > However, during configuration, I get errors like > > > > C:optsopt64-kdeincludeglibconfig.h unknown command. > > > > > > Show the entire command that failed. > > > > > 5.7 does not reach even glib. > > Please paste the full output. > OK. + cd qtbase + /usr/src/qt5/qtbase/configure -top-level --prefix=/opt -opensource -confirm-license -nomake tests -nomake examples -no-separate-debug-info -release -force-debug-info -reduce-relocations -optimized-qmake -platform win32-g++ -I /opt/include -I /opt/include/freetype2 -I /opt/include/glib-2.0 -L /opt/lib -lglib-2.0 -lintl -fontconfig -pkg-config -openssl -glib -gtk -v This is the Qt Open Source Edition. You are licensed to use this software under the terms of the GNU Lesser General Public License (LGPL) versions 3. You are also licensed to use this software under the terms of the GNU General Public License (GPL) versions 2. You have already accepted the terms of the Open Source license. DEFAULT_INCDIRS="Z:/foss/gcc/64bit/gcc-posix-5.3.0/lib/gcc/x86_64-w64-mingw32/5.3.0/include Z:/foss/gcc/64bit/gcc-posix-5.3.0/lib/gcc/x86_64-w64-mingw32/5.3.0/include-fixed Z:/foss/gcc/64bit/gcc-posix-5.3.0/x86_64-w64-mingw32/include Z:/foss/gcc/64bit/gcc-posix-5.3.0/x86_64-w64-mingw32/include/c++ Z:/foss/gcc/64bit/gcc-posix-5.3.0/x86_64-w64-mingw32/include/c++/x86_64-w64-mingw32 Z:/foss/gcc/64bit/gcc-posix-5.3.0/x86_64-w64-mingw32/include/c++/backward " DEFAULT_LIBDIRS="/foss/gcc/64bit/gcc-posix-5.3.0/x86_64-w64-mingw32/lib/;Z /foss/gcc/64bit/gcc-posix-5.3.0/lib/;Z /foss/gcc/64bit/gcc-posix-5.3.0/lib Z /foss/gcc/64bit/gcc-posix-5.3.0/lib/gcc/x86_64-w64-mingw32/5.3.0/;Z /foss/gcc/64bit/gcc-posix-5.3.0/lib/gcc/;Z " = Z:/src/qt5/qtbase = Z:/src/qt5/qtbase QtCore: created fwd-include header(s) for /src/corelib/animation/ { qabstractanimation.h (1), qabstractanimation_p.h (1), qanimationgroup.h (1), qanimationgroup_p.h (1), qparallelanimationgroup.h (1), qparallelanimationgroup_p.h (1), qpauseanimation.h (1), qpropertyanimation.h (1), qpropertyanimation_p.h (1), qsequentialanimationgroup.h (1), qsequentialanimationgroup_p.h (1), qvariantanimation.h (1), qvariantanimation_p.h (1) } QtCore: created fwd-include header(s) for /src/corelib/arch/ { qatomic_bootstrap.h (1), qatomic_cxx11.h (1), qatomic_msvc.h (1) } QtCore: created fwd-include header(s) for /src/corelib/codecs/ { cp949codetbl_p.h (1), qbig5codec_p.h (1), qeucjpcodec_p.h (1), qeuckrcodec_p.h (1), qgb18030codec_p.h (1), qiconvcodec_p.h (1), qicucodec_p.h (1), qisciicodec_p.h (1), qjiscodec_p.h (1), qjpunicode_p.h (1), qlatincodec_p.h (1), qsimplecodec_p.h (1), qsjiscodec_p.h (1), qtextcodec.h (1), qtextcodec_p.h (1), qtsciicodec_p.h (1), qutfcodec_p.h (1), qwindowscodec_p.h (1) } QtCore: created fwd-include header(s) for /src/corelib/global/ { qcompilerdetection.h (1), qconfig-dist.h (1), qconfig-large.h (1), qconfig-medium.h (1), qconfig-minimal.h (1), qconfig-nacl.h (1), qconfig-small.h (1), qendian.h (1), qflags.h (1), qglobal.h (1), qglobalstatic.h (1), qhooks_p.h (1), qisenum.h (1), qlibraryinfo.h (1), qlogging.h (1), qnamespace.h (1), qnumeric.h (1), qnumeric_p.h (1), qprocessordetection.h (1), qsysinfo.h (1), qsystemdetection.h (1), qt_pch.h (1), qt_windows.h (1), qtypeinfo.h (1), qtypetraits.h (1), qversiontagging.h (1) } QtCore: created fwd-include header(s) for /src/corelib/io/ { qabstractfileengine_p.h (1), qbuffer.h (1), qdatastream.h (1), qdatastream_p.h (1), qdataurl_p.h (1), qdebug.h (1), qdebug_p.h (1), qdir.h (1), qdir_p.h (1), qdiriterator.h (1), qfile.h (1), qfile_p.h (1), qfiledevice.h (1), qfiledevice_p.h (1), qfileinfo.h (1), qfileinfo_p.h (1), qfileselector.h (1), qfileselector_p.h (1), qfilesystemengine_p.h (1), qfilesystementry_p.h (1), qfilesystemiterator_p.h (1), qfilesystemmetadata_p.h (1), qfilesystemwatcher.h (1), qfilesystemwatcher_fsevents_p.h (1), qfilesystemwatcher_inotify_p.h (1), qfilesystemwatcher_kqueue_p.h (1), qfilesystemwatcher_p.h (1), qfilesystemwatcher_polling_p.h (1), qfilesystemwatcher_win_p.h (1), qfsfileengine_iterator_p.h (1), qfsfileengine_p.h (1), qiodevice.h (1), qiodevice_p.h (1), qipaddress_p.h (1), qlockfile.h (1), qlockfile_p.h (1), qloggingcategory.h (1), qloggingregistry_p.h (1), qnoncontiguousbytedevice_p.h (1), qprocess.h (1), qprocess_p.h (1), qresource.h (1), qresource_iterator_p.h (1), qresource_p.h (1), qsavefile.h (1), qsavefile_p.h (1), qsettings.h (1), qsettings_p.h (1), qstandardpaths.h (1), qstorageinfo.h (1), qstorageinfo_p.h (1), qtemporarydir.h (1), qtemporaryfile.h (1), qtemporaryfile_p.h (1), qtextstream.h (1), qtextstream_p.h (1), qtldurl_p.h (1), qurl.h (1), qurl_p.h (1), qurlquery.h (1), qurltlds_p.h (1), qwindowspipereader_p.h (1), qwindowspipewriter_p.h (1), qwinoverlappedionotifier_p.h (1) } QtCore: created fwd-include header(s) for /src/corelib/itemmodels/ { qabstractitemmodel.h (1), qabstractitemmodel_p.h (1), qabstractproxymodel.h (1), qabstractproxymodel_p.h (1), qidentityproxymodel.h (1), qitemselectionmodel.h (1), qitemselectionmodel_p.h (1), qsortfilterproxymodel.h (1), qstringlistmodel.h (1) } QtCore: created fwd-include header(s) for /src/corelib/json/ { qjson_p.h (1), qjsonarray.h (1), qjsondocument.h (1), qjsonobject.h (1), qjsonparser_p.h (1), qjsonvalue.h (1), qjsonwriter_p.h (1) } QtCore: created fwd-include header(s) for /src/corelib/kernel/ { qabstracteventdispatcher.h (1), qabstracteventdispatcher_p.h (1), qabstractnativeeventfilter.h (1), qbasictimer.h (1), qcfsocketnotifier_p.h (1), qcore_mac_p.h (1), qcore_unix_p.h (1), qcoreapplication.h (1), qcoreapplication_p.h (1), qcorecmdlineargs_p.h (1), qcoreevent.h (1), qcoreglobaldata_p.h (1), qcrashhandler_p.h (1), qeventdispatcher_cf_p.h (1), qeventdispatcher_glib_p.h (1), qeventdispatcher_unix_p.h (1), qeventdispatcher_win_p.h (1), qeventdispatcher_winrt_p.h (1), qeventloop.h (1), qeventloop_p.h (1), qfunctions_fake_env_p.h (1), qfunctions_nacl.h (1), qfunctions_p.h (1), qfunctions_vxworks.h (1), qfunctions_wince.h (1), qfunctions_winrt.h (1), qjni_p.h (1), qjnihelpers_p.h (1), qmath.h (1), qmetaobject.h (1), qmetaobject_moc_p.h (1), qmetaobject_p.h (1), qmetaobjectbuilder_p.h (1), qmetatype.h (1), qmetatype_p.h (1), qmetatypeswitcher_p.h (1), qmimedata.h (1), qobject.h (1), qobject_impl.h (1), qobject_p.h (1), qobjectcleanuphandler.h (1), qobjectdefs.h (1), qobjectdefs_impl.h (1), qpointer.h (1), qpoll_p.h (1), qppsattribute_p.h (1), qppsattributeprivate_p.h (1), qppsobject_p.h (1), qppsobjectprivate_p.h (1), qsharedmemory.h (1), qsharedmemory_p.h (1), qsignalmapper.h (1), qsocketnotifier.h (1), qsystemerror_p.h (1), qsystemsemaphore.h (1), qsystemsemaphore_p.h (1), qtimer.h (1), qtimerinfo_unix_p.h (1), qtranslator.h (1), qtranslator_p.h (1), qvariant.h (1), qvariant_p.h (1), qwineventnotifier.h (1) } QtCore: created fwd-include header(s) for /src/corelib/mimetypes/ { qmimedatabase.h (1), qmimedatabase_p.h (1), qmimeglobpattern_p.h (1), qmimemagicrule_p.h (1), qmimemagicrulematcher_p.h (1), qmimeprovider_p.h (1), qmimetype.h (1), qmimetype_p.h (1), qmimetypeparser_p.h (1) } QtCore: created fwd-include header(s) for /src/corelib/plugin/ { qelfparser_p.h (1), qfactoryinterface.h (1), qfactoryloader_p.h (1), qlibrary.h (1), qlibrary_p.h (1), qmachparser_p.h (1), qplugin.h (1), qpluginloader.h (1), qsystemlibrary_p.h (1), quuid.h (1) } QtCore: created fwd-include header(s) for /src/corelib/statemachine/ { qabstractstate.h (1), qabstractstate_p.h (1), qabstracttransition.h (1), qabstracttransition_p.h (1), qeventtransition.h (1), qeventtransition_p.h (1), qfinalstate.h (1), qfinalstate_p.h (1), qhistorystate.h (1), qhistorystate_p.h (1), qsignaleventgenerator_p.h (1), qsignaltransition.h (1), qsignaltransition_p.h (1), qstate.h (1), qstate_p.h (1), qstatemachine.h (1), qstatemachine_p.h (1) } QtCore: created fwd-include header(s) for /src/corelib/thread/ { qatomic.h (1), qbasicatomic.h (1), qexception.h (1), qfuture.h (1), qfutureinterface.h (1), qfutureinterface_p.h (1), qfuturesynchronizer.h (1), qfuturewatcher.h (1), qfuturewatcher_p.h (1), qgenericatomic.h (1), qmutex.h (1), qmutex_p.h (1), qmutexpool_p.h (1), qorderedmutexlocker_p.h (1), qreadwritelock.h (1), qreadwritelock_p.h (1), qresultstore.h (1), qrunnable.h (1), qsemaphore.h (1), qthread.h (1), qthread_p.h (1), qthreadpool.h (1), qthreadpool_p.h (1), qthreadstorage.h (1), qwaitcondition.h (1) } QtCore: created fwd-include header(s) for /src/corelib/tools/ { qalgorithms.h (1), qarraydata.h (1), qarraydataops.h (1), qarraydatapointer.h (1), qbitarray.h (1), qbytearray.h (1), qbytearray_p.h (1), qbytearraylist.h (1), qbytearraymatcher.h (1), qbytedata_p.h (1), qcache.h (1), qchar.h (1), qcollator.h (1), qcollator_p.h (1), qcommandlineoption.h (1), qcommandlineparser.h (1), qcontainerfwd.h (1), qcontiguouscache.h (1), qcryptographichash.h (1), qdatetime.h (1), qdatetime_p.h (1), qdatetimeparser_p.h (1), qdoublescanprint_p.h (1), qeasingcurve.h (1), qelapsedtimer.h (1), qfreelist_p.h (1), qharfbuzz_p.h (1), qhash.h (1), qhashfunctions.h (1), qiterator.h (1), qline.h (1), qlinkedlist.h (1), qlist.h (1), qlocale.h (1), qlocale_data_p.h (1), qlocale_p.h (1), qlocale_tools_p.h (1), qmap.h (1), qmargins.h (1), qmessageauthenticationcode.h (1), qpair.h (1), qpodlist_p.h (1), qpoint.h (1), qqueue.h (1), qrect.h (1), qrefcount.h (1), qregexp.h (1), qregularexpression.h (1), qringbuffer_p.h (1), qscopedpointer.h (1), qscopedpointer_p.h (1), qscopedvaluerollback.h (1), qset.h (1), qshareddata.h (1), qsharedpointer.h (1), qsharedpointer_impl.h (1), qsimd_p.h (1), qsize.h (1), qstack.h (1), qstring.h (1), qstringalgorithms_p.h (1), qstringbuilder.h (1), qstringiterator_p.h (1), qstringlist.h (1), qstringmatcher.h (1), qtextboundaryfinder.h (1), qtimeline.h (1), qtimezone.h (1), qtimezoneprivate_data_p.h (1), qtimezoneprivate_p.h (1), qtools_p.h (1), qunicodetables_p.h (1), qunicodetools_p.h (1), qvarlengtharray.h (1), qvector.h (1), qversionnumber.h (1) } QtCore: created fwd-include header(s) for /src/corelib/xml/ { qxmlstream.h (1), qxmlstream_p.h (1), qxmlutils_p.h (1) } Creating qmake... g++ -c -o project.o -DUNICODE -g -IZ:/src/qt5/qtbase/qmake -IZ:/src/qt5/qtbase/qmake/library -IZ:/src/qt5/qtbase/qmake/generators -IZ:/src/qt5/qtbase/qmake/generators/unix -IZ:/src/qt5/qtbase/qmake/generators/win32 -IZ:/src/qt5/qtbase/qmake/generators/mac -IZ:/src/qt5/qtbase/qmake/generators/integrity -I../include -I../include/QtCore -I../include/QtCore/5.7.0 -I../include/QtCore/5.7.0/QtCore -I../src/corelib/global -DHAVE_QCONFIG_CPP -IZ:/src/qt5/qtbase/mkspecs/win32-g++ -IZ:/src/qt5/qtbase/tools/shared -DQT_VERSION_STR=\"5.7.0\" -DQT_VERSION_MAJOR=5 -DQT_VERSION_MINOR=7 -DQT_VERSION_PATCH=0 -DQT_BUILD_QMAKE -DQT_BOOTSTRAPPED -DPROEVALUATOR_FULL -DQT_NO_TEXTCODEC -DQT_NO_UNICODETABLES -DQT_NO_COMPONENT -DQT_NO_COMPRESS -DQT_NO_THREAD -DQT_NO_QOBJECT -DQT_NO_GEOM_VARIANT -DQT_NO_DATASTREAM -DQT_CRYPTOGRAPHICHASH_ONLY_SHA1 -DQT_JSON_READONLY -DQT_NO_STANDARDPATHS Z:/src/qt5/qtbase/qmake/project.cpp In file included from ../include/QtCore/qglobal.h:1:0, from Z:/src/qt5/qtbase/qmake/library/qmake_global.h:32, from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:32, from Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, from Z:/src/qt5/qtbase/qmake/project.h:32, from Z:/src/qt5/qtbase/qmake/project.cpp:29: Z:/src/qt5/qtbase/src/corelib/global/qglobal.h:1123:23: error: expected ',' or '...' before '&&' token void qAsConst(const T &&) Q_DECL_EQ_DELETE; ^ In file included from ../include/QtCore/qhash.h:1:0, from Z:/src/qt5/qtbase/qmake/library/proitems.h:36, from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:33, from Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, from Z:/src/qt5/qtbase/qmake/project.h:32, from Z:/src/qt5/qtbase/qmake/project.cpp:29: Z:/src/qt5/qtbase/src/corelib/tools/qhash.h: In member function 'QPair::iterator, QHash::iterator> QHash::equal_range(const Key&)': Z:/src/qt5/qtbase/src/corelib/tools/qhash.h:953:10: error: 'pair' does not name a type auto pair = qAsConst(*this).equal_range(akey); ^ Z:/src/qt5/qtbase/src/corelib/tools/qhash.h:954:31: error: 'pair' was not declared in this scope return qMakePair(iterator(pair.first.i), iterator(pair.second.i)); ^ Z:/src/qt5/qtbase/src/corelib/tools/qhash.h:954:31: note: suggested alternative: In file included from Z:/foss/gcc/64bit/gcc-posix-5.3.0/x86_64-w64-mingw32/include/c++/utility:70:0, from Z:/src/qt5/qtbase/src/corelib/global/qcompilerdetection.h:939, from ../include/QtCore/qcompilerdetection.h:1, from Z:/src/qt5/qtbase/src/corelib/global/qglobal.h:80, from ../include/QtCore/qglobal.h:1, from Z:/src/qt5/qtbase/qmake/library/qmake_global.h:32, from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:32, from Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, from Z:/src/qt5/qtbase/qmake/project.h:32, from Z:/src/qt5/qtbase/qmake/project.cpp:29: Z:/foss/gcc/64bit/gcc-posix-5.3.0/x86_64-w64-mingw32/include/c++/bits/stl_pair.h:96:12: note: 'std::pair' struct pair ^ In file included from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:33:0, from Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, from Z:/src/qt5/qtbase/qmake/project.h:32, from Z:/src/qt5/qtbase/qmake/project.cpp:29: Z:/src/qt5/qtbase/qmake/library/proitems.h: At global scope: Z:/src/qt5/qtbase/qmake/library/proitems.h:367:35: error: expected ',' or '...' before '&&' token ProFunctionDef(ProFunctionDef &&other) Q_DECL_NOTHROW ^ Z:/src/qt5/qtbase/qmake/library/proitems.h:367:42: error: invalid constructor; you probably meant 'ProFunctionDef (const ProFunctionDef&)' ProFunctionDef(ProFunctionDef &&other) Q_DECL_NOTHROW ^ Z:/src/qt5/qtbase/qmake/library/proitems.h:380:46: error: expected ',' or '...' before '&&' token ProFunctionDef &operator=(ProFunctionDef &&other) Q_DECL_NOTHROW ^ Z:/src/qt5/qtbase/qmake/library/proitems.h: In member function 'ProFunctionDef& ProFunctionDef::operator=(ProFunctionDef)': Z:/src/qt5/qtbase/qmake/library/proitems.h:382:30: error: 'move' is not a member of 'std' ProFunctionDef moved(std::move(other)); ^ Z:/src/qt5/qtbase/qmake/library/proitems.h:382:40: error: 'other' was not declared in this scope ProFunctionDef moved(std::move(other)); ^ In file included from Z:/src/qt5/qtbase/qmake/project.cpp:31:0: Z:/src/qt5/qtbase/qmake/option.h: In static member function 'static bool Option::hasFileExtension(const QString&, const QStringList&)': Z:/src/qt5/qtbase/qmake/option.h:156:35: warning: range-based 'for' loops only available with -std=c++11 or -std=gnu++11 for (const QString &ext : extensions) ^ Z:/src/qt5/qtbase/qmake/project.cpp: In function 'ProStringList prepareBuiltinArgs(const QList&)': Z:/src/qt5/qtbase/qmake/project.cpp:76:37: warning: range-based 'for' loops only available with -std=c++11 or -std=gnu++11 for (const ProStringList &arg : args) ^ Z:/src/qt5/qtbase/qmake/project.cpp: In member function 'void QMakeProject::dump() const': Z:/src/qt5/qtbase/qmake/project.cpp:149:39: warning: range-based 'for' loops only available with -std=c++11 or -std=gnu++11 for (const ProString &v : it.value()) ^ Z:/src/qt5/qtbase/qmake/project.cpp:155:29: warning: range-based 'for' loops only available with -std=c++11 or -std=gnu++11 for (const QString &v : qAsConst(out)) ^ Z:/src/qt5/qtbase/qmake/project.cpp:155:41: error: call of overloaded 'qAsConst(QStringList&)' is ambiguous for (const QString &v : qAsConst(out)) ^ In file included from ../include/QtCore/qglobal.h:1:0, from Z:/src/qt5/qtbase/qmake/library/qmake_global.h:32, from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:32, from Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, from Z:/src/qt5/qtbase/qmake/project.h:32, from Z:/src/qt5/qtbase/qmake/project.cpp:29: Z:/src/qt5/qtbase/src/corelib/global/qglobal.h:1120:58: note: candidate: typename QtPrivate::QAddConst::Type& qAsConst(T&) [with T = QStringList; typename QtPrivate::QAddConst::Type = const QStringList] Q_DECL_CONSTEXPR typename QtPrivate::QAddConst::Type &qAsConst(T &t) Q_DECL_NOTHROW { return t; } ^ Z:/src/qt5/qtbase/src/corelib/global/qglobal.h:1123:6: note: candidate: void qAsConst(T) [with T = QStringList] void qAsConst(const T &&) Q_DECL_EQ_DELETE; ^ Makefile:188: recipe for target `project.o' failed make.exe: *** [project.o] Error 1 > > > In file included from ../include/QtCore/qglobal.h:1:0, > > from Z:/src/qt5/qtbase/qmake/library/qmake_global.h:32, > > from Z:/src/qt5/qtbase/qmake/library/qmakeparser.h:32, > > from > Z:/src/qt5/qtbase/qmake/library/qmakeevaluator.h:36, > > from Z:/src/qt5/qtbase/qmake/project.h:32, > > from Z:/src/qt5/qtbase/qmake/project.cpp:29: > > Z:/src/qt5/qtbase/src/corelib/global/qglobal.h:1123:23: error: expected > ',' > > or '...' before '&&' token > > void qAsConst(const T &&) Q_DECL_EQ_DELETE; > > ^ > > Looks like it's not compiling as C++11. > Adding c++11 does not make any difference. :( > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From partha1b at gmail.com Tue Mar 29 00:49:00 2016 From: partha1b at gmail.com (Partha Bagchi) Date: Mon, 28 Mar 2016 18:49:00 -0400 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <4201675.V7MkygiQxE@tjmaciei-mobl4> References: <20160328201354.GA5540@orion> <4201675.V7MkygiQxE@tjmaciei-mobl4> Message-ID: On Mon, Mar 28, 2016 at 4:44 PM, Thiago Macieira wrote: > On segunda-feira, 28 de março de 2016 17:13:56 PDT Rafael Roquetto wrote: > > Hey, > > > > 1. don't use msys shell. > > 2. make sure stuff like sh.exe is not on your path > > Doesn't match my recommendation. I do use the msys shell and I do have > sh.exe > on PATH. > > Correct. However, msys shell does not work and you can't run configure without getting errors. > > 3. use configure.bat (not the configure shell script) > > However, I do use configure.bat. To run it from the msys shell, I need to > run: > > cmd \ /c configure.bat [args] > > As I mentioned at the top of the thread. I switched to Windows cmdline to run configure.bat. After that I ran mingw32-make where I got into the trouble mentioned at the top of the thread. Based on your suggestion above, I am now running it all within a msys shell with cmd (which btw opens a subshell for me) and I am running configure with args. Then I exited from the subshell and am running make. Will keep you posted. -- > 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 > Thanks for staying on this with me!! I totally appreciate it. Partha -------------- next part -------------- An HTML attachment was scrubbed... URL: From partha1b at gmail.com Tue Mar 29 01:20:56 2016 From: partha1b at gmail.com (Partha Bagchi) Date: Mon, 28 Mar 2016 19:20:56 -0400 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: References: <20160328201354.GA5540@orion> <4201675.V7MkygiQxE@tjmaciei-mobl4> Message-ID: On Mon, Mar 28, 2016 at 6:49 PM, Partha Bagchi wrote: > > > On Mon, Mar 28, 2016 at 4:44 PM, Thiago Macieira < > thiago.macieira at intel.com> wrote: > >> On segunda-feira, 28 de março de 2016 17:13:56 PDT Rafael Roquetto wrote: >> > Hey, >> > >> > 1. don't use msys shell. >> > 2. make sure stuff like sh.exe is not on your path >> >> Doesn't match my recommendation. I do use the msys shell and I do have >> sh.exe >> on PATH. >> >> Correct. However, msys shell does not work and you can't run configure > without getting errors. > >> > 3. use configure.bat (not the configure shell script) >> >> However, I do use configure.bat. To run it from the msys shell, I need to >> run: >> >> cmd \ /c configure.bat [args] >> >> As I mentioned at the top of the thread. I switched to Windows cmdline to > run configure.bat. After that I ran mingw32-make where I got into the > trouble mentioned at the top of the thread. > > Based on your suggestion above, I am now running it all within a msys > shell with cmd (which btw opens a subshell for me) and I am running > configure with args. > > > Then I exited from the subshell and am running make. Will keep you posted. > Same difference. I am now configured. However, when I run make, I get the following error (after a long time): g++ -c -pipe -fno-keep-inline-dllexport -O2 -std=c++1z -fno-exceptions -frtti -Wall -Wextra -Wvla -Wdate-time -DUNICODE -DQT_NO_URL_CAST_FROM_STRING -DQT_NO_INTEGER_EVENT_COORDINATES -DWTF_EXPORT_PRIVATE= -DJS_EXPORT_PRIVATE= -DENABLE_ASSEMBLER_WX_EXCLUSIVE=1 -DWTFReportAssertionFailure=qmlWTFReportAssertionFailure -DWTFReportBacktrace=qmlWTFReportBacktrace -DWTFInvokeCrashHook=qmlWTFInvokeCrashHook -DNOMINMAX -DENABLE_LLINT=0 -DENABLE_DFG_JIT=0 -DENABLE_DFG_JIT_UTILITY_METHODS=1 -DENABLE_JIT_CONSTANT_BLINDING=0 -DBUILDING_QT__ -DWTF_USE_UDIS86=0 -DNDEBUG -DQT_BUILD_QML_LIB -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG -DQT_NETWORK_LIB -DQT_CORE_LIB -I. -IZ:/opts/opt64-kde/include -IZ:/opts/opt64-kde/include/freetype2 -IZ:/opts/opt64-kde/include/glib-2.0 -Imemory -I. -Icompiler -I. -I../3rdparty/masm/jit -I../3rdparty/masm/assembler -I../3rdparty/masm/runtime -I../3rdparty/masm/wtf -I../3rdparty/masm/stubs -I../3rdparty/masm/stubs/wtf -I../3rdparty/masm -I../3rdparty/masm/disassembler -I../3rdparty/masm/disassembler/udis86 -Ijit -I. -I.generated/release -Ijsruntime -I. -Idebugger -Ianimations -I../../include -I../../include/QtQml -I../../include/QtQml/5.7.0 -I../../include/QtQml/5.7.0/QtQml -Itmp -IZ:/src/qt5/qtbase/include/QtCore/5.7.0 -IZ:/src/qt5/qtbase/include/QtCore/5.7.0/QtCore -IZ:/src/qt5/qtbase/include -IZ:/src/qt5/qtbase/include/QtNetwork -IZ:/src/qt5/qtbase/include/QtCore -I.moc/release -IZ:/src/qt5/qtbase/mkspecs/win32-g++ -o .obj/release/qv4regalloc.o jit/qv4regalloc.cpp jit/qv4regalloc.cpp:648:8: error: missing binary operator before token "(" #if CPU(X86) || CPU(X86_64) ^ Makefile.Release:16312: recipe for target `.obj/release/qv4regalloc.o' failed make[4]: *** [.obj/release/qv4regalloc.o] Error 1 make[4]: Leaving directory `/usr/src/qt5/qtdeclarative/src/qml' Makefile:34: recipe for target `release' failed make[3]: *** [release] Error 2 make[3]: Leaving directory `/usr/src/qt5/qtdeclarative/src/qml' Makefile:46: recipe for target `sub-qml-make_first-ordered' failed make[2]: *** [sub-qml-make_first-ordered] Error 2 make[2]: Leaving directory `/usr/src/qt5/qtdeclarative/src' Makefile:41: recipe for target `sub-src-make_first' failed make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory `/usr/src/qt5/qtdeclarative' Makefile:326: recipe for target `module-qtdeclarative-make_first' failed make: *** [module-qtdeclarative-make_first] Error 2 > -- >> 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 >> > > Thanks for staying on this with me!! I totally appreciate it. > > Partha > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Mar 29 03:25:32 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 28 Mar 2016 18:25:32 -0700 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: References: <5664382.lmtlsEfOUK@tjmaciei-mobl4> Message-ID: <1972527.4yFI88HYkW@tjmaciei-mobl4> On segunda-feira, 28 de março de 2016 18:30:22 PDT Partha Bagchi wrote: > > Looks like it's not compiling as C++11. > > Adding c++11 does not make any difference. configure should have got the flag from the mkspec. Can you check if qmake/ Makefile has a line with QMAKE_CXXFLAGS_CXX11? It probably exists and is empty for you. That means configure failed to parse your mkspec somehow. Happy debugging the getQMakeConf shell function. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From partha1b at gmail.com Tue Mar 29 03:33:11 2016 From: partha1b at gmail.com (Partha Bagchi) Date: Mon, 28 Mar 2016 21:33:11 -0400 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <1972527.4yFI88HYkW@tjmaciei-mobl4> References: <5664382.lmtlsEfOUK@tjmaciei-mobl4> <1972527.4yFI88HYkW@tjmaciei-mobl4> Message-ID: On Mon, Mar 28, 2016 at 9:25 PM, Thiago Macieira wrote: > On segunda-feira, 28 de março de 2016 18:30:22 PDT Partha Bagchi wrote: > > > Looks like it's not compiling as C++11. > > > > Adding c++11 does not make any difference. > > configure should have got the flag from the mkspec. Can you check if qmake/ > Makefile has a line with QMAKE_CXXFLAGS_CXX11? It probably exists and is > empty > for you. That means configure failed to parse your mkspec somehow. > > Well, qtbase/qmake/Makefile does not contain QMAKE_CXXFLAGS_CXX11, but it does have QMAKESPEC = $(SOURCE_PATH)\mkspecs\win32-g++ EXTRA_CFLAGS = -DUNICODE -ffunction-sections EXTRA_CXXFLAGS = -std=c++11 -DUNICODE -ffunction-sections EXTRA_LFLAGS = -Wl,--gc-sections > Happy debugging the getQMakeConf shell function. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Mar 29 03:57:53 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 28 Mar 2016 18:57:53 -0700 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: References: <1972527.4yFI88HYkW@tjmaciei-mobl4> Message-ID: <1727325.CtYLaX67qZ@tjmaciei-mobl4> On segunda-feira, 28 de março de 2016 21:33:11 PDT Partha Bagchi wrote: > EXTRA_CXXFLAGS = -std=c++11 -DUNICODE -ffunction-sections It's there, but it's not in your command-line, which had: g++ -c -o project.o -DUNICODE -g -IZ:/src/qt5/qtbase/qmake It's missing two options. I don't know how or why. From what I can see in the Makefile, it should be impossible. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andreas.holzammer at kdab.com Tue Mar 29 07:05:41 2016 From: andreas.holzammer at kdab.com (Andreas Holzammer) Date: Tue, 29 Mar 2016 07:05:41 +0200 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <1727325.CtYLaX67qZ@tjmaciei-mobl4> References: <1972527.4yFI88HYkW@tjmaciei-mobl4> <1727325.CtYLaX67qZ@tjmaciei-mobl4> Message-ID: <56FA0D25.9070801@kdab.com> Hey, this got fixed in the 5.6 branch and did not get forward merged yet. https://codereview.qt-project.org/#/c/153305/ Please use that patch and the c++11 error should go away. Thank you Andy Am 29.03.2016 um 03:57 schrieb Thiago Macieira: > On segunda-feira, 28 de março de 2016 21:33:11 PDT Partha Bagchi wrote: >> EXTRA_CXXFLAGS = -std=c++11 -DUNICODE -ffunction-sections > > It's there, but it's not in your command-line, which had: > > g++ -c -o project.o -DUNICODE -g -IZ:/src/qt5/qtbase/qmake > > It's missing two options. I don't know how or why. From what I can see in the > Makefile, it should be impossible. > -- Andreas Holzammer | andreas.holzammer at kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4070 bytes Desc: S/MIME Cryptographic Signature URL: From rafael.roquetto at kdab.com Tue Mar 29 14:33:12 2016 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Tue, 29 Mar 2016 09:33:12 -0300 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <4201675.V7MkygiQxE@tjmaciei-mobl4> References: <20160328201354.GA5540@orion> <4201675.V7MkygiQxE@tjmaciei-mobl4> Message-ID: <20160329123309.GB4895@orion> On Mon, Mar 28, 2016 at 01:44:07PM -0700, Thiago Macieira wrote: > On segunda-feira, 28 de março de 2016 17:13:56 PDT Rafael Roquetto wrote: > > Hey, > > > > 1. don't use msys shell. > > 2. make sure stuff like sh.exe is not on your path > > Doesn't match my recommendation. I do use the msys shell and I do have sh.exe > on PATH. That only works for MinGW. If you ever switch to MSVC, sh.exe will trick qmake into generating Unix makefiles and you will probably encounter all these path problems. -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4861 bytes Desc: not available URL: From massimocallegari at yahoo.it Tue Mar 29 15:32:33 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Tue, 29 Mar 2016 13:32:33 +0000 (UTC) Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <20160329123309.GB4895@orion> References: <20160329123309.GB4895@orion> Message-ID: <1006457415.2916464.1459258353341.JavaMail.yahoo@mail.yahoo.com> Hi everyone it is not my intention to hijack this thread, but it comes at the right time when I'm contributing to the MSYS project. In the last few days, I've been working to improve the qt5-git package: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-qt5-git The goal is to offer a trivial way to clone and build a Qt5 GIT branch (right now 5.7) for developers to test and follow the developments of specific Qt modules. In theory once the work is complete, it should work out of the box also for 64bit builds. The beauty is that with MSYS2, with just a single command (makepkg-mingw -sLf) you can build a monster project like Qt without any development skill, or without following messy wiki pages like those I found related to MinGW or MSYS. (like this https://wiki.qt.io/MinGW-64-bit or this https://wiki.qt.io/Building_Qt_Desktop_for_Windows_with_MinGW) Unfortunately (and here comes the hijack) I stumbled on some OpenGL problem. Apparently I also found the solution, but I would like to understand from the experts why it is happening. Here's the details (see pastebin): https://github.com/Alexpux/MINGW-packages/pull/1254 Basically, the qopengles2ext.h include goes into QtGui forward includes via syncqt.pl, even if I'm telling configure to build with "-opengl desktop" Manually commenting that include in QtGui fwd file allows the build to proceed. QtOpenGl.dll is then created correctly and so on. Any insight about this would be helpful, and it would allow me to commit a working solution even within tonight. I would also like to point out (but it's my humble opinion) that MSYS2 should be taken more into account by Qt developers to offer a non Microsoft way to work with Qt on Windows. Especially for Linux fans like me :) Even if I don't know the whole story, I am aware that some patches proposed by the MSYS devs went upstream, but still, to build Qt5 on MSYS2 requires something like 40 patches right now, and it's a mess to maintain them across newer Qt versions. Not mentioning the fact that QtWebEngine still doesn't build there and it's really a pity. Thanks, Massimo ________________________________ Da: Rafael Roquetto A: Thiago Macieira Cc: development at qt-project.org Inviato: Martedì 29 Marzo 2016 14:33 Oggetto: Re: [Development] Compiling QT 5.7 Windows 64-bit On Mon, Mar 28, 2016 at 01:44:07PM -0700, Thiago Macieira wrote: > On segunda-feira, 28 de março de 2016 17:13:56 PDT Rafael Roquetto wrote: > > Hey, > > > > 1. don't use msys shell. > > 2. make sure stuff like sh.exe is not on your path > > Doesn't match my recommendation. I do use the msys shell and I do have sh.exe > on PATH. That only works for MinGW. If you ever switch to MSVC, sh.exe will trick qmake into generating Unix makefiles and you will probably encounter all these path problems. -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Mar 29 16:08:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Mar 2016 07:08:07 -0700 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <20160329123309.GB4895@orion> References: <4201675.V7MkygiQxE@tjmaciei-mobl4> <20160329123309.GB4895@orion> Message-ID: <1568644.PBnim2jyUZ@tjmaciei-mobl4> On terça-feira, 29 de março de 2016 09:33:12 PDT Rafael Roquetto wrote: > On Mon, Mar 28, 2016 at 01:44:07PM -0700, Thiago Macieira wrote: > > On segunda-feira, 28 de março de 2016 17:13:56 PDT Rafael Roquetto wrote: > > > Hey, > > > > > > 1. don't use msys shell. > > > 2. make sure stuff like sh.exe is not on your path > > > > Doesn't match my recommendation. I do use the msys shell and I do have > > sh.exe on PATH. > > That only works for MinGW. If you ever switch to MSVC, sh.exe will trick > qmake into generating Unix makefiles and you will probably encounter all > these path problems. I don't build MinGW. I only build for MSVC and sometimes for ICC. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Mar 29 23:52:42 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 29 Mar 2016 23:52:42 +0200 Subject: [Development] gerrit : pointers to use it cleverly/efficiently? Message-ID: <1635019.vHF9KLjsb5@portia.local> Hi, I've got a few things I'd like to put up for code review, which I've been putting off because I can only think of doing them either one by one (carrying each to completion before moving on to the next) or by using parallel working copies. Neither is what I'd call efficient, and I'm sure there must be a more clever way to achieve the same thing, possible involving git branches for instance. Can someone point me in the right direction, maybe to a tutorial of sorts that outlines how to do several code reviews from a single working copy? I'm not exactly familiar with using branches; I just tried to create one, apply a patch, commit it and then push to gerrit. That was a bit of a failure; the commit to my local branch was also applied to the branch I thought I'd branched off, and the push to gerrit was refused: %> git push gerrit fatal: You are pushing to remote 'gerrit', which is not the upstream of your current branch '5.6.0', without telling me what to push to update which remote branch. Exit 128 %> git push gerrit 5.6.0:5.6.0 X11 forwarding request failed on channel 0 Counting objects: 6, done. Delta compression using up to 4 threads. Compressing objects: 100% (6/6), done. Writing objects: 100% (6/6), 820 bytes | 0 bytes/s, done. Total 6 (delta 5), reused 0 (delta 0) remote: Resolving deltas: 100% (5/5) remote: Processing changes: refs: 1, done To ssh://codereview.qt-project.org/qt/qtbase ! [remote rejected] 5.6.0 -> 5.6.0 (prohibited by Gerrit) error: failed to push some refs to 'ssh://codereview.qt-project.org/qt/qtbase' Exit 1 Gerrit really ought to accept patches without requiring them to be committed first; that should also make it much easier to keep them up to date to follow evolution of the targeted code (in any case I don't see how it could not make that easier). R. From annulen at yandex.ru Tue Mar 29 23:58:45 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 30 Mar 2016 00:58:45 +0300 Subject: [Development] gerrit : pointers to use it cleverly/efficiently? In-Reply-To: <1635019.vHF9KLjsb5@portia.local> References: <1635019.vHF9KLjsb5@portia.local> Message-ID: <1280191459288725@web6g.yandex.ru> 30.03.2016, 00:53, "René J.V. Bertin" : > Hi, > > I've got a few things I'd like to put up for code review, which I've been putting off because I can only think of doing them either one by one (carrying each to completion before moving on to the next) or by using parallel working copies. Neither is what I'd call efficient, and I'm sure there must be a more clever way to achieve the same thing, possible involving git branches for instance. > > Can someone point me in the right direction, maybe to a tutorial of sorts that outlines how to do several code reviews from a single working copy? > > I'm not exactly familiar with using branches; I just tried to create one, apply a patch, commit it and then push to gerrit. > That was a bit of a failure; the commit to my local branch was also applied to the branch I thought I'd branched off, and the push to gerrit was refused: > > %> git push gerrit > fatal: You are pushing to remote 'gerrit', which is not the upstream of > your current branch '5.6.0', without telling me what to push > to update which remote branch. > Exit 128 > > %> git push gerrit 5.6.0:5.6.0 > X11 forwarding request failed on channel 0 > Counting objects: 6, done. > Delta compression using up to 4 threads. > Compressing objects: 100% (6/6), done. > Writing objects: 100% (6/6), 820 bytes | 0 bytes/s, done. > Total 6 (delta 5), reused 0 (delta 0) > remote: Resolving deltas: 100% (5/5) > remote: Processing changes: refs: 1, done > To ssh://codereview.qt-project.org/qt/qtbase >  ! [remote rejected] 5.6.0 -> 5.6.0 (prohibited by Gerrit) > error: failed to push some refs to 'ssh://codereview.qt-project.org/qt/qtbase' > Exit 1 > > Gerrit really ought to accept patches without requiring them to be committed first; that should also make it much easier to keep them up to date to follow evolution of the targeted code (in any case I don't see how it could not make that easier). https://wiki.qt.io/Gerrit_Introduction#Creating_and_Uploading_Contributions You were trying to make direct push to 5.6.0 (which you are not allowed to do), instead of pushing it to review. -- Regards, Konstantin From rjvbertin at gmail.com Wed Mar 30 00:29:27 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 30 Mar 2016 00:29:27 +0200 Subject: [Development] gerrit : pointers to use it cleverly/efficiently? In-Reply-To: <1280191459288725@web6g.yandex.ru> References: <1635019.vHF9KLjsb5@portia.local> <1280191459288725@web6g.yandex.ru> Message-ID: <5229146.NcEJzI9Lm3@portia.local> On Wednesday March 30 2016 00:58:45 Konstantin Tokarev wrote: > https://wiki.qt.io/Gerrit_Introduction#Creating_and_Uploading_Contributions Thanks, I'll have another look. I may have missed the bit about the "topic branch" when I last perused that document. > You were trying to make direct push to 5.6.0 (which you are not allowed to do), instead of pushing it to review. I must be getting old, I'm having more and more difficulties wrapping my head around things like this that seem needlessly complicated =) R. From thiago.macieira at intel.com Wed Mar 30 00:51:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 29 Mar 2016 15:51:55 -0700 Subject: [Development] gerrit : pointers to use it cleverly/efficiently? In-Reply-To: <5229146.NcEJzI9Lm3@portia.local> References: <1635019.vHF9KLjsb5@portia.local> <1280191459288725@web6g.yandex.ru> <5229146.NcEJzI9Lm3@portia.local> Message-ID: <4472051.SQ3dbPP3Pc@tjmaciei-mobl4> On quarta-feira, 30 de março de 2016 00:29:27 PDT René J.V. Bertin wrote: > On Wednesday March 30 2016 00:58:45 Konstantin Tokarev wrote: > > https://wiki.qt.io/Gerrit_Introduction#Creating_and_Uploading_Contribution > > s > > Thanks, I'll have another look. I may have missed the bit about the "topic > branch" when I last perused that document. > > You were trying to make direct push to 5.6.0 (which you are not allowed to > > do), instead of pushing it to review. > I must be getting old, I'm having more and more difficulties wrapping my > head around things like this that seem needlessly complicated =) Use the git-gpush script. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sandy.martel at gmail.com Wed Mar 30 02:05:27 2016 From: sandy.martel at gmail.com (Sandy Martel) Date: Wed, 30 Mar 2016 11:05:27 +1100 Subject: [Development] Compiling 5.6.0 with VS2015 Message-ID: <9D615B76-2A68-4A1C-A1A2-A85BC5C12DD1@gmail.com> Anyone knows how to compile 5.6 tarball release with VS2015? I cannot get pass that error. Some have the same problem with VS2013. My config: configure.bat -icu -debug-and-release -nomake examples -prefix C:\Qt\VS2015\qt-5.6.0 -platform win32-msvc2015 -force-debug-info Result: C:\Qt\qt-build-5.6.0\qtwebengine\src\3rdparty\ninja\ninja.exe -C C:/Qt/qt-build-5.6.0/qtwebengine/src/core/Debug ninja: Entering directory `C:/Qt/qt-build-5.6.0/qtwebengine/src/core/Debug' [1/85] ACTION QtWebEngineCore: web_engine_settings.moc_77b3603f3e0b4538e38cc350a4bda9c0 [2/85] ACTION QtWebEngineCore: moc_clipboard_qt.cpp_77b3603f3e0b4538e38cc350a4bda9c0 [3/85] ACTION QtWebEngineCore: moc_url_request_custom_job_delegate.cpp_77b3603f3e0b4538e38cc350a4bda9c0 [4/85] ACTION QtWebEngineCore: moc_authentication_dialog_controller.cpp_77b3603f3e0b4538e38cc350a4bda9c0 [5/85] ACTION QtWebEngineCore: moc_javascript_dialog_controller.cpp_77b3603f3e0b4538e38cc350a4bda9c0 [6/85] ACTION QtWebEngineCore: moc_gl_context_qt.cpp_77b3603f3e0b4538e38cc350a4bda9c0 [7/85] ACTION QtWebEngineCore: moc_file_picker_controller.cpp_77b3603f3e0b4538e38cc350a4bda9c0 [8/85] ACTION QtWebEngineCore: location_provider_qt.moc_77b3603f3e0b4538e38cc350a4bda9c0 FAILED: C:\Qt\Python27\python.exe gyp-win-tool action-wrapper environment.x86 QtWebEngineCore_target_moc_clipboard_qt_cpp_77b3603f3e0b4538e38cc350a4bda9c0..rsp c:/qt/qt-src-5.6.0/qtwebengine\src\core moc: Cannot open options file specified with @ QCommandLineParser: argument list cannot be empty, it should contain at least the executable name FAILED: C:\Qt\Python27\python.exe gyp-win-tool action-wrapper environment.x86 QtWebEngineCore_target_web_engine_settings_moc_77b3603f3e0b4538e38cc350a4bda9c0..rsp c:/qt/qt-src-5.6.0/qtwebengine\src\core moc: Cannot open options file specified with @ QCommandLineParser: argument list cannot be empty, it should contain at least the executable name FAILED: C:\Qt\Python27\python.exe gyp-win-tool action-wrapper environment.x86 QtWebEngineCore_target_moc_url_request_custom_job_delegate_cpp_77b3603f3e0b4538e38cc350a4bda9c0..rsp c:/qt/qt-src-5.6.0/qtwebengine\src\core moc: Cannot open options file specified with @ QCommandLineParser: argument list cannot be empty, it should contain at least the executable name FAILED: C:\Qt\Python27\python.exe gyp-win-tool action-wrapper environment.x86 QtWebEngineCore_target_moc_javascript_dialog_controller_cpp_77b3603f3e0b4538e38cc350a4bda9c0..rsp c:/qt/qt-src-5.6.0/qtwebengine\src\core moc: Cannot open options file specified with @ QCommandLineParser: argument list cannot be empty, it should contain at least the executable name FAILED: C:\Qt\Python27\python.exe gyp-win-tool action-wrapper environment.x86 QtWebEngineCore_target_moc_authentication_dialog_controller_cpp_77b3603f3e0b4538e38cc350a4bda9c0..rsp c:/qt/qt-src-5.6.0/qtwebengine\src\core moc: Cannot open options file specified with @ QCommandLineParser: argument list cannot be empty, it should contain at least the executable name FAILED: C:\Qt\Python27\python.exe gyp-win-tool action-wrapper environment.x86 QtWebEngineCore_target_moc_file_picker_controller_cpp_77b3603f3e0b4538e38cc350a4bda9c0..rsp c:/qt/qt-src-5.6.0/qtwebengine\src\core moc: Cannot open options file specified with @ QCommandLineParser: argument list cannot be empty, it should contain at least the executable name FAILED: C:\Qt\Python27\python.exe gyp-win-tool action-wrapper environment.x86 QtWebEngineCore_target_moc_gl_context_qt_cpp_77b3603f3e0b4538e38cc350a4bda9c0..rsp c:/qt/qt-src-5.6.0/qtwebengine\src\core moc: Cannot open options file specified with @ QCommandLineParser: argument list cannot be empty, it should contain at least the executable name FAILED: C:\Qt\Python27\python.exe gyp-win-tool action-wrapper environment.x86 QtWebEngineCore_target_location_provider_qt_moc_77b3603f3e0b4538e38cc350a4bda9c0..rsp c:/qt/qt-src-5.6.0/qtwebengine\src\core moc: Cannot open options file specified with @ QCommandLineParser: argument list cannot be empty, it should contain at least the executable name ninja: build stopped: subcommand failed. jom: C:\Qt\qt-build-5.6.0\qtwebengine\src\core\Makefile.gyp_run.Debug [invoke_ninja] Error 1 jom: C:\Qt\qt-build-5.6.0\qtwebengine\src\core\Makefile.gyp_run [debug-all] Error 2 jom: C:\Qt\qt-build-5.6.0\qtwebengine\src\core\Makefile [sub-gyp_run-pro-make_first] Error 2 jom: C:\Qt\qt-build-5.6.0\qtwebengine\src\Makefile [sub-core-make_first] Error 2 jom: C:\Qt\qt-build-5.6.0\qtwebengine\Makefile [sub-src-make_first] Error 2 jom: C:\Qt\qt-build-5.6.0\Makefile [module-qtwebengine-make_first] Error 2 From partha1b at gmail.com Wed Mar 30 02:35:53 2016 From: partha1b at gmail.com (Partha Bagchi) Date: Tue, 29 Mar 2016 20:35:53 -0400 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <56FA0D25.9070801@kdab.com> References: <1972527.4yFI88HYkW@tjmaciei-mobl4> <1727325.CtYLaX67qZ@tjmaciei-mobl4> <56FA0D25.9070801@kdab.com> Message-ID: On Tue, Mar 29, 2016 at 1:05 AM, Andreas Holzammer < andreas.holzammer at kdab.com> wrote: > Hey, > > this got fixed in the 5.6 branch and did not get forward merged yet. > https://codereview.qt-project.org/#/c/153305/ > Please use that patch and the c++11 error should go away. > > Thank you > > Andy > > Am 29.03.2016 um 03:57 schrieb Thiago Macieira: > > On segunda-feira, 28 de março de 2016 21:33:11 PDT Partha Bagchi wrote: > >> EXTRA_CXXFLAGS = -std=c++11 -DUNICODE -ffunction-sections > > > > It's there, but it's not in your command-line, which had: > > > > g++ -c -o project.o -DUNICODE -g -IZ:/src/qt5/qtbase/qmake > > > > It's missing two options. I don't know how or why. From what I can see > in the > > Makefile, it should be impossible. > > > > OK, I think I applied the patch properly. Here is what I did: git fetch https://codereview.qt-project.org/qt/qtbase refs/changes/05/153305/4 && git format-patch -1 --stdout FETCH_HEAD One question, do I run mingw32-make from the cmd subshell or should I try to run make from the regular shell? I configured within the cmd subshell with the following command: configure -prefix Z:/opts/opt64-kde -opensource -confirm-license -optimized-tools -shared -nomake tests -nomake examples -release -opengl desktop -openssl -glib -qt-style-windows -I Z:\opts\opt64-kde\include -I Z:\opts\opt64-kde\include/freetype2 -I Z:\opts\opt64-kde\include/glib-2.0 -L Z:\opts\opt64-kde\lib -l glib-2.0 -l intl -l fontconfig -l freetype -l harfbuzz -fontconfig -system-zlib -system-libpng -system-harfbuzz -system-freetype -system-libjpeg -icu -largefile -wmf-backend Another question. After you run configure from the subshell, you get the following message: Qt is now configured for building. Just run mingw32-make. To reconfigure, run mingw32-make confclean and configure. However, mingw32-make confclean gives an error: Z:\src\kde\qt5>mingw32-make confclean mingw32-make: *** No rule to make target 'confclean'. Stop. Perhaps it's time to change this message? :) Thanks, Partha > -- > Andreas Holzammer | andreas.holzammer at kdab.com | Senior Software Engineer > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company > Tel: +49-30-521325470 > KDAB - The Qt 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 partha1b at gmail.com Wed Mar 30 04:25:36 2016 From: partha1b at gmail.com (Partha Bagchi) Date: Tue, 29 Mar 2016 22:25:36 -0400 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: References: <1972527.4yFI88HYkW@tjmaciei-mobl4> <1727325.CtYLaX67qZ@tjmaciei-mobl4> <56FA0D25.9070801@kdab.com> Message-ID: On Tue, Mar 29, 2016 at 8:35 PM, Partha Bagchi wrote: > > > On Tue, Mar 29, 2016 at 1:05 AM, Andreas Holzammer < > andreas.holzammer at kdab.com> wrote: > >> Hey, >> >> this got fixed in the 5.6 branch and did not get forward merged yet. >> https://codereview.qt-project.org/#/c/153305/ >> Please use that patch and the c++11 error should go away. >> >> Thank you >> >> Andy >> >> Am 29.03.2016 um 03:57 schrieb Thiago Macieira: >> > On segunda-feira, 28 de março de 2016 21:33:11 PDT Partha Bagchi wrote: >> >> EXTRA_CXXFLAGS = -std=c++11 -DUNICODE -ffunction-sections >> > >> > It's there, but it's not in your command-line, which had: >> > >> > g++ -c -o project.o -DUNICODE -g -IZ:/src/qt5/qtbase/qmake >> > >> > It's missing two options. I don't know how or why. From what I can see >> in the >> > Makefile, it should be impossible. >> > >> >> OK, I think I applied the patch properly. Here is what I did: > git fetch https://codereview.qt-project.org/qt/qtbase > refs/changes/05/153305/4 && git format-patch -1 --stdout FETCH_HEAD > > One question, do I run mingw32-make from the cmd subshell or should I try > to run make from the regular shell? > > I configured within the cmd subshell with the following command: > > configure -prefix Z:/opts/opt64-kde -opensource -confirm-license > -optimized-tools -shared -nomake tests -nomake examples -release -opengl > desktop -openssl -glib -qt-style-windows -I Z:\opts\opt64-kde\include -I > Z:\opts\opt64-kde\include/freetype2 -I Z:\opts\opt64-kde\include/glib-2.0 > -L Z:\opts\opt64-kde\lib -l glib-2.0 -l intl -l fontconfig -l freetype -l > harfbuzz -fontconfig -system-zlib -system-libpng -system-harfbuzz > -system-freetype -system-libjpeg -icu -largefile -wmf-backend > > > Another question. After you run configure from the subshell, you get the > following message: > > Qt is now configured for building. Just run mingw32-make. > To reconfigure, run mingw32-make confclean and configure. > > However, mingw32-make confclean gives an error: > > Z:\src\kde\qt5>mingw32-make confclean > mingw32-make: *** No rule to make target 'confclean'. Stop. > > Perhaps it's time to change this message? :) > > Thanks, > Partha > > >> -- >> Andreas Holzammer | andreas.holzammer at kdab.com | Senior Software Engineer >> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company >> Tel: +49-30-521325470 >> KDAB - The Qt Experts >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> > I went ahead and ran make from the msys shell. I now get the following error: g++ -c -pipe -fno-keep-inline-dllexport -O2 -std=c++1z -fno-exceptions -frtti -Wall -Wextra -Wvla -Wdate-time -DUNICODE -DQ_FONTCONFIGDATABASE -DQT_NO_EXCEPTIONS -DQT_NO_DEBUG -DQT_PLUGIN -DQT_PLATFORMSUPPORT_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I. -IZ:/opts/opt64-kde/include -IZ:/opts/opt64-kde/include/freetype2 -IZ:/opts/opt64-kde/include/glib-2.0 -I../../../../include -I../../../../include/QtPlatformSupport -I../../../../include/QtPlatformSupport/5.7.0 -I../../../../include/QtPlatformSupport/5.7.0/QtPlatformSupport -I../../../../include/QtGui/5.7.0 -I../../../../include/QtGui/5.7.0/QtGui -I../../../../include/QtGui -I../../../../include/QtCore/5.7.0 -I../../../../include/QtCore/5.7.0/QtCore -I../../../../include/QtCore -I.moc/release -I../../../../mkspecs/win32-g++ -o .obj/release/qminimalintegration.o qminimalintegration.cpp qminimalintegration.cpp: In member function 'virtual QPlatformFontDatabase* QMinimalIntegration::fontDatabase() const': qminimalintegration.cpp:123:34: error: 'QGenericUnixFontDatabase' does not name a type m_fontDatabase = new QGenericUnixFontDatabase; ^ Makefile.Release:916: recipe for target `.obj/release/qminimalintegration.o' failed make[6]: *** [.obj/release/qminimalintegration.o] Error 1 make[6]: Leaving directory `/usr/src/kde/qt5/qtbase/src/plugins/platforms/minimal' Makefile:34: recipe for target `release' failed make[5]: *** [release] Error 2 make[5]: Leaving directory `/usr/src/kde/qt5/qtbase/src/plugins/platforms/minimal' Makefile:39: recipe for target `sub-minimal-make_first' failed make[4]: *** [sub-minimal-make_first] Error 2 make[4]: Leaving directory `/usr/src/kde/qt5/qtbase/src/plugins/platforms' Makefile:95: recipe for target `sub-platforms-make_first' failed make[3]: *** [sub-platforms-make_first] Error 2 make[3]: Leaving directory `/usr/src/kde/qt5/qtbase/src/plugins' Makefile:661: recipe for target `sub-plugins-make_first' failed make[2]: *** [sub-plugins-make_first] Error 2 make[2]: Leaving directory `/usr/src/kde/qt5/qtbase/src' Makefile:41: recipe for target `sub-src-make_first' failed make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory `/usr/src/kde/qt5/qtbase' Makefile:83: recipe for target `module-qtbase-make_first' failed make: *** [module-qtbase-make_first] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at theqtcompany.com Wed Mar 30 08:29:01 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Wed, 30 Mar 2016 06:29:01 +0000 Subject: [Development] Compiling 5.6.0 with VS2015 In-Reply-To: <9D615B76-2A68-4A1C-A1A2-A85BC5C12DD1@gmail.com> References: <9D615B76-2A68-4A1C-A1A2-A85BC5C12DD1@gmail.com> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+kai.koehne=theqtcompany.com at qt-project.org] On Behalf Of > Sandy Martel > Sent: Wednesday, March 30, 2016 2:05 AM > To: development at qt-project.org > Subject: [Development] Compiling 5.6.0 with VS2015 > > Anyone knows how to compile 5.6 tarball release with VS2015? I cannot get > pass that error. Some have the same problem with VS2013. This was also raised yesterday on the interest@ mailing list. It's https://bugreports.qt.io/browse/QTBUG-51847 So far it seems only a problem with the .7z archives (unix line endings on Windows)? Regards Kai From nospam at pusling.com Wed Mar 30 09:12:13 2016 From: nospam at pusling.com (Sune Vuorela) Date: Wed, 30 Mar 2016 07:12:13 +0000 (UTC) Subject: [Development] gerrit : pointers to use it cleverly/efficiently? References: <1635019.vHF9KLjsb5@portia.local> Message-ID: On 2016-03-29, René J.V Bertin wrote: > Can someone point me in the right direction, maybe to a tutorial of sorts that outlines how to do several code reviews from a single working copy? > > I'm not exactly familiar with using branches; I just tried to create one, apply a patch, commit it and then push to gerrit. > That was a bit of a failure; the commit to my local branch was also applied to the branch I thought I'd branched off, and the push to gerrit was refused: Yesterday, I created a review for a bug fix. This is more or less my shell history: git checkout 3.6 #start from 3.6 branch. qtcreator fix git checkout -b readonly-reformat # create a branch, reformatting of qml vim/kate/qtcreator/whatever your sources make, make test, git add .... git commit git push origin HEAD:refs/for/3.6 #oops missing change id git commit --amend #add changeid git push origin HEAD:refs/for/3.6 #read sanitybot comments vim/kate/... git commit --amend git push origin HEAD:refs/for/3.6 Add reviewers. For next change, go to start. When reviews come in, go back to this branch git checkout readonly-reformat #hack hack hack git add git commit --amend git push origin HEAD:refs/for/3.6 /Sune From rolland at ghs.com Wed Mar 30 09:41:12 2016 From: rolland at ghs.com (Rolland Dudemaine) Date: Wed, 30 Mar 2016 09:41:12 +0200 Subject: [Development] gerrit : pointers to use it cleverly/efficiently? In-Reply-To: <1635019.vHF9KLjsb5@portia.local> References: <1635019.vHF9KLjsb5@portia.local> Message-ID: <56FB8318.7000604@ghs.com> On 29/03/2016 23:52, René J.V. Bertin wrote: > Hi, > > I've got a few things I'd like to put up for code review, which I've been putting off because I can only think of doing them either one by one (carrying each to completion before moving on to the next) or by using parallel working copies. Neither is what I'd call efficient, and I'm sure there must be a more clever way to achieve the same thing, possible involving git branches for instance. > > Can someone point me in the right direction, maybe to a tutorial of sorts that outlines how to do several code reviews from a single working copy? > I've been doing something slightly different, of the kind: git checkout 5.7 git add ... git commit git add ... git commit then: git checkout -b temp origin/5.7 git cherry-pick first-commit-sha second-commit-sha (or just one of those) git push gerrit HEAD:refs/for/5.7 git checkout 5.7 git branch -D temp But git-gpush as Thiago mentioned may be still far better... --Rolland/vapula From marc.mutz at kdab.com Wed Mar 30 10:17:09 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 30 Mar 2016 10:17:09 +0200 Subject: [Development] gerrit : pointers to use it cleverly/efficiently? In-Reply-To: References: <1635019.vHF9KLjsb5@portia.local> Message-ID: <201603301017.10516.marc.mutz@kdab.com> On Wednesday 30 March 2016 09:12:13 Sune Vuorela wrote: > On 2016-03-29, René J.V Bertin wrote: > > Can someone point me in the right direction, maybe to a tutorial of sorts > > that outlines how to do several code reviews from a single working copy? > > > > I'm not exactly familiar with using branches; I just tried to create one, > > apply a patch, commit it and then push to gerrit. > > > That was a bit of a failure; the commit to my local branch was also applied to the branch I thought I'd branched off, and the push to gerrit was refused: > Yesterday, I created a review for a bug fix. This is more or less my > shell history: > > git checkout 3.6 #start from 3.6 branch. qtcreator fix > git checkout -b readonly-reformat # create a branch, reformatting of qml > > vim/kate/qtcreator/whatever your sources > make, make test, > > git add .... > git commit > git push origin HEAD:refs/for/3.6 > #oops missing change id > git commit --amend #add changeid > git push origin HEAD:refs/for/3.6 > #read sanitybot comments > vim/kate/... > git commit --amend > git push origin HEAD:refs/for/3.6 > > Add reviewers. > > For next change, go to start. > When reviews come in, go back to this branch > > git checkout readonly-reformat > #hack hack hack > git add > git commit --amend > git push origin HEAD:refs/for/3.6 I usually just have one checkout from which I submit, and another one on which I develop. This makes it easier for me without an icecream cluster to shoulder the compile times. I regularly rebase my work on a local merge of 5.6 and 5.7 into dev, so merged commits disappear from my local branch, and start a new submission branch from then-current gerrit/5.x for the submission checkout. When I need to fix a commit, I just git checkout sha-from-Gerrit-page in the submission checkout, usually not bothering to update the corresponding change in the development checkout (it will be solved with the next merge from upstream) ie. I don't bother keeping branches. I did, but their rebasing is just too much work. So basically, my workflow currently is: qtbase-work at work$ edit ... qtbase-work at work$ compile/test (more intensive) qtbase-work at work$ git add -p qtbase-work at work$ git commit -m ... qtbase-work at work$ cd - qtbase-submit@(no branch)$ git fetch work && git cherry-pick work/work qtbase-submit@(no branch)$ compile/test (less intensive) qtbase-submit@(no branch)$ git gpush +thiago +ogoffart +lars ... HEAD:5.6/ubsan qtbase-submit@(no branch)$ cd - qtbase-work at work$ edit ... # oops, review needs update: qtbase-work at work$ cd - qtbase-submit@(no branch)$ git checkout sha1-from-Gerrit-page [1] qtbase-submit@(no branch)$ git fetch gerrit ... && git checkout FETCH_HEAD [1] qtbase-submit@(no branch)$ edit / compile / test qtbase-submit@(no branch)$ git push gerrit HEAD:refs/for/5.6 [1] if possible [2] if git-fsck deleted it locally in the meantime # periodically (submit) qtbase-submit@(no branch)$ git fetch gerrit qtbase-submit@(no branch)$ git checkout gerrit/5.6 # to start anew # periodically (work): qtbase-work at work$ git fetch gerrit qtbase-work at work$ git checkout gerrit/dev qtbase-work at gerrit/dev$ git merge gerrit/5.7 qtbase-work@(no branch)$ git merge gerrit/5.6 qtbase-work@(no branch)$ gitk & # remember current sha1 :) qtbase-work@(no branch)$ git rebase --onto HEAD gerrit-dev+merges work [3] qtbase-work at work$ git tag -d gerrit-dev+merges qtbase-work at work$ git tag gerrit-dev+mperges sha1-from-open-gitk qtbase-work at work$ git rebase -i gerrit-dev+merges [3] resolve conflicts, usually with rebase --skip (when change was upstreamed) [4] eg. squash oops commits, drop abandoned changes, ... I haven't checked the multiple-checkouts feature of newer gits, but that would make this workflow even simpler, because sha1s would be automatically shared between the two checkouts without the need to deal with local remotes and their mess of branches. I only keep this setup for qtbase, because that's where I work almost exclusively. For the rest of qt5.git, I just develop and submit from the same checkout. And I often abuse the submit checkout for development when the development checkout is recompiling the world after a change to qglobal.h or similar. HTH, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From sean.harmer at kdab.com Wed Mar 30 10:34:40 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Wed, 30 Mar 2016 09:34:40 +0100 Subject: [Development] Nominating Volker Krause for Approver status Message-ID: <1837438.BeO96xjKmG@titan> Hi All, I'd like to nominate Volker Krause for approver status. Volker is one of the main authors of GammaRay, is very active in the Qt Automotive sphere where he leads up KDAB's contributions, and has touched many parts all over Qt (including Qt 3D). His dashboard is at: https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z and reviews at: https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z Can I get a +1 please? Cheers, Sean Disclaimer: I work at KDAB with Volker. -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From rich at kde.org Wed Mar 30 11:17:00 2016 From: rich at kde.org (Richard Moore) Date: Wed, 30 Mar 2016 10:17:00 +0100 Subject: [Development] Nominating Volker Krause for Approver status In-Reply-To: <1837438.BeO96xjKmG@titan> References: <1837438.BeO96xjKmG@titan> Message-ID: +1 On 30 March 2016 at 09:34, Sean Harmer wrote: > Hi All, > > I'd like to nominate Volker Krause for approver status. Volker is one of > the > main authors of GammaRay, is very active in the Qt Automotive sphere where > he > leads up KDAB's contributions, and has touched many parts all over Qt > (including Qt 3D). > > His dashboard is at: > > https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z > > and reviews at: > > https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z > > Can I get a +1 please? > > Cheers, > > Sean > > Disclaimer: I work at KDAB with Volker. > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at theqtcompany.com Wed Mar 30 11:18:36 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 30 Mar 2016 09:18:36 +0000 Subject: [Development] Nominating Volker Krause for Approver status In-Reply-To: References: <1837438.BeO96xjKmG@titan> Message-ID: <2387C660-589D-4C10-BE6F-11734B6F11E2@theqtcompany.com> He isn’t yet? In that case, a big +1 from me :) Cheers, Lars From: Development > on behalf of Richard Moore > Date: Wednesday 30 March 2016 at 11:17 To: Qt development mailing list > Subject: Re: [Development] Nominating Volker Krause for Approver status +1 On 30 March 2016 at 09:34, Sean Harmer > wrote: Hi All, I'd like to nominate Volker Krause for approver status. Volker is one of the main authors of GammaRay, is very active in the Qt Automotive sphere where he leads up KDAB's contributions, and has touched many parts all over Qt (including Qt 3D). His dashboard is at: https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z and reviews at: https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z Can I get a +1 please? Cheers, Sean Disclaimer: I work at KDAB with Volker. -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.vatra at kdab.com Wed Mar 30 11:25:51 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Wed, 30 Mar 2016 12:25:51 +0300 Subject: [Development] Nominating Volker Krause for Approver status In-Reply-To: <2387C660-589D-4C10-BE6F-11734B6F11E2@theqtcompany.com> References: <1837438.BeO96xjKmG@titan> <2387C660-589D-4C10-BE6F-11734B6F11E2@theqtcompany.com> Message-ID: <2066236.pQuZ3jWlZB@zmeu> +1 for my side! Cheers, BogDan. On Wednesday 30 March 2016 09:18:36 Knoll Lars wrote: > He isn’t yet? In that case, a big +1 from me :) > > Cheers, > Lars > > From: Development > lopment-bounces+lars.knoll=theqtcompany.com at qt-project.org>> on behalf of > Richard Moore > Date: Wednesday 30 March > 2016 at 11:17 > To: Qt development mailing list > > Subject: > Re: [Development] Nominating Volker Krause for Approver status > +1 > > On 30 March 2016 at 09:34, Sean Harmer > > wrote: Hi All, > > I'd like to nominate Volker Krause for approver status. Volker is one of > the main authors of GammaRay, is very active in the Qt Automotive sphere > where he leads up KDAB's contributions, and has touched many parts all over > Qt (including Qt 3D). > > His dashboard is at: > > https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z > > and reviews at: > > https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z > > Can I get a +1 please? > > Cheers, > > Sean > > Disclaimer: I work at KDAB with Volker. > -- > Dr Sean Harmer | sean.harmer at kdab.com | > Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. UK +44 (0)1625 809908, Sweden (HQ) > +46-563-540090 KDAB - Qt Experts - > Platform-independent software solutions > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From marc.mutz at kdab.com Wed Mar 30 11:47:14 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 30 Mar 2016 11:47:14 +0200 Subject: [Development] Nominating Volker Krause for Approver status In-Reply-To: <2387C660-589D-4C10-BE6F-11734B6F11E2@theqtcompany.com> References: <1837438.BeO96xjKmG@titan> <2387C660-589D-4C10-BE6F-11734B6F11E2@theqtcompany.com> Message-ID: <201603301147.17767.marc.mutz@kdab.com> [...] > I'd like to nominate Volker Krause for approver status. +1 > Disclaimer: I work at KDAB with Volker. Same here. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From oswald.buddenhagen at theqtcompany.com Wed Mar 30 12:46:48 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 30 Mar 2016 12:46:48 +0200 Subject: [Development] Compiling QT 5.7 Windows 64-bit In-Reply-To: <20160329123309.GB4895@orion> References: <20160328201354.GA5540@orion> <4201675.V7MkygiQxE@tjmaciei-mobl4> <20160329123309.GB4895@orion> Message-ID: <20160330104648.GE29908@troll08.it.local> On Tue, Mar 29, 2016 at 09:33:12AM -0300, Rafael Roquetto wrote: > If you ever switch to MSVC, sh.exe will trick qmake into generating > Unix makefiles > i wonder where you got that idea from ... From edward.welbourne at theqtcompany.com Wed Mar 30 14:54:30 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Wed, 30 Mar 2016 12:54:30 +0000 Subject: [Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?) In-Reply-To: <1635019.vHF9KLjsb5@portia.local> References: <1635019.vHF9KLjsb5@portia.local> Message-ID: René J.V. Bertin said: > I've got a few things I'd like to put up for code review, which I've > been putting off because I can only think of doing them either one by > one (carrying each to completion before moving on to the next) or by > using parallel working copies. Neither is what I'd call efficient, and > I'm sure there must be a more clever way to achieve the same thing, > possible involving git branches for instance. In principle you don't actually need branches; you can work in a "detached head" state (which git lectures you about, but you can probably suppress that with a config option or the -q flag I'll use below), e.g. after making some changes on your local dev, $ git checkout -q gerrit/dev $ git cherry-pick single-sha1-from-local-dev # sort out any conflicts, test, review locally $ git push gerrit HEAD:refs/for/dev You can equally do this using a tmp branch, $ git checkout -b tmp gerrit/dev $ git cherry-pick ... $ git push gerrit tmp:refs/for/dev $ git reset --hard gerrit/dev $ git cherry-pick ... etc. which can be helpful if some of your commits are dependent on one another and you want to gather them together, review and test locally, fixup (rebasing to squash the fixes into the commit that made them necessary, etc.), rinse and repeat, before pushing to gerrit. This is halfway to using topic branches. Once you're done, it's tidy to $ git branch -D tmp Personally, I do my development on topic branches so that my dev, 5.7, 5.6 are pristine images of upstream. The topic branch names also help me keep track of what each one is about. I put unrelated changes on separate branches. If I find I've mixed changes on a branch that I later want to separate, I'll first rebase -i to shuffle their order so there's an early part of the branch that's one group of changes (ending with early-tip-sha1 below) and the rest is the other. Then $ git branch early-part-name early-tip-sha1 # That created a branch, leaving you still on old-mixed-branch; # skip the next two if old-mixed-branch is a good name for the late part: $ git checkout -b late-part-name old-mixed-branch $ git branch -d old-mixed-branch # Now separate the late part from the early: $ git rebase early-part-name -onto dev That last part, a rebase with -onto, picks up everything after the early part - i.e. the whole late part, without the early part - and replays it on top of dev, transforming dev early-part-name | | v v o--A--B--C--W--X--Y--Z <- late-part-name (early points to C, in case formatting got messed up !) into dev | v o--A--B--C <- early-part-name \ W--X--Y--Z <- late-part-name It's best to do such major branch surgery *before* pushing anything involved to Gerrit - and, if doing so after, for the first push of the rearranged changes, to make no changes *but* this rearrangement and let reviewers know about it, since they can't usefully compare earlier patch sets with later ones. Combining real changes to your patch set with rebasing is unkind to reviewers - keep rebases clean, when you need to do them, and let reviewers know about them. If I just want to select take a few commits from an existing branch to send for early review, I'll typically use a tmp branch as described above. It's also possible to use a tmp branch to check several separate branches do all play nicely together: $ git checkout -b tmp last-branch $ git rebase penultimate-branch #... $ git rebase second-branch $ git rebase first-branch # build test, etc. which shall teach you about conflicts along the way. Just remember that any changes you make on tmp aren't reflected on the original branches until you cherry-pick them back there (and optionally rebase to put them where they belong). Eddy. From edward.welbourne at theqtcompany.com Wed Mar 30 14:55:23 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Wed, 30 Mar 2016 12:55:23 +0000 Subject: [Development] gerrit : what went wrong (was: pointers to use it cleverly/efficiently?) In-Reply-To: <1635019.vHF9KLjsb5@portia.local> References: <1635019.vHF9KLjsb5@portia.local> Message-ID: René J.V. Bertin said: > I'm not exactly familiar with using branches; I just tried to create > one, apply a patch, commit it and then push to gerrit. That was a bit > of a failure; the commit to my local branch was also applied to the > branch I thought I'd branched off, and the push to gerrit was refused: > > %> git push gerrit > fatal: You are pushing to remote 'gerrit', which is not the upstream of > your current branch '5.6.0', without telling me what to push > to update which remote branch. > Exit 128 That sounds like you didn't do what you thought you did. If you create a branch with $ git checkout -b topic origin/upstream then git shall know that your topic branch is based on origin's upstream branch; a git push origin will then know to push topic to upstream. However, that's not the workflow for Gerrit, where you push to a refs/for/upstream instead of directly to upstream (as others have pointed out; your > ! [remote rejected] 5.6.0 -> 5.6.0 (prohibited by Gerrit) was caused by this). In any case, the error message indicates you currently have branch 5.6.0 checked out, where you thought you had a topic branch checked out. If you $ git branch topic [base] then it *creates* the branch, topic (starting at base, if given, else at your present HEAD) but *does not* check out that branch; for that use $ git checkout -b topic [base] If you used git branch and then made your changes, then you made your changes on your original branch, presumably 5.6.0, not on the branch you'd created and not checked out. With git checkout -b, you checkout the newly-created branch and won't be making changes to the base. > %> git push gerrit 5.6.0:5.6.0 > X11 forwarding request failed on channel 0 This smells like you've got some default ssh config enabling X11 forwarding: you should probably turn that off for the gerrit server ! Eddy. From milian.wolff at kdab.com Wed Mar 30 15:23:46 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 30 Mar 2016 15:23:46 +0200 Subject: [Development] Nominating Volker Krause for Approver status In-Reply-To: <201603301147.17767.marc.mutz@kdab.com> References: <1837438.BeO96xjKmG@titan> <2387C660-589D-4C10-BE6F-11734B6F11E2@theqtcompany.com> <201603301147.17767.marc.mutz@kdab.com> Message-ID: <2220437.W4mW4mjVhl@milian-kdab2> On Wednesday, March 30, 2016 11:47:14 AM CEST Marc Mutz wrote: > [...] > > > I'd like to nominate Volker Krause for approver status. > > +1 > > > Disclaimer: I work at KDAB with Volker. > > Same here. +1 for both. -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From olivier at woboq.com Wed Mar 30 16:08:52 2016 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 30 Mar 2016 16:08:52 +0200 Subject: [Development] Changing definition of Qt meta macro to allow tools integration Message-ID: <2846913.44WYRE1kvo@finn> Hi, As I am working on porting qdoc using clang, this is yet another time a tool is using clang to get information about Qt code and Qt meta macro (signals, slots, properties, ...) This has been done before: qtcreator's clang code model [1], moc-ng [2], kdevelop, ... In each case, we need to resort to hacks to redefine the macros at the right place when there should be redefined. Hence while doing it for qdoc, I suggest doing it in a generic way so that we can simplify the hacks using additional macro. Here is the patch: https://codereview.qt-project.org/151667 The way it works is that one can inject new macros at the begining of the translation unit (which makes everything simpler). The macro injected are compiler dependent. This works well with clang. I don't know if there is any other tool or compiler that needs to be suported and that would have different needs. And that's the reason of this mail. This meet the needs for qdoc and moc-ng, and I guess also for QtCreator. By this mail I'm asking if other tools author think about improvement. I am also wondering in which branch to push this. Should it go in Qt 5.6 LTS so newer Qt creator can benefit of it starting from Qt 5.6.1? [1] https://code.woboq.org/qt5/qt-creator/share/qtcreator/cplusplus/wrappedQtHeaders/QtCore/qobjectdefs.h.html [2] https://code.woboq.org/mocng/src/qobjectdefs-injected.h.html -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From rjvbertin at gmail.com Wed Mar 30 17:00:20 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 30 Mar 2016 17:00:20 +0200 Subject: [Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?) In-Reply-To: References: <1635019.vHF9KLjsb5@portia.local> Message-ID: <1885186.XDnYivrAq4@patux> On Wednesday March 30 2016 12:54:30 Welbourne Edward wrote: >René J.V. Bertin said: >> I've got a few things I'd like to put up for code review, which I've >> been putting off because I can only think of doing them either one by Hi, Thanks for such a lengthy and detailed overview - I hope you had that sitting around somewhere! :) It also illustrates very nicely why I'll keep thinking that it'd be so much easier if Qt had a review system to which you can upload the (possibly pruned) results of `git diff` (and download it again if needed). I've learned along the way that I tend to be too sloppy and absent-minded to be trusted with series of commands you showed, esp. if they have names that aren't necessarily very clear about what they do. What works well for me e.g. before doing a commit is what I think of as manual rebasing: I remove my patches one way or another, git-pull, and then reapply the patch(es). A repo like qtbase is a bit big to mess up locally and then just check out again on a regular basis. I don't know what exactly went wrong with my 1st attempt to use branches (I did do a checkout and verified that I was on my branch), but now that I know how to create topic branches and switch between them, "rewinding" to a clean state should be as simple as deleting the branch (presuming that can be done without merging it). R From edward.welbourne at theqtcompany.com Wed Mar 30 17:51:49 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Wed, 30 Mar 2016 15:51:49 +0000 Subject: [Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?) In-Reply-To: <1885186.XDnYivrAq4@patux> References: <1635019.vHF9KLjsb5@portia.local> , <1885186.XDnYivrAq4@patux> Message-ID: > Thanks for such a lengthy and detailed overview - I hope you had that > sitting around somewhere! :) heh - I touch-type at speed and have all of that in my head. I learned git under demanding circumstances, so learned it thorouhgly. > It also illustrates very nicely why I'll keep thinking that it'd be so > much easier if Qt had a review system to which you can upload the > (possibly pruned) results of `git diff` (and download it again if > needed). I met such a review tool once. It was actually horribly frustrating. I'd much sooner be using critic [0]. [0] https://github.com/jensl/critic > I've learned along the way that I tend to be too sloppy and > absent-minded to be trusted with series of commands you showed, > esp. if they have names that aren't necessarily very clear about what > they do. I'm afraid git was designed by people who take command-line arcana for granted. It's a mighty powerful tool, but you do have to invest time and brain-space in it. > What works well for me e.g. before doing a commit is what I think of > as manual rebasing: I remove my patches one way or another, git-pull, > and then reapply the patch(es). That's pretty much exactly what $ git pull -r (a.k.a. --rebase) will do for you, automagically. It might not play ideally with merges in all cases, but I'm guessing you don't have a surfeit of those. Generally, rebase is just a way to replay a succession of changes starting from a different upstream. > A repo like qtbase is a bit big to > mess up locally and then just check out again on a regular basis. Yes. Doing the git submodule update --init --recursive after the git clone can be a bit time-consuming, even from a local bare repo (i.e. without the network traffic of fetching from Gerrit). > I don't know what exactly went wrong with my 1st attempt to use > branches (I did do a checkout and verified that I was on my branch), OK. Then my guess at what went wrong missed. Hard to diagnose from what you described, though. > but now that I know how to create topic branches and switch between > them, "rewinding" to a clean state should be as simple as deleting the > branch (presuming that can be done without merging it). Well, simply checking out the branch you want to be on will get you back to it, without having to delete any useful state. If you're on a topic branch, off dev say, and want to get up date with recent changes to dev, it's as simple as: $ git checkout dev $ git pull $ git checkout topic-branch $ git rebase dev and you're done, using just easy commands. The first two commands are what gets your dev up to date, the other two bring your topic-branch up to date with it. You can even shorten that to: $ git fetch gerrit $ git rebase gerrit/dev if you don't mind your local dev staying out of date until next time you're using it (which may even be an advantage, in some cases). If you have local changes you aren't yet ready to commit, you can wrap commands like those above in $ git stash ... $ git stash pop to save and restore the mess, Eddy. From thiago.macieira at intel.com Wed Mar 30 17:58:48 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 30 Mar 2016 08:58:48 -0700 Subject: [Development] Changing definition of Qt meta macro to allow tools integration In-Reply-To: <2846913.44WYRE1kvo@finn> References: <2846913.44WYRE1kvo@finn> Message-ID: <2561142.S9agivpbA3@tjmaciei-mobl4> On quarta-feira, 30 de março de 2016 16:08:52 PDT Olivier Goffart wrote: > Hi, > > As I am working on porting qdoc using clang, this is yet another time a tool > is using clang to get information about Qt code and Qt meta macro (signals, > slots, properties, ...) > > This has been done before: qtcreator's clang code model [1], moc-ng [2], > kdevelop, ... In each case, we need to resort to hacks to redefine the > macros at the right place when there should be redefined. > > Hence while doing it for qdoc, I suggest doing it in a generic way so that > we can simplify the hacks using additional macro. > > Here is the patch: https://codereview.qt-project.org/151667 That's a good idea. I like it and I've approved it. But please wait for reactions to your email (especially branching) before staging. > I am also wondering in which branch to push this. Should it go in Qt 5.6 LTS > so newer Qt creator can benefit of it starting from Qt 5.6.1? You've proposed it for dev, but I think it deserves at least 5.7. I don't have a problem in it landing in 5.6, but I don't see much benefit there since qdoc for 5.6 is already released and Qt Creator will need to deal with 5.6.0 as-is and previous versions anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 30 18:04:05 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 30 Mar 2016 09:04:05 -0700 Subject: [Development] gerrit : pointers to use it cleverly/efficiently? In-Reply-To: <56FB8318.7000604@ghs.com> References: <1635019.vHF9KLjsb5@portia.local> <56FB8318.7000604@ghs.com> Message-ID: <21164333.kbmRCzqGRv@tjmaciei-mobl4> On quarta-feira, 30 de março de 2016 09:41:12 PDT Rolland Dudemaine wrote: > git checkout -b temp origin/5.7 > git cherry-pick first-commit-sha second-commit-sha (or just one of those) > git push gerrit HEAD:refs/for/5.7 > git checkout 5.7 > git branch -D temp > > But git-gpush as Thiago mentioned may be still far better... This is exactly what git gpush does, except that it does everything without changing your checkout, which means you won't trigger a full rebuild-the- world. It has a few more features beyond that, including the ability to pass reviewers in the command-line and handling of multiple patch groups in the same branch, for those who are crazy to develop like I am. Sometimes, the cherry-picking without checkout fails. So you may have to do the above anyway. If this happens often enough, like it does for me, I recommend having a separate clone or git new-workdir, so you aren't forced to rebuild the world. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 30 18:10:49 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 30 Mar 2016 09:10:49 -0700 Subject: [Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?) In-Reply-To: <1885186.XDnYivrAq4@patux> References: <1635019.vHF9KLjsb5@portia.local> <1885186.XDnYivrAq4@patux> Message-ID: <1852255.FUzVmog2yV@tjmaciei-mobl4> On quarta-feira, 30 de março de 2016 17:00:20 PDT René J.V. Bertin wrote: > It also illustrates very nicely why I'll keep thinking that it'd be so much > easier if Qt had a review system to which you can upload the (possibly > pruned) results of `git diff` (and download it again if needed). git diff misses the parent commit ID and the commit message. The output from git format-patch has the commit message, but still misses the parent commit ID. Note that upstream Gerrit has a feature to download files from each change, the full patch as well as the full revision, plus you can edit the files on the web, not just the commit message. Our Gerrit doesn't have those features because we can't upgrade and we aren't using the new Gerrit UI. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Mar 30 18:14:38 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 30 Mar 2016 19:14:38 +0300 Subject: [Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?) In-Reply-To: <1852255.FUzVmog2yV@tjmaciei-mobl4> References: <1635019.vHF9KLjsb5@portia.local> <1885186.XDnYivrAq4@patux> <1852255.FUzVmog2yV@tjmaciei-mobl4> Message-ID: <156851459354478@web19g.yandex.ru> 30.03.2016, 19:11, "Thiago Macieira" : > On quarta-feira, 30 de março de 2016 17:00:20 PDT René J.V. Bertin wrote: >>  It also illustrates very nicely why I'll keep thinking that it'd be so much >>  easier if Qt had a review system to which you can upload the (possibly >>  pruned) results of `git diff` (and download it again if needed). > > git diff misses the parent commit ID and the commit message. The output from > git format-patch has the commit message, but still misses the parent commit > ID. > > Note that upstream Gerrit has a feature to download files from each change, the > full patch as well as the full revision, plus you can edit the files on the > web, not just the commit message. Our Gerrit doesn't have those features > because we can't upgrade and we aren't using the new Gerrit UI. New UI is not required to use these features -- Regards, Konstantin From rjvbertin at gmail.com Wed Mar 30 19:09:42 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 30 Mar 2016 19:09:42 +0200 Subject: [Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?) In-Reply-To: References: <1635019.vHF9KLjsb5@portia.local> <1885186.XDnYivrAq4@patux> Message-ID: <291962355.PTURBcOlE2@portia.local> On Wednesday March 30 2016 15:51:49 Welbourne Edward wrote: > I met such a review tool once. > It was actually horribly frustrating. > I'd much sooner be using critic [0]. I am a regular user of KDE's Reviewboard. It's undoubtedly not ideal, but I find it more than powerful enough. > I'm afraid git was designed by people who take command-line arcana for > granted. It's a mighty powerful tool, but you do have to invest time > and brain-space in it. I have no problem with the fact that it's a commandline tool. I've been living on command lines since the TRS80 ... Git's sub commands are a problem though, somehow. It's got a lot of commands that do a whole bunch of things that aren't necessarily clear, and that appear to have been named by people who speak a different kind of English. > That's pretty much exactly what > > $ git pull -r > > (a.k.a. --rebase) will do for you, automagically. It might not play > ideally with merges in all cases, but I'm guessing you don't have a > surfeit of those. I know, but as a matter of fact I do get merges and conflicts or otherwise not cleanly applying patches a little too often, which tend to leave my working copy in a state from which I know I haven't been able to recuperate a few times too many. > > A repo like qtbase is a bit big to > > mess up locally and then just check out again on a regular basis. > > Yes. Doing the git submodule update --init --recursive after the git > clone can be a bit time-consuming, even from a local bare repo And I was only speaking about qtbase.git. > OK. Then my guess at what went wrong missed. > Hard to diagnose from what you described, though. Oh, don't worry about that, I now know I should simply use "checkout -b" and only manhandle `git branch` when I want to delete a branch. > to it, without having to delete any useful state. If you're on a topic > branch, off dev say, and want to get up date with recent changes to dev, > it's as simple as: > > $ git checkout dev > $ git pull > $ git checkout topic-branch > $ git rebase dev provided the rebase doesn't go awry (and the "parent" branch hasn't disappeared from the remote, like the 5.6.0 branch I was using). Either way, deleting `topic-branch` and creating it anew will be much less of a hassle than recreating the whole working copy. But I suspect that even if you delete such a branch, it will be kept in the history because git never throws out anything completely? Cheers, René From andre at familiesomers.nl Wed Mar 30 20:35:41 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 30 Mar 2016 20:35:41 +0200 Subject: [Development] gerrit : using branches In-Reply-To: <291962355.PTURBcOlE2@portia.local> References: <1635019.vHF9KLjsb5@portia.local> <1885186.XDnYivrAq4@patux> <291962355.PTURBcOlE2@portia.local> Message-ID: <56FC1C7D.6040703@familiesomers.nl> Op 30/03/2016 om 19:09 schreef René J.V. Bertin: > On Wednesday March 30 2016 15:51:49 Welbourne Edward wrote: > >> I met such a review tool once. >> It was actually horribly frustrating. >> I'd much sooner be using critic [0]. > I am a regular user of KDE's Reviewboard. It's undoubtedly not ideal, but I find it more than powerful enough. > >> I'm afraid git was designed by people who take command-line arcana for >> granted. It's a mighty powerful tool, but you do have to invest time >> and brain-space in it. > I have no problem with the fact that it's a commandline tool. I've been living on command lines since the TRS80 ... > Git's sub commands are a problem though, somehow. It's got a lot of commands that do a whole bunch of things that aren't necessarily clear, and that appear to have been named by people who speak a different kind of English. That's why I have a cheat sheet hanging next to my desk. In case of doubt, look at that. Most of the fancy stuff you never or hardly ever need anyway. Then Google is your friend. > >> That's pretty much exactly what >> >> $ git pull -r >> >> (a.k.a. --rebase) will do for you, automagically. It might not play >> ideally with merges in all cases, but I'm guessing you don't have a >> surfeit of those. > I know, but as a matter of fact I do get merges and conflicts or otherwise not cleanly applying patches a little too often, which tend to leave my working copy in a state from which I know I haven't been able to recuperate a few times too many. Git reflog is your friend here. It can get you out of a tight spot in case of need. André From edward.welbourne at theqtcompany.com Wed Mar 30 20:55:12 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Wed, 30 Mar 2016 18:55:12 +0000 Subject: [Development] gerrit : using branches In-Reply-To: <56FC1C7D.6040703@familiesomers.nl> References: <1635019.vHF9KLjsb5@portia.local> <1885186.XDnYivrAq4@patux> <291962355.PTURBcOlE2@portia.local>, <56FC1C7D.6040703@familiesomers.nl> Message-ID: I said: >>> That's pretty much exactly what >>> >>> $ git pull -r >>> >>> (a.k.a. --rebase) will do for you, automagically. It might not play >>> ideally with merges in all cases, but I'm guessing you don't have a >>> surfeit of those. To which: > Op 30/03/2016 om 19:09 schreef René J.V. Bertin: >> I know, but as a matter of fact I do get merges and conflicts or >> otherwise not cleanly applying patches a little too often, which tend >> to leave my working copy in a state from which I know I haven't been >> able to recuperate a few times too many. and André Somers replied: > Git reflog is your friend here. It can get you out of a tight spot in > case of need. ... with a little help from git reset --hard as the way to get your current branch and your working tree both back to somewhere you were recently, that seemed like a better place than the mess you're now in. Eddy. From annulen at yandex.ru Wed Mar 30 21:23:35 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 30 Mar 2016 22:23:35 +0300 Subject: [Development] QThreadStorage and C++11 Message-ID: <301561459365815@web13o.yandex.ru> Hello, Are there any plans to reimplement QThreadStorage via thread_local for compilers which support it? -- Regards, Konstantin From olivier at woboq.com Wed Mar 30 21:35:55 2016 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 30 Mar 2016 21:35:55 +0200 Subject: [Development] Changing definition of Qt meta macro to allow tools integration In-Reply-To: <2561142.S9agivpbA3@tjmaciei-mobl4> References: <2846913.44WYRE1kvo@finn> <2561142.S9agivpbA3@tjmaciei-mobl4> Message-ID: <1553050.fTJH5BaTsB@finn> Am Mittwoch, 30. März 2016, 08:58:48 CEST schrieb Thiago Macieira: > On quarta-feira, 30 de março de 2016 16:08:52 PDT Olivier Goffart wrote: > > Hi, > > > > As I am working on porting qdoc using clang, this is yet another time a > > tool is using clang to get information about Qt code and Qt meta macro > > (signals, slots, properties, ...) > > > > This has been done before: qtcreator's clang code model [1], moc-ng [2], > > kdevelop, ... In each case, we need to resort to hacks to redefine the > > macros at the right place when there should be redefined. > > > > Hence while doing it for qdoc, I suggest doing it in a generic way so that > > we can simplify the hacks using additional macro. > > > > Here is the patch: https://codereview.qt-project.org/151667 > > That's a good idea. I like it and I've approved it. But please wait for > reactions to your email (especially branching) before staging. > > > I am also wondering in which branch to push this. Should it go in Qt 5.6 > > LTS so newer Qt creator can benefit of it starting from Qt 5.6.1? > > You've proposed it for dev, but I think it deserves at least 5.7. I don't > have a problem in it landing in 5.6, but I don't see much benefit there > since qdoc for 5.6 is already released and Qt Creator will need to deal > with 5.6.0 as-is and previous versions anyway. What minimum version of Qt will Qt Creator released in 2 year from now require? (to develop with) Will it be Qt 5.6.0 or Qt 5.6.1? Or maybe 5.6.7? I don't think it will be 5.6.0. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Wed Mar 30 21:38:57 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 30 Mar 2016 12:38:57 -0700 Subject: [Development] QThreadStorage and C++11 In-Reply-To: <301561459365815@web13o.yandex.ru> References: <301561459365815@web13o.yandex.ru> Message-ID: <2466995.AY7YjMsaIa@tjmaciei-mobl4> On quarta-feira, 30 de março de 2016 22:23:35 PDT Konstantin Tokarev wrote: > Hello, > > Are there any plans to reimplement QThreadStorage via thread_local for > compilers which support it? I haven't investigated whether it's possible. Probably not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Mar 30 21:39:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 30 Mar 2016 12:39:58 -0700 Subject: [Development] Changing definition of Qt meta macro to allow tools integration In-Reply-To: <1553050.fTJH5BaTsB@finn> References: <2846913.44WYRE1kvo@finn> <2561142.S9agivpbA3@tjmaciei-mobl4> <1553050.fTJH5BaTsB@finn> Message-ID: <2169915.xr42Tts652@tjmaciei-mobl4> On quarta-feira, 30 de março de 2016 21:35:55 PDT Olivier Goffart wrote: > > > I am also wondering in which branch to push this. Should it go in Qt 5.6 > > > LTS so newer Qt creator can benefit of it starting from Qt 5.6.1? > > > > You've proposed it for dev, but I think it deserves at least 5.7. I don't > > have a problem in it landing in 5.6, but I don't see much benefit there > > since qdoc for 5.6 is already released and Qt Creator will need to deal > > with 5.6.0 as-is and previous versions anyway. > > What minimum version of Qt will Qt Creator released in 2 year from now > require? (to develop with) > Will it be Qt 5.6.0 or Qt 5.6.1? Or maybe 5.6.7? > I don't think it will be 5.6.0. What minimum version of Qt will Qt Creator be able to edit files from? Probably Qt 4.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ekke at ekkes-corner.org Wed Mar 30 22:24:30 2016 From: ekke at ekkes-corner.org (ekke) Date: Wed, 30 Mar 2016 22:24:30 +0200 Subject: [Development] [Announce] Qt 5.7 Alpha released In-Reply-To: References: Message-ID: <56FC35FE.7090208@ekkes-corner.org> hi, are there any news on Qt 5.7 Beta ? is 2016-03-31 still valid ? thx ekke Am 11.03.16 um 09:18 schrieb List for announcements regarding Qt releases and development: > > Hi all! > > > > Qt 5.7 Alpha release is out, see > http://blog.qt.io/blog/2016/03/11/qt-5-7-alpha-released/ > > > > > As earlier, Alpha is source code delivery only. The plan forward is > now to create a beta (including binary packages) during the next few > weeks. > > > > Big thanks for everyone who were involved to make this happen! > > > > Br, > > Akseli > > > > > > _______________________________________________ > Announce mailing list > Announce at qt-project.org > http://lists.qt-project.org/mailman/listinfo/announce > > > _______________________________________________ > 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 Wed Mar 30 22:44:20 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 30 Mar 2016 13:44:20 -0700 Subject: [Development] [Announce] Qt 5.7 Alpha released In-Reply-To: <56FC35FE.7090208@ekkes-corner.org> References: <56FC35FE.7090208@ekkes-corner.org> Message-ID: <132684338.9CuIjaOG0f@tjmaciei-mobl4> On quarta-feira, 30 de março de 2016 22:24:30 PDT ekke wrote: > hi, > > are there any news on Qt 5.7 Beta ? Yes, see the minutes from yesterday's release meeting. It was posted to the releasing mailing list. > is 2016-03-31 still valid ? No. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From massimocallegari at yahoo.it Wed Mar 30 23:05:48 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Wed, 30 Mar 2016 21:05:48 +0000 (UTC) Subject: [Development] Qt git 5.7 + MSYS2 + lrelease References: <1831317652.4578040.1459371948951.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1831317652.4578040.1459371948951.JavaMail.yahoo@mail.yahoo.com> Hi all, I have finally been able to produce the first qt5-git (5.7 branch) package with MSYS2, including libraries, executables, examples, tools and docs. For all the submodules except for qtscxml. I believe it is a very nice one-command automation for who doesn't want to bother with long and complicated setups. However, when processing qttranslations, I realized the lrelease.exe executable is not right. It fails on the first .ts file with this error: /D/MINGW-packages/mingw-w64-qt5-git/src/qt5/qttranslations/translations/lrelease_wrapper.sh assistant_cs.ts -qm assistant_cs.qm This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information. terminate called after throwing an instance of 'std::ios_base::failure' what(): basic_ios::clear I am wondering if anyone has seen this before and can help. I am not able to tell (yet) if this depends on GCC 5.3.0 or the Qt c++11 ongoing porting. Any advise appreciated. Thanks and regards, Massimo From ekke at ekkes-corner.org Wed Mar 30 23:10:05 2016 From: ekke at ekkes-corner.org (ekke) Date: Wed, 30 Mar 2016 23:10:05 +0200 Subject: [Development] [Announce] Qt 5.7 Alpha released In-Reply-To: <132684338.9CuIjaOG0f@tjmaciei-mobl4> References: <56FC35FE.7090208@ekkes-corner.org> <132684338.9CuIjaOG0f@tjmaciei-mobl4> Message-ID: <56FC40AD.6030603@ekkes-corner.org> Am 30.03.16 um 22:44 schrieb Thiago Macieira: > On quarta-feira, 30 de março de 2016 22:24:30 PDT ekke wrote: >> hi, >> >> are there any news on Qt 5.7 Beta ? > Yes, see the minutes from yesterday's release meeting. It was posted to the > releasing mailing list. thx. wasn't aware of this only looked at https://wiki.qt.io/Qt-5.7-release >> is 2016-03-31 still valid ? > No. > From olivier at woboq.com Thu Mar 31 00:10:48 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 31 Mar 2016 00:10:48 +0200 Subject: [Development] Changing definition of Qt meta macro to allow tools integration In-Reply-To: <2169915.xr42Tts652@tjmaciei-mobl4> References: <2846913.44WYRE1kvo@finn> <1553050.fTJH5BaTsB@finn> <2169915.xr42Tts652@tjmaciei-mobl4> Message-ID: <3452244.9ZzMBG3as6@finn> Am Mittwoch, 30. März 2016, 12:39:58 CEST schrieb Thiago Macieira: > On quarta-feira, 30 de março de 2016 21:35:55 PDT Olivier Goffart wrote: > > > > I am also wondering in which branch to push this. Should it go in Qt > > > > 5.6 > > > > LTS so newer Qt creator can benefit of it starting from Qt 5.6.1? > > > > > > You've proposed it for dev, but I think it deserves at least 5.7. I > > > don't > > > have a problem in it landing in 5.6, but I don't see much benefit there > > > since qdoc for 5.6 is already released and Qt Creator will need to deal > > > with 5.6.0 as-is and previous versions anyway. > > > > What minimum version of Qt will Qt Creator released in 2 year from now > > require? (to develop with) > > Will it be Qt 5.6.0 or Qt 5.6.1? Or maybe 5.6.7? > > I don't think it will be 5.6.0. > > What minimum version of Qt will Qt Creator be able to edit files from? > Probably Qt 4.0. Yes, maybe even Qt 1.44 :-) The question is rather, the Qt creator that will be release in 2 years will maybe want to use these macros to auto complete signals/slots and properties. I would assume some people would still have a LTS version of Qt which would then be, say Qt 5.6.4. So then it would be valable to habe this patch in the LTS branch. Same goes for KDevelop, or other (possibly future) tools or analyzers that could support the LTS version if this patch goes in the 5.6 branch. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From robert.griebl at pelagicore.com Thu Mar 31 00:39:06 2016 From: robert.griebl at pelagicore.com (Robert Griebl) Date: Thu, 31 Mar 2016 00:39:06 +0200 Subject: [Development] Nominating Volker Krause for Approver status In-Reply-To: <2387C660-589D-4C10-BE6F-11734B6F11E2@theqtcompany.com> References: <1837438.BeO96xjKmG@titan> <2387C660-589D-4C10-BE6F-11734B6F11E2@theqtcompany.com> Message-ID: <56FC558A.3000104@pelagicore.com> +1 On 30.03.2016 11:18, Knoll Lars wrote: > He isn’t yet? In that case, a big +1 from me :) > > Cheers, > Lars > > From: Development > > > on behalf of Richard Moore > > Date: Wednesday 30 March 2016 at 11:17 > To: Qt development mailing list > > Subject: Re: [Development] Nominating Volker Krause for Approver status > > +1 > > On 30 March 2016 at 09:34, Sean Harmer > wrote: > > Hi All, > > I'd like to nominate Volker Krause for approver status. Volker is > one of the > main authors of GammaRay, is very active in the Qt Automotive sphere > where he > leads up KDAB's contributions, and has touched many parts all over Qt > (including Qt 3D). > > His dashboard is at: > > https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z > > and reviews at: > > https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z > > Can I get a +1 please? > > Cheers, > > Sean > > Disclaimer: I work at KDAB with Volker. > -- > Dr Sean Harmer | sean.harmer at kdab.com > | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. UK +44 (0)1625 809908 , > Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Robert Griebl Senior Software Engineer Pelagicore AG Balanstr. 55, 81541 Munich, Germany robert.griebl at pelagicore.com www.pelagicore.com From chris.adams at qinetic.com.au Thu Mar 31 05:33:04 2016 From: chris.adams at qinetic.com.au (Chris Adams) Date: Thu, 31 Mar 2016 13:33:04 +1000 Subject: [Development] QtQuick Call for Maintainer In-Reply-To: <56E141B5.6060201@theqtcompany.com> References: <7811068.TYrtjBnhy4@frederik-thinkcentre-m93p> <56E141B5.6060201@theqtcompany.com> Message-ID: +1 from me too. www.qinetic.com.au - Qt And QML User Experience Specialists On Thu, Mar 10, 2016 at 7:43 PM, Eskil Abrahamsen Blomfeldt < eskil.abrahamsen-blomfeldt at theqtcompany.com> wrote: > > > Den 09.03.2016 10:56, skrev Frederik Gladhorn: > >> We are in the luxury position of having two great candidates. >> I briefly talked to both Robin and Shawn yesterday and one option would >> be to >> have a shared maintainership. This seems to have worked nicely for Qt >> Networking and dividing the responsibilty will lessen the burden. >> > > +1 for shared maintainership. > > -- Eskil > > > _______________________________________________ > 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 Thu Mar 31 06:04:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 30 Mar 2016 21:04:50 -0700 Subject: [Development] Changing definition of Qt meta macro to allow tools integration In-Reply-To: <3452244.9ZzMBG3as6@finn> References: <2846913.44WYRE1kvo@finn> <2169915.xr42Tts652@tjmaciei-mobl4> <3452244.9ZzMBG3as6@finn> Message-ID: <9552821.MVqncs4VOC@tjmaciei-mobl4> On quinta-feira, 31 de março de 2016 00:10:48 PDT Olivier Goffart wrote: > The question is rather, the Qt creator that will be release in 2 years will > maybe want to use these macros to auto complete signals/slots and > properties. I would assume some people would still have a LTS version of Qt > which would then be, say Qt 5.6.4. So then it would be valable to habe > this patch in the LTS branch. I don't think it's valuable because those tools will need to deal with Qt 5.6.0 and older. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Thu Mar 31 07:54:03 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 31 Mar 2016 07:54:03 +0200 Subject: [Development] Changing definition of Qt meta macro to allow tools integration In-Reply-To: <9552821.MVqncs4VOC@tjmaciei-mobl4> References: <2846913.44WYRE1kvo@finn> <2169915.xr42Tts652@tjmaciei-mobl4> <3452244.9ZzMBG3as6@finn> <9552821.MVqncs4VOC@tjmaciei-mobl4> Message-ID: <56FCBB7B.9040800@familiesomers.nl> Op 31/03/2016 om 06:04 schreef Thiago Macieira: > On quinta-feira, 31 de março de 2016 00:10:48 PDT Olivier Goffart wrote: >> The question is rather, the Qt creator that will be release in 2 years will >> maybe want to use these macros to auto complete signals/slots and >> properties. I would assume some people would still have a LTS version of Qt >> which would then be, say Qt 5.6.4. So then it would be valable to habe >> this patch in the LTS branch. > I don't think it's valuable because those tools will need to deal with Qt > 5.6.0 and older. > "Deal with" can be done on many levels. I'd say it would be acceptable if some more advanced features are not available for older Qt versions. Sure you can edit projects based on old Qt versions, but do you really think that it has to offer the same level of tooling that is made possible with newer versions? So for what its worth, I think I'm with Olivier here: it makes sense to put it in an LTS that is expected to see use for a long time yet. André From scott at towel42.com Thu Mar 31 08:29:57 2016 From: scott at towel42.com (Scott Aron Bloom) Date: Thu, 31 Mar 2016 06:29:57 +0000 Subject: [Development] Help with QChart 2.0 Message-ID: I had previously posted some issues I found with the new QChart system. I haven't heard back from anyone.. Is there a better place to post usage issues? Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Thu Mar 31 08:38:26 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 31 Mar 2016 08:38:26 +0200 Subject: [Development] Changing definition of Qt meta macro to allow tools integration In-Reply-To: <9552821.MVqncs4VOC@tjmaciei-mobl4> References: <2846913.44WYRE1kvo@finn> <3452244.9ZzMBG3as6@finn> <9552821.MVqncs4VOC@tjmaciei-mobl4> Message-ID: <1880440.IYmo2xS9RW@finn> Am Mittwoch, 30. März 2016, 21:04:50 CEST schrieb Thiago Macieira: > On quinta-feira, 31 de março de 2016 00:10:48 PDT Olivier Goffart wrote: > > The question is rather, the Qt creator that will be release in 2 years > > will > > maybe want to use these macros to auto complete signals/slots and > > properties. I would assume some people would still have a LTS version of > > Qt > > which would then be, say Qt 5.6.4. So then it would be valable to habe > > this patch in the LTS branch. > > I don't think it's valuable because those tools will need to deal with Qt > 5.6.0 and older. Why would they need to deal with 5.6.0 specifically? As you said in another mail, 5.6 is LTS, not 5.6.0 -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From nikolai.kosjar at theqtcompany.com Thu Mar 31 09:03:42 2016 From: nikolai.kosjar at theqtcompany.com (Nikolai Kosjar) Date: Thu, 31 Mar 2016 09:03:42 +0200 Subject: [Development] Changing definition of Qt meta macro to allow tools integration In-Reply-To: <3452244.9ZzMBG3as6@finn> References: <2846913.44WYRE1kvo@finn> <1553050.fTJH5BaTsB@finn> <2169915.xr42Tts652@tjmaciei-mobl4> <3452244.9ZzMBG3as6@finn> Message-ID: <56FCCBCE.9020000@theqtcompany.com> On 03/31/2016 12:10 AM, Olivier Goffart wrote: > The question is rather, the Qt creator that will be release in 2 years will > maybe want to use these macros to auto complete signals/slots and properties. > I would assume some people would still have a LTS version of Qt which would > then be, say Qt 5.6.4. So then it would be valable to habe this patch in the > LTS branch. +1. Plus, the change is not risky at all? So we can only win :) Nikolai From edward.welbourne at theqtcompany.com Thu Mar 31 09:49:17 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 31 Mar 2016 07:49:17 +0000 Subject: [Development] QThreadStorage and C++11 In-Reply-To: <2466995.AY7YjMsaIa@tjmaciei-mobl4> References: <301561459365815@web13o.yandex.ru>, <2466995.AY7YjMsaIa@tjmaciei-mobl4> Message-ID: On quarta-feira, 30 de março de 2016 22:23:35 PDT Konstantin Tokarev wrote: >> Hello, >> >> Are there any plans to reimplement QThreadStorage via thread_local for >> compilers which support it? Thiago Macieira replied: > I haven't investigated whether it's possible. Probably not. Konstantin: try searching Jira for a ticket suggesting it. If you can't find one, open one. Either way, feel free to set me as a watcher. It can't hurt to at least look into whether it's possible, if only so as to document a negative result, Eddy. From Lars.Knoll at theqtcompany.com Thu Mar 31 10:01:54 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 31 Mar 2016 08:01:54 +0000 Subject: [Development] Changing definition of Qt meta macro to allow tools integration In-Reply-To: <1880440.IYmo2xS9RW@finn> References: <2846913.44WYRE1kvo@finn> <3452244.9ZzMBG3as6@finn> <9552821.MVqncs4VOC@tjmaciei-mobl4> <1880440.IYmo2xS9RW@finn> Message-ID: On 31/03/16 08:38, "Development on behalf of Olivier Goffart" wrote: >Am Mittwoch, 30. März 2016, 21:04:50 CEST schrieb Thiago Macieira: >> On quinta-feira, 31 de março de 2016 00:10:48 PDT Olivier Goffart wrote: >> > The question is rather, the Qt creator that will be release in 2 years >> > will >> > maybe want to use these macros to auto complete signals/slots and >> > properties. I would assume some people would still have a LTS version of >> > Qt >> > which would then be, say Qt 5.6.4. So then it would be valable to habe >> > this patch in the LTS branch. >> >> I don't think it's valuable because those tools will need to deal with Qt >> 5.6.0 and older. > >Why would they need to deal with 5.6.0 specifically? >As you said in another mail, 5.6 is LTS, not 5.6.0 I’m with Olivier here. We will not support 5.6.0 in three years anymore. What we will support is 5.6.x (x being the latest available patch level release). So it does make sense to put the patch into 5.6, if the creator team is interested in using it. Cheers, Lars From olivier at woboq.com Thu Mar 31 10:39:20 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 31 Mar 2016 10:39:20 +0200 Subject: [Development] QThreadStorage and C++11 In-Reply-To: <301561459365815@web13o.yandex.ru> References: <301561459365815@web13o.yandex.ru> Message-ID: <21153104.g3LZymybDT@finn> Am Mittwoch, 30. März 2016, 22:23:35 CEST schrieb Konstantin Tokarev: > Hello, > > Are there any plans to reimplement QThreadStorage via thread_local for > compilers which support it? QThreadStorage is already implemented with __thread which is a bit like thread_local before it existed. https://code.woboq.org/qt5/qtbase/src/corelib/thread/qthread_unix.cpp.html#_ZL17currentThreadData But it's not possible to make each instance of QThreadStorage a thread_local, because QThreadStorage is creating an instance and you can't have thread_local per instance of QThreadStorage. The best we could do is a macro: something like this // if the compiler don't have thread_local #define Q_THREAD_LOCAL(TYPE, XX) QThreadStorage XX // else #define Q_THREAD_LOCAL(TYPE, XX) thread_local QFakeThreadStorage XX (where QFakeThreadStorage is just a class that contains an instance with the same API as QThreadStorage) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From dominik.holland at pelagicore.com Thu Mar 31 11:12:18 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Thu, 31 Mar 2016 11:12:18 +0200 Subject: [Development] Nominating Volker Krause for Approver status In-Reply-To: <56FC558A.3000104@pelagicore.com> References: <1837438.BeO96xjKmG@titan> <2387C660-589D-4C10-BE6F-11734B6F11E2@theqtcompany.com> <56FC558A.3000104@pelagicore.com> Message-ID: <56FCE9F2.2070603@pelagicore.com> +1 Am 03/31/2016 um 12:39 AM schrieb Robert Griebl: > +1 > > > On 30.03.2016 11:18, Knoll Lars wrote: >> He isn’t yet? In that case, a big +1 from me :) >> >> Cheers, >> Lars >> >> From: Development >> > > >> on behalf of Richard Moore > >> Date: Wednesday 30 March 2016 at 11:17 >> To: Qt development mailing list > > >> Subject: Re: [Development] Nominating Volker Krause for Approver status >> >> +1 >> >> On 30 March 2016 at 09:34, Sean Harmer > > wrote: >> >> Hi All, >> >> I'd like to nominate Volker Krause for approver status. Volker is >> one of the >> main authors of GammaRay, is very active in the Qt Automotive sphere >> where he >> leads up KDAB's contributions, and has touched many parts all over Qt >> (including Qt 3D). >> >> His dashboard is at: >> >> https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z >> >> and reviews at: >> >> >> https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z >> >> Can I get a +1 please? >> >> Cheers, >> >> Sean >> >> Disclaimer: I work at KDAB with Volker. >> -- >> Dr Sean Harmer | sean.harmer at kdab.com >> | Managing Director UK >> Klarälvdalens Datakonsult AB, a KDAB Group company >> Tel. UK +44 (0)1625 809908 , >> Sweden (HQ) +46-563-540090 >> KDAB - Qt Experts - Platform-independent software solutions >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > -- Dominik Holland SENIOR SOFTWARE ENGINEER Pelagicore AG Balanstr. 55, 81541 Munich, Germany +49 (0)171 760 25 96 dominik.holland at pelagicore.com www.pelagicore.com From sergio.martins at kdab.com Thu Mar 31 10:21:08 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 31 Mar 2016 10:21:08 +0200 Subject: [Development] Nominating Volker Krause for Approver status In-Reply-To: <1837438.BeO96xjKmG@titan> References: <1837438.BeO96xjKmG@titan> Message-ID: <2913403.PCcjDfMA1C@laptop-8abmhjpb> On Wednesday, March 30, 2016 09:34:40 AM Sean Harmer wrote: > Hi All, > > I'd like to nominate Volker Krause for approver status. Volker is one of the > main authors of GammaRay, is very active in the Qt Automotive sphere where > he leads up KDAB's contributions, and has touched many parts all over Qt > (including Qt 3D). > > His dashboard is at: > > https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z > > and reviews at: > > https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z > > Can I get a +1 please? > > Cheers, > > Sean > > Disclaimer: I work at KDAB with Volker. +1 Regards, -- Sérgio Martins | sergio.martins 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 Experts From milian.wolff at kdab.com Thu Mar 31 11:52:14 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 31 Mar 2016 11:52:14 +0200 Subject: [Development] QThreadStorage and C++11 In-Reply-To: <301561459365815@web13o.yandex.ru> References: <301561459365815@web13o.yandex.ru> Message-ID: <2352734.LzmAV2EPD2@milian-kdab2> On Wednesday, March 30, 2016 10:23:35 PM CEST Konstantin Tokarev wrote: > Hello, > > Are there any plans to reimplement QThreadStorage via thread_local for > compilers which support it? Why not use thread_local _instead of_ QThreadStorage in user code, where applicable? -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From samuel.gaist at edeltech.ch Thu Mar 31 13:02:31 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Thu, 31 Mar 2016 13:02:31 +0200 Subject: [Development] Nominating Volker Krause for Approver status In-Reply-To: <1837438.BeO96xjKmG@titan> References: <1837438.BeO96xjKmG@titan> Message-ID: +1 On 30 mars 2016, at 10:34, Sean Harmer wrote: > Hi All, > > I'd like to nominate Volker Krause for approver status. Volker is one of the > main authors of GammaRay, is very active in the Qt Automotive sphere where he > leads up KDAB's contributions, and has touched many parts all over Qt > (including Qt 3D). > > His dashboard is at: > > https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z > > and reviews at: > > https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z > > Can I get a +1 please? > > Cheers, > > Sean > > Disclaimer: I work at KDAB with Volker. > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From frederik.gladhorn at theqtcompany.com Thu Mar 31 13:08:07 2016 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Thu, 31 Mar 2016 13:08:07 +0200 Subject: [Development] Nominating Volker Krause for Approver status In-Reply-To: <1837438.BeO96xjKmG@titan> References: <1837438.BeO96xjKmG@titan> Message-ID: <2490211.ScAIPsqEX2@frederik-thinkcentre-m93p> On Wednesday, March 30, 2016 09:34:40 AM Sean Harmer wrote: > Hi All, > > I'd like to nominate Volker Krause for approver status. Volker is one of the > main authors of GammaRay, is very active in the Qt Automotive sphere where > he leads up KDAB's contributions, and has touched many parts all over Qt > (including Qt 3D). > > His dashboard is at: > > https://codereview.qt-project.org/#/q/owner:%22Volker+Krause%22,n,z > > and reviews at: > > https://codereview.qt-project.org/#/q/reviewer:%22Volker+Krause%22,n,z > > Can I get a +1 please? +1 from me as well :) Greetings, Frederik > > Cheers, > > Sean > > Disclaimer: I work at KDAB with Volker. > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jkt at kde.org Thu Mar 31 17:38:59 2016 From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Thu, 31 Mar 2016 17:38:59 +0200 Subject: [Development] =?iso-8859-1?q?gerrit_=3A_using_branches_=28was=3A_?= =?iso-8859-1?q?pointers_to_use_it_cleverly/efficiently=3F=29?= In-Reply-To: <156851459354478@web19g.yandex.ru> References: <1635019.vHF9KLjsb5@portia.local> <1885186.XDnYivrAq4@patux> <1852255.FUzVmog2yV@tjmaciei-mobl4> <156851459354478@web19g.yandex.ru> Message-ID: On Wednesday, 30 March 2016 18:14:38 CEST, Konstantin Tokarev wrote: > New UI is not required to use these features Inline editting is only available in 2.11, and the old change screen is gone in 2.11, too. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From partha1b at gmail.com Thu Mar 31 20:25:08 2016 From: partha1b at gmail.com (Partha Bagchi) Date: Thu, 31 Mar 2016 14:25:08 -0400 Subject: [Development] qtwebkit fails to build Message-ID: I seem to have hit another snag. Hoping someone can point to a solution. In my build process, I am getting the following error: mingw32-make[2]: Entering directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore' ( test -e Makefile.WebCore.DerivedSources || Z:/src/kde/qt5/qtbase/bin/qmake.exe Z:/src/kde/qt5/qtwebkit/Source/WebCore/DerivedSources.pri -o Makefile.WebCore.DerivedSources ) && mingw32-make -f Makefile.WebCore.DerivedSources WARNING: Failure to find: generated/InternalSettingsGenerated.idl mingw32-make[3]: Entering directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore' perl -IZ:/src/kde/qt5/qtwebkit/Source/WebCore/bindings/scripts Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl --tags Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathtags.in --attrs Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/mathattrs.in --extraDefines "UNICODE ENABLE_3D_RENDERING=1 ENABLE_ACCELERATED_2D_CANVAS=1 ENABLE_BLOB=1 ENABLE_CANVAS_PATH=1 ENABLE_CHANNEL_MESSAGING=1 ENABLE_CSS_BOX_DECORATION_BREAK=1 ENABLE_CSS_COMPOSITING=1 ENABLE_CSS_EXCLUSIONS=1 ENABLE_CSS_FILTERS=1 ENABLE_CSS_IMAGE_SET=1 ENABLE_CSS_REGIONS=1 ENABLE_CSS_SHAPES=1 ENABLE_CSS_STICKY_POSITION=1 ENABLE_CSS_TRANSFORMS_ANIMATIONS_UNPREFIXED=1 ENABLE_DATALIST_ELEMENT=1 ENABLE_DETAILS_ELEMENT=1 ENABLE_DEVICE_ORIENTATION=1 ENABLE_DOWNLOAD_ATTRIBUTE=1 ENABLE_FAST_MOBILE_SCROLLING=1 ENABLE_FILTERS=1 ENABLE_FTPDIR=1 ENABLE_FULLSCREEN_API=1 ENABLE_GEOLOCATION=1 ENABLE_GESTURE_EVENTS=1 ENABLE_ICONDATABASE=1 ENABLE_IFRAME_SEAMLESS=1 ENABLE_INDEXED_DATABASE=1 ENABLE_INPUT_TYPE_COLOR=1 ENABLE_INSPECTOR=1 ENABLE_INSPECTOR_SERVER=1 ENABLE_JAVASCRIPT_DEBUGGER=1 ENABLE_LEGACY_NOTIFICATIONS=1 ENABLE_LEGACY_VIEWPORT_ADAPTION=1 ENABLE_LEGACY_VENDOR_PREFIXES=1 ENABLE_LEGACY_WEB_AUDIO=1 ENABLE_LINK_PREFETCH=1 ENABLE_METER_ELEMENT=1 ENABLE_MHTML=1 ENABLE_NOTIFICATIONS=1 ENABLE_ORIENTATION_EVENTS=1 ENABLE_PAGE_VISIBILITY_API=1 ENABLE_PROGRESS_ELEMENT=1 ENABLE_RESOLUTION_MEDIA_QUERY=1 ENABLE_REQUEST_ANIMATION_FRAME=1 ENABLE_SHARED_WORKERS=1 ENABLE_SMOOTH_SCROLLING=1 ENABLE_SQL_DATABASE=1 ENABLE_SUBPIXEL_LAYOUT=1 ENABLE_SVG=1 ENABLE_SVG_FONTS=1 ENABLE_TOUCH_ADJUSTMENT=1 ENABLE_TOUCH_EVENTS=1 ENABLE_VIDEO_TRACK=1 ENABLE_VIEW_MODE_CSS_MEDIA=1 ENABLE_WEB_SOCKETS=1 ENABLE_WEB_TIMING=1 ENABLE_WORKERS=1 ENABLE_XHR_TIMEOUT=1 WTF_USE_TILED_BACKING_STORE=1 WTF_USE_CROSS_PLATFORM_CONTEXT_MENUS=1 HAVE_QTQUICK=1 HAVE_QTPRINTSUPPORT=1 HAVE_QSTYLE=1 HAVE_QTTESTLIB=1 HAVE_QTPOSITIONING=1 HAVE_QTSENSORS=1 WTF_USE_LIBXML2=1 ENABLE_XSLT=1 WTF_USE_ZLIB=1 WTF_USE_WEBP=1 WTF_USE_LIBJPEG=1 WTF_USE_LIBPNG=1 ENABLE_NETSCAPE_PLUGIN_API=1 PLUGIN_ARCHITECTURE_UNSUPPORTED=1 WTF_USE_3D_GRAPHICS=1 ENABLE_WEBGL=1 ENABLE_VIDEO=1 WTF_USE_QT_MULTIMEDIA=1 HAVE_SQLITE3=1 ENABLE_TOUCH_SLIDER=1 WTF_USE_LEVELDB=1 ENABLE_BATTERY_STATUS=0 ENABLE_CANVAS_PROXY=0 ENABLE_CSP_NEXT=0 ENABLE_CSS_GRID_LAYOUT=0 ENABLE_CSS_HIERARCHIES=0 ENABLE_CSS_IMAGE_ORIENTATION=0 ENABLE_CSS_IMAGE_RESOLUTION=0 ENABLE_CSS_SHADERS=0 ENABLE_CSS_VARIABLES=0 ENABLE_CSS3_CONDITIONAL_RULES=0 ENABLE_CSS3_TEXT=0 ENABLE_CSS3_TEXT_LINE_BREAK=0 ENABLE_DASHBOARD_SUPPORT=0 ENABLE_DATAGRID=0 ENABLE_DATA_TRANSFER_ITEMS=0 ENABLE_DIRECTORY_UPLOAD=0 ENABLE_FILE_SYSTEM=0 ENABLE_FONT_LOAD_EVENTS=0 ENABLE_GAMEPAD=0 ENABLE_HIGH_DPI_CANVAS=0 ENABLE_INPUT_SPEECH=0 ENABLE_INPUT_TYPE_DATE=0 ENABLE_INPUT_TYPE_DATETIME_INCOMPLETE=0 ENABLE_INPUT_TYPE_DATETIMELOCAL=0 ENABLE_INPUT_TYPE_MONTH=0 ENABLE_INPUT_TYPE_TIME=0 ENABLE_INPUT_TYPE_WEEK=0 ENABLE_LEGACY_CSS_VENDOR_PREFIXES=0 ENABLE_MATHML=0 ENABLE_MEDIA_SOURCE=0 ENABLE_MEDIA_STATISTICS=0 ENABLE_MEDIA_STREAM=0 ENABLE_MICRODATA=0 ENABLE_MOUSE_CURSOR_SCALE=0 ENABLE_NAVIGATOR_CONTENT_UTILS=0 ENABLE_NETWORK_INFO=0 ENABLE_NOSNIFF=0 ENABLE_PROXIMITY_EVENTS=0 ENABLE_QUOTA=0 ENABLE_RESOURCE_TIMING=0 ENABLE_SCRIPTED_SPEECH=0 ENABLE_SECCOMP_FILTERS=0 ENABLE_SHADOW_DOM=0 ENABLE_STYLE_SCOPED=0 ENABLE_TEMPLATE_ELEMENT=0 ENABLE_TEXT_AUTOSIZING=0 ENABLE_THREADED_HTML_PARSER=0 ENABLE_TOUCH_ICON_LOADING=0 ENABLE_USER_TIMING=0 ENABLE_VIBRATION=0 ENABLE_WEB_AUDIO=0" --preprocessor "'Z:\src\kde\qt5\qtbase\bin\moc.exe' -E" --factory --wrapperFactory --outputDir generated Failed to open file: Z:/src/kde/qt5/qtwebkit/Source/WebCore/mathml/ mathtags.in at Z:/src/kde/qt5/qtwebkit/Source/WebCore/dom/make_names.pl line 306. Makefile.WebCore.DerivedSources:786: recipe for target 'generated/MathMLNames.cpp' failed mingw32-make[3]: *** [generated/MathMLNames.cpp] Error 9 mingw32-make[3]: Leaving directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore' Makefile.WebCore:36: recipe for target 'sub-DerivedSources-pri-make_first-ordered' failed mingw32-make[2]: *** [sub-DerivedSources-pri-make_first-ordered] Error 2 mingw32-make[2]: Leaving directory 'Z:/src/kde/qt5/qtwebkit/Source/WebCore' Makefile:218: recipe for target 'sub-Source-WebCore-WebCore-pro-make_first-ordered' failed mingw32-make[1]: *** [sub-Source-WebCore-WebCore-pro-make_first-ordered] Error 2 mingw32-make[1]: Leaving directory 'Z:/src/kde/qt5/qtwebkit' Makefile:1074: recipe for target 'module-qtwebkit-make_first' failed mingw32-make: *** [module-qtwebkit-make_first] Error 2 mathtags.in exists at the location specified, just not being opened. Grateful for any pointers! Thanks in advance, Partha -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Mar 31 20:33:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 31 Mar 2016 11:33:08 -0700 Subject: [Development] Changing definition of Qt meta macro to allow tools integration In-Reply-To: References: <2846913.44WYRE1kvo@finn> <1880440.IYmo2xS9RW@finn> Message-ID: <31066388.SzHpg1OhqY@tjmaciei-mobl4> On quinta-feira, 31 de março de 2016 08:01:54 PDT Knoll Lars wrote: > >Why would they need to deal with 5.6.0 specifically? > >As you said in another mail, 5.6 is LTS, not 5.6.0 > > I’m with Olivier here. We will not support 5.6.0 in three years anymore. > What we will support is 5.6.x (x being the latest available patch level > release). This is a totally different definition of "support". Are you saying Qt Creator will not be able to open projects linking to Qt 5.6.0 or older? > So it does make sense to put the patch into 5.6, if the creator team is > interested in using it. Sure, what is the team's opinion? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Thu Mar 31 22:25:06 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 31 Mar 2016 22:25:06 +0200 Subject: [Development] gerrit : using branches (was: pointers to use it cleverly/efficiently?) References: <1635019.vHF9KLjsb5@portia.local> <1885186.XDnYivrAq4@patux> <1852255.FUzVmog2yV@tjmaciei-mobl4> Message-ID: <2763793.OfNggsPmAf@portia.local> Thiago Macieira wrote: > git diff misses the parent commit ID and the commit message. The output from > git format-patch has the commit message, but still misses the parent commit > ID. So? A system that accepts patches rather than commits will evidently need and provide a mechanism to enter at least a title and description for the patch. R.