From Julius.Bullinger at asctec.de Wed Jun 1 08:01:05 2016 From: Julius.Bullinger at asctec.de (Julius Bullinger) Date: Wed, 1 Jun 2016 06:01:05 +0000 Subject: [Development] Qt 5.6 StyleSheet In-Reply-To: References: Message-ID: <7a951bcac0e4479c86f8614f5acc515b@SRV1.asctec.local> Von: Development [mailto:development-bounces+julius.bullinger=asctec.de at qt-project.org] Im Auftrag von Berkay Elbir Gesendet: Dienstag, 31. Mai 2016 12:23 Uhr An: development at qt-project.org Betreff: [Development] Qt 5.6 StyleSheet > It affects whole project. I mean that affecting other widgets. All the expand symbols change to plus sign. This QLabel is unrelated to this widget(below). > Did anyone face with this problem? I faced the same problem, reported it as QTBUG-51799, and it is fixed in 5.6.1 (to be released in a few days). Best regards, Julius -------------- next part -------------- An HTML attachment was scrubbed... URL: From berkayelbir at gmail.com Wed Jun 1 08:57:38 2016 From: berkayelbir at gmail.com (Berkay Elbir) Date: Wed, 1 Jun 2016 09:57:38 +0300 Subject: [Development] [Interest] About Qt StyleSheet In-Reply-To: <41c7603478de4c2e9193838d5aae7a02@SRV1.asctec.local> References: <1b5e0183-2337-3085-43d6-811de314a838@familiesomers.nl> <41c7603478de4c2e9193838d5aae7a02@SRV1.asctec.local> Message-ID: Oh, I see Thank you for response. Regards, Berkay On Wed, Jun 1, 2016 at 9:07 AM, Julius Bullinger wrote: > As said in the [development] thread, this is most probably > https://bugreports.qt.io/browse/QTBUG-52230, which is fixed in Qt 5.6.1 > (to be released in a few days). > > > > Best regards, > > Julius > > > > _______________________________________________ > Interest mailing list > Interest at qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Wed Jun 1 09:29:53 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Wed, 1 Jun 2016 07:29:53 +0000 Subject: [Development] Nominating Alexandru Croitor for Approver status In-Reply-To: <57331401.6020201@qt.io> References: <57331401.6020201@qt.io> Message-ID: Congratulations to Alexandru. Approver rights have been granted. -- Alex ________________________________________ From: Development on behalf of Michael Brüning Sent: Wednesday, 11 May 2016 1:14:09 PM To: development at qt-project.org Subject: [Development] Nominating Alexandru Croitor for Approver status Hi all, I would like to nominate Alexandru Croitor for Approver status. Alexandru joined The Qt Company about 6 months ago and has been working full time on Qt since then and especially on the Qt WebEngine module. Here is his Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:"Alexandru Croitor "status:merged,n,z And a list of his reviews: https://codereview.qt-project.org/#/q/reviewer:"Alexandru Croitor ",n,z Cheers, Michael _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Wed Jun 1 12:02:30 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 1 Jun 2016 10:02:30 +0000 Subject: [Development] Qt 5.7.0 rc packages for testing Message-ID: Hi all, We have finally Qt 5.7.0 rc packages for testing: Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/482/ Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/442/ Mac: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/376/ src: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/latest_src/ Packages are RTA tested & seems to be pretty much Ok. Known issues in the packages here: https://bugreports.qt.io/issues/?filter=17719 We will release these packages as Qt 5.7.0 rc this Friday if nothing really serious found during testing. So please inform me immediately if there is something badly broken. And at this time we are really minimizing changes between rc & final and so on we are taking in only fixes for real release blockers. All others should be just listed in known issues page (https://wiki.qt.io/Qt_5.7.0_Known_Issues) & fixed in '5.7' branch instead. Documentation changes and missing change files are exception: We will take those in still during this week so please finalize those as well really soon, latest this Sunday. We will start creating final packages Monday 6th June morning. br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Jun 1 14:41:30 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 1 Jun 2016 14:41:30 +0200 Subject: [Development] commas in ctor-init-lists Message-ID: <201606011441.31348.marc.mutz@kdab.com> Hi, There seems to have been a silent underground move to uglify the Qt sources , by using commas to introduce lines . I have no idea where this came from , but it looks butt -ugly and it is in violation of http ://wiki .qt .io /Qt_Coding_Style QFoo::QFoo() : QBase(), m_f1(), m_f2() { } -not- QFoo::QFoo() : QBase() , m_f1() , m_f2() { } (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the _end_ of wrapped lines") Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From Simon.Hausmann at qt.io Wed Jun 1 14:56:12 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 1 Jun 2016 12:56:12 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606011441.31348.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> Message-ID: <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> Hi, I'm in favorof changing our coding style to adopt the model you call "butt ugly" because I find it more appealing and I find that it makes diffs easier to read. Simon ________________________________ From: Marc Mutz Sent: Jun 1, 2016 14:41 To: development at qt-project.org Subject: [Development] commas in ctor-init-lists Hi, There seems to have been a silent underground move to uglify the Qt sources , by using commas to introduce lines . I have no idea where this came from , but it looks butt -ugly and it is in violation of http ://wiki .qt .io /Qt_Coding_Style QFoo::QFoo() : QBase(), m_f1(), m_f2() { } -not- QFoo::QFoo() : QBase() , m_f1() , m_f2() { } (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the _end_ of wrapped lines") Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts _______________________________________________ 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 dominik.holland at pelagicore.com Wed Jun 1 14:57:27 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Wed, 1 Jun 2016 14:57:27 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> Message-ID: +1 for changing they coding style Am 06/01/2016 um 02:56 PM schrieb Simon Hausmann: > Hi, > > I'm in favorof changing our coding style to adopt the model you call > "butt ugly" because I find it more appealing and I find that it makes > diffs easier to read. > > Simon > > > ------------------------------------------------------------------------ > *From:* Marc Mutz > *Sent:* Jun 1, 2016 14:41 > *To:* development at qt-project.org > *Subject:* [Development] commas in ctor-init-lists > > Hi, > > There seems to have been a silent underground move to uglify the Qt sources > , by using commas to introduce lines > . I have no idea where this came from > , but it looks butt > -ugly and it is in violation of http > ://wiki > .qt > .io > /Qt_Coding_Style > > QFoo::QFoo() > : QBase(), > m_f1(), > m_f2() > { > > } > > -not- > > QFoo::QFoo() > : QBase() > , m_f1() > , m_f2() > { > > } > > (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the > _end_ of wrapped lines") > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > 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 markg85 at gmail.com Wed Jun 1 15:06:16 2016 From: markg85 at gmail.com (Mark Gaiser) Date: Wed, 1 Jun 2016 15:06:16 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606011441.31348.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> Message-ID: On Wed, Jun 1, 2016 at 2:41 PM, Marc Mutz wrote: > Hi, > > There seems to have been a silent underground move to uglify the Qt sources > , by using commas to introduce lines > . I have no idea where this came from > , but it looks butt > -ugly and it is in violation of http > ://wiki > .qt > .io > /Qt_Coding_Style > > QFoo::QFoo() > : QBase(), > m_f1(), > m_f2() > { > > } > > -not- > > QFoo::QFoo() > : QBase() > , m_f1() > , m_f2() > { > > } > > (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the > _end_ of wrapped lines") > > Thanks, > Marc > > The "butt-ugly" style looks more readable to me. And imho it reduces the possibility of forgetting a forgetting a comma in the begin since then your arguments will look out of alignment. Funny in the coding style you mention. For operators: "An operator at the end of the line is easy to miss if the editor is too narrow." The exact same could be said for commas at the end of the line. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.martins at kdab.com Wed Jun 1 15:15:17 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Wed, 01 Jun 2016 14:15:17 +0100 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606011441.31348.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> Message-ID: <1595975.TPAtiFIfjf@serj-laptop> On Wednesday, 1 June 2016 14:41:30 WEST Marc Mutz wrote: > Hi, > > There seems to have been a silent underground move to uglify the Qt sources > , by using commas to introduce lines > . I have no idea where this came from > , but it looks butt > -ugly and it is in violation of http > (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the > _end_ of wrapped lines") I think that refers to function calls and wasn't written with ctor init-lists in mind, but we can improve it so it stops being a violation. Subjective reasons against leading commas: - It's ugly Subjective reasons against trailling commas: - It's ugly Objective reasons in favor of leading commas: - You get 1 line diffs - You can comment it out by commenting only 1 line - Code generators / tooling only have to touch 1 line to add or remove Weren't these reasons even a motivation for C++11 to support "trailling enum comma" ? Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From andreas.aardal.hanssen at gmail.com Wed Jun 1 15:16:01 2016 From: andreas.aardal.hanssen at gmail.com (Andreas Aardal Hanssen) Date: Wed, 1 Jun 2016 15:16:01 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> Message-ID: <99B52978-52B9-4D77-867F-3E18AA4C3D30@gmail.com> > Den 1. jun. 2016 kl. 15.06 skrev Mark Gaiser : > ... > Funny in the coding style you mention. For operators: "An operator at the end of the line is easy to miss if the editor is too narrow." The exact same could be said for commas at the end of the line. Silly point, it's pretty much a given that there is a comma there, it's insignificant. But the precise operator makes all the difference. +1 Marc, who cares if the diff is shorter or easier to read if the _code_ is hard to read. And butt-ugly code is hard to read. Code is easiest to read if it resembles English , and commas at the beginning of a line just doesn't. Andreas From milian.wolff at kdab.com Wed Jun 1 15:17:40 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 01 Jun 2016 15:17:40 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> Message-ID: <1709250.FYKrsMtoJA@milian-kdab2> On Wednesday, June 1, 2016 12:56:12 PM CEST Simon Hausmann wrote: > Hi, > > I'm in favorof changing our coding style to adopt the model you call "butt > ugly" because I find it more appealing and I find that it makes diffs > easier to read. +1, less diff noise when an initializer is added/removed -- 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 Jun 1 15:36:43 2016 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 01 Jun 2016 15:36:43 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> Message-ID: <1565127.n0exVmCJzs@oscar> On Mittwoch, 1. Juni 2016 12:56:12 CEST Simon Hausmann wrote: > Hi, > > I'm in favorof changing our coding style to adopt the model you call "butt > ugly" because I find it more appealing and I find that it makes diffs > easier to read. > > Simon +1 as well, if someone counts the votes! Also there was some talk about optionally allowing braces for single line if (more similar to KDE style, less diff, and avoid "goto fail" kind of problem) Anyone has a config file for clang-format to use with qt so it can be used with git-clang-format? -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Wed Jun 1 15:44:22 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 1 Jun 2016 15:44:22 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <1595975.TPAtiFIfjf@serj-laptop> References: <201606011441.31348.marc.mutz@kdab.com> <1595975.TPAtiFIfjf@serj-laptop> Message-ID: <201606011544.23559.marc.mutz@kdab.com> On Wednesday 01 June 2016 15:15:17 Sergio Martins wrote: > On Wednesday, 1 June 2016 14:41:30 WEST Marc Mutz wrote: > > Hi, > > > > There seems to have been a silent underground move to uglify the Qt > > sources , by using commas to introduce lines > > . I have no idea where this came from > > , but it looks butt > > -ugly and it is in violation of http > > (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at > > the _end_ of wrapped lines") > > I think that refers to function calls and wasn't written with ctor > init-lists in mind, but we can improve it so it stops being a violation. I'm pretty sure it was written with ctor-init-lists in mind, because all of QtBase uses trailing comma. I only come across the leading comma version in new modules. > Subjective reasons against leading commas: > - It's ugly > > Subjective reasons against trailling commas: > - It's ugly I beg your pardon? Trailing commas are ugly? So where's the text editor that folds prose text to have commas on the next line? > Objective reasons in favor of leading commas: > - You get 1 line diffs You get the same when you insert fields in the middle. Only at the end there's a difference. > - You can comment it out by commenting only 1 line > - Code generators / tooling only have to touch 1 line to add or remove All these are also valid for enums and function argument lists, but I see no- one doing similar things for enums and functions. If those reasons were strong enough to do away with 100s of years of typesetting history, why don't we use it for functions, too: func( loooooooooooooooooooooooooooooooooongarg1 , loooooooooooooooooooooooooooooooooooooooooooonerarg2 , looooooooooooooooooooooooooooooongestarg3 ); Hmm, sweet... > Weren't these reasons even a motivation for C++11 to support "trailling > enum comma" ? Yes, and we should wait for / propose that they do the same change for ctor- init-list, too. Not apply some horrible work-around. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From jedrzej.nowacki at qt.io Wed Jun 1 15:49:20 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Wed, 1 Jun 2016 15:49:20 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <99B52978-52B9-4D77-867F-3E18AA4C3D30@gmail.com> References: <201606011441.31348.marc.mutz@kdab.com> <99B52978-52B9-4D77-867F-3E18AA4C3D30@gmail.com> Message-ID: <1495604.9ecc0P7k4d@42> On Wednesday 01 of June 2016 15:16:01 Andreas Aardal Hanssen wrote: > > Den 1. jun. 2016 kl. 15.06 skrev Mark Gaiser : > > ... > > Funny in the coding style you mention. For operators: "An operator at the > > end of the line is easy to miss if the editor is too narrow." The exact > > same could be said for commas at the end of the line. > Silly point, it's pretty much a given that there is a comma there, it's > insignificant. But the precise operator makes all the difference. > > +1 Marc, who cares if the diff is shorter or easier to read if the _code_ is > hard to read. And butt-ugly code is hard to read. Code is easiest to read > if it resembles English , and commas at the beginning of a line just > doesn't. > > Andreas > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Yey for coding style fights! I care about easy to read diffs and not every butt is ugly :-) These days I'm probably reading more code then English literature (which is definitely visible in my mails and commit messages...) and argument about how similar code is to natural language is a bit odd to me, I'm not aware of any successful programing language that simulates natural grammar :-) . Btw. How often do you _read_ commas? My brain automatically skips them... In the end it simply doesn't matter much. Cheers, Jędrek From jedrzej.nowacki at qt.io Wed Jun 1 15:58:35 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Wed, 1 Jun 2016 15:58:35 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606011544.23559.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> <1595975.TPAtiFIfjf@serj-laptop> <201606011544.23559.marc.mutz@kdab.com> Message-ID: <1503207.cKBCUfLLVM@42> On Wednesday 01 of June 2016 15:44:22 Marc Mutz wrote: > > Subjective reasons against trailling commas: > > - It's ugly > > I beg your pardon? Trailing commas are ugly? So where's the text editor > that folds prose text to have commas on the next line? Aesthetics are subjective by definition, you could argue that leading commas are creating optically aligned result, highlighting indentation of the initialization list :D > > Objective reasons in favor of leading commas: > > - You get 1 line diffs > > You get the same when you insert fields in the middle. Only at the end > there's a difference. You can not always pick where you insert new field, it may cause warnings and bugs cause by wrong initialization order. > > - You can comment it out by commenting only 1 line > > - Code generators / tooling only have to touch 1 line to add or remove > > All these are also valid for enums and function argument lists, but I see > no- one doing similar things for enums and functions. > > If those reasons were strong enough to do away with 100s of years of > typesetting history, why don't we use it for functions, too: > > func( > loooooooooooooooooooooooooooooooooongarg1 > , loooooooooooooooooooooooooooooooooooooooooooonerarg2 > , looooooooooooooooooooooooooooooongestarg3 > ); > > Hmm, sweet... Good idea we should all that everywhere :-) > > Weren't these reasons even a motivation for C++11 to support "trailling > > enum comma" ? > > Yes, and we should wait for / propose that they do the same change for ctor- > init-list, too. Not apply some horrible work-around. We have long tradition of doing stuff before C++ standard. We can not just drop it :P Enough trolling :-) Cheers , Jędrek From annulen at yandex.ru Wed Jun 1 16:17:57 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 01 Jun 2016 17:17:57 +0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: <1495604.9ecc0P7k4d@42> References: <201606011441.31348.marc.mutz@kdab.com> <99B52978-52B9-4D77-867F-3E18AA4C3D30@gmail.com> <1495604.9ecc0P7k4d@42> Message-ID: <181221464790677@web5h.yandex.ru> 01.06.2016, 16:50, "Jędrzej Nowacki" : > On Wednesday 01 of June 2016 15:16:01 Andreas Aardal Hanssen wrote: >>  > Den 1. jun. 2016 kl. 15.06 skrev Mark Gaiser : >>  > ... >>  > Funny in the coding style you mention. For operators: "An operator at the >>  > end of the line is easy to miss if the editor is too narrow." The exact >>  > same could be said for commas at the end of the line. >>  Silly point, it's pretty much a given that there is a comma there, it's >>  insignificant. But the precise operator makes all the difference. >> >>  +1 Marc, who cares if the diff is shorter or easier to read if the _code_ is >>  hard to read. And butt-ugly code is hard to read. Code is easiest to read >>  if it resembles English , and commas at the beginning of a line just >>  doesn't. >> >>  Andreas >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > Yey for coding style fights! > > I care about easy to read diffs and not every butt is ugly :-) These days I'm > probably reading more code then English literature (which is definitely visible > in my mails and commit messages...) and argument about how similar code is to > natural language is a bit odd to me, I'm not aware of any successful > programing language that simulates natural grammar :-) . For example, Perl is somewhat closer to it than C++, it's designed by linguist after all. > Btw. How often do you > _read_ commas? My brain automatically skips them... In the end it simply > doesn't matter much. > > Cheers, >  Jędrek > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From sergio.martins at kdab.com Wed Jun 1 16:33:39 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Wed, 01 Jun 2016 15:33:39 +0100 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606011544.23559.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> <1595975.TPAtiFIfjf@serj-laptop> <201606011544.23559.marc.mutz@kdab.com> Message-ID: <1503286.Zm5WjmxBNV@serj-laptop> On Wednesday, 1 June 2016 15:44:22 WEST Marc Mutz wrote: > On Wednesday 01 June 2016 15:15:17 Sergio Martins wrote: > > Subjective reasons against leading commas: > > - It's ugly > > > > Subjective reasons against trailling commas: > > - It's ugly > > I beg your pardon? Trailing commas are ugly? So where's the text editor that > folds prose text to have commas on the next line? What does prose text have to do with C++ ? When people say readable code resembles english it's not about punctuation. It just means you can understand the business logic by reading the variable and function names: while (isSick) { eatApples(); } You're pushing the analogy too far. > > > - You can comment it out by commenting only 1 line > > - Code generators / tooling only have to touch 1 line to add or remove > > All these are also valid for enums and function argument lists, but I see > no- one doing similar things for enums and functions. What does function arguments have to do with ctor-init-lists ? The number of member variables to initialize scales linearly with the number of features, can you say the same about functions ? Do you keep growing your function until you have 10 or 20 arguments ? I don't care about commas in functions, I refactor the function instead. Agreed about enums, but I write a order of magnitude more ctors than enums, so never felt motivated to use C++11 trailling enum feature. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From edward.welbourne at qt.io Wed Jun 1 16:50:49 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 1 Jun 2016 14:50:49 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <181221464790677@web5h.yandex.ru> References: <201606011441.31348.marc.mutz@kdab.com> <99B52978-52B9-4D77-867F-3E18AA4C3D30@gmail.com> <1495604.9ecc0P7k4d@42>,<181221464790677@web5h.yandex.ru> Message-ID: Jędrek remarked: >> argument about how similar code is to natural language is a bit odd >> to me, I'm not aware of any successful programing language that >> simulates natural grammar :-) . On 1st June 2016 at 16:17 Konstantin Tokarev added to the discussion: > For example, Perl is somewhat closer to it than C++, it's designed by > linguist after all. I suspect Jędrek was aware of this and actively meant to insinuate something about whether perl is a "successful programing language". For my own part, although I do enjoy perl's scope for poetic choices about how to phrase things, I must confess its linguistic pretensions mostly lead to programmers, who *haven't* thought carefully about the future readers of their code, writing code that's made harder to read. The freedom to express things in Tim Toady's many ways does make it possible to write elegant and poetic perl, but most programmers are lousy poets in too much of a hurry to hack something together to worry about elegance. Much as may be said for the natural language we write. In any case, C++ isn't perl and doesn't come close to it in terms of naturality of linguistic form. C++ isn't even Algol, in which multi-word identifiers were allowed to embed (ignored) spaces, making camelCase redundant. So whether C++ reads, or is typeset, like English is far less important than whether it is easy to see, at a glance, whether it is correct. As to commas normally appearing at the end of prior text: where I learned my anglic, colons do the same - yet we quite commonly split a class constructor just before the colon, that introduces the initialization before the body, rather than just after it. Doing the same for the comma-joined subsequent initializer list is no worse - and arguably at least consistent with the treatment of the colon. As to that, I can see why some like the comma-first style (and I notice emacs does a decent job of indenting it sensibly), although I don't really see a huge win in either direction and my eyes parse each with roughly equal ease. Speaking of colons, one coder's "butt-ugly" is another's "callipygian", I guess, Eddy. From Eskil.Abrahamsen-Blomfeldt at qt.io Wed Jun 1 17:00:05 2016 From: Eskil.Abrahamsen-Blomfeldt at qt.io (Eskil Abrahamsen-Blomfeldt) Date: Wed, 1 Jun 2016 15:00:05 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> Message-ID: <1FBB92C9-F564-49D5-A53A-A07B10DBF202@qt.io> +1 from me as well. The argument about natural language makes no sense to me; Nothing in C++ resembles natural grammar, nor should it; It might take some getting used to, like any change in style, but after a while you won't think it is ugly anymore, and then we can reap the benefits of it being objectively superior because it minimizes diffs in initializer lists. :) -- Eskil Abrahamsen Blomfeldt Senior Manager, Qt Graphics/Multimedia The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io From: Development > on behalf of Simon Hausmann > Date: Wednesday 1 June 2016 at 14:56 To: Marc Mutz >, "development at qt-project.org" > Subject: Re: [Development] commas in ctor-init-lists Hi, I'm in favorof changing our coding style to adopt the model you call "butt ugly" because I find it more appealing and I find that it makes diffs easier to read. Simon ________________________________ From: Marc Mutz > Sent: Jun 1, 2016 14:41 To: development at qt-project.org Subject: [Development] commas in ctor-init-lists Hi, There seems to have been a silent underground move to uglify the Qt sources , by using commas to introduce lines . I have no idea where this came from , but it looks butt -ugly and it is in violation of http ://wiki .qt .io /Qt_Coding_Style QFoo::QFoo() : QBase(), m_f1(), m_f2() { } -not- QFoo::QFoo() : QBase() , m_f1() , m_f2() { } (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the _end_ of wrapped lines") Thanks, Marc -- Marc Mutz > | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts _______________________________________________ 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 mathias.hasselmann at kdab.com Wed Jun 1 17:12:35 2016 From: mathias.hasselmann at kdab.com (Mathias Hasselmann) Date: Wed, 1 Jun 2016 17:12:35 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606011544.23559.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> <1595975.TPAtiFIfjf@serj-laptop> <201606011544.23559.marc.mutz@kdab.com> Message-ID: <574EFB63.5070802@kdab.com> First of all: Thank you Marc for raising that topic. Actually it also concerned me quite often, but so far I was to shy to mention this very opinionated topic. Am 01.06.2016 um 15:44 schrieb Marc Mutz: > On Wednesday 01 June 2016 15:15:17 Sergio Martins wrote: >> On Wednesday, 1 June 2016 14:41:30 WEST Marc Mutz wrote: >>> Hi, >>> >>> There seems to have been a silent underground move to uglify the Qt >>> sources , by using commas to introduce lines >>> . I have no idea where this came from I've seen it first at Nokia, but it might be older. Reasoning was to minimize patches and to reduce chance of merge conflicts. >>> , but it looks butt Which is highly subjective. >>> -ugly and it is in violation of http >>> (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at >>> the _end_ of wrapped lines") >> >> I think that refers to function calls and wasn't written with ctor >> init-lists in mind, but we can improve it so it stops being a violation. > > I'm pretty sure it was written with ctor-init-lists in mind, because all of > QtBase uses trailing comma. I only come across the leading comma version in > new modules. > >> Subjective reasons against leading commas: >> - It's ugly >> >> Subjective reasons against trailling commas: >> - It's ugly > > I beg your pardon? Trailing commas are ugly? So where's the text editor that > folds prose text to have commas on the next line? Now as we are at bike-sheding: Yes, when it comes to initializer lists the trailing comma looks ugly to me. Because of the inconsistent two-space indent for the first initializer. Because line starts of are not aligned. Lets proceed with smart-assing: Trailing comma violates two very explicit rules: - operators start at the beginning of the new lines - 4 spaces are used for indentation Leading comma: - fixes those style violations - reduces patch noise - reduces inconsistent - at the cost of maybe violating one rule with unclear scope ("commas go at the end of wrapped lines") I for my part prefer leading comma. > Yes, and we should wait for / propose that they do the same change for ctor- > init-list, too. Not apply some horrible work-around. By your choice of wording you seem rather upset. For myself I know that I feel upset when my comfort zone gets violate, when someone tries to changes things I grew comfortable with. How are the chances that you are upset just for the very same reason? Ciao, Mathias -- Mathias Hasselmann | mathias.hasselmann 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: 4016 bytes Desc: S/MIME Cryptographic Signature URL: From mathias.hasselmann at kdab.com Wed Jun 1 17:41:23 2016 From: mathias.hasselmann at kdab.com (Mathias Hasselmann) Date: Wed, 1 Jun 2016 17:41:23 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <1595975.TPAtiFIfjf@serj-laptop> References: <201606011441.31348.marc.mutz@kdab.com> <1595975.TPAtiFIfjf@serj-laptop> Message-ID: <574F0223.50701@kdab.com> Am 01.06.2016 um 15:15 schrieb Sergio Martins: > On Wednesday, 1 June 2016 14:41:30 WEST Marc Mutz wrote: >> Hi, >> >> There seems to have been a silent underground move to uglify the Qt sources >> , by using commas to introduce lines >> . I have no idea where this came from >> , but it looks butt >> -ugly and it is in violation of http >> (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the >> _end_ of wrapped lines") > > > I think that refers to function calls and wasn't written with ctor init-lists > in mind, but we can improve it so it stops being a violation. > > Subjective reasons against leading commas: > - It's ugly > > Subjective reasons against trailling commas: > - It's ugly > > Objective reasons in favor of leading commas: > - You get 1 line diffs > - You can comment it out by commenting only 1 line > - Code generators / tooling only have to touch 1 line to add or remove Not mentioned yet: Conditional compilation vs. stable ABI: MamanBar::MamanBar(...) : m_field1(...), m_field2(...), // oh... #ifdef FEATURE1_ENABLED m_field3(...), // ...ah #endif #ifdef FEATURE2_ENABLED m_field4(...) #endif { } Ciao, Mathias -- Mathias Hasselmann | mathias.hasselmann 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: 4016 bytes Desc: S/MIME Cryptographic Signature URL: From scott at towel42.com Wed Jun 1 19:05:39 2016 From: scott at towel42.com (Scott Aron Bloom) Date: Wed, 1 Jun 2016 17:05:39 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606011441.31348.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> Message-ID: In previous projects I have worked on, the "leading comma" was done because it makes it easier if you have #ifdef'ed variables that need initialization. You are less likely to introduce a syntax error when the defined variable is not set.. Ie, the first one causes a syntax error QFoo::QFoo() : QBase(), m_f1(), #ifdef USE_F2 m_f2() #endif { } Whereas the second does not QFoo::QFoo() : QBase() , m_f1() #ifdef USE_F2 , m_f2() #endif { } -----Original Message----- From: Development [mailto:development-bounces+scott=towel42.com at qt-project.org] On Behalf Of Marc Mutz Sent: Wednesday, June 1, 2016 5:42 AM To: development at qt-project.org Subject: [Development] commas in ctor-init-lists Hi, There seems to have been a silent underground move to uglify the Qt sources , by using commas to introduce lines . I have no idea where this came from , but it looks butt -ugly and it is in violation of http ://wiki .qt .io /Qt_Coding_Style QFoo::QFoo() : QBase(), m_f1(), m_f2() { } -not- QFoo::QFoo() : QBase() , m_f1() , m_f2() { } (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the _end_ of wrapped lines") Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From dmitry at 0fe.ru Wed Jun 1 19:59:32 2016 From: dmitry at 0fe.ru (Dmitry Shapovalov) Date: Wed, 1 Jun 2016 22:59:32 +0500 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: <21228815.hmc38veoAe@w530.nolden.freebsd> References: <21228815.hmc38veoAe@w530.nolden.freebsd> Message-ID: Okay. I think i found the source of problem. Calculation of send timeout is incorrect. Here is the calculation code: http://code.qt.io/cgit/qt/qtserialbus.git/tree/src/serialbus/qmodbusrtuserialmaster_p.h#n294 // Example: 9600 baud, 11 bit per packet -> 872 char/sec // so: 1000 ms / 872 char = 1.147 ms/char * 3.5 character m_sendTimer.start((1000. / (qreal(m_baudRate) / 11.)) * m_current.adu.size()); Which in my case (115200 and 8 bytes of data) gives 0.7 ms. And after conversion to int, it becomes zero. So m_sendTimer is fired up immediately, which brings us to to this code: http://code.qt.io/cgit/qt/qtserialbus.git/tree/src/serialbus/qmodbusrtuserialmaster_p.h#n323 } else if (m_current.bytesWritten < m_current.adu.size()) { qCDebug(QT_MODBUS) << "(RTU client) Send failed:" << m_current.requestPdu; if (m_current.numberOfRetries <= 0) { if (m_current.reply) { m_current.reply->setError(QModbusDevice::TimeoutError, QModbusClient::tr("Request timeout.")); } So there comes a premature timeout. I experimented with a timeout and found that even a value of 15-20ms does not give stable results. only the value of around 50ms gives a stable result in my case. I suppose that timeout calculation must include some additional minimum time constant. I will report this bug. Thank you all for the help ) 2016-05-31 17:15 GMT+05:00 Ralf Nolden : > Am Dienstag, 31. Mai 2016, 13:53:15 schrieb Denis Shienkov: > > > But why ? > > > > I don't know.. maybe the Qt Modbus Master closes the connection without > > waiting of data send, > > > > maybe something else.. > > > > PS: I just have checked the QSerialPort autotests with the PL2303 on > > Windows - all worked. > > > > PS2: You can try to use the Terminal Example (from the Qt Serial Port) > > with the Rx/Tx connected, > > > > to check that your serial port works. > > If you have a second PC around, try running the slave example there and > connect them with a second adapter, then try the master example to see if > your > conection works between those two computers. > > At any rate. the modbus master is doing the right thing if the error comes > from the serial port. We can't just ignore port errors in cases where the > returned response theoretically matches the expected results :) > > > > > 31.05.2016 13:17, Dmitry Shapovalov пишет: > > > Yep. That's right. It is ERROR_OPERATION_ABORTED. > > > But why ? Any other application works as expected with this hardware. > > > > > > And i confirm that 0x01040000000131ca and 0x0104024c494c06 are correct > > > request and response. > > > > > > > > > 2016-05-31 15:05 GMT+05:00 Denis Shienkov > > > > > >: > > > Seems, this: > > > > qt.modbus: (RTU server) QSerialPort error: > > > > QSerialPort::SerialPortError(ResourceError) "Операция> > > > ввода/вывода была прервана из-за завершения потока команд или по > > > запросу приложения." > > > > > > It is an 'ERROR_OPERATION_ABORTED', that can be caused by > > > > > > ::CancelIo() (e.g. when the serial port closes) or by a HW > problems. > > > > > > BR, > > > > > > Denis > > > > > > 31.05.2016 12:23, Dmitry Shapovalov пишет: > > >> Thanks for reply Ralf. Email more preferable for me. > > >> > > >> Can you tell me what type of adapter you are using? Which version > > >> of qtserialport are you using? Maybe my problem is related to the > > >> type of serial port adapter. I tried use arduino with different > > >> usb-uart chips(ch430 and pl2303), but unsuccessfully. > > >> > > >> Here is output of qt modbus master example > > >> > > >> Запускается > > >> > C:\Qt\Examples\Qt-5.6\qtserialbus\serialbus\modbus\build-master-Deskt > > >> op_Qt_5_6_0_MinGW_32bit-Debug\debug\modbusmaster.exe... qt.modbus: > > >> (RTU client) Sent Serial PDU: 0x0400000001 > > >> qt.modbus.lowlevel: (RTU client) Sent Serial ADU: > 0x01040000000131ca > > >> qt.modbus: (RTU client) Send failed: 0x0400000001 > > >> qt.modbus: (RTU server) QSerialPort error: > > >> QSerialPort::SerialPortError(ResourceError) "Операция > > >> ввода/вывода была прервана из-за завершения потока команд или по > > >> запросу приложения." > > >> qt.modbus.lowlevel: (RTU client) Response buffer: "01" > > >> qt.modbus: (RTU client) Modbus ADU not complete > > >> qt.modbus.lowlevel: (RTU client) Response buffer: "0104024c494c06" > > >> qt.modbus: (RTU client) Received ADU: "0104024c494c06" > > >> qt.modbus: (RTU client) Cannot match response with open request, > > >> ignoring > > >> > > >> Look like it actually sends request, but qtserialport reports > > >> error, so qtserialbus(modbus) ignores response. > > >> > > >> > > >> 2016-05-31 11:59 GMT+05:00 Ralf Nolden > >> > > >> >: > > >> Am Dienstag, 31. Mai 2016, 09:34:19 schrieb Dmitry Shapovalov: > > >> > Hello, > > >> > can someone confirm that modbus over serial port is working > > >> > > >> on windows ? > > >> I have tested modbus over serial port on windows with two > > >> Schneider Electric > > >> PLCs, a Twido and a Premium, both with TCP and RS485. We > > >> could evaluate your > > >> problems on IRC if you want. > > >> > > >> > all my experiments led me to the thought that it is > > >> > > >> absolutely broken. > > >> > > >> > i am using arduno as a modbus device. i tested it with > > >> > > >> qmodbus and modbus > > >> > > >> > poll. works great. but when i try to use modbus examples > from > > >> > qt(qtserialbus/examples/serialbus/modbus/master), look like > > >> > > >> it can not send > > >> > > >> > request. > > >> > i tried release(5.6) and git version of qtserialbus and > > >> > > >> qtserialport > > >> > > >> > modules with no luck. > > >> > > > >> > i am using windows 7 on virtualbox. > > >> > arduino modbus library from here > > >> > > https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino > > >> > arduino sketch http://pastebin.com/FHW3B7TX > > >> > > > >> > it's me or it's really broken ? > > >> > > >> -- > > >> Kind regards, > > >> > > >> Ralf Nolden > > >> > > >> _______________________________________________ > > >> Development mailing list > > >> Development at qt-project.org > > > >> http://lists.qt-project.org/mailman/listinfo/development > > >> > > >> _______________________________________________ > > >> Development mailing list > > >> Development at qt-project.org > > >> http://lists.qt-project.org/mailman/listinfo/development > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Kind regards, > > Ralf Nolden > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- -- With Best Regards Dmitry Shapovalov -------------- next part -------------- An HTML attachment was scrubbed... URL: From mardy at users.sourceforge.net Wed Jun 1 20:57:12 2016 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Wed, 1 Jun 2016 21:57:12 +0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: <574EFB63.5070802@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> <1595975.TPAtiFIfjf@serj-laptop> <201606011544.23559.marc.mutz@kdab.com> <574EFB63.5070802@kdab.com> Message-ID: <574F3008.1040303@users.sourceforge.net> On 01/06/2016 18:12, Mathias Hasselmann wrote: > Yes, when it comes to initializer lists the trailing comma looks ugly to > me. Because of the inconsistent two-space indent for the first > initializer. Because line starts of are not aligned. In my projects I use this style: MyObject::MyObject(): SuperClass(), m_var1(), m_var2() { } Having a diff taking two lines never annoyed me, especially given that often the last member is either d_ptr() or q_ptr(), so I usually add members in the middle. > Not mentioned yet: Conditional compilation vs. stable ABI: > > MamanBar::MamanBar(...) > : m_field1(...), > m_field2(...), // oh... > #ifdef FEATURE1_ENABLED > m_field3(...), // ...ah > #endif > #ifdef FEATURE2_ENABLED > m_field4(...) > #endif > { > } You can always find cases which break with either style. MamanBar::MamanBar(...) #ifdef FEATURE1_ENABLED : m_field1(...) // ...ah #endif , m_field2(...) , m_field3(...) { } Ultimately, it's just a matter of personal preferences; people like to argue about diff size or better spotting of obvious mistakes (when putting operators at the beginning of the line), while as a matter of fact people can live perfectly well and be equally productive with either style. Ciao, Alberto From Andy.Nichols at qt.io Wed Jun 1 21:23:26 2016 From: Andy.Nichols at qt.io (Andy Nichols) Date: Wed, 1 Jun 2016 19:23:26 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> References: <201606011441.31348.marc.mutz@kdab.com>, <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> Message-ID: <9C2F9C14-5FB1-44FC-99A5-E959728FE71E@qt.io> +1 to specify the coding style to be the "butt ugly" one. I'm one of those who has (not so secretly) been committing and approving the offending style after all ;-) Though for the record I did not think it mattered and was not covered by the style guideline you cited. Andy Nichols > On 01 Jun 2016, at 14:56, Simon Hausmann wrote: > > I'm in favorof changing our coding style to adopt the model you call "butt ugly" because I find it more appealing and I find that it makes diffs easier to read. > > Simon From robin+qt at viroteck.net Wed Jun 1 21:33:12 2016 From: robin+qt at viroteck.net (Robin Burchell) Date: Wed, 01 Jun 2016 21:33:12 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <9C2F9C14-5FB1-44FC-99A5-E959728FE71E@qt.io> References: <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> <9C2F9C14-5FB1-44FC-99A5-E959728FE71E@qt.io> Message-ID: <1464809592.1056024.625147657.57A94636@webmail.messagingengine.com> And another +1 from me. -- Robin Burchell On Wed, Jun 1, 2016, at 09:23 PM, Andy Nichols wrote: > +1 to specify the coding style to be the "butt ugly" one. > > I'm one of those who has (not so secretly) been committing and approving > the offending style after all ;-) Though for the record I did not think > it mattered and was not covered by the style guideline you cited. > > Andy Nichols > > > On 01 Jun 2016, at 14:56, Simon Hausmann wrote: > > > > I'm in favorof changing our coding style to adopt the model you call "butt ugly" because I find it more appealing and I find that it makes diffs easier to read. > > > > Simon > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Wed Jun 1 23:27:44 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 1 Jun 2016 23:27:44 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <1503286.Zm5WjmxBNV@serj-laptop> References: <201606011441.31348.marc.mutz@kdab.com> <201606011544.23559.marc.mutz@kdab.com> <1503286.Zm5WjmxBNV@serj-laptop> Message-ID: <201606012327.45715.marc.mutz@kdab.com> On Wednesday 01 June 2016 16:33:39 Sergio Martins wrote: > On Wednesday, 1 June 2016 15:44:22 WEST Marc Mutz wrote: > > On Wednesday 01 June 2016 15:15:17 Sergio Martins wrote: > > > Subjective reasons against leading commas: > > > - It's ugly > > > > > > Subjective reasons against trailling commas: > > > - It's ugly > > > > I beg your pardon? Trailing commas are ugly? So where's the text editor > > that folds prose text to have commas on the next line? > > What does prose text have to do with C++ ? When people say readable code > resembles english it's not about punctuation. It just means you can > understand the business logic by reading the variable and function names: > > while (isSick) { eatApples(); } > > You're pushing the analogy too far. I don't think so. Semicolons and commas are visually *designed* to be trailing. And consequently every C++ text book uses trailing commas. Not even GNU style dares to tread there. Seeing leading commas just hurts visually, and they are not idiomatic C++. To a C++ programmer, they look alien, out of place. That is not the case with whitespace, or where to put braces, because there is corresponding variance in the C++ text books, too. But there is no variance in comma placement. *All* C++ text books use trailing commas. > > > - You can comment it out by commenting only 1 line > > > - Code generators / tooling only have to touch 1 line to add or remove > > > > All these are also valid for enums and function argument lists, but I see > > no- one doing similar things for enums and functions. > > What does function arguments have to do with ctor-init-lists ? What do they *not* have to do with each other? They are both comma-separated, and often need line wrapping to fit within the given column limit. Functions also may have parameters that are absent in conditional compilation. Functions are used more often and tend to have longer expressions as arguments than ctor-init-list entries, making such problems as cited for ctor-init-lists more frequent in functions than in ctor-init-lists. > The number > of member variables to initialize scales linearly with the number of > features, can you say the same about functions ? I dispute that. A class that has more than five semantically-different data members smells just as strongly as a function that has five arguments. > Do you keep growing your > function until you have 10 or 20 arguments ? I don't care about commas in > functions, I refactor the function instead. And I'd refactor the class, too. > Agreed about enums, but I write a order of magnitude more ctors than enums, > so never felt motivated to use C++11 trailling enum feature. Well, and we all write an order of magnitude more functions than ctors, so why come we never use the same comma rule as for ctor-init-lists? We instead write the same function twice, cf. QTemporaryFile ctors vs. QT_NO_QOBJECT. Why? Because it's *ugly*. NSDMI and ctor delegation will solve most of this, btw, for ctor-init-lists (but not functions). It seems to me that people are arguing that a problem exists in a construct used X times (ctor-init-lists), and the same problem does not exist in a construct used 10X times (functions) per unit code. Either be consequent about it, and demand the same (the ugly) comma placement for function arguments and enums, or acknowledge that the reasons cited for using leading commas in ctor-init-lists are applicable to functions and enums, too, and, seeing no problem there, are thus no problem in ctor-init-lists, either. Otherwise, this is nothing more than arguing for some random, inconsistent, style-of-the-day, just because some Nokia-era modules happen to use it in violation of the Qt Coding Style, QtBase and C++ text books existing practice. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From bstottle at ford.com Thu Jun 2 00:45:51 2016 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Wed, 1 Jun 2016 22:45:51 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606012327.45715.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> <201606011544.23559.marc.mutz@kdab.com> <1503286.Zm5WjmxBNV@serj-laptop> <201606012327.45715.marc.mutz@kdab.com> Message-ID: On 6/1/16, 5:27 PM, "Development on behalf of Marc Mutz" wrote: ... >Semicolons and commas are visually *designed* to be >trailing. And consequently every C++ text book uses trailing commas. The pros that have been cited include code review and diffs for leading commas. One nice thing about books is that they are fairly static, so the pro doesn’t really apply ;-) I thought it looked strange at first, and was weird to use for about a day. But when the code changes, it comes in pretty handy. Now I’ve found I like the approach. My $.02. Brett From mandeepsandhu.chd at gmail.com Thu Jun 2 01:10:34 2016 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Wed, 1 Jun 2016 16:10:34 -0700 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606011544.23559.marc.mutz@kdab.com> <1503286.Zm5WjmxBNV@serj-laptop> <201606012327.45715.marc.mutz@kdab.com> Message-ID: The leading comma's are also helpful if we have some part of the initializer list protected by a preprocessor conditional (or might be needed in the future). QFoo::QFoo() : QBase() , m_f1() #ifdef XYZ , m_f2() #endif , m_f3() Although I'm not sure if we have many (of any at all) such instances in the Qt source. But this form does take some getting used to. My natural tendency is to put the comma at the end. Just my 2¢. -mandeep From robert.griebl at pelagicore.com Thu Jun 2 01:13:49 2016 From: robert.griebl at pelagicore.com (Robert Griebl) Date: Thu, 2 Jun 2016 01:13:49 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> Message-ID: And another +1 cu Robert On 01.06.2016 14:56, Simon Hausmann wrote: > Hi, > > I'm in favorof changing our coding style to adopt the model you call > "butt ugly" because I find it more appealing and I find that it makes > diffs easier to read. > > Simon > > > ------------------------------------------------------------------------ > *From:* Marc Mutz > *Sent:* Jun 1, 2016 14:41 > *To:* development at qt-project.org > *Subject:* [Development] commas in ctor-init-lists > > Hi, > > There seems to have been a silent underground move to uglify the Qt sources > , by using commas to introduce lines > . I have no idea where this came from > , but it looks butt > -ugly and it is in violation of http > ://wiki > .qt > .io > /Qt_Coding_Style > > QFoo::QFoo() > : QBase(), > m_f1(), > m_f2() > { > > } > > -not- > > QFoo::QFoo() > : QBase() > , m_f1() > , m_f2() > { > > } > > (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the > _end_ of wrapped lines") > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > 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 thiago.macieira at intel.com Thu Jun 2 02:05:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 01 Jun 2016 21:05:09 -0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: <1495604.9ecc0P7k4d@42> References: <201606011441.31348.marc.mutz@kdab.com> <99B52978-52B9-4D77-867F-3E18AA4C3D30@gmail.com> <1495604.9ecc0P7k4d@42> Message-ID: <1583063.BaABOAz7H6@tjmaciei-mobl1> On quarta-feira, 1 de junho de 2016 15:49:20 BRT Jędrzej Nowacki wrote: > Btw. How often do you > _read_ commas? My brain automatically skips them... In the end it simply > doesn't matter much. Quite often. There's this author I'm reading that often forgets commas when writing things like: "it should be easy to convince people of the importance of that Thiago thought" (comma missing before "Thiago thought") And *every* time I read a sentence like that, I stop and cringe. There are some sentences that you also have to stop and think about what the author meant. Excess commas are also bad. I remember reading some text by Sune once (I think it was in Danish) and found it really weird the placement of commas, making me stop where the sentence structure didn't in my mind call for it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jun 2 02:01:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 01 Jun 2016 21:01:58 -0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> Message-ID: <1954846.vM7SB0D0Xj@tjmaciei-mobl1> On quarta-feira, 1 de junho de 2016 15:06:16 BRT Mark Gaiser wrote: > The "butt-ugly" style looks more readable to me. > And imho it reduces the possibility of forgetting a forgetting a comma in > the begin since then your arguments will look out of alignment. The compiler won't let you forget, so that's not an argument. > Funny in the coding style you mention. For operators: "An operator at the > end of the line is easy to miss if the editor is too narrow." The exact > same could be said for commas at the end of the line. I don't like the rule of placing operators at the beginning of the next line. I prefer it at the end, which indicates to the reader that the line continues, as it doesn't end in either ) or semi-colon. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jun 2 02:00:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 01 Jun 2016 21:00:11 -0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> Message-ID: <1631387.G5zvdddk6l@tjmaciei-mobl1> On quarta-feira, 1 de junho de 2016 12:56:12 BRT Simon Hausmann wrote: > Hi, > > I'm in favorof changing our coding style to adopt the model you call "butt > ugly" because I find it more appealing and I find that it makes diffs > easier to read. I object to that, I have rejected patches to QtCore that add code like that and I have even fixed the coding style for patches that were approved by others without my knowledge, as is my prerrogative as maintainer. Gerrit show intra-line differences, so it's easy to spot the comma moving. The trick for enums is to always place last an enum with a special value. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jun 2 02:09:06 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 01 Jun 2016 21:09:06 -0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: <1583063.BaABOAz7H6@tjmaciei-mobl1> References: <201606011441.31348.marc.mutz@kdab.com> <1495604.9ecc0P7k4d@42> <1583063.BaABOAz7H6@tjmaciei-mobl1> Message-ID: <34161655.G0XmMaP59p@tjmaciei-mobl1> On quarta-feira, 1 de junho de 2016 21:05:09 BRT Thiago Macieira wrote: > On quarta-feira, 1 de junho de 2016 15:49:20 BRT Jędrzej Nowacki wrote: > > Btw. How often do you > > > > _read_ commas? My brain automatically skips them... In the end it simply > > doesn't matter much. > > Quite often. There's this author I'm reading that often forgets commas when > writing things like: > "it should be easy to convince people of the importance of that Thiago > thought" (comma missing before "Thiago thought") Oh, I forgot to say: a comma can save a life. Let's eat Grandma Let's eat, Grandma -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From denis.shienkov at gmail.com Thu Jun 2 07:10:38 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 2 Jun 2016 08:10:38 +0300 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: References: <21228815.hmc38veoAe@w530.nolden.freebsd> Message-ID: <6d1d5e1f-f9ae-4bd7-97d3-288fb81e545d@gmail.com> > only the value of around 50ms gives a stable result in my case. Hehh.. I warned the QtSerialBus team that introduction of 3.5 timeouts will lead to bugs and that it doesn't make sense (though, it is described in the Modbus specification). We do not need to rely on this 'characters timeouts', because the OS can not provide this precision timeout (besides, Qt5 event loop introduces also an delay). But, nobody haven't listened to me. BR, Denis 01.06.2016 20:59, Dmitry Shapovalov пишет: > Okay. I think i found the source of problem. Calculation of send > timeout is incorrect. > > Here is the calculation code: > > http://code.qt.io/cgit/qt/qtserialbus.git/tree/src/serialbus/qmodbusrtuserialmaster_p.h#n294 > > // Example: 9600 baud, 11 bit per packet -> 872 char/sec > // so: 1000 ms / 872 char = 1.147 ms/char * 3.5 character > m_sendTimer.start((1000. / (qreal(m_baudRate) / 11.)) * > m_current.adu.size()); > > Which in my case (115200 and 8 bytes of data) gives 0.7 ms. And after > conversion to int, it becomes zero. > So m_sendTimer is fired up immediately, which brings us to to this code: > > http://code.qt.io/cgit/qt/qtserialbus.git/tree/src/serialbus/qmodbusrtuserialmaster_p.h#n323 > > } else if (m_current.bytesWritten < m_current.adu.size()) { > qCDebug(QT_MODBUS) << "(RTU client) Send failed:" << > m_current.requestPdu; > > if (m_current.numberOfRetries <= 0) { > if (m_current.reply) { > m_current.reply->setError(QModbusDevice::TimeoutError, > QModbusClient::tr("Request timeout.")); > } > So there comes a premature timeout. > > I experimented with a timeout and found that even a value of 15-20ms > does not give stable results. only the value of around 50ms gives a > stable result in my case. > I suppose that timeout calculation must include some additional > minimum time constant. > > I will report this bug. > > Thank you all for the help ) > > 2016-05-31 17:15 GMT+05:00 Ralf Nolden >: > > Am Dienstag, 31. Mai 2016, 13:53:15 schrieb Denis Shienkov: > > > But why ? > > > > I don't know.. maybe the Qt Modbus Master closes the connection > without > > waiting of data send, > > > > maybe something else.. > > > > PS: I just have checked the QSerialPort autotests with the PL2303 on > > Windows - all worked. > > > > PS2: You can try to use the Terminal Example (from the Qt Serial > Port) > > with the Rx/Tx connected, > > > > to check that your serial port works. > > If you have a second PC around, try running the slave example > there and > connect them with a second adapter, then try the master example to > see if your > conection works between those two computers. > > At any rate. the modbus master is doing the right thing if the > error comes > from the serial port. We can't just ignore port errors in cases > where the > returned response theoretically matches the expected results :) > > > > > 31.05.2016 13:17, Dmitry Shapovalov пишет: > > > Yep. That's right. It is ERROR_OPERATION_ABORTED. > > > But why ? Any other application works as expected with this > hardware. > > > > > > And i confirm that 0x01040000000131ca and 0x0104024c494c06 are > correct > > > request and response. > > > > > > > > > 2016-05-31 15:05 GMT+05:00 Denis Shienkov > > > > > > > >>: > > > Seems, this: > > > > qt.modbus: (RTU server) QSerialPort error: > > > > QSerialPort::SerialPortError(ResourceError) "Операция> > > > ввода/вывода была прервана из-за завершения потока команд > или по > > > запросу приложения." > > > > > > It is an 'ERROR_OPERATION_ABORTED', that can be caused by > > > > > > ::CancelIo() (e.g. when the serial port closes) or by a HW > problems. > > > > > > BR, > > > > > > Denis > > > > > > 31.05.2016 12:23, Dmitry Shapovalov пишет: > > >> Thanks for reply Ralf. Email more preferable for me. > > >> > > >> Can you tell me what type of adapter you are using? Which > version > > >> of qtserialport are you using? Maybe my problem is > related to the > > >> type of serial port adapter. I tried use arduino with > different > > >> usb-uart chips(ch430 and pl2303), but unsuccessfully. > > >> > > >> Here is output of qt modbus master example > > >> > > >> Запускается > > >> > C:\Qt\Examples\Qt-5.6\qtserialbus\serialbus\modbus\build-master-Deskt > > >> op_Qt_5_6_0_MinGW_32bit-Debug\debug\modbusmaster.exe... > qt.modbus: > > >> (RTU client) Sent Serial PDU: 0x0400000001 > > >> qt.modbus.lowlevel: (RTU client) Sent Serial ADU: > 0x01040000000131ca > > >> qt.modbus: (RTU client) Send failed: 0x0400000001 > > >> qt.modbus: (RTU server) QSerialPort error: > > >> QSerialPort::SerialPortError(ResourceError) "Операция > > >> ввода/вывода была прервана из-за завершения потока команд > или по > > >> запросу приложения." > > >> qt.modbus.lowlevel: (RTU client) Response buffer: "01" > > >> qt.modbus: (RTU client) Modbus ADU not complete > > >> qt.modbus.lowlevel: (RTU client) Response buffer: > "0104024c494c06" > > >> qt.modbus: (RTU client) Received ADU: "0104024c494c06" > > >> qt.modbus: (RTU client) Cannot match response with open > request, > > >> ignoring > > >> > > >> Look like it actually sends request, but qtserialport reports > > >> error, so qtserialbus(modbus) ignores response. > > >> > > >> > > >> 2016-05-31 11:59 GMT+05:00 Ralf Nolden > > >> > > >> >>: > > >> Am Dienstag, 31. Mai 2016, 09:34:19 schrieb Dmitry > Shapovalov: > > >> > Hello, > > >> > can someone confirm that modbus over serial port is > working > > >> > > >> on windows ? > > >> I have tested modbus over serial port on windows with two > > >> Schneider Electric > > >> PLCs, a Twido and a Premium, both with TCP and RS485. We > > >> could evaluate your > > >> problems on IRC if you want. > > >> > > >> > all my experiments led me to the thought that it is > > >> > > >> absolutely broken. > > >> > > >> > i am using arduno as a modbus device. i tested it with > > >> > > >> qmodbus and modbus > > >> > > >> > poll. works great. but when i try to use modbus > examples from > > >> > qt(qtserialbus/examples/serialbus/modbus/master), > look like > > >> > > >> it can not send > > >> > > >> > request. > > >> > i tried release(5.6) and git version of qtserialbus and > > >> > > >> qtserialport > > >> > > >> > modules with no luck. > > >> > > > >> > i am using windows 7 on virtualbox. > > >> > arduino modbus library from here > > >> > > https://github.com/smarmengol/Modbus-Master-Slave-for-Arduino > > >> > arduino sketch http://pastebin.com/FHW3B7TX > > >> > > > >> > it's me or it's really broken ? > > >> > > >> -- > > >> Kind regards, > > >> > > >> Ralf Nolden > > >> > > >> _______________________________________________ > > >> Development mailing list > > >> Development at qt-project.org > > > > > >>http://lists.qt-project.org/mailman/listinfo/development > > >> > > >> _______________________________________________ > > >> Development mailing list > > >> Development at qt-project.org > > > > > >>http://lists.qt-project.org/mailman/listinfo/development > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > > >http://lists.qt-project.org/mailman/listinfo/development > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Kind regards, > > Ralf Nolden > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > > -- > -- > With Best Regards > Dmitry Shapovalov > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From philwave at gmail.com Thu Jun 2 07:16:48 2016 From: philwave at gmail.com (Philippe) Date: Thu, 02 Jun 2016 07:16:48 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: Message-ID: <20160602071647.ED35.6F0322A@gmail.com> > The leading comma's are also helpful if we have some part of the > initializer list protected by a preprocessor conditional (or might be > needed in the future). This is right. This is what CLangFormat proposed me by default. I thought is was a bit strange when I started to use this, but now I would not change. Philippe On Wed, 1 Jun 2016 16:10:34 -0700 Mandeep Sandhu wrote: > The leading comma's are also helpful if we have some part of the > initializer list protected by a preprocessor conditional (or might be > needed in the future). > > QFoo::QFoo() > : QBase() > , m_f1() > #ifdef XYZ > , m_f2() > #endif > , m_f3() > > Although I'm not sure if we have many (of any at all) such instances > in the Qt source. > > But this form does take some getting used to. My natural tendency is > to put the comma at the end. > > Just my 2¢. > > -mandeep > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From massimocallegari at yahoo.it Thu Jun 2 10:17:08 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Thu, 2 Jun 2016 08:17:08 +0000 (UTC) Subject: [Development] Video playback on Ubuntu 16.04 References: <2133812746.5764153.1464855428416.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <2133812746.5764153.1464855428416.JavaMail.yahoo@mail.yahoo.com> Hi everyone, is it just me or QtMultimedia 5.6.0 video playback is quite broken on Ubuntu 16.04 ? I think the reason is that Qt 5.6.0 (and 5.7.0 as well) are still built against gstreamer 0.10, which is quite obsolete now. In fact, I built Qt 5.7.0 myself with gstreamer 1.0 and video playback works as expected. On Ubuntu 16.04, gst 1.0 is the default, and even if I install the available gst 0.10 packages, video playback still doesn't work, displaying a colorful number of error messages such as: 10:03:11:massimo:player > ./player Cannot connect to server socket err = No such file or directory Cannot connect to server request channel jack server is not running or cannot be started JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock JackShmReadWritePtr::~JackShmReadWritePtr - Init not done for 4294967295, skipping unlock GStreamer; Unable to pause - "file:///home/massimo/Scaricati/Star Trek Trailer 3 HD 720p (720p).mp4" GStreamer; Unable to pause - "file:///home/massimo/Scaricati/Star Trek Trailer 3 HD 720p (720p).mp4" Warning: "No decoder available for type 'video/x-h264, stream-format=(string)avc, alignment=(string)au, level=(string)3.1, profile=(string)main, codec_data=(buffer)014d401fffe10016674d401fe88028022d0800001f480005dc0078c1889001000468ebef20, width=(int)1280, height=(int)544, framerate=(fraction)45000/1877, pixel-aspect-ratio=(fraction)1/1'." Problem is that gst 0.10 plugins-bad/ugly packages are not available anymore on 16.04. There is only gstreamer0.10-plugins-good. My request is: can you please consider to drop gst 0.10 and build by default with gstreamer 1.0 ? At least for Qt 5.7.0, even though since Qt 5.6 is a LTS and Ubuntu 16.04 is a LTS, I would say Qt 5.6.1 should bring this change too. In the end, it's easier for a Ubuntu 14.04 user to install gst 1.0 rather than for a Ubuntu 16.04 user to install gst 0.10. Thanks, Massimo From julien.blanc at nmc-company.com Thu Jun 2 10:53:48 2016 From: julien.blanc at nmc-company.com (Julien Blanc) Date: Thu, 02 Jun 2016 10:53:48 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <1565127.n0exVmCJzs@oscar> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> <1565127.n0exVmCJzs@oscar> Message-ID: <1464857628.2602.21.camel@nmc-company.com> Le mercredi 01 juin 2016 à 15:36 +0200, Olivier Goffart a écrit : > > Anyone has a config file for clang-format to use with qt so it can be used > with git-clang-format? > This is the most relevant question in this kinda trollish kind of topic. Everyone has different opinion on these matters, and, this is more a matter of style / habits than real arguments. But there’s one thing that matters a lot more than code style itself : consistency. But to go back to the topic, we’re in 2016 now, and still we face the same discussions as in the nineties. Why is that that I can’t work with the code the way *I* want, and share it with the others the way *they* want. Hey, we now have really pretty decent tools to reformat code ! What i have in mind is something like : - post-checkout/clone git hook that reformat code to *my* style when i work on it - pre-commit hook that reformat code to the *neutral* (ie, qt style rules) style when committing - difftool customization so that diff are displayed in my style rather than the neutral one - server-side : style is checked in the pre-commit hook, either it is reformatted automatically or rejected if not in the good format. Never had the time to play with something like that, i’m wondering if someone ever did, and in that case what’s working and what’s not, the issues faced. Regards, Julien -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Thu Jun 2 11:59:20 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 2 Jun 2016 11:59:20 +0200 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <26003352.DV2JlzaxBy@tjmaciei-mobl4> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <26003352.DV2JlzaxBy@tjmaciei-mobl4> Message-ID: <201606021159.21757.marc.mutz@kdab.com> On Saturday 20 February 2016 19:04:18 Thiago Macieira wrote: > It would buy us, if we raised to GCC 4.8 too: > - deleted and defaulted members > (nsdmi, delegating constructors, template aliases require GCC 4.7) According to qcompilerdetection.h, deleted and defaulted members are available from GCC 4.6 on up. Do you have other information? Does qcd.h need adjustments? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From sergio.martins at kdab.com Thu Jun 2 12:00:20 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 02 Jun 2016 11:00:20 +0100 Subject: [Development] Video playback on Ubuntu 16.04 In-Reply-To: <2133812746.5764153.1464855428416.JavaMail.yahoo@mail.yahoo.com> References: <2133812746.5764153.1464855428416.JavaMail.yahoo.ref@mail.yahoo.com> <2133812746.5764153.1464855428416.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1716093.jcrfbDzTWn@serj-laptop> On Thursday, 2 June 2016 08:17:08 WEST Massimo Callegari via Development wrote: > Hi everyone, > > is it just me or QtMultimedia 5.6.0 video playback is quite broken on Ubuntu > 16.04 ? > > I think the reason is that Qt 5.6.0 (and 5.7.0 as well) are still built > against gstreamer 0.10, which is quite obsolete now. In fact, I built Qt > 5.7.0 myself with gstreamer 1.0 and video playback works as expected. Hi, + -gstreamer Enable GStreamer support With no parameter, this will attempt to auto-detect GStreamer 0.10 and 1.0. GStreamer 1.0 is used by default when available. Use 0.10 or 1.0 for to override auto-detection. 1.0 is the default since Qt 5.6, so it's probably an Ubuntu issue. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From massimocallegari at yahoo.it Thu Jun 2 12:03:29 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Thu, 2 Jun 2016 10:03:29 +0000 (UTC) Subject: [Development] Video playback on Ubuntu 16.04 In-Reply-To: <1716093.jcrfbDzTWn@serj-laptop> References: <2133812746.5764153.1464855428416.JavaMail.yahoo.ref@mail.yahoo.com> <2133812746.5764153.1464855428416.JavaMail.yahoo@mail.yahoo.com> <1716093.jcrfbDzTWn@serj-laptop> Message-ID: <764632272.5971424.1464861809859.JavaMail.yahoo@mail.yahoo.com> 1) Ubuntu 16.04 delivers Qt 5.5.1 2) I am using Qt 5.6.0 official release (Linux x64). Not some PPA, nor Ubuntu stuff. ----- Messaggio originale ----- Da: Sergio Martins A: development at qt-project.org; Massimo Callegari Inviato: Giovedì 2 Giugno 2016 12:00 Oggetto: Re: [Development] Video playback on Ubuntu 16.04 On Thursday, 2 June 2016 08:17:08 WEST Massimo Callegari via Development wrote: > Hi everyone, > > is it just me or QtMultimedia 5.6.0 video playback is quite broken on Ubuntu > 16.04 ? > > I think the reason is that Qt 5.6.0 (and 5.7.0 as well) are still built > against gstreamer 0.10, which is quite obsolete now. In fact, I built Qt > 5.7.0 myself with gstreamer 1.0 and video playback works as expected. Hi, + -gstreamer Enable GStreamer support With no parameter, this will attempt to auto-detect GStreamer 0.10 and 1.0. GStreamer 1.0 is used by default when available. Use 0.10 or 1.0 for to override auto-detection. 1.0 is the default since Qt 5.6, so it's probably an Ubuntu issue. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From massimocallegari at yahoo.it Thu Jun 2 12:09:23 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Thu, 2 Jun 2016 10:09:23 +0000 (UTC) Subject: [Development] Video playback on Ubuntu 16.04 In-Reply-To: <1716093.jcrfbDzTWn@serj-laptop> References: <2133812746.5764153.1464855428416.JavaMail.yahoo.ref@mail.yahoo.com> <2133812746.5764153.1464855428416.JavaMail.yahoo@mail.yahoo.com> <1716093.jcrfbDzTWn@serj-laptop> Message-ID: <1856225942.5883739.1464862163955.JavaMail.yahoo@mail.yahoo.com> Also, if you don't believe me, this is what comes out from Qt's CI system: ldd Qt5.6.0/5.6/gcc_64/plugins/mediaservice/libgstmediaplayer.so linux-vdso.so.1 => (0x00007fff4da5f000) libqgsttools_p.so.1 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libqgsttools_p.so.1 (0x00007f25ddfbe000) libgstaudio-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstaudio-0.10.so.0 (0x00007f25ddd5a000) libgstinterfaces-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstinterfaces-0.10.so.0 (0x00007f25ddb48000) libgstvideo-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstvideo-0.10.so.0 (0x00007f25dd92b000) libgstpbutils-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstpbutils-0.10.so.0 (0x00007f25dd706000) libgstapp-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstapp-0.10.so.0 (0x00007f25dd4f9000) libgstbase-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstbase-0.10.so.0 (0x00007f25dd29f000) libgstreamer-0.10.so.0 => /usr/lib/x86_64-linux-gnu/libgstreamer-0.10.so.0 (0x00007f25dcfaf000) libgobject-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 (0x00007f25dcd5c000) libgmodule-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 (0x00007f25dcb58000) libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007f25dc955000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f25dc74d000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007f25dc43c000) libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2 (0x00007f25dc081000) libQt5MultimediaWidgets.so.5 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libQt5MultimediaWidgets.so.5 (0x00007f25dbe63000) libQt5Multimedia.so.5 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libQt5Multimedia.so.5 (0x00007f25dbb52000) libQt5Widgets.so.5 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libQt5Widgets.so.5 (0x00007f25db2df000) libQt5Gui.so.5 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libQt5Gui.so.5 (0x00007f25daae8000) libQt5Network.so.5 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libQt5Network.so.5 (0x00007f25da789000) libQt5Core.so.5 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libQt5Core.so.5 (0x00007f25da076000) libGL.so.1 => /usr/lib/nvidia-361/libGL.so.1 (0x00007f25d9de7000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f25d9bca000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f25d9847000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f25d953e000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f25d9328000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f25d8f5e000) libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f25d8c5e000) liborc-0.4.so.0 => /usr/lib/x86_64-linux-gnu/liborc-0.4.so.0 (0x00007f25d89dd000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f25d87d9000) libffi.so.6 => /usr/lib/x86_64-linux-gnu/libffi.so.6 (0x00007f25d85d0000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f25d8360000) libicuuc.so.55 => /usr/lib/x86_64-linux-gnu/libicuuc.so.55 (0x00007f25d7fcc000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f25d7db1000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f25d7b8f000) libQt5OpenGL.so.5 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libQt5OpenGL.so.5 (0x00007f25d7938000) libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x00007f25d76e8000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x00007f25d74d6000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f25d719b000) libicui18n.so.56 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libicui18n.so.56 (0x00007f25d6d01000) libicuuc.so.56 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libicuuc.so.56 (0x00007f25d6948000) libicudata.so.56 => /opt/Qt5.6.0/5.6/gcc_64/plugins/mediaservice/../../lib/libicudata.so.56 (0x00007f25d4f65000) /lib64/ld-linux-x86-64.so.2 (0x000055573dcab000) libGLX.so.0 => /usr/lib/nvidia-361/libGLX.so.0 (0x00007f25d4d33000) libGLdispatch.so.0 => /usr/lib/nvidia-361/libGLdispatch.so.0 (0x00007f25d4a4a000) libicudata.so.55 => /usr/lib/x86_64-linux-gnu/libicudata.so.55 (0x00007f25d2f93000) libjson-c.so.2 => /lib/x86_64-linux-gnu/libjson-c.so.2 (0x00007f25d2d87000) libpulsecommon-8.0.so => /usr/lib/x86_64-linux-gnu/pulseaudio/libpulsecommon-8.0.so (0x00007f25d2b0d000) libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x00007f25d28c1000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f25d269e000) libsystemd.so.0 => /lib/x86_64-linux-gnu/libsystemd.so.0 (0x00007f25d2619000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x00007f25d240e000) libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x00007f25d21a5000) libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x00007f25d1f9f000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f25d1d9a000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f25d1b94000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f25d1972000) libgcrypt.so.20 => /lib/x86_64-linux-gnu/libgcrypt.so.20 (0x00007f25d1690000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f25d1477000) libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x00007f25d1202000) libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x00007f25d0f58000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x00007f25d0d3d000) libgpg-error.so.0 => /lib/x86_64-linux-gnu/libgpg-error.so.0 (0x00007f25d0b28000) libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x00007f25d091f000) libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x00007f25d06f3000) ----- Messaggio originale ----- Da: Sergio Martins A: development at qt-project.org; Massimo Callegari Inviato: Giovedì 2 Giugno 2016 12:00 Oggetto: Re: [Development] Video playback on Ubuntu 16.04 On Thursday, 2 June 2016 08:17:08 WEST Massimo Callegari via Development wrote: > Hi everyone, > > is it just me or QtMultimedia 5.6.0 video playback is quite broken on Ubuntu > 16.04 ? > > I think the reason is that Qt 5.6.0 (and 5.7.0 as well) are still built > against gstreamer 0.10, which is quite obsolete now. In fact, I built Qt > 5.7.0 myself with gstreamer 1.0 and video playback works as expected. Hi, + -gstreamer Enable GStreamer support With no parameter, this will attempt to auto-detect GStreamer 0.10 and 1.0. GStreamer 1.0 is used by default when available. Use 0.10 or 1.0 for to override auto-detection. 1.0 is the default since Qt 5.6, so it's probably an Ubuntu issue. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From annulen at yandex.ru Thu Jun 2 12:25:29 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 02 Jun 2016 13:25:29 +0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606011441.31348.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> Message-ID: <3638801464863129@web20m.yandex.ru> 01.06.2016, 15:41, "Marc Mutz" : > Hi, > > There seems to have been a silent underground move to uglify the Qt sources > , by using commas to introduce lines > . I have no idea where this came from It's codified by WebKit coding style, and many people here have contributed to QtWebKit: https://webkit.org/code-style-guidelines/#other-punctuation > , but it looks butt > -ugly and it is in violation of http > ://wiki > .qt > .io > /Qt_Coding_Style > > QFoo::QFoo() >   : QBase(), >     m_f1(), >     m_f2() > { > > } > > -not- > > QFoo::QFoo() >   : QBase() >   , m_f1() >   , m_f2() > { > > } > > (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the > _end_ of wrapped lines") > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From tor.arne.vestbo at qt.io Thu Jun 2 13:07:27 2016 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 2 Jun 2016 13:07:27 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> Message-ID: <836213f9-477e-4697-51ce-4931145b3811@qt.io> On 01/06/16 14:56, Simon Hausmann wrote: > Hi, > > I'm in favorof changing our coding style to adopt the model you call > "butt ugly" because I find it more appealing and I find that it makes > diffs easier to read. +2 Bar::Bar(Bla *b) : Foo(b) , m_baz(123) , m_biz(321) { } aligns and reads much easier (in both diffs and code) than: Bar::Bar(Bla *b) : Foo(b), m_baz(123), m_biz(321) { } especially recognizing the baseclass-init over member init. The two space indented colon in the coding style is even more awkward, having to manually indent the colon instead of using the editor's tab feature, plus it breaks the "put things at the end rule". Bar::Bar(Bla *b) : Foo(b), m_baz(123), m_biz(321) { } tor arne > > Simon > > > ------------------------------------------------------------------------ > *From:* Marc Mutz > *Sent:* Jun 1, 2016 14:41 > *To:* development at qt-project.org > *Subject:* [Development] commas in ctor-init-lists > > Hi, > > There seems to have been a silent underground move to uglify the Qt sources > , by using commas to introduce lines > . I have no idea where this came from > , but it looks butt > -ugly and it is in violation of http > ://wiki > .qt > .io > /Qt_Coding_Style > > QFoo::QFoo() > : QBase(), > m_f1(), > m_f2() > { > > } > > -not- > > QFoo::QFoo() > : QBase() > , m_f1() > , m_f2() > { > > } > > (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the > _end_ of wrapped lines") > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > 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 Martin.Smith at qt.io Thu Jun 2 13:17:45 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Thu, 2 Jun 2016 11:17:45 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <836213f9-477e-4697-51ce-4931145b3811@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io>, <836213f9-477e-4697-51ce-4931145b3811@qt.io> Message-ID: >The two space indented colon in the coding style is even more awkward, having to >manually indent the colon instead of using the editor's tab feature, plus it breaks the >"put things at the end rule". emacs has handled it correctly for me for at least two decades. I just hit return it goes to the correct column. In fact, emacs handles it correctly whether I put the colon after the paren or on the next line. martin ________________________________________ From: Development on behalf of Tor Arne Vestbø Sent: Thursday, June 2, 2016 1:07:27 PM To: Simon Hausmann; Marc Mutz; development at qt-project.org Subject: Re: [Development] commas in ctor-init-lists On 01/06/16 14:56, Simon Hausmann wrote: > Hi, > > I'm in favorof changing our coding style to adopt the model you call > "butt ugly" because I find it more appealing and I find that it makes > diffs easier to read. +2 Bar::Bar(Bla *b) : Foo(b) , m_baz(123) , m_biz(321) { } aligns and reads much easier (in both diffs and code) than: Bar::Bar(Bla *b) : Foo(b), m_baz(123), m_biz(321) { } especially recognizing the baseclass-init over member init. The two space indented colon in the coding style is even more awkward, having to manually indent the colon instead of using the editor's tab feature, plus it breaks the "put things at the end rule". Bar::Bar(Bla *b) : Foo(b), m_baz(123), m_biz(321) { } tor arne > > Simon > > > ------------------------------------------------------------------------ > *From:* Marc Mutz > *Sent:* Jun 1, 2016 14:41 > *To:* development at qt-project.org > *Subject:* [Development] commas in ctor-init-lists > > Hi, > > There seems to have been a silent underground move to uglify the Qt sources > , by using commas to introduce lines > . I have no idea where this came from > , but it looks butt > -ugly and it is in violation of http > ://wiki > .qt > .io > /Qt_Coding_Style > > QFoo::QFoo() > : QBase(), > m_f1(), > m_f2() > { > > } > > -not- > > QFoo::QFoo() > : QBase() > , m_f1() > , m_f2() > { > > } > > (http://wiki.qt.io/Qt_Coding_Style#Line_breaks 2nd item: "Commas go at the > _end_ of wrapped lines") > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From milla.pohjanheimo at qt.io Thu Jun 2 13:32:52 2016 From: milla.pohjanheimo at qt.io (Milla Pohjanheimo) Date: Thu, 2 Jun 2016 11:32:52 +0000 Subject: [Development] g++ 5.2.1 compiler bug Message-ID: We bumped into a compiler bug specific for g++ 5.2.1 when running CI for dev branch on RHEL 7.2 (gcc 5.2.1). Nested structs don't get their constructors called under some circumstances. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67550. A possible workaround for the issue can be found from here: https://codereview.qt-project.org/#/c/161071/ There are issues with gcc 4.9.2 also and those have been discussed in here: http://lists.qt-project.org/pipermail/development/2015-March/020632.html. What do you think, where is the best place to document these issues? Is it supported platforms page, page that lists X11 requirements, some known issues page or something else? - Milla -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Thu Jun 2 13:42:27 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Thu, 2 Jun 2016 11:42:27 +0000 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: <6d1d5e1f-f9ae-4bd7-97d3-288fb81e545d@gmail.com> References: <21228815.hmc38veoAe@w530.nolden.freebsd> <6d1d5e1f-f9ae-4bd7-97d3-288fb81e545d@gmail.com> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Denis Shienkov > Sent: Thursday, 2 June 2016 7:11 > To: development at qt-project.org > Subject: Re: [Development] modbus over serial port on windows 7 ? > > > only the value of around 50ms gives a stable result in my case. > > Hehh.. I warned the QtSerialBus team that introduction of 3.5 timeouts will lead > to bugs and that it doesn't make sense (though, it is described in the Modbus > specification). > We do not need to rely on this 'characters timeouts', because the > OS can not provide this precision timeout (besides, Qt5 event loop introduces > also an delay). But, nobody haven't listened to me. Denis, that's a nice simplistic viewpoint but does not work for Modbus and comments like the above do not help either. Certain error cases can only be detected if you make assumptions about timeouts. Otherwise there is no way to determine where one packet stops and where the next one begins. We are dealing with contradicting requirements on protocol and OS level. Obviously the current point is not optimal. We have to tweak more. Let's see what we can manage in QTBUG-53767. Please shift this discussion to the bug now. Thank you. -- Alex From marc.mutz at kdab.com Thu Jun 2 14:29:24 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 2 Jun 2016 14:29:24 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <836213f9-477e-4697-51ce-4931145b3811@qt.io> Message-ID: <201606021429.26139.marc.mutz@kdab.com> On Thursday 02 June 2016 13:17:45 Martin Smith wrote: > >The two space indented colon in the coding style is even more awkward, > >having to manually indent the colon instead of using the editor's tab > >feature, plus it breaks the "put things at the end rule". > > emacs has handled it correctly for me for at least two decades. As does QtC, of course, for as long as it exists. -- 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 Eike.Ziller at qt.io Thu Jun 2 14:30:22 2016 From: Eike.Ziller at qt.io (Eike Ziller) Date: Thu, 2 Jun 2016 12:30:22 +0000 Subject: [Development] Video playback on Ubuntu 16.04 In-Reply-To: <764632272.5971424.1464861809859.JavaMail.yahoo@mail.yahoo.com> References: <2133812746.5764153.1464855428416.JavaMail.yahoo.ref@mail.yahoo.com> <2133812746.5764153.1464855428416.JavaMail.yahoo@mail.yahoo.com> <1716093.jcrfbDzTWn@serj-laptop> <764632272.5971424.1464861809859.JavaMail.yahoo@mail.yahoo.com> Message-ID: <426B594E-4AC5-437A-8BBA-CD29CE1A1C68@qt.io> > On Jun 2, 2016, at 12:03 PM, Massimo Callegari via Development wrote: > > 1) Ubuntu 16.04 delivers Qt 5.5.1 > 2) I am using Qt 5.6.0 official release (Linux x64). Not some PPA, nor Ubuntu stuff. > https://bugreports.qt.io/browse/QTBUG-53668 ? Br, Eike > > ----- Messaggio originale ----- > Da: Sergio Martins > A: development at qt-project.org; Massimo Callegari > Inviato: Giovedì 2 Giugno 2016 12:00 > Oggetto: Re: [Development] Video playback on Ubuntu 16.04 > > On Thursday, 2 June 2016 08:17:08 WEST Massimo Callegari via Development > wrote: >> Hi everyone, >> >> is it just me or QtMultimedia 5.6.0 video playback is quite broken on Ubuntu >> 16.04 ? >> >> I think the reason is that Qt 5.6.0 (and 5.7.0 as well) are still built >> against gstreamer 0.10, which is quite obsolete now. In fact, I built Qt >> 5.7.0 myself with gstreamer 1.0 and video playback works as expected. > > > Hi, > > + -gstreamer Enable GStreamer support > With no parameter, this will attempt to auto-detect GStreamer 0.10 and > 1.0. GStreamer 1.0 is used by default when available. Use 0.10 or 1.0 for > to override auto-detection. > > 1.0 is the default since Qt 5.6, so it's probably an Ubuntu issue. > > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From massimocallegari at yahoo.it Thu Jun 2 14:41:02 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Thu, 2 Jun 2016 12:41:02 +0000 (UTC) Subject: [Development] Video playback on Ubuntu 16.04 In-Reply-To: <426B594E-4AC5-437A-8BBA-CD29CE1A1C68@qt.io> References: <2133812746.5764153.1464855428416.JavaMail.yahoo.ref@mail.yahoo.com> <2133812746.5764153.1464855428416.JavaMail.yahoo@mail.yahoo.com> <1716093.jcrfbDzTWn@serj-laptop> <764632272.5971424.1464861809859.JavaMail.yahoo@mail.yahoo.com> <426B594E-4AC5-437A-8BBA-CD29CE1A1C68@qt.io> Message-ID: <1902821428.6166992.1464871262269.JavaMail.yahoo@mail.yahoo.com> Yes ! That's it. Thanks Eike. My request is toward 5.7.0 though. Targeting 5.8 means other 6 months of broken videos :) ----- Messaggio originale ----- Da: Eike Ziller A: Massimo Callegari Cc: Sergio Martins ; "development at qt-project.org" Inviato: Giovedì 2 Giugno 2016 14:30 Oggetto: Re: [Development] Video playback on Ubuntu 16.04 > On Jun 2, 2016, at 12:03 PM, Massimo Callegari via Development wrote: > > 1) Ubuntu 16.04 delivers Qt 5.5.1 > 2) I am using Qt 5.6.0 official release (Linux x64). Not some PPA, nor Ubuntu stuff. > https://bugreports.qt.io/browse/QTBUG-53668 ? Br, Eike > > ----- Messaggio originale ----- > Da: Sergio Martins > A: development at qt-project.org; Massimo Callegari > Inviato: Giovedì 2 Giugno 2016 12:00 > Oggetto: Re: [Development] Video playback on Ubuntu 16.04 > > On Thursday, 2 June 2016 08:17:08 WEST Massimo Callegari via Development > wrote: >> Hi everyone, >> >> is it just me or QtMultimedia 5.6.0 video playback is quite broken on Ubuntu >> 16.04 ? >> >> I think the reason is that Qt 5.6.0 (and 5.7.0 as well) are still built >> against gstreamer 0.10, which is quite obsolete now. In fact, I built Qt >> 5.7.0 myself with gstreamer 1.0 and video playback works as expected. > > > Hi, > > + -gstreamer Enable GStreamer support > With no parameter, this will attempt to auto-detect GStreamer 0.10 and > 1.0. GStreamer 1.0 is used by default when available. Use 0.10 or 1.0 for > to override auto-detection. > > 1.0 is the default since Qt 5.6, so it's probably an Ubuntu issue. > > > Regards, > -- > Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From thiago.macieira at intel.com Thu Jun 2 14:58:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 02 Jun 2016 09:58:38 -0300 Subject: [Development] Supported platforms for Qt 5.8 In-Reply-To: <201606021159.21757.marc.mutz@kdab.com> References: <93206D18-A127-4580-90B1-1AA857AE023F@theqtcompany.com> <26003352.DV2JlzaxBy@tjmaciei-mobl4> <201606021159.21757.marc.mutz@kdab.com> Message-ID: <8189148.gBCNoyrnZL@tjmaciei-mobl1> On quinta-feira, 2 de junho de 2016 11:59:20 BRT Marc Mutz wrote: > On Saturday 20 February 2016 19:04:18 Thiago Macieira wrote: > > It would buy us, if we raised to GCC 4.8 too: > > - deleted and defaulted members > > > > (nsdmi, delegating constructors, template aliases require GCC 4.7) > > According to qcompilerdetection.h, deleted and defaulted members are > available from GCC 4.6 on up. > > Do you have other information? Does qcd.h need adjustments? No, I always use qcd.h. It's more likely I misread it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tobiashaslop at hotmail.de Thu Jun 2 15:55:36 2016 From: tobiashaslop at hotmail.de (Tobias Haslop) Date: Thu, 2 Jun 2016 13:55:36 +0000 Subject: [Development] No way to set the framerate of QCamera Message-ID: Hello, I want to implement a backend for SVS-Vistek Gigabit Ethernet cameras, but I see no way to set the camera's framerate. There is the FrameRateRange, but I am not sure about its meaning: Does setting a framerate range guarantee for each consecutive frame to arrive in a certain timespan? Or does a supported framerate range mean that framerates in that range can be set? My intuition was the latter, but after not being able to find a hint how to set the framerate I am starting to believe it is the first meaning. The SVS-Vistek API allows me to query framerate range and step as well as to set the framerate directly and I do not want to miss that ability. I guess adding a custom control to set the framerate is an option for me, but before I do that I want to be sure that I did not miss anything. Thanks, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From tobiashaslop at hotmail.de Thu Jun 2 16:02:31 2016 From: tobiashaslop at hotmail.de (Tobias Haslop) Date: Thu, 2 Jun 2016 14:02:31 +0000 Subject: [Development] No way to set the framerate of QCamera In-Reply-To: References: Message-ID: Nevermind, for some reason I was not able to read the docs properly: If the minimum frame rate is equal to the maximum frame rate, the frame rate is fixed. If not, the actual frame rate fluctuates between the minimum and the maximum. Sorry ________________________________ From: Tobias Haslop Sent: Thursday, June 2, 2016 3:55 PM To: development at qt-project.org Subject: No way to set the framerate of QCamera Hello, I want to implement a backend for SVS-Vistek Gigabit Ethernet cameras, but I see no way to set the camera's framerate. There is the FrameRateRange, but I am not sure about its meaning: Does setting a framerate range guarantee for each consecutive frame to arrive in a certain timespan? Or does a supported framerate range mean that framerates in that range can be set? My intuition was the latter, but after not being able to find a hint how to set the framerate I am starting to believe it is the first meaning. The SVS-Vistek API allows me to query framerate range and step as well as to set the framerate directly and I do not want to miss that ability. I guess adding a custom control to set the framerate is an option for me, but before I do that I want to be sure that I did not miss anything. Thanks, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Thu Jun 2 16:06:05 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 2 Jun 2016 14:06:05 +0000 Subject: [Development] g++ 5.2.1 compiler bug In-Reply-To: References: Message-ID: On 2nd June 2016 at 13:32, Milla Pohjanheimo mentioned > We bumped into a compiler bug specific for g++ 5.2.1 ... > There are issues with gcc 4.9.2 also ... and asked > What do you think, where is the best place to document these issues? > Is it > supported platforms page, This should, at least, link to wherever we list complications like this, since they do affect platform support, in so far as the buggy compiler might be in use on any given platform. * https://wiki.qt.io/Supported_Platforms I am unable to edit the main page - I suggest whoever can should link to that from it ! Possibly under the General heading in the right column below the Quick Access portal. > page that lists X11 requirements, Seems rather sideways to relevant; this isn't about X11, it's about our compilation tool-chain. I could not, in any case, find such a page. [[Supported Platforms]] should link to it, if it exists. > some known issues page Well, it *is* a known issue. So if we don't have a "known issues with tool-chains" or "known issues with gcc" page, creating one for this would make sense. I failed to find any such pages. https://wiki.qt.io/index.php?search="known+issue" found some pages to which such a page should link, if one exists or gets created. That page should itself be linked from [[Supported Platforms]]. > or something else? Probably best to go with known issues, or possibly a section of the [[Supported Platforms]] page given over to this topic. Wherever it ends up, any and all such pages should be more easily find-able from the Wiki main page; Wikis have a tendency to contain many perls of useful information hidden from the world by a lack of suitable linkage. Their author knows what phrase to search for to find them, so confidently tells folk it's on the wiki, but others are less likely to stumble upon it. Eddy. From thiago.macieira at intel.com Thu Jun 2 15:02:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 02 Jun 2016 10:02:14 -0300 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: References: <6d1d5e1f-f9ae-4bd7-97d3-288fb81e545d@gmail.com> Message-ID: <6606475.OVlacRMt22@tjmaciei-mobl1> On quinta-feira, 2 de junho de 2016 11:42:27 BRT Alexander Blasche wrote: > Certain error cases can only be detected if you make assumptions about > timeouts. Otherwise there is no way to determine where one packet stops and > where the next one begins. You can't do that with timing on a non-real-time task. Forget it. If this bus requires that, make sure to do the packet splitting in a real-time *kernel* task. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From denis.shienkov at gmail.com Thu Jun 2 16:53:49 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 2 Jun 2016 17:53:49 +0300 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: <6606475.OVlacRMt22@tjmaciei-mobl1> References: <6d1d5e1f-f9ae-4bd7-97d3-288fb81e545d@gmail.com> <6606475.OVlacRMt22@tjmaciei-mobl1> Message-ID: > You can't do that with timing on a non-real-time task. Quite so! The Modbus spec has been written for the PLC's, where are used the Real-Time OS (or for 'bare metal' hardwares). I have added some ideas, how to avoid it to QTBUG-53767 BR, Denis 2016-06-02 16:02 GMT+03:00 Thiago Macieira : > On quinta-feira, 2 de junho de 2016 11:42:27 BRT Alexander Blasche wrote: > > Certain error cases can only be detected if you make assumptions about > > timeouts. Otherwise there is no way to determine where one packet stops > and > > where the next one begins. > > You can't do that with timing on a non-real-time task. Forget it. > > If this bus requires that, make sure to do the packet splitting in a > real-time > *kernel* task. > > -- > 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 Karsten.Heimrich at qt.io Thu Jun 2 21:13:57 2016 From: Karsten.Heimrich at qt.io (Karsten Heimrich) Date: Thu, 2 Jun 2016 19:13:57 +0000 Subject: [Development] modbus over serial port on windows 7 ? In-Reply-To: References: <6d1d5e1f-f9ae-4bd7-97d3-288fb81e545d@gmail.com> <6606475.OVlacRMt22@tjmaciei-mobl1>, Message-ID: Hi, just a short note, we already added API for overwriting the timeout in 5.7. See http://doc-snapshots.qt.io/qt5-5.7/qmodbusrtuserialmaster.html#setInterFrameDelay But as seen here http://code.qt.io/cgit/qt/qtserialbus.git/tree/src/serialbus/qmodbusrtuserialmaster_p.h#n294 we missed to update some parts. --Karsten ________________________________ From: Development on behalf of Denis Shienkov Sent: Thursday, June 2, 2016 4:53:49 PM Cc: development at qt-project.org Subject: Re: [Development] modbus over serial port on windows 7 ? > You can't do that with timing on a non-real-time task. Quite so! The Modbus spec has been written for the PLC's, where are used the Real-Time OS (or for 'bare metal' hardwares). I have added some ideas, how to avoid it to QTBUG-53767 BR, Denis 2016-06-02 16:02 GMT+03:00 Thiago Macieira >: On quinta-feira, 2 de junho de 2016 11:42:27 BRT Alexander Blasche wrote: > Certain error cases can only be detected if you make assumptions about > timeouts. Otherwise there is no way to determine where one packet stops and > where the next one begins. You can't do that with timing on a non-real-time task. Forget it. If this bus requires that, make sure to do the packet splitting in a real-time *kernel* task. -- 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 apoenitz at t-online.de Thu Jun 2 21:39:01 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 2 Jun 2016 21:39:01 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> Message-ID: <20160602193900.GA1461@klara.mpi.htwm.de> On Wed, Jun 01, 2016 at 02:57:27PM +0200, Dominik Holland wrote: > +1 for changing they coding style -1 for anything that's not applied uniformly within a reasonably short time to the whole codebase. More often than not I really don't care too much *what* the change is, but I am getting sick of seeing more and more ways being introduced to express the same thing within the same module, or even within the same file. I appreciate that it sometimes spares me from running a 'git blame', because it's rather clear who touched the code last and what time that was approximately, but overall I am very much in favour of a *uniform* code base, and I'd pretty much prefer to *not* know who wrote a certain stanza before running 'git blame'. Since we are at the topic of "ongoing underground movements": IMNSHO there is by now way too much of that going on, and that's not only about coding style in a few .cpp, but also about general design patterns used and public API. For me, covenient and reasonably uniform API and implementation used to be Qt's second major selling point besides platform independence. Right now I believe that "underground movements" and the current system of any approximately two out of a few hundred people being able to change random bits to random values does not work into the direction of preserving that. >From the four possible combinations of { "people stick to agreed rules" , "people play around" } x { "lots of people can submit", "tightly controled approval" } the "people play around"-and-"lots of people can submit" case is the least viable one long term. Andre' From apoenitz at t-online.de Thu Jun 2 21:47:17 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 2 Jun 2016 21:47:17 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <1565127.n0exVmCJzs@oscar> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> <1565127.n0exVmCJzs@oscar> Message-ID: <20160602194717.GB1461@klara.mpi.htwm.de> On Wed, Jun 01, 2016 at 03:36:43PM +0200, Olivier Goffart wrote: > On Mittwoch, 1. Juni 2016 12:56:12 CEST Simon Hausmann wrote: > > Hi, > > > > I'm in favorof changing our coding style to adopt the model you call "butt > > ugly" because I find it more appealing and I find that it makes diffs > > easier to read. > > > > Simon > > +1 as well, if someone counts the votes! Why would anyone bother to count votes before any (theoretically binding or non-binding, doesn't seem to matter) result of voting gets ignored by the next submitter anyway? Andre' From mandeepsandhu.chd at gmail.com Thu Jun 2 21:56:26 2016 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Thu, 2 Jun 2016 12:56:26 -0700 Subject: [Development] commas in ctor-init-lists In-Reply-To: <20160602194717.GB1461@klara.mpi.htwm.de> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> <1565127.n0exVmCJzs@oscar> <20160602194717.GB1461@klara.mpi.htwm.de> Message-ID: > > Why would anyone bother to count votes before any (theoretically binding > or non-binding, doesn't seem to matter) result of voting gets ignored by > the next submitter anyway? I think the votes are meant for 'ratifying' the coding guidelines. And the hope that submitters _will_ follow the rules mentioned there. If not following the guidelines is a common occurrence, then that warrants a separate discussion. -mandeep > > Andre' > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kde at carewolf.com Fri Jun 3 02:02:55 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 3 Jun 2016 02:02:55 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606011441.31348.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> Message-ID: <201606030202.55936.kde@carewolf.com> On Wednesday 01 June 2016, Marc Mutz wrote: > Hi, > > There seems to have been a silent underground move to uglify the Qt sources > , by using commas to introduce lines > . I have no idea where this came from > I am probably one of those introducing it since it comes from WebKit coding style. Sorry, I also think it is kind of ugly, but it is very structurally clean and in some circumstances I prefer it due to that. Note there is a related coding style violation for if statements. if (blabla || lala || justDoIt) { doIt(); } This has the same benefits for diffs as the leading comma, though I mainly use it to avoid the sub-expressions of the if statements to indent the same as statements inside the if-block. This helps again make the code faster and easier to read at glance, though it violates Qt coding style. `Allan From Martin.Smith at qt.io Fri Jun 3 08:28:19 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 3 Jun 2016 06:28:19 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606030202.55936.kde@carewolf.com> References: <201606011441.31348.marc.mutz@kdab.com>, <201606030202.55936.kde@carewolf.com> Message-ID: >but it is very structurally clean and in some circumstances I prefer it due to that. The structure is a comma separated list. Historically, the comma has always been placed directly after the first of two list items. The comma tells the reader that another list item will follow. There is nothing to clean. Note the comma I used appeared right after the word "Historically," as did that one, and that one appeared right after the word "none." The comma has never appeared as the first character of anything. >Note there is a related coding style violation for if statements. The relationship is tenuous. '||' is an operator, ',' is a separator. '||' represents a word to the reader ( "or"). The comma doesn't represent a word. >This has the same benefits for diffs as the leading comma, Is "diff noise" really a thing? If it is, why doesn't someone rewrite diff with an option to suppress it? ________________________________________ From: Development on behalf of Allan Sandfeld Jensen Sent: Friday, June 3, 2016 2:02:55 AM To: development at qt-project.org Subject: Re: [Development] commas in ctor-init-lists On Wednesday 01 June 2016, Marc Mutz wrote: > Hi, > > There seems to have been a silent underground move to uglify the Qt sources > , by using commas to introduce lines > . I have no idea where this came from > I am probably one of those introducing it since it comes from WebKit coding style. Sorry, I also think it is kind of ugly, but it is very structurally clean and in some circumstances I prefer it due to that. Note there is a related coding style violation for if statements. if (blabla || lala || justDoIt) { doIt(); } This has the same benefits for diffs as the leading comma, though I mainly use it to avoid the sub-expressions of the if statements to indent the same as statements inside the if-block. This helps again make the code faster and easier to read at glance, though it violates Qt coding style. `Allan _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From andre at familiesomers.nl Fri Jun 3 08:45:29 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 3 Jun 2016 08:45:29 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> Message-ID: <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> Hi, Op 03/06/2016 om 08:28 schreef Martin Smith: >> but it is very structurally clean and in some circumstances I prefer it due to that. > The structure is a comma separated list. Historically, the comma has always been placed directly after the first of two list items. The comma tells the reader that another list item will follow. There is nothing to clean. Note the comma I used appeared right after the word "Historically," as did that one, and that one appeared right after the word "none." The comma has never appeared as the first character of anything. > >> Note there is a related coding style violation for if statements. > The relationship is tenuous. '||' is an operator, ',' is a separator. '||' represents a word to the reader ( "or"). The comma doesn't represent a word. Well, if we go that way, lists of conditions are often written like this: You can do this, given: * You bla, or * You boo, or * You foo Note the position of the or. Does that mean that the equivalent C++ should look like this: if ( bla || boo || foo ) { //we can debate the position of the opening brace here as well... do this... } No. I think this drawing of parallels with natural language formatting is not very productive. Code is not natural language and we should not apply the same formatting rules to them. > >> This has the same benefits for diffs as the leading comma, > Is "diff noise" really a thing? If it is, why doesn't someone rewrite diff with an option to suppress it? Ehhh? The diff is there and is significant, isn't it? So it should not be suppressed unlike some stray white space differences. Anyway, I am all for using an auto-formatter. I think they are good enough nowadays. They may not in every circumstance generate the absolute most beautiful layout, but it saves a huge amount of time not having to care for it anymore, not getting style^Hformatting related -1's from the CI any more and not having to debate it any more. So I think it is well worth the loss of prefered formatting here and there. And yes, you can use your own prefered format locally if you please, as long as it gets reformatted to the standard one on submission. Sounds ideal to me. André From andre at familiesomers.nl Fri Jun 3 08:47:47 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 3 Jun 2016 08:47:47 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <20160602194717.GB1461@klara.mpi.htwm.de> References: <201606011441.31348.marc.mutz@kdab.com> <9a79ea8c-f952-4895-867f-c1072ecc7cd4@qt.io> <1565127.n0exVmCJzs@oscar> <20160602194717.GB1461@klara.mpi.htwm.de> Message-ID: <347155c1-aad5-15fd-9af5-7c1b91748595@familiesomers.nl> Op 02/06/2016 om 21:47 schreef André Pönitz: > On Wed, Jun 01, 2016 at 03:36:43PM +0200, Olivier Goffart wrote: >> On Mittwoch, 1. Juni 2016 12:56:12 CEST Simon Hausmann wrote: >>> Hi, >>> >>> I'm in favorof changing our coding style to adopt the model you call "butt >>> ugly" because I find it more appealing and I find that it makes diffs >>> easier to read. >>> >>> Simon >> +1 as well, if someone counts the votes! > Why would anyone bother to count votes before any (theoretically binding > or non-binding, doesn't seem to matter) result of voting gets ignored by > the next submitter anyway? > Well, if the rules would be encoded in a clang-format format that is used in a commit hook, that would not be an issue any more, would it? André From Martin.Smith at qt.io Fri Jun 3 08:52:20 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 3 Jun 2016 06:52:20 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> , <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> Message-ID: >You can do this, given: Nobody does that. We always write: * You bla, or you boo, or you foo, and in this case we would normally write: You bla, you boo, or you foo. Even better: You bla, boo, or foo. You are inventing problems that don't exist. ________________________________________ From: Development on behalf of André Somers Sent: Friday, June 3, 2016 8:45:29 AM To: development at qt-project.org Subject: Re: [Development] commas in ctor-init-lists Hi, Op 03/06/2016 om 08:28 schreef Martin Smith: >> but it is very structurally clean and in some circumstances I prefer it due to that. > The structure is a comma separated list. Historically, the comma has always been placed directly after the first of two list items. The comma tells the reader that another list item will follow. There is nothing to clean. Note the comma I used appeared right after the word "Historically," as did that one, and that one appeared right after the word "none." The comma has never appeared as the first character of anything. > >> Note there is a related coding style violation for if statements. > The relationship is tenuous. '||' is an operator, ',' is a separator. '||' represents a word to the reader ( "or"). The comma doesn't represent a word. Well, if we go that way, lists of conditions are often written like this: You can do this, given: * You bla, or * You boo, or * You foo Note the position of the or. Does that mean that the equivalent C++ should look like this: if ( bla || boo || foo ) { //we can debate the position of the opening brace here as well... do this... } No. I think this drawing of parallels with natural language formatting is not very productive. Code is not natural language and we should not apply the same formatting rules to them. > >> This has the same benefits for diffs as the leading comma, > Is "diff noise" really a thing? If it is, why doesn't someone rewrite diff with an option to suppress it? Ehhh? The diff is there and is significant, isn't it? So it should not be suppressed unlike some stray white space differences. Anyway, I am all for using an auto-formatter. I think they are good enough nowadays. They may not in every circumstance generate the absolute most beautiful layout, but it saves a huge amount of time not having to care for it anymore, not getting style^Hformatting related -1's from the CI any more and not having to debate it any more. So I think it is well worth the loss of prefered formatting here and there. And yes, you can use your own prefered format locally if you please, as long as it gets reformatted to the standard one on submission. Sounds ideal to me. André _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From andre at familiesomers.nl Fri Jun 3 09:25:18 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 3 Jun 2016 09:25:18 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> Message-ID: Op 03/06/2016 om 08:52 schreef Martin Smith: >> You can do this, given: > Nobody does that. We always write: * You bla, or you boo, or you foo, and in this case we would normally write: You bla, you boo, or you foo. Even better: You bla, boo, or foo. You are inventing problems that don't exist. > If you say so. So that means that our C++ code should look like this then? if (blah || boo || foo) { //no line breaking allowed something(); } What a load of nonsense. André From Martin.Smith at qt.io Fri Jun 3 09:43:22 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 3 Jun 2016 07:43:22 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> , Message-ID: >So that means that our C++ code should look like this then? >if (blah || boo || foo) { //no line breaking allowed In that case, yes, because the entire expression is short. And the ctor example that was used originally would also be on one line. Why not? Does the Qt coding standard require each expression to be on a separate line? I thought they should be on separate lines when the list is too long to be on a single line. martin ________________________________________ From: André Somers Sent: Friday, June 3, 2016 9:25:18 AM To: Martin Smith; development at qt-project.org Subject: Re: [Development] commas in ctor-init-lists Op 03/06/2016 om 08:52 schreef Martin Smith: >> You can do this, given: > Nobody does that. We always write: * You bla, or you boo, or you foo, and in this case we would normally write: You bla, you boo, or you foo. Even better: You bla, boo, or foo. You are inventing problems that don't exist. > If you say so. So that means that our C++ code should look like this then? if (blah || boo || foo) { //no line breaking allowed something(); } What a load of nonsense. André From edward.welbourne at qt.io Fri Jun 3 09:49:45 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 3 Jun 2016 07:49:45 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> , Message-ID: Martin: >> Nobody does that. We always write: * You bla, or you boo, or you foo, >> and in this case we would normally write: You bla, you boo, or you >> foo. Even better: You bla, boo, or foo. You are inventing problems >> that don't exist. yet, when the list items are too big to inline and a display list is used, I would most certainly have * first thing, * subsequent ... things, * penultimate thing or * final thing. with the or on the end of the penultimate entry. Our coding style asks for the equivalent of that "or" being on the start of the final thing. I can even argue for why that makes a certain sense - it *is* easy to miss that trailing "or" on the end of the penultimate item, which *can* make it harder for the reader to tell whether this is an or-list or an and-list. Yet I do in fact use the style just illustrated and would only use the other if I wanted to put particular emphasis on the "or". However, as others have pointed out, arguing by analogy with typographic practice in English is not really pertinent to the case in point. This is code; we put parentheses around things for quite different reasons than English text does and we use commas differently, too. André: > So that means that our C++ code should look like this then? > > if (blah || boo || foo) { //no line breaking allowed > something(); > } No. Our coding style quite explicitly says that you can split lines as long as the operator appears at the start of the line. I personally find that butt-ugly; but it's what our coding style mandates so I go along with it. Regularity makes for ease of reading, once you are familiar with the form being followed, as long as it's not too perversely bad - so I tolerate that every job I've ever had has obliged me to use a coding style I don't like. I can think of a case where that style was so bad it got in the way, but what we presently have as our coding style is half-way decent and that's good enough for me. There is too much diversity of preference for any coding style to be blessed in the eyes of all, so we live with a consensus all can endure. I do, however, like the suggestion that we formalise it all into a scriptable style that can be what the code gets mashed into on commit, with each developer free to mash into any style they like on checkout. Show me an implementation of that and I'll be happy to see the end of all flame-wars about code layout. Other than that, changing coding style just leads to inconsistency in the code-base; even a change to a style I prefer needs a stronger argument for it than "I prefer it" to get over the cost of the transitional phase with some code in the old style, some in the new. I'd sooner stick to a style I don't like but can read well enough than have the approved style keep changing. Eddy. From edward.welbourne at qt.io Fri Jun 3 09:54:43 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 3 Jun 2016 07:54:43 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> , , Message-ID: André >> So that means that our C++ code should look like this then? >> if (blah || boo || foo) { //no line breaking allowed Martin > In that case, yes, because the entire expression is short. And the > ctor example that was used originally would also be on one line. Why > not? Does the Qt coding standard require each expression to be on a > separate line? I thought they should be on separate lines when the > list is too long to be on a single line. Please allow that, in giving illustrations, short texts may be used as surrogates for tacitly long ones, so that if (blah || boo || foo) { some.code(); } is tacitly standing for if (somee.really(long.and.complicated, expression) || another.such(that, makes, the.line.too.long) || and.then.some.more()) { some.code(); } in examples - it gets boring to write the examples out in full like that and I would hope everyone is capable of interpolating the big long ugly expressions for which short tokens are used in illustrations. Eddy. From Martin.Smith at qt.io Fri Jun 3 10:00:26 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 3 Jun 2016 08:00:26 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> , , , Message-ID: >Please allow that, I do, of course. Andre didn't. He wrote... >> if (blah || boo || foo) { //no line breaking allowed ...with the comment. ________________________________________ From: Edward Welbourne Sent: Friday, June 3, 2016 9:54:43 AM To: Martin Smith; André Somers; development at qt-project.org Subject: Re: [Development] commas in ctor-init-lists André >> So that means that our C++ code should look like this then? >> if (blah || boo || foo) { //no line breaking allowed Martin > In that case, yes, because the entire expression is short. And the > ctor example that was used originally would also be on one line. Why > not? Does the Qt coding standard require each expression to be on a > separate line? I thought they should be on separate lines when the > list is too long to be on a single line. Please allow that, in giving illustrations, short texts may be used as surrogates for tacitly long ones, so that if (blah || boo || foo) { some.code(); } is tacitly standing for if (somee.really(long.and.complicated, expression) || another.such(that, makes, the.line.too.long) || and.then.some.more()) { some.code(); } in examples - it gets boring to write the examples out in full like that and I would hope everyone is capable of interpolating the big long ugly expressions for which short tokens are used in illustrations. Eddy. From edward.welbourne at qt.io Fri Jun 3 10:05:52 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 3 Jun 2016 08:05:52 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> , , , , Message-ID: I wrote: >> Please allow that, Martin: > I do, of course. Andre didn't. He wrote... >>> if (blah || boo || foo) { //no line breaking allowed > ...with the comment. I am fairly sure he did in fact mean if (somee.really(long.and.complicated, expression) || another.such(that, makes, the.line.too.long) || and.then.some.more()) and that he was, at that point, reading the earlier objection as meaning we wouldn't be allowed to split this line. I disagree - our coding style does allow splitting it as if (somee.really(long.and.complicated, expression) || another.such(that, makes, the.line.too.long) || and.then.some.more()) unless I misunderstood a rule I didn't like - but I'm fairly sure he did mean to use blah, boo and foo as metasyntactic variables. Please take a little time to read other folks' contributions charitably, rather than rushing to find fault with them. Eddy. From Martin.Smith at qt.io Fri Jun 3 10:07:02 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 3 Jun 2016 08:07:02 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> , , , , Message-ID: I think it would be instructive to hear the reasoning of the first engineer to add a ctor-init-list on separate lines with leading commas. I have been in the software engineering business since BEFORE Al Gore invented the internet, yet I have never been temped to start a line with a comma. What devious thinking would cause one to do that in the first place? martin ________________________________________ From: Development on behalf of Martin Smith Sent: Friday, June 3, 2016 10:00:26 AM To: Edward Welbourne; André Somers; development at qt-project.org Subject: Re: [Development] commas in ctor-init-lists >Please allow that, I do, of course. Andre didn't. He wrote... >> if (blah || boo || foo) { //no line breaking allowed ...with the comment. ________________________________________ From: Edward Welbourne Sent: Friday, June 3, 2016 9:54:43 AM To: Martin Smith; André Somers; development at qt-project.org Subject: Re: [Development] commas in ctor-init-lists André >> So that means that our C++ code should look like this then? >> if (blah || boo || foo) { //no line breaking allowed Martin > In that case, yes, because the entire expression is short. And the > ctor example that was used originally would also be on one line. Why > not? Does the Qt coding standard require each expression to be on a > separate line? I thought they should be on separate lines when the > list is too long to be on a single line. Please allow that, in giving illustrations, short texts may be used as surrogates for tacitly long ones, so that if (blah || boo || foo) { some.code(); } is tacitly standing for if (somee.really(long.and.complicated, expression) || another.such(that, makes, the.line.too.long) || and.then.some.more()) { some.code(); } in examples - it gets boring to write the examples out in full like that and I would hope everyone is capable of interpolating the big long ugly expressions for which short tokens are used in illustrations. Eddy. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at qt.io Fri Jun 3 10:14:38 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 3 Jun 2016 08:14:38 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> , , , , , Message-ID: > I think it would be instructive to hear the reasoning of the first > engineer to add a ctor-init-list on separate lines with leading > commas. I have been in the software engineering business since BEFORE > Al Gore invented the internet, yet I have never been temped to start a > line with a comma. What devious thinking would cause one to do that in > the first place? My earliest encounters with this style were well into the present millennium and I am fairly sure they were motivated by the relative ease of fitting with #if-ery near the end of an initializer list, as has been illustrated by a few advocates of this style. As a few others have commented, I found it perverse at first but got used to it fairly swiftly. I strongly suspect the #if-ery argument is what first prompted someone to want to do this, but I imagine the invention of this style is lost in the mists of time. Incidentally, the problem with this style at the start of an initializer list can usually be overcome by including a base-class construction explicitly, despite its being fatuous: Derived::Derived(type arg) : Base() // fatuous and unnecessary, but accommodates: #if FEEPING , creature(itis) #endif , etc(arg) Not that I wish to particularly advocate either side of the debate; I'd just rather both sides' cases were properly and clearly stated ... Eddy. From denis.shienkov at gmail.com Fri Jun 3 10:15:39 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 3 Jun 2016 11:15:39 +0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> Message-ID: Hi all, my personal opinion: e.g. I prefer a commas *before* the variable in ctor, because it simplifies editing of a code. e.g. {code} Foo::Foo() : a, b, c {code} when I need to remove the 'c' variable, I need to remove and the ',' after 'b' too. {code} Foo::Foo() : a , b , c {code} but here I need to remove only whole line ',c' .. :) Besides, it is consistent with : {code} int sum = a + b + c; bool result = a || b || c; {code} BR, Denis From Martin.Smith at qt.io Fri Jun 3 10:16:48 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 3 Jun 2016 08:16:48 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> , , , , , Message-ID: >I am fairly sure he did in fact mean Eddie, we should write with precision. That's kind of the point of this thread. Some are saying putting the comma on the next line is more precise; some are saying it isn't. But note that you didn't defend my argument the same way you are defending Andre's, yet his reply to me was explicitly absolute, where mine was not. martin ________________________________________ From: Edward Welbourne Sent: Friday, June 3, 2016 10:05:52 AM To: Martin Smith; André Somers; development at qt-project.org Subject: Re: [Development] commas in ctor-init-lists I wrote: >> Please allow that, Martin: > I do, of course. Andre didn't. He wrote... >>> if (blah || boo || foo) { //no line breaking allowed > ...with the comment. I am fairly sure he did in fact mean if (somee.really(long.and.complicated, expression) || another.such(that, makes, the.line.too.long) || and.then.some.more()) and that he was, at that point, reading the earlier objection as meaning we wouldn't be allowed to split this line. I disagree - our coding style does allow splitting it as if (somee.really(long.and.complicated, expression) || another.such(that, makes, the.line.too.long) || and.then.some.more()) unless I misunderstood a rule I didn't like - but I'm fairly sure he did mean to use blah, boo and foo as metasyntactic variables. Please take a little time to read other folks' contributions charitably, rather than rushing to find fault with them. Eddy. From Martin.Smith at qt.io Fri Jun 3 10:22:46 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 3 Jun 2016 08:22:46 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> , , , , , , Message-ID: >My earliest encounters with this style were well into the present >millennium and I am fairly sure they were motivated by the relative ease >of fitting with #if-ery near the end of an initializer list, as has been >illustrated by a few advocates of this style. Then why not just add a note to the Qt coding style saying that using the leading comma is allowed|recommended when using conditional compilation in a comma list? Why does it have to be uniform throughout the entire code base? Sometimes diffs are hard to read. martin ________________________________________ From: Edward Welbourne Sent: Friday, June 3, 2016 10:14:38 AM To: Martin Smith; André Somers; development at qt-project.org Subject: Re: [Development] commas in ctor-init-lists > I think it would be instructive to hear the reasoning of the first > engineer to add a ctor-init-list on separate lines with leading > commas. I have been in the software engineering business since BEFORE > Al Gore invented the internet, yet I have never been temped to start a > line with a comma. What devious thinking would cause one to do that in > the first place? My earliest encounters with this style were well into the present millennium and I am fairly sure they were motivated by the relative ease of fitting with #if-ery near the end of an initializer list, as has been illustrated by a few advocates of this style. As a few others have commented, I found it perverse at first but got used to it fairly swiftly. I strongly suspect the #if-ery argument is what first prompted someone to want to do this, but I imagine the invention of this style is lost in the mists of time. Incidentally, the problem with this style at the start of an initializer list can usually be overcome by including a base-class construction explicitly, despite its being fatuous: Derived::Derived(type arg) : Base() // fatuous and unnecessary, but accommodates: #if FEEPING , creature(itis) #endif , etc(arg) Not that I wish to particularly advocate either side of the debate; I'd just rather both sides' cases were properly and clearly stated ... Eddy. From Eike.Ziller at qt.io Fri Jun 3 10:42:20 2016 From: Eike.Ziller at qt.io (Eike Ziller) Date: Fri, 3 Jun 2016 08:42:20 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> Message-ID: <624A1CD0-53E4-4D34-8CBE-F242AF27ED7E@qt.io> > On Jun 3, 2016, at 10:07 AM, Martin Smith wrote: > > I think it would be instructive to hear the reasoning of the first engineer to add a ctor-init-list on separate lines with leading commas. I have been in the software engineering business since BEFORE Al Gore invented the internet, yet I have never been temped to start a line with a comma. > What devious thinking would cause one to do that in the first place? Why devious? Let’s have a look at the advantages of both styles: comma at the end: * feels more natural wrt natural languages comma at the start: * better visual alignment together with the : and , all at the start * easier diff when adding something at the end (which is commonly done) * easier rearrangement when it involves the last item * easier ifdef’ing of individual items The advantages of the one are the disadvantages of the other. So some people argue that “feels more natural” overweighs the perceived small advantages of comma at the start. And some other people argue that coding has not much to do with natural languages anyhow, the “small” advantages are worth the change, and it doesn’t feel unnatural anymore after getting used to it. > Then why not just add a note to the Qt coding style saying that using the leading comma is allowed|recommended when using conditional compilation in a comma list? Why does it have to be uniform throughout the entire code base? Sometimes diffs are hard to read. Possibly because for some people consistency is of higher value. (Disclaimer: I personally really don’t care which style is taken.) Br, Eike > martin > > ________________________________________ > From: Development on behalf of Martin Smith > Sent: Friday, June 3, 2016 10:00:26 AM > To: Edward Welbourne; André Somers; development at qt-project.org > Subject: Re: [Development] commas in ctor-init-lists > >> Please allow that, > > I do, of course. Andre didn't. He wrote... > >>> if (blah || boo || foo) { //no line breaking allowed > > ...with the comment. > > ________________________________________ > From: Edward Welbourne > Sent: Friday, June 3, 2016 9:54:43 AM > To: Martin Smith; André Somers; development at qt-project.org > Subject: Re: [Development] commas in ctor-init-lists > > André >>> So that means that our C++ code should look like this then? >>> if (blah || boo || foo) { //no line breaking allowed > > Martin >> In that case, yes, because the entire expression is short. And the >> ctor example that was used originally would also be on one line. Why >> not? Does the Qt coding standard require each expression to be on a >> separate line? I thought they should be on separate lines when the >> list is too long to be on a single line. > > Please allow that, in giving illustrations, short texts may be used as > surrogates for tacitly long ones, so that > > if (blah > || boo > || foo) { > some.code(); > } > > is tacitly standing for > > if (somee.really(long.and.complicated, expression) > || another.such(that, makes, the.line.too.long) > || and.then.some.more()) { > some.code(); > } > > in examples - it gets boring to write the examples out in full like that > and I would hope everyone is capable of interpolating the big long ugly > expressions for which short tokens are used in illustrations. > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From announce at qt-project.org Fri Jun 3 11:16:52 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Fri, 3 Jun 2016 09:16:52 +0000 Subject: [Development] [Announce] Qt 5.7.0 RC released Message-ID: Hi all, Qt 5.7.0 RC is now released, see http://blog.qt.io/blog/2016/06/03/qt-5-7-0-release-candidate-available/ Big thanks to everyone involved! br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From Martin.Smith at qt.io Fri Jun 3 13:01:17 2016 From: Martin.Smith at qt.io (Martin Smith) Date: Fri, 3 Jun 2016 11:01:17 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <624A1CD0-53E4-4D34-8CBE-F242AF27ED7E@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> , <624A1CD0-53E4-4D34-8CBE-F242AF27ED7E@qt.io> Message-ID: >Why devious? Because every human being learns from an early age that when forming a list of words separated by commas, each comma is placed immediately after the word. Putting the comma at the start is a deviation from what every human being first learned. No human being on the planet was taught to put a comma at the beginning of a line. But this is not an issue of readability or feeling natural. The three formats are equally readable. One can even argue that if the list is long, the single line format is less readable than either of the multiple line formats. Nor should the auto-indent feature of your favorite editor have any sway. My editor handles either multi-line format with ease. If yours can't, get better one. So we really just have the conditional compilation issue and the diff noise issue. These are valid issues. So, here is a simple Qt coding style guideline. In a comma list, be consistent about where the comma is placed. Either place it immediately after each list item (comma-last), or at the start of each line (comma-first). When using conditional compilation in a comma-last list, change the entire list to be comma-first. Once a list becomes comma-first, never change it to comma-last, even when the conditional compilation is removed. martin ________________________________________ From: Eike Ziller Sent: Friday, June 3, 2016 10:42:20 AM To: Martin Smith Cc: Edward Welbourne; André Somers; development at qt-project.org Subject: Re: [Development] commas in ctor-init-lists > On Jun 3, 2016, at 10:07 AM, Martin Smith wrote: > > I think it would be instructive to hear the reasoning of the first engineer to add a ctor-init-list on separate lines with leading commas. I have been in the software engineering business since BEFORE Al Gore invented the internet, yet I have never been temped to start a line with a comma. > What devious thinking would cause one to do that in the first place? Why devious? Let’s have a look at the advantages of both styles: comma at the end: * feels more natural wrt natural languages comma at the start: * better visual alignment together with the : and , all at the start * easier diff when adding something at the end (which is commonly done) * easier rearrangement when it involves the last item * easier ifdef’ing of individual items The advantages of the one are the disadvantages of the other. So some people argue that “feels more natural” overweighs the perceived small advantages of comma at the start. And some other people argue that coding has not much to do with natural languages anyhow, the “small” advantages are worth the change, and it doesn’t feel unnatural anymore after getting used to it. > Then why not just add a note to the Qt coding style saying that using the leading comma is allowed|recommended when using conditional compilation in a comma list? Why does it have to be uniform throughout the entire code base? Sometimes diffs are hard to read. Possibly because for some people consistency is of higher value. (Disclaimer: I personally really don’t care which style is taken.) Br, Eike > martin > > ________________________________________ > From: Development on behalf of Martin Smith > Sent: Friday, June 3, 2016 10:00:26 AM > To: Edward Welbourne; André Somers; development at qt-project.org > Subject: Re: [Development] commas in ctor-init-lists > >> Please allow that, > > I do, of course. Andre didn't. He wrote... > >>> if (blah || boo || foo) { //no line breaking allowed > > ...with the comment. > > ________________________________________ > From: Edward Welbourne > Sent: Friday, June 3, 2016 9:54:43 AM > To: Martin Smith; André Somers; development at qt-project.org > Subject: Re: [Development] commas in ctor-init-lists > > André >>> So that means that our C++ code should look like this then? >>> if (blah || boo || foo) { //no line breaking allowed > > Martin >> In that case, yes, because the entire expression is short. And the >> ctor example that was used originally would also be on one line. Why >> not? Does the Qt coding standard require each expression to be on a >> separate line? I thought they should be on separate lines when the >> list is too long to be on a single line. > > Please allow that, in giving illustrations, short texts may be used as > surrogates for tacitly long ones, so that > > if (blah > || boo > || foo) { > some.code(); > } > > is tacitly standing for > > if (somee.really(long.and.complicated, expression) > || another.such(that, makes, the.line.too.long) > || and.then.some.more()) { > some.code(); > } > > in examples - it gets boring to write the examples out in full like that > and I would hope everyone is capable of interpolating the big long ugly > expressions for which short tokens are used in illustrations. > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From ulf.hermann at qt.io Fri Jun 3 13:05:10 2016 From: ulf.hermann at qt.io (Ulf Hermann) Date: Fri, 3 Jun 2016 13:05:10 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606030202.55936.kde@carewolf.com> <1f97a9de-1ca6-059f-e96c-d349d76b8fd6@familiesomers.nl> <624A1CD0-53E4-4D34-8CBE-F242AF27ED7E@qt.io> Message-ID: <57516466.701@qt.io> On 06/03/2016 01:01 PM, Martin Smith wrote: > Because every human being learns from an early age that when forming a list of words separated by commas, each comma is placed immediately after the word. Putting the comma at the start is a deviation from what every human being first learned. No human being on the planet was taught to put a comma at the beginning of a line. I think you are a western supremacist ;) Now the debate is over. From marc.mutz at kdab.com Fri Jun 3 13:53:55 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Jun 2016 13:53:55 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> Message-ID: <201606031353.57829.marc.mutz@kdab.com> On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: > if (somee.really(long.and.complicated, expression) || another.such(that, > makes, the.line.too.long) || and.then.some.more()) To be perfectly blunt: such expressions shouldn't be allowed. Period. Neither with nor without line breaks. Such monsters should be subjected to Extract Method with extreme prejudice. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From andre at familiesomers.nl Fri Jun 3 14:26:03 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 3 Jun 2016 14:26:03 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606031353.57829.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> Message-ID: <0d89b6d1-3e4c-c40d-93d0-e30f0b2d82ad@familiesomers.nl> Op 03/06/2016 om 13:53 schreef Marc Mutz: > On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: >> if (somee.really(long.and.complicated, expression) || another.such(that, >> makes, the.line.too.long) || and.then.some.more()) > To be perfectly blunt: such expressions shouldn't be allowed. Period. Neither > with nor without line breaks. Such monsters should be subjected to Extract > Method with extreme prejudice. > > Thanks, > Marc > Fine. Lets replace it with something like this then: if (theValue == MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue1 || theValue == MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue2 || theValue == MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue3) { } André From edward.welbourne at qt.io Fri Jun 3 14:50:08 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 3 Jun 2016 12:50:08 +0000 Subject: [Development] when to Extract Method (was Re: commas in ctor-init-lists) In-Reply-To: <201606031353.57829.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> , <201606031353.57829.marc.mutz@kdab.com> Message-ID: On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: >> if (somee.really(long.and.complicated, expression) || another.such(that, makes, the.line.too.long) || and.then.some.more()) Marc Mutz responded: > To be perfectly blunt: such expressions shouldn't be > allowed. Period. Neither with nor without line breaks. Such monsters > should be subjected to Extract Method with extreme prejudice. I'm fascinated - and we're now on a whole new topic - you mean this, even when the relevant combination of expressions is meaningless outside the one context in which it is used: an expression that combines three computed values with a binary operator is so complex it should be turned into a method ? Even if the three conditions are unrelated ? How about if all three are tested separately ? if (some.really(long.and.complicated, expression)) { // this one reason for an early return delete thing; return; } if (another.such(that, makes, the.line.too.long)) { // this quite different reason for it delete thing; return; } if (and.then.some.more()) { // a third quite different reasons delete thing; return; } I see lots of code like that. If combining them into if (some.really(long.and.complicated, expression) // this one reason for an early return // this quite different reason for it: || another.such(that, makes, the.line.too.long) // a third quite different reasons: || and.then.some.more()) { delete thing; return; } requires Extract Method, I suspect the method name is going to end up being too long to fit on a line, on account of being thisOneReasonOrThatQuiteDifferentReasonOrThatThirdReason(long, expression, that, makes, the, and, another, some); with lots of unrelated parameters in order to do its job. Well, I suppose its name could be shouldReturnEarlyFromOriginalMethod(...) instead; but I conclude that you actually prefer the three separate clauses, albeit in the extracted method, where each returns true, so that the calling code only has to do its tidy-up (and possibly other) code once. So, I'm fascinated: when is Extract Method the right pattern to apply ? I would normally reserve it for cases where it adds semantic clarity (by naming the condition concisely), avoids duplication or modularises an over-long method, Eddy. From marc.mutz at kdab.com Fri Jun 3 14:52:07 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Jun 2016 14:52:07 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <0d89b6d1-3e4c-c40d-93d0-e30f0b2d82ad@familiesomers.nl> References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> <0d89b6d1-3e4c-c40d-93d0-e30f0b2d82ad@familiesomers.nl> Message-ID: <201606031452.10195.marc.mutz@kdab.com> On Friday 03 June 2016 14:26:03 André Somers wrote: > Op 03/06/2016 om 13:53 schreef Marc Mutz: > > On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: > >> if (somee.really(long.and.complicated, expression) || > >> another.such(that, > >> > >> makes, the.line.too.long) || and.then.some.more()) > > > > To be perfectly blunt: such expressions shouldn't be allowed. Period. > > Neither with nor without line breaks. Such monsters should be subjected > > to Extract Method with extreme prejudice. > > > > Thanks, > > Marc > > Fine. Lets replace it with something like this then: > > if (theValue == > MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue1 || > theValue == > MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue2 || > theValue == > MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue3) { > > } Umm... same thing? What I'm saying is: - Multi-line conditions in if statements should *always* be refactored to a single function call. Then we don't need to talk about how to format multi-line ifs at all, because they do not exist anymore. Same goes for other expressions, too, really, but a free statement is much easier line-wrapped than an if, whose then-clause' opening brace is lost in complete noise with a multi-line if statement. I was also saying earlier, but it probably was overlooked: - Conditional compilation members should be initied by nsdmi (or placed in a struct with a default ctor that inits the values, so the member of struct type can be omitted from the ctor-init-list). And we can leave trailing comma ctor-init-lists in, because there will be no more conditional compilation in ctor-init-lists. And with a minimum of foresight, a class author will place a field last than can stay last, to accomodate new fields. Even the subset of C++11 features that we can use will make much of the argumentation for leading commas moot. Even more so if we find (qcd.h doesn't track it) that we can also use trailing comma in enums. We have the same problem in .pro files: QtC just appends new files, always creating a patch the churns the old-last line in SOURCES. If it would sort them in lexicographically, most additions would be one-liners. Here's an example (QLabel) which was problematic in the past because of the many preprocessor conditionals (attached). NSDMI doesn't work for bit-fields, but if I were to finish that patch, the bit fields would probably be replaced by a uint flags field. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-QLabelPrivate-use-nsdmi.patch Type: text/x-patch Size: 2855 bytes Desc: not available URL: From edward.welbourne at qt.io Fri Jun 3 14:58:01 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 3 Jun 2016 12:58:01 +0000 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606031452.10195.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> <0d89b6d1-3e4c-c40d-93d0-e30f0b2d82ad@familiesomers.nl>, <201606031452.10195.marc.mutz@kdab.com> Message-ID: Marc Mutz > We have the same problem in .pro files: QtC just appends new files, > always creating a patch the churns the old-last line in SOURCES. If it > would sort them in lexicographically, most additions would be > one-liners. Right - the "always add at end => always get conflict on merge" anti-pattern, whereas ordering things (members, files, fields, methods, whatever) in some coherent way related to their meaning or just simply dumbly alphabetically would mean additions typically happen all over the list, so contemporary changes seldom collide and merges are easy. But we digress, Eddy. From thiago.macieira at intel.com Fri Jun 3 14:57:49 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Jun 2016 09:57:49 -0300 Subject: [Development] when to Extract Method (was Re: commas in ctor-init-lists) In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> Message-ID: <2253454.5012HCTPGT@tjmaciei-mobl1> On sexta-feira, 3 de junho de 2016 12:50:08 BRT Edward Welbourne wrote: > > To be perfectly blunt: such expressions shouldn't be > > allowed. Period. Neither with nor without line breaks. Such monsters > > should be subjected to Extract Method with extreme prejudice. > > I'm fascinated - and we're now on a whole new topic - you mean this, > even when the relevant combination of expressions is meaningless outside > the one context in which it is used: an expression that combines three > computed values with a binary operator is so complex it should be turned > into a method ? Even if the three conditions are unrelated ? Another thing to be very, VERY careful is about nested function call chains, as in: if (foo(bar(), baz(quux()), variable, xyz()) == variable) Can you tell me if bar, baz, quux, or xyz modify variable? If so, what is the call order? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 3 14:55:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Jun 2016 09:55:09 -0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: <57516466.701@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <57516466.701@qt.io> Message-ID: <20163855.Z08aMDjka0@tjmaciei-mobl1> On sexta-feira, 3 de junho de 2016 13:05:10 BRT Ulf Hermann wrote: > On 06/03/2016 01:01 PM, Martin Smith wrote: > > Because every human being learns from an early age that when forming a > > list of words separated by commas, each comma is placed immediately after > > the word. Putting the comma at the start is a deviation from what every > > human being first learned. No human being on the planet was taught to put > > a comma at the beginning of a line. > I think you are a western supremacist Do you know of any language that even has a space before a comma? I know French requires a space before any punctuation consisting of more than one drawing (! ? ; and : all have two drawings), which means a comma is excluded from that and is placed right next to the previous word, without space. In English, that is so much so that it comes *inside* the closing quote of a quotation, even if the quotation did not have a comma there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 3 14:52:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Jun 2016 09:52:04 -0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: <624A1CD0-53E4-4D34-8CBE-F242AF27ED7E@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <624A1CD0-53E4-4D34-8CBE-F242AF27ED7E@qt.io> Message-ID: <1705775.pt7S3bMt8y@tjmaciei-mobl1> On sexta-feira, 3 de junho de 2016 08:42:20 BRT Eike Ziller wrote: > Why devious? > > Let’s have a look at the advantages of both styles: > > comma at the end: > > * feels more natural wrt natural languages > > comma at the start: > > * better visual alignment together with the : and , all at the start Alignment of the *comma* is not important. It's a small thing, just a few pixels tall. It's only there because we need to have it. What's important is the aligment of the variable names. Regardless of where you put the comma, the variable names will align. Therefore, I don't think the above is an argument. > * easier diff when adding something at the end (which is commonly done) True, though with intra-line and across-line diffs that Gerrit shows, this is minimised. It shows that the previous line was unmodified except for the comma. > * easier rearrangement when it involves the last item True, but same as above. > * easier ifdef’ing of individual items Only if it involves the last item. And since #ifdef is a sore eye anyway, using a sore-eye construction for the last item is not going to make it much worse. Please also note that this only applies to ctors with already-split lines. They often don't start like that. They often have a few variables and are initialised like: Foo::Foo() : i(0), status(None), enabled(false) { // ... } When that grows, it becomes: Foo::Foo() : QObject(*new FooPrivate), ptr(nullptr), i(0), status(None), enabled(false) { // ... } Besides, do we need a rule so that our if-else chains with #ifdef in the middle be nice too? I've seen a lot of code do: #ifdef FOO if (foo) { // something } else #endif if (bar) { // something else } else { // default } That if-else chain violates our coding standard. Should we adapt it so that it works with #if in the middle? I would prefer not. (there's trick you can do to minimise this; exercise left to the reader) > The advantages of the one are the disadvantages of the other. > > So some people argue that “feels more natural” overweighs the perceived > small advantages of comma at the start. > And some other people argue that > coding has not much to do with natural languages anyhow, the “small” > advantages are worth the change, and it doesn’t feel unnatural anymore > after getting used to it. Then let's insert a space *before* *every* comma! > > Then why not just add a note to the Qt coding style saying that using the > > leading comma is allowed|recommended when using conditional compilation > > in a comma list? Why does it have to be uniform throughout the entire > > code base? Sometimes diffs are hard to read. > > Possibly because for some people consistency is of higher value. Agreed. Consistency is important for me, which is why I reject patches to QtCore that contain leading commas. I only allow it if it is necessary because of #if, which already made it a sore-eye in the first place. That is, in QtCore, it's only allowed when strictly required. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Jun 3 14:59:12 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Jun 2016 14:59:12 +0200 Subject: [Development] when to Extract Method (was Re: commas in ctor-init-lists) In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> Message-ID: <201606031459.13819.marc.mutz@kdab.com> On Friday 03 June 2016 14:50:08 Edward Welbourne wrote: > On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: > >> if (somee.really(long.and.complicated, expression) || > >> another.such(that, makes, the.line.too.long) || and.then.some.more()) > > Marc Mutz responded: > > To be perfectly blunt: such expressions shouldn't be > > allowed. Period. Neither with nor without line breaks. Such monsters > > should be subjected to Extract Method with extreme prejudice. > > I'm fascinated - and we're now on a whole new topic - you mean this, > even when the relevant combination of expressions is meaningless outside > the one context in which it is used: an expression that combines three > computed values with a binary operator is so complex it should be turned > into a method ? Even if the three conditions are unrelated ? > > How about if all three are tested separately ? > > if (some.really(long.and.complicated, expression)) { > // this one reason for an early return > delete thing; > return; > } > > if (another.such(that, makes, the.line.too.long)) { > // this quite different reason for it > delete thing; > return; > } > > if (and.then.some.more()) { > // a third quite different reasons > delete thing; > return; > } > > I see lots of code like that. If combining them into > > if (some.really(long.and.complicated, expression) // this one reason for an > early return > > // this quite different reason for it: > || another.such(that, makes, the.line.too.long) > > // a third quite different reasons: > || and.then.some.more()) { > > delete thing; > return; > } > > requires Extract Method, I suspect the method name is going to end up > being too long to fit on a line, on account of being > > thisOneReasonOrThatQuiteDifferentReasonOrThatThirdReason(long, expression, > that, makes, the, and, another, some); > > with lots of unrelated parameters in order to do its job. Well, I > suppose its name could be shouldReturnEarlyFromOriginalMethod(...) > instead; but I conclude that you actually prefer the three separate > clauses, albeit in the extracted method, where each returns true, so > that the calling code only has to do its tidy-up (and possibly other) > code once. The three clauses should stay three clauses if the action (their then-block) is independent. If the then-block, as you seem to suggest, is idenitical in tokens and semantics, then you *will* find a name to describe it that doesn't just transliterate the original C++ code into English: shouldDeleteThing, thingIsExpired, isNoLongerNeeded(thing), ... > So, I'm fascinated: when is Extract Method the right pattern to apply ? > I would normally reserve it for cases where it adds semantic clarity (by > naming the condition concisely), avoids duplication or modularises an > over-long method, To say it with Fowler: It should be used whenever the original code Smells. Overly-long if statements Smell, imo. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From andre at familiesomers.nl Fri Jun 3 15:02:23 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 3 Jun 2016 15:02:23 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <201606031452.10195.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> <0d89b6d1-3e4c-c40d-93d0-e30f0b2d82ad@familiesomers.nl> <201606031452.10195.marc.mutz@kdab.com> Message-ID: <0a2fdcb7-5325-5abd-30bc-56588a4c79d5@familiesomers.nl> Op 03/06/2016 om 14:52 schreef Marc Mutz: > On Friday 03 June 2016 14:26:03 André Somers wrote: >> Op 03/06/2016 om 13:53 schreef Marc Mutz: >>> On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: >>>> if (somee.really(long.and.complicated, expression) || >>>> another.such(that, >>>> >>>> makes, the.line.too.long) || and.then.some.more()) >>> To be perfectly blunt: such expressions shouldn't be allowed. Period. >>> Neither with nor without line breaks. Such monsters should be subjected >>> to Extract Method with extreme prejudice. >>> >>> Thanks, >>> Marc >> Fine. Lets replace it with something like this then: >> >> if (theValue == >> MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue1 || >> theValue == >> MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue2 || >> theValue == >> MyNameSpace::MyLongAndComplicatedClassName::MyClassEnum::TheValue3) { >> >> } > Umm... same thing? > > What I'm saying is: > > - Multi-line conditions in if statements should *always* be refactored to a > single function call. > > Then we don't need to talk about how to format multi-line ifs at all, because > they do not exist anymore. Eh... So you move the same to a different method. How does that help? You'd basically get the same expression but then in a method of it's own? > [...] > > We have the same problem in .pro files: QtC just appends new files, always > creating a patch the churns the old-last line in SOURCES. If it would sort > them in lexicographically, most additions would be one-liners. I requested this quite a while ago already. André From edward.welbourne at qt.io Fri Jun 3 15:10:42 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 3 Jun 2016 13:10:42 +0000 Subject: [Development] when to Extract Method (was Re: commas in ctor-init-lists) In-Reply-To: <2253454.5012HCTPGT@tjmaciei-mobl1> References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> , <2253454.5012HCTPGT@tjmaciei-mobl1> Message-ID: Thiago Macieira > Another thing to be very, VERY careful is about nested function call > chains, as in: > > if (foo(bar(), baz(quux()), variable, xyz()) == variable) > > Can you tell me if bar, baz, quux, or xyz modify variable? If so, what > is the call order? If any of bar, baz, quux or xyz plausibly might modify variable, then this code has undefined behaviour - because the call order is undefined. (... except for quux() being called before baz; and baz, bar and xyz being called before foo, of course; the point in all that at which variable's value gets read is indeterminate, any which way.) Not that I see how this bears on whether that complex call to foo() should be extracted as a separate method, Eddy. From edward.welbourne at qt.io Fri Jun 3 15:14:13 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 3 Jun 2016 13:14:13 +0000 Subject: [Development] when to Extract Method (was Re: commas in ctor-init-lists) In-Reply-To: <201606031459.13819.marc.mutz@kdab.com> References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> , <201606031459.13819.marc.mutz@kdab.com> Message-ID: Marc Mutz > The three clauses should stay three clauses if the action (their > then-block) is independent. If the then-block, as you seem to suggest, > is idenitical in tokens and semantics, then you *will* find a name to > describe it that doesn't just transliterate the original C++ code into > English: shouldDeleteThing, thingIsExpired, isNoLongerNeeded(thing), > ... Just to be clear, my example code's delete thing was just using that as "there's some random tidy-up we need to do before any early return"; so the three conditions are all "we need to return early from this method" and the need to delete thing (which was nowhere referenced in any of the conditionals) is incidental to the test. In such a case I very much doubt there's a nice name for the method. Eddy. From thiago.macieira at intel.com Fri Jun 3 15:03:52 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Jun 2016 10:03:52 -0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606031452.10195.marc.mutz@kdab.com> Message-ID: <1850372.75z7yM8Qsd@tjmaciei-mobl1> On sexta-feira, 3 de junho de 2016 12:58:01 BRT Edward Welbourne wrote: > Right - the "always add at end => always get conflict on merge" You get conflict on merge if it was within three lines of the other change, regardless of where the commas were. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 3 15:19:26 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Jun 2016 10:19:26 -0300 Subject: [Development] when to Extract Method (was Re: commas in ctor-init-lists) In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <2253454.5012HCTPGT@tjmaciei-mobl1> Message-ID: <2870476.cMrmNZECBq@tjmaciei-mobl1> On sexta-feira, 3 de junho de 2016 13:10:42 BRT Edward Welbourne wrote: > Thiago Macieira > > > Another thing to be very, VERY careful is about nested function call > > > > chains, as in: > > if (foo(bar(), baz(quux()), variable, xyz()) == variable) > > > > Can you tell me if bar, baz, quux, or xyz modify variable? If so, what > > is the call order? > > If any of bar, baz, quux or xyz plausibly might modify variable, then > this code has undefined behaviour - because the call order is undefined. Exactly! > (... except for quux() being called before baz; and baz, bar and xyz > being called before foo, of course; the point in all that at which > variable's value gets read is indeterminate, any which way.) > > Not that I see how this bears on whether that complex call to foo() > should be extracted as a separate method, -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Jun 3 15:34:28 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Jun 2016 15:34:28 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <0a2fdcb7-5325-5abd-30bc-56588a4c79d5@familiesomers.nl> References: <201606011441.31348.marc.mutz@kdab.com> <201606031452.10195.marc.mutz@kdab.com> <0a2fdcb7-5325-5abd-30bc-56588a4c79d5@familiesomers.nl> Message-ID: <201606031534.29908.marc.mutz@kdab.com> On Friday 03 June 2016 15:02:23 André Somers wrote: > > Then we don't need to talk about how to format multi-line ifs at all, > > because they do not exist anymore. > > Eh... So you move the same to a different method. How does that help? > You'd basically get the same expression but then in a method of it's own? You have more freedom to format the code in the method. You can use a multi- line return statement, already an improvement over a multi-line if statement, or you can use guard clauses, possibly interspersed with comments... But the main advantage is that you replaced an ugly, unreadable construction with a *name*. We humans like to name things. E.g. I don't like unnamed lambdas. I think it's much preferable to assign a lambda to an auto variable than to inline it into the expression, precisely because it drives people crazy when they need to come up with a name (hi, Anton :). But that mental effort expended by that one person (and their reviewers, hi Eddy) is saved for everyone else (iff the name chosen is descriptive). As Fowler argues in Refactoring, sometimes the Smell is so bad that you Extract Method even if the result is longer _at the call site_ than the original code was. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Fri Jun 3 15:37:32 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Jun 2016 15:37:32 +0200 Subject: [Development] when to Extract Method (was Re: commas in ctor-init-lists) In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606031459.13819.marc.mutz@kdab.com> Message-ID: <201606031537.34295.marc.mutz@kdab.com> On Friday 03 June 2016 15:14:13 Edward Welbourne wrote: > Marc Mutz > > > The three clauses should stay three clauses if the action (their > > then-block) is independent. If the then-block, as you seem to suggest, > > is idenitical in tokens and semantics, then you *will* find a name to > > describe it that doesn't just transliterate the original C++ code into > > English: shouldDeleteThing, thingIsExpired, isNoLongerNeeded(thing), > > ... > > Just to be clear, my example code's delete thing was just using that as > "there's some random tidy-up we need to do before any early return"; so > the three conditions are all "we need to return early from this method" > and the need to delete thing (which was nowhere referenced in any of the > conditionals) is incidental to the test. In such a case I very much > doubt there's a nice name for the method. Ok, sorry, then I misunderstood. In that case: the thing should have been held in a scoped pointer and the three guard clauses should stay separate, but with just 'return' as the action. With the cleanup dealt with by RAII, I don't see a reason to combine the ifs anymore. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From olivier at woboq.com Fri Jun 3 15:37:12 2016 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 03 Jun 2016 15:37:12 +0200 Subject: [Development] when to Extract Method (was Re: commas in ctor-init-lists) In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> Message-ID: <3214288.tNC00nglJ6@maurice> On Freitag, 3. Juni 2016 12:50:08 CEST Edward Welbourne wrote: > On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: > >> if (somee.really(long.and.complicated, expression) || > >> another.such(that, makes, the.line.too.long) || and.then.some.more()) > Marc Mutz responded: > > To be perfectly blunt: such expressions shouldn't be > > allowed. Period. Neither with nor without line breaks. Such monsters > > should be subjected to Extract Method with extreme prejudice. > > I'm fascinated - and we're now on a whole new topic - you mean this, > even when the relevant combination of expressions is meaningless outside > the one context in which it is used: an expression that combines three > computed values with a binary operator is so complex it should be turned > into a method ? Even if the three conditions are unrelated ? > > How about if all three are tested separately ? > > if (some.really(long.and.complicated, expression)) { > // this one reason for an early return > delete thing; > return; > } > > if (another.such(that, makes, the.line.too.long)) { > // this quite different reason for it > delete thing; > return; > } > > if (and.then.some.more()) { > // a third quite different reasons > delete thing; > return; > } > > I see lots of code like that. If combining them into > > if (some.really(long.and.complicated, expression) // this one reason for an > early return > // this quite different reason for it: > || another.such(that, makes, the.line.too.long) > > // a third quite different reasons: > || and.then.some.more()) { > > delete thing; > return; > } > > requires Extract Method, I suspect the method name is going to end up > being too long to fit on a line, on account of being > > thisOneReasonOrThatQuiteDifferentReasonOrThatThirdReason(long, expression, > that, makes, the, and, another, some); > > with lots of unrelated parameters in order to do its job. Well, I > suppose its name could be shouldReturnEarlyFromOriginalMethod(...) > instead; but I conclude that you actually prefer the three separate > clauses, albeit in the extracted method, where each returns true, so > that the calling code only has to do its tidy-up (and possibly other) > code once. > > So, I'm fascinated: when is Extract Method the right pattern to apply ? > I would normally reserve it for cases where it adds semantic clarity (by > naming the condition concisely), avoids duplication or modularises an > over-long method, What i'd possibly do: bool alreadyComputed = some.really(long.and.complicated, expression); bool computationNeeded = another.such(that, makes, the.line.too.long) || and.then.some.more(); if (alreadyComputed || computationNeeded) { delete thing; return; } If the cost of calling the conditions function is neglectible enough that it can be done even if the first condition would be false. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From christian.kandeler at qt.io Fri Jun 3 15:59:34 2016 From: christian.kandeler at qt.io (Christian Kandeler) Date: Fri, 3 Jun 2016 15:59:34 +0200 Subject: [Development] commas in ctor-init-lists In-Reply-To: <1705775.pt7S3bMt8y@tjmaciei-mobl1> References: <201606011441.31348.marc.mutz@kdab.com> <624A1CD0-53E4-4D34-8CBE-F242AF27ED7E@qt.io> <1705775.pt7S3bMt8y@tjmaciei-mobl1> Message-ID: <5841ab5e-33d4-bbba-df17-0f3b720f56a1@qt.io> On 06/03/2016 02:52 PM, Thiago Macieira wrote: > I've seen a lot of code do: > > #ifdef FOO > if (foo) { > // something > } else > #endif > if (bar) { > // something else > } else { > // default > } This kind of thing is an abomination that should never ever be allowed, regardless of other coding style considerations. You can hardly even tell whether the code is syntactically correct in both cases, let alone semantics. Factor out ifdefs into dedicated functions whenever possible. You'll be glad you did, and even more so the people who have to read your code later. Christian From enmarantispam at gmail.com Fri Jun 3 15:59:44 2016 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 3 Jun 2016 16:59:44 +0300 Subject: [Development] when to Extract Method (was Re: commas in ctor-init-lists) In-Reply-To: <3214288.tNC00nglJ6@maurice> References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> <3214288.tNC00nglJ6@maurice> Message-ID: Or you could turn the second expression into a lamba for lazy evaluation and use it like bool computationNeeded = [](){ return another.such(that, makes, the.line.too.long) || and.then.some.more(); } if (alreadyComputed || computationNeeded()) On Fri, Jun 3, 2016 at 4:37 PM, Olivier Goffart wrote: > On Freitag, 3. Juni 2016 12:50:08 CEST Edward Welbourne wrote: > > On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: > > >> if (somee.really(long.and.complicated, expression) || > > >> another.such(that, makes, the.line.too.long) || > and.then.some.more()) > > Marc Mutz responded: > > > To be perfectly blunt: such expressions shouldn't be > > > allowed. Period. Neither with nor without line breaks. Such monsters > > > should be subjected to Extract Method with extreme prejudice. > > > > I'm fascinated - and we're now on a whole new topic - you mean this, > > even when the relevant combination of expressions is meaningless outside > > the one context in which it is used: an expression that combines three > > computed values with a binary operator is so complex it should be turned > > into a method ? Even if the three conditions are unrelated ? > > > > How about if all three are tested separately ? > > > > if (some.really(long.and.complicated, expression)) { > > // this one reason for an early return > > delete thing; > > return; > > } > > > > if (another.such(that, makes, the.line.too.long)) { > > // this quite different reason for it > > delete thing; > > return; > > } > > > > if (and.then.some.more()) { > > // a third quite different reasons > > delete thing; > > return; > > } > > > > I see lots of code like that. If combining them into > > > > if (some.really(long.and.complicated, expression) // this one reason for > an > > early return > > // this quite different reason for it: > > || another.such(that, makes, the.line.too.long) > > > > // a third quite different reasons: > > || and.then.some.more()) { > > > > delete thing; > > return; > > } > > > > requires Extract Method, I suspect the method name is going to end up > > being too long to fit on a line, on account of being > > > > thisOneReasonOrThatQuiteDifferentReasonOrThatThirdReason(long, > expression, > > that, makes, the, and, another, some); > > > > with lots of unrelated parameters in order to do its job. Well, I > > suppose its name could be shouldReturnEarlyFromOriginalMethod(...) > > instead; but I conclude that you actually prefer the three separate > > clauses, albeit in the extracted method, where each returns true, so > > that the calling code only has to do its tidy-up (and possibly other) > > code once. > > > > So, I'm fascinated: when is Extract Method the right pattern to apply ? > > I would normally reserve it for cases where it adds semantic clarity (by > > naming the condition concisely), avoids duplication or modularises an > > over-long method, > > What i'd possibly do: > > bool alreadyComputed = some.really(long.and.complicated, expression); > bool computationNeeded = another.such(that, makes, the.line.too.long) > || and.then.some.more(); > if (alreadyComputed || computationNeeded) { > delete thing; > return; > } > > If the cost of calling the conditions function is neglectible enough that > it > can be done even if the first condition would be false. > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - > https://code.woboq.org > _______________________________________________ > 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 enmarantispam at gmail.com Fri Jun 3 16:06:28 2016 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 3 Jun 2016 17:06:28 +0300 Subject: [Development] when to Extract Method (was Re: commas in ctor-init-lists) In-Reply-To: References: <201606011441.31348.marc.mutz@kdab.com> <201606031353.57829.marc.mutz@kdab.com> <3214288.tNC00nglJ6@maurice> Message-ID: Which actually raises the question, can we get Extract Lambda refactoring ?:) On Fri, Jun 3, 2016 at 4:59 PM, NIkolai Marchenko wrote: > Or you could turn the second expression into a lamba for lazy evaluation > and use it like > bool computationNeeded = [](){ return another.such(that, makes, > the.line.too.long) > || and.then.some.more(); } > if (alreadyComputed || computationNeeded()) > > On Fri, Jun 3, 2016 at 4:37 PM, Olivier Goffart wrote: > >> On Freitag, 3. Juni 2016 12:50:08 CEST Edward Welbourne wrote: >> > On Friday 03 June 2016 10:05:52 Edward Welbourne wrote: >> > >> if (somee.really(long.and.complicated, expression) || >> > >> another.such(that, makes, the.line.too.long) || >> and.then.some.more()) >> > Marc Mutz responded: >> > > To be perfectly blunt: such expressions shouldn't be >> > > allowed. Period. Neither with nor without line breaks. Such monsters >> > > should be subjected to Extract Method with extreme prejudice. >> > >> > I'm fascinated - and we're now on a whole new topic - you mean this, >> > even when the relevant combination of expressions is meaningless outside >> > the one context in which it is used: an expression that combines three >> > computed values with a binary operator is so complex it should be turned >> > into a method ? Even if the three conditions are unrelated ? >> > >> > How about if all three are tested separately ? >> > >> > if (some.really(long.and.complicated, expression)) { >> > // this one reason for an early return >> > delete thing; >> > return; >> > } >> > >> > if (another.such(that, makes, the.line.too.long)) { >> > // this quite different reason for it >> > delete thing; >> > return; >> > } >> > >> > if (and.then.some.more()) { >> > // a third quite different reasons >> > delete thing; >> > return; >> > } >> > >> > I see lots of code like that. If combining them into >> > >> > if (some.really(long.and.complicated, expression) // this one reason >> for an >> > early return >> > // this quite different reason for it: >> > || another.such(that, makes, the.line.too.long) >> > >> > // a third quite different reasons: >> > || and.then.some.more()) { >> > >> > delete thing; >> > return; >> > } >> > >> > requires Extract Method, I suspect the method name is going to end up >> > being too long to fit on a line, on account of being >> > >> > thisOneReasonOrThatQuiteDifferentReasonOrThatThirdReason(long, >> expression, >> > that, makes, the, and, another, some); >> > >> > with lots of unrelated parameters in order to do its job. Well, I >> > suppose its name could be shouldReturnEarlyFromOriginalMethod(...) >> > instead; but I conclude that you actually prefer the three separate >> > clauses, albeit in the extracted method, where each returns true, so >> > that the calling code only has to do its tidy-up (and possibly other) >> > code once. >> > >> > So, I'm fascinated: when is Extract Method the right pattern to apply ? >> > I would normally reserve it for cases where it adds semantic clarity (by >> > naming the condition concisely), avoids duplication or modularises an >> > over-long method, >> >> What i'd possibly do: >> >> bool alreadyComputed = some.really(long.and.complicated, expression); >> bool computationNeeded = another.such(that, makes, the.line.too.long) >> || and.then.some.more(); >> if (alreadyComputed || computationNeeded) { >> delete thing; >> return; >> } >> >> If the cost of calling the conditions function is neglectible enough that >> it >> can be done even if the first condition would be false. >> >> -- >> Olivier >> >> Woboq - Qt services and support - https://woboq.com - >> https://code.woboq.org >> _______________________________________________ >> 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 fromqt at tungware.se Sat Jun 4 00:40:02 2016 From: fromqt at tungware.se (Henry Skoglund) Date: Sat, 4 Jun 2016 00:40:02 +0200 Subject: [Development] Qt 5.7.0 rc packages for testing In-Reply-To: References: Message-ID: <57520742.2030302@tungware.se> Hi, just tested 5.7 RC on Ubuntu, looks good. (Also I see Qt Creator 4.01's project view has nicer icons.) But I spotted one problem, problem for me at least: When building a vanilla HelloQt widgets test app, I notice that the chrpath of the app just points to Qt's installation path, e.g.: chrpath TestApp TestApp: RPATH=/home/henry/Qt/5.7/gcc_64/lib (in Qt 5.5 it was: TestApp: RPATH=/home/henry/Qt/5.5/gcc_64:/home/henry/Qt/5.5/gcc_64/lib removing the first RPATH entry in 5.7 makes sense, it is almost never used.) but in Qt 5.6 it was: TestApp: RPATH=$ORIGIN:/home/henry/Qt/5.6/gcc_64/lib and that was *really* nice because then, on a deployment PC without Qt installed, you could place the .so files the app needs like libQt5Core.so.5 together with the .elf file in the same directory (i.e. the same type of deployment that are used on Windows). But in this 5.7RC it's back to pre-5.6 behavior. To get it to work anyway, I usually add to the .pro file (for deployment): QMAKE_LFLAGS += -Wl,-rpath,"'\$$ORIGIN'" But this is not so well documented for average developer I think. So if this lossage of $ORIGIN in RPATH remains in 5.7, I will miss 5.6 :-( P.S. Also the platform plugin DLL libqxcb.so has reverted to 5.5 behavior regarding it's RPATH settings, i.e. in Qt 5.5 and 5.7 RC it's libqxcb.so: RUNPATH=$ORIGIN/../../lib In Qt 5.6 it was: libqxcb.so: RUNPATH=$ORIGIN:$ORIGIN/../../lib Before Qt 5.5 the RPATH settings of the plugin .so files were immaterial, but starting with 5.5 they matter for loading the .so files needed by libqxcb.so, like libQt5XcbQpa.so.5 and libQt5DBus.so.5. On a development PC with Qt installed 5.5, 5.6 and 5.7 all work fine because the .so files are placed correctly, i.e. $ORIGIN/../../lib points correctly. But on a deployment PC without Qt installed this is a pain point for 5.5 and 5.7 RC because usually (for a naive developer like me) you place all the .so files needed next to the .elf file. And to fix good plugin loading in 5.6, you just placed a copy of libQt5XcbQpa.so.5 and libQt5DBus.so.5 together with libqxcb.so in the platforms subdirectory and all was fine and dandy for deployment. Of course you emulate the installed Qt's directory structure and create a subdirectory called 'lib' one position above where the .elf file is so that $ORIGIN/../../lib works, but why can't we continue to get a libqxcb.so in 5.7 that has a $ORIGIN as well in its RPATH setting? Rrgrds Henry On 2016-06-01 12:02, Jani Heikkinen wrote: > Hi all, > > > We have finally Qt 5.7.0 rc packages for testing: > > > Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/482/ > > Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/442/ > > Mac: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/376/ > > src: http://download.qt.io/snapshots/qt/5.7/5.7.0-rc/latest_src/ > > > Packages are RTA tested & seems to be pretty much Ok. Known issues in > the packages here: https://bugreports.qt.io/issues/?filter=17719 > > > We will release these packages as Qt 5.7.0 rc this Friday if nothing > really serious found during testing. So please inform me immediately if > there is something badly broken. > > > And at this time we are really minimizing changes between rc & final and > so on we are taking in only fixes for real release blockers. All others > should be just listed in known issues page > (https://wiki.qt.io/Qt_5.7.0_Known_Issues) & fixed in '5.7' branch > instead. Documentation changes and missing change files are exception: > We will take those in still during this week so please finalize those as > well really soon, latest this Sunday. We will start creating final > packages Monday 6th June morning. > > > br, > > Jani > > > Jani Heikkinen > ReleaseManager > > The Qt Company > Elektroniikkatie 13 > 90590 Oulu Finland > jani.heikkinen at qt.io > +358 50 4873735 > http://qt.io > > > > > > > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From thiago.macieira at intel.com Sat Jun 4 00:51:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Jun 2016 19:51:08 -0300 Subject: [Development] commas in ctor-init-lists In-Reply-To: <5841ab5e-33d4-bbba-df17-0f3b720f56a1@qt.io> References: <201606011441.31348.marc.mutz@kdab.com> <1705775.pt7S3bMt8y@tjmaciei-mobl1> <5841ab5e-33d4-bbba-df17-0f3b720f56a1@qt.io> Message-ID: <1612488.9Z2vkSjYBR@tjmaciei-mobl1> On sexta-feira, 3 de junho de 2016 15:59:34 BRT Christian Kandeler wrote: > This kind of thing is an abomination that should never ever be allowed, > regardless of other coding style considerations. You can hardly even > tell whether the code is syntactically correct in both cases, let alone > semantics. > Factor out ifdefs into dedicated functions whenever possible. You'll be > glad you did, and even more so the people who have to read your code later. Agreed. Like I said, #ifdefs are an eye-sore of their own and should be avoided as much as possible. Therefore, I don't consider them valid arguments for placing commas at the beginning of a line. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Sat Jun 4 21:20:14 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 04 Jun 2016 22:20:14 +0300 Subject: [Development] QtWebKit is coming back Message-ID: <3364561465068014@web16m.yandex.ru> Hi all, As some of you may already know, there is an ongoing effort to revive QtWebKit by updating its WebKit engine to the current state of upstream at webkit.org [1]. While it still haven't reached feature parity with QtWebkit module hosted by Qt Project, its Widgets API is already in a good shape [2]. It also brings many new features, including support for large part of ES2015. It is binary compatible with QtWebKit 5.6 and can be used as drop-in replacement. In this regard I have following questions to the Qt community: 1. Would you like to see this project as a part of Qt Project? QtWebKit used to be a part of Qt Essentials (at least before its removal in 5.6 release, I'm not sure what status does it have right now). I think it's neither feasible nor reasonable to restore this status it as a part of Qt Essentials, as it used to be before 5.6. We have a massive amount of 3rd party code so it would require much more work to support complete range of platforms and compilers, supported by Qt. In particular, full C++ 11 support is required from compiler, making minimal required GCC version as high as 4.8. (In the meanwhile, WebKit already started adoption of C++1y in trunk, though GCC 4.9 is still supported) Also it's likely that supported platforms won't have perfect feature parity, and it's not clear if we are going to support WebKit 2 on Windows at all (if somebody reading this is interested, please join us!) 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should it be versioned? Pros: * It is a drop-in replacement for QtWebKit, so it would simplify its downstream adoption, e.g. Linux distros could replace old insecure QtWebKit 5.6 with this new offering. * QtWebKit is a name of Qt port of WebKit. This project is basically a rebase of Qt port code to the newer revision of trunk, so I don't see it as a fork of original project, but mere update. Cons: * Old QtWebKit will probably continue to exist, because range of supported platforms for new QtWebKit is more limited. Right now we have no plans to support Android, QNX or WinCE, it's also unclear if we will ever support WebKit 2 on Windows. That means we need a way to make a clear difference between branches of the project. * Users may mistakenly report problems specific to the new version to Qt JIRA. This issue could be worked around if Qt Project kindly allowed us to have a project in Qt JIRA (maybe even resurrect old QTWEBKIT product), so I could simply move such reports to another project and reassign. OTOH, it's quite possible that bugs reported against new QtWebKit affect 5.6 as well, for example see QTBUG-53532. Of course, if anybody here is interested, any kind of help will be greatly appreciated. Thanks in advance! [1] https://github.com/annulen/webkit/wiki [2] https://lists.webkit.org/pipermail/webkit-qt/2016-May/004062.html Latest development is in "qtwebkit-stable" branch, we are planning to release TP2 with many fixes and improvements really soon -- Regards, Konstantin From thiago.macieira at intel.com Sat Jun 4 22:40:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 04 Jun 2016 17:40:36 -0300 Subject: [Development] QtWebKit is coming back In-Reply-To: <3364561465068014@web16m.yandex.ru> References: <3364561465068014@web16m.yandex.ru> Message-ID: <40706211.Aq2gYuneVo@tjmaciei-mobl1> Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu: > 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should > it be versioned? > > Pros: > * It is a drop-in replacement for QtWebKit, Please don't. You can use the same soname if you are binary compatible, but please call the module / project something different to indicate that it's different from the previous effort. We cannot give the impression that it is a continuation if it doesn't get as wide support as the old one had and feature parity. PS: Windows CE is dropped from 5.8, so you don't have to worry about it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at qt.io Mon Jun 6 09:20:21 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Mon, 6 Jun 2016 07:20:21 +0000 Subject: [Development] Documenting 3rd party license code (with SPDX?) Message-ID: tl;dr: Does anyone have experience with SPDX? Qt modules contain quite some 3rd party code under various (permissible) licenses. We've been listening these in the documentation, but this is certainly improvable - while the list is (hopefully) comprehensive, it gives users little help in where the 3rd party code is actually used (library, plugin, platform), what to do to avoid it (configure arguments?), how to acknowledge distribution requirements ... The list is also managed centrally in qtdoc.git, which requires a lot of effort to keep up to date with the other modules. My first step to improve the situation is therefore to move the documentation to where the code is actually located. At the same time I think it's a good idea not to just write .qdoc, but use a more specific format that then can be processed. What I'd like to suggest eventually is that - every code in our git modules where we don't have the relicensing rights for needs to be under a '3rdparty' folder - every folder needs a structured document that describes things like the license(s), copyright, where the code originated ... And that we then automatically process the documents to generate the documentation. Anyhow, first we have to settle on a file format. So far I have had a look at two file formats: * README.Chromium * Chromium mandates that every folder under 3rdparty needs a semi-structured file called 'README.chromium': https://src.chromium.org/viewvc/chrome/trunk/src/third_party/README.chromium.template There's then a python tool that takes some of the information, and generates the credits information page (chrome://credits) The file format is pretty light-weight and informal, but this has its drawbacks: Namely that the tool doesn't really validate much, and there seems to be some ongoing confusion on what exactly the individual fields should contain. Take e.g. URL: This is rendered in Chrome as a link to the 'Homepage' of the project, but a lot of documents actually link to individual downloads there. It's also focused on credits page, so it would need to be extended ... * SPDX * SPDX (Software Package Data Exchange) "is a standard format for communicating the components, licenses and copyrights associated with a software package." The probably most popular thing they have is a list of standard names for different licenses https://spdx.org/licenses/ But there's also an elaborate standard how to document 'software packages'. The documents can apparently both be written in Excel, RDF (XML), and Key/Value formats, there are (Java) tools to convert them, and there's a lot of tooling around it. But honestly speaking I've troubles wrapping my mind around the standard. It seems quite heavy, and I'm lost how exactly to apply it to our situation. But I do see that, if a lot of customers/upstream distributions would like to use SPDX files too, using it directly in Qt might be beneficial. So, does anyone had exposure to SPDX already, and maybe have an idea how it could be used for our 3rdparty directories in Qt? Personally I'm leaning towards defining our own customized JSON format that uses the best things from SPDX (standardized license id's) and README.Chromium. But I'd be glad to discuss with people interested in the topic :) Thanks for reading Kai -- Kai Köhne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From kde at carewolf.com Mon Jun 6 15:13:47 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 6 Jun 2016 15:13:47 +0200 Subject: [Development] QtWebKit is coming back In-Reply-To: <40706211.Aq2gYuneVo@tjmaciei-mobl1> References: <3364561465068014@web16m.yandex.ru> <40706211.Aq2gYuneVo@tjmaciei-mobl1> Message-ID: <201606061513.47473.kde@carewolf.com> On Saturday 04 June 2016, Thiago Macieira wrote: > Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu: > > 2. Is it OK to use "QtWebKit" name for this project, and if yes, how > > should it be versioned? > > > > Pros: > > * It is a drop-in replacement for QtWebKit, > > Please don't. You can use the same soname if you are binary compatible, but > please call the module / project something different to indicate that it's > different from the previous effort. We cannot give the impression that it > is a continuation if it doesn't get as wide support as the old one had and > feature parity. > I would suggest the name WebKitQt, that would fit the names of other upstream WebKit ports. `Allan From ronan.jouchet at cadensimaging.com Mon Jun 6 15:27:16 2016 From: ronan.jouchet at cadensimaging.com (Ronan Jouchet) Date: Mon, 6 Jun 2016 09:27:16 -0400 Subject: [Development] Qt 5.7.0 rc packages for testing In-Reply-To: <57520742.2030302@tungware.se> References: <57520742.2030302@tungware.se> Message-ID: <5eae30c4-ca67-2b7c-76b5-aff1cd4424c6@cadensimaging.com> On 2016-06-03 18:40, Henry Skoglund wrote: > Hi, just tested 5.7 RC on Ubuntu, looks good. > (Also I see Qt Creator 4.01's project view has nicer icons.) Hi Henry. What do you mean? Could you be also affected by https://bugreports.qt.io/browse/QTBUG-53844 ? Good day. From Lars.Knoll at qt.io Mon Jun 6 15:53:59 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Mon, 6 Jun 2016 13:53:59 +0000 Subject: [Development] QtWebKit is coming back In-Reply-To: <40706211.Aq2gYuneVo@tjmaciei-mobl1> References: <3364561465068014@web16m.yandex.ru> <40706211.Aq2gYuneVo@tjmaciei-mobl1> Message-ID: Hi Konstantin, I’d be happy to host this project here on qt-project.org (and that includes of course both source code and bug tracking) :) I don’t think it is a problem that the set of supported platforms is different from Qt WebKit in 5.6, this would have evolved in any way due to changes in the upstream project. I can also see why it would be hard to support certain things such as webkit2 on Windows (it has been difficult to support that in the past). I don’t even see a larger problem with continuing the development in the existing qtwebkit repository under three conditions: First, the branch names should make it clear that this is the new effort and not the older Qt WebKit that is being shipped with 5.6. Secondly the project needs to continue to either have full binary compatibility with the old QtWebKit in this case or bump the major .so version. A drop-in replacement (ie. Keeping BC) would be preferred if that’s possible. Thirdly, the documentation needs to be very explicit about the feature delta between old and new versions. Cheers, Lars On 04/06/16 22:40, "Development on behalf of Thiago Macieira" wrote: >Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu: >> 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should >> it be versioned? >> >> Pros: >> * It is a drop-in replacement for QtWebKit, > >Please don't. You can use the same soname if you are binary compatible, but >please call the module / project something different to indicate that it's >different from the previous effort. We cannot give the impression that it is a >continuation if it doesn't get as wide support as the old one had and feature >parity. > >PS: Windows CE is dropped from 5.8, so you don't have to worry about 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 jani.heikkinen at qt.io Mon Jun 6 16:53:57 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 6 Jun 2016 14:53:57 +0000 Subject: [Development] Qt 5.6.1 packages available Message-ID: Hi all We have Qt5.6.1 packages available: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.1/496/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.1/444/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.1/380/ Src: http://download.qt.io/snapshots/qt/5.6/5.6.1/latest_src/ Please test the packages to everything is still ok. We are planning to release Qt 5.6.1 during this week if nothing really serious found during testing. Also update known issues page (https://wiki.qt.io/Qt_5.6.1_Known_Issues) as well for the release. Qt Creator in the packages is a bit old one & will be updated before final release. br, Jani --- Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland Jani.heikkinen at qt.io +358 50 4873735 http://qt.io --- From annulen at yandex.ru Mon Jun 6 17:40:57 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 06 Jun 2016 18:40:57 +0300 Subject: [Development] QtWebKit is coming back In-Reply-To: References: <3364561465068014@web16m.yandex.ru> <40706211.Aq2gYuneVo@tjmaciei-mobl1> Message-ID: <2421231465227657@web27g.yandex.ru> 06.06.2016, 16:54, "Lars Knoll" : > Hi Konstantin, > > I’d be happy to host this project here on qt-project.org (and that includes of course both source code and bug tracking) :) Thank you! > > I don’t think it is a problem that the set of supported platforms is different from Qt WebKit in 5.6, this would have evolved in any way due to changes in the upstream project. I can also see why it would be hard to support certain things such as webkit2 on Windows (it has been difficult to support that in the past). > > I don’t even see a larger problem with continuing the development in the existing qtwebkit repository under three conditions: First, the branch names should make it clear that this is the new effort and not the older Qt WebKit that is being shipped with 5.6. Secondly the project needs to continue to either have full binary compatibility with the old QtWebKit in this case or bump the major .so version. A drop-in replacement (ie. Keeping BC) would be preferred if that’s possible. Thirdly, the documentation needs to be very explicit about the feature delta between old and new versions. There is one technical reason _against_ re-using existing qtwebkit repository: these two repos do not have any shared history. Repository [1] is a direct fork of upstream, while repository [2] uses squashed history and does not include LayoutTests. If we want to reuse [2] to hold code from [1] and don't want to bloat it with several extra GiBs of data overnight, the only reasonable startegy is to import snapshots, like it was done in old days. Having such stripped-down repository will probably be beneficial for users (and maybe occasional contributors as well) who won't need to deal with full-blown WebKit repo, but for actual development full repository is needed. There are other concerns which may affect your decision: 1. We use CMake-based build system, most of which is shared with other Webkit ports. This is purely pragmatic decision, aimed at maintenance cost reduction [3]. 2. We use the same licensing policy as WebKit, i.e. BSD + LGPLv2 and no LGPLv3 [4] 3. Our plan is to use stable branches of WebKitGTK as a base of our stable branches, e.g. now it is 2.12 branch [5]. This may cause lack of alignment with Qt release schedule sometimes. [1] https://github.com/annulen/webkit [2] http://code.qt.io/cgit/qt/qtwebkit.git/ [3] https://github.com/annulen/webkit/wiki/FAQ [4] https://github.com/annulen/webkit/wiki/Licensing [5] Reasons to use WebKitGTK instead of Apple's stable branch: * we share more code with GTK than with Apple, especially on *nix * on embedded, Apple is strongly focused on ARM64 whle GTK supports wider range of platforms * GTK creates stable branches 2x more often than Apple => less lagging behind ToT > > Cheers, > Lars > > On 04/06/16 22:40, "Development on behalf of Thiago Macieira" wrote: > >> Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu: >>>  2. Is it OK to use "QtWebKit" name for this project, and if yes, how should >>>  it be versioned? >>> >>>  Pros: >>>  * It is a drop-in replacement for QtWebKit, >> >> Please don't. You can use the same soname if you are binary compatible, but >> please call the module / project something different to indicate that it's >> different from the previous effort. We cannot give the impression that it is a >> continuation if it doesn't get as wide support as the old one had and feature >> parity. >> >> PS: Windows CE is dropped from 5.8, so you don't have to worry about 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 -- Regards, Konstantin From annulen at yandex.ru Mon Jun 6 17:45:17 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 06 Jun 2016 18:45:17 +0300 Subject: [Development] QtWebKit is coming back In-Reply-To: References: <3364561465068014@web16m.yandex.ru> <40706211.Aq2gYuneVo@tjmaciei-mobl1> Message-ID: <2439511465227917@web27g.yandex.ru> 06.06.2016, 16:54, "Lars Knoll" : > Hi Konstantin, > > I’d be happy to host this project here on qt-project.org (and that includes of course both source code and bug tracking) :) > > I don’t think it is a problem that the set of supported platforms is different from Qt WebKit in 5.6, this would have evolved in any way due to changes in the upstream project. I can also see why it would be hard to support certain things such as webkit2 on Windows (it has been difficult to support that in the past). > > I don’t even see a larger problem with continuing the development in the existing qtwebkit repository under three conditions: First, the branch names should make it clear that this is the new effort and not the older Qt WebKit that is being shipped with 5.6. Secondly the project needs to continue to either have full binary compatibility with the old QtWebKit in this case or bump the major .so version. A drop-in replacement (ie. Keeping BC) would be preferred if that’s possible. The only exisiting BC issue is with linker scripts, since we don't use qmake we'll need to imitate what different Qt versions do. Otherwise, it is compatible, e.g. it was reported to work with binary PyQt packages installed from repositories > Thirdly, the documentation needs to be very explicit about the feature delta between old and new versions. > > Cheers, > Lars > > On 04/06/16 22:40, "Development on behalf of Thiago Macieira" wrote: > >> Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu: >>>  2. Is it OK to use "QtWebKit" name for this project, and if yes, how should >>>  it be versioned? >>> >>>  Pros: >>>  * It is a drop-in replacement for QtWebKit, >> >> Please don't. You can use the same soname if you are binary compatible, but >> please call the module / project something different to indicate that it's >> different from the previous effort. We cannot give the impression that it is a >> continuation if it doesn't get as wide support as the old one had and feature >> parity. >> >> PS: Windows CE is dropped from 5.8, so you don't have to worry about 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 -- Regards, Konstantin From fromqt at tungware.se Mon Jun 6 17:57:23 2016 From: fromqt at tungware.se (Henry Skoglund) Date: Mon, 6 Jun 2016 17:57:23 +0200 Subject: [Development] Qt 5.7.0 rc packages for testing In-Reply-To: <5eae30c4-ca67-2b7c-76b5-aff1cd4424c6@cadensimaging.com> References: <57520742.2030302@tungware.se> <5eae30c4-ca67-2b7c-76b5-aff1cd4424c6@cadensimaging.com> Message-ID: <5e02dc42-459d-7498-b223-34a87d97de27@tungware.se> On 2016-06-06 15:27, Ronan Jouchet wrote: > On 2016-06-03 18:40, Henry Skoglund wrote: >> Hi, just tested 5.7 RC on Ubuntu, looks good. >> (Also I see Qt Creator 4.01's project view has nicer icons.) > > Hi Henry. > > What do you mean? Could you be also affected by > https://bugreports.qt.io/browse/QTBUG-53844 ? > > Good day. > Yes, indeed I also see the blue icons with Qt 5.7 RC on my Ubuntu 14.04 (Unity). And I thought they looked nicer, didn't realize it is a bug :-) From Lars.Knoll at qt.io Tue Jun 7 08:38:35 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Tue, 7 Jun 2016 06:38:35 +0000 Subject: [Development] QtWebKit is coming back In-Reply-To: <2421231465227657@web27g.yandex.ru> References: <3364561465068014@web16m.yandex.ru> <40706211.Aq2gYuneVo@tjmaciei-mobl1> <2421231465227657@web27g.yandex.ru> Message-ID: <1C7D9E30-0988-41C6-9434-BC09D67ED561@qt.io> On 06/06/16 17:40, "Konstantin Tokarev" wrote: > > >06.06.2016, 16:54, "Lars Knoll" : >> Hi Konstantin, >> >> I’d be happy to host this project here on qt-project.org (and that includes of course both source code and bug tracking) :) > >Thank you! > >> >> I don’t think it is a problem that the set of supported platforms is different from Qt WebKit in 5.6, this would have evolved in any way due to changes in the upstream project. I can also see why it would be hard to support certain things such as webkit2 on Windows (it has been difficult to support that in the past). >> >> I don’t even see a larger problem with continuing the development in the existing qtwebkit repository under three conditions: First, the branch names should make it clear that this is the new effort and not the older Qt WebKit that is being shipped with 5.6. Secondly the project needs to continue to either have full binary compatibility with the old QtWebKit in this case or bump the major .so version. A drop-in replacement (ie. Keeping BC) would be preferred if that’s possible. Thirdly, the documentation needs to be very explicit about the feature delta between old and new versions. > >There is one technical reason _against_ re-using existing qtwebkit repository: these two repos do not have any shared history. Repository [1] is a direct fork of upstream, while repository [2] uses squashed history and does not include LayoutTests. If we want to reuse [2] to hold code from [1] and don't want to bloat it with several extra GiBs of data overnight, the only reasonable startegy is to import snapshots, like it was done in old days. > >Having such stripped-down repository will probably be beneficial for users (and maybe occasional contributors as well) who won't need to deal with full-blown WebKit repo, but for actual development full repository is needed. Ok, in this case a separate repo is maybe a better strategy. WebKitQt (as Allan proposed) might be a good name in this case :) If it’s a separate repo, I don’t see a problem with having the actual repo here. > >There are other concerns which may affect your decision: > >1. We use CMake-based build system, most of which is shared with other Webkit ports. This is purely pragmatic decision, aimed at maintenance cost reduction [3]. >2. We use the same licensing policy as WebKit, i.e. BSD + LGPLv2 and no LGPLv3 [4] >3. Our plan is to use stable branches of WebKitGTK as a base of our stable branches, e.g. now it is 2.12 branch [5]. This may cause lack of alignment with Qt release schedule sometimes. I would probably do the same/similar decisions here. I don’t think they are reasons not to have the repo on qt-project.org if you want to have it there. Of course the webkit port would live it’s own life independent of the rest of Qt in terms of release schedules, but that’s fine. Cheers, Lars > > >[1] https://github.com/annulen/webkit >[2] http://code.qt.io/cgit/qt/qtwebkit.git/ >[3] https://github.com/annulen/webkit/wiki/FAQ >[4] https://github.com/annulen/webkit/wiki/Licensing >[5] Reasons to use WebKitGTK instead of Apple's stable branch: > * we share more code with GTK than with Apple, especially on *nix > * on embedded, Apple is strongly focused on ARM64 whle GTK supports wider range of platforms > * GTK creates stable branches 2x more often than Apple => less lagging behind ToT > >> >> Cheers, >> Lars >> >> On 04/06/16 22:40, "Development on behalf of Thiago Macieira" wrote: >> >>> Em sábado, 4 de junho de 2016, às 22:20:14 BRT, Konstantin Tokarev escreveu: >>>> 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should >>>> it be versioned? >>>> >>>> Pros: >>>> * It is a drop-in replacement for QtWebKit, >>> >>> Please don't. You can use the same soname if you are binary compatible, but >>> please call the module / project something different to indicate that it's >>> different from the previous effort. We cannot give the impression that it is a >>> continuation if it doesn't get as wide support as the old one had and feature >>> parity. >>> >>> PS: Windows CE is dropped from 5.8, so you don't have to worry about 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 > >-- >Regards, >Konstantin From me at the-compiler.org Tue Jun 7 08:47:12 2016 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 7 Jun 2016 08:47:12 +0200 Subject: [Development] QtWebKit is coming back In-Reply-To: <1C7D9E30-0988-41C6-9434-BC09D67ED561@qt.io> References: <3364561465068014@web16m.yandex.ru> <40706211.Aq2gYuneVo@tjmaciei-mobl1> <2421231465227657@web27g.yandex.ru> <1C7D9E30-0988-41C6-9434-BC09D67ED561@qt.io> Message-ID: <20160607064712.i2sy2otyil3nhtci@tonks> * Lars Knoll [2016-06-07 06:38:35 +0000]: > Ok, in this case a separate repo is maybe a better strategy. > WebKitQt (as Allan proposed) might be a good name in this case :) I don't want to start any bike-shedding here, but if there's a QtWebKit and a WebKitQt and those are *basically* different versions of the same thing, that sounds like a source for a lot of confusion... FWIW the unofficial name it just happened to get in various related IRC channels is "QtWebKit-NG" ;) Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From thomas.krenn at kabsi.at Tue Jun 7 10:26:27 2016 From: thomas.krenn at kabsi.at (Thomas Krenn) Date: Tue, 7 Jun 2016 10:26:27 +0200 Subject: [Development] Documentation for QPagedPrintDevice::setPageSize should specify a unit Message-ID: <57568533.1070701@kabsi.at> Hello, Steve Schilz requested on Wed, 4 May 2016: QPagedPrintDevice::setPageSize should specify a unit QTextDocument::setPageSize (http://doc.qt.io/qt-5/qtextdocument.html#pageSize-prop) --- Looking at the source code and the generated PDF's my conclusion is is that the numbers of the property pageSize dependent on the platform because all internal calculations of QTextDocument are done with: 'qt_defaultDpi' Notably on Windows (qt_defaultDpi = 96 dpi) the produced PDF is to small with a pageSize e.g.: fullRectPoints 595 / 842 (595,44) / (841,62) (72 dpi / A4) and a PDF printer with: QString pdfName("hello.pdf") QPrinter printer(QPrinter::HighResolution); printer.setOutputFormat(QPrinter::PdfFormat); printer.setOutputFileName(pdfName); printer.setResolution(1200); QPageSize pageSizeA(QPageSize::A4); printer.setPageSize(pageSizeA); // setting the printer margin to 0 (or full page mode) is important to avoid PDF page scaling. QMarginsF margins(0, 0, 0, 0); printer.setPageMargins(margins); Best regards Thomas Krenn -------------- next part -------------- A non-text attachment was scrubbed... Name: thomas_krenn.vcf Type: text/x-vcard Size: 222 bytes Desc: not available URL: From annulen at yandex.ru Tue Jun 7 13:15:44 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 07 Jun 2016 14:15:44 +0300 Subject: [Development] QtWebKit is coming back In-Reply-To: <20160607064712.i2sy2otyil3nhtci@tonks> References: <3364561465068014@web16m.yandex.ru> <40706211.Aq2gYuneVo@tjmaciei-mobl1> <2421231465227657@web27g.yandex.ru> <1C7D9E30-0988-41C6-9434-BC09D67ED561@qt.io> <20160607064712.i2sy2otyil3nhtci@tonks> Message-ID: <635211465298144@web6g.yandex.ru> 07.06.2016, 09:47, "Florian Bruhin" : > * Lars Knoll [2016-06-07 06:38:35 +0000]: >>  Ok, in this case a separate repo is maybe a better strategy. >>  WebKitQt (as Allan proposed) might be a good name in this case :) > > I don't want to start any bike-shedding here, but if there's a > QtWebKit and a WebKitQt and those are *basically* different versions > of the same thing, that sounds like a source for a lot of confusion... I admit that I was thinking about WebKitQt name before Allan proposed it, for the same reason + because project becomes somewhat more "WebKitish" and less "Qtish" over the time. However I have the same concern as Florian, i.e. difference is too subtle to eleminate confusion, and too significant for seamless update. BTW, I think it's not strictly necessary to equate public name of the project and basename of the final component of repo url. For instance, new repo could be at qt/webkit.git. Optionally with snapshots and tags pushed into qt/qtwebkit.git for convenience of packagers. > > FWIW the unofficial name it just happened to get in various related > IRC channels is "QtWebKit-NG" ;) > > Florian > > -- > http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) >    GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc >          I love long mails! | http://email.is-not-s.ms/ > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Tue Jun 7 16:03:29 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Jun 2016 07:03:29 -0700 Subject: [Development] QtWebKit is coming back In-Reply-To: <20160607064712.i2sy2otyil3nhtci@tonks> References: <3364561465068014@web16m.yandex.ru> <1C7D9E30-0988-41C6-9434-BC09D67ED561@qt.io> <20160607064712.i2sy2otyil3nhtci@tonks> Message-ID: <1857547.KeOjVlOzGl@tjmaciei-mobl1> Em terça-feira, 7 de junho de 2016, às 08:47:12 PDT, Florian Bruhin escreveu: > FWIW the unofficial name it just happened to get in various related > IRC channels is "QtWebKit-NG" ;) I like that. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at qt.io Tue Jun 7 16:08:55 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Tue, 7 Jun 2016 14:08:55 +0000 Subject: [Development] QtWebKit is coming back In-Reply-To: <1857547.KeOjVlOzGl@tjmaciei-mobl1> References: <3364561465068014@web16m.yandex.ru> <1C7D9E30-0988-41C6-9434-BC09D67ED561@qt.io> <20160607064712.i2sy2otyil3nhtci@tonks> <1857547.KeOjVlOzGl@tjmaciei-mobl1> Message-ID: On 07/06/16 16:03, "Development on behalf of Thiago Macieira" wrote: >Em terça-feira, 7 de junho de 2016, às 08:47:12 PDT, Florian Bruhin escreveu: >> FWIW the unofficial name it just happened to get in various related >> IRC channels is "QtWebKit-NG" ;) > >I like that. Sounds good to me as well. Lars From sschilz at pasco.com Tue Jun 7 17:57:09 2016 From: sschilz at pasco.com (Steve Schilz) Date: Tue, 7 Jun 2016 15:57:09 +0000 Subject: [Development] Development Digest, Vol 57, Issue 23 In-Reply-To: References: Message-ID: <783C4432-E316-4BB5-9E35-238537FDE9D5@pasco.com> Hi Thomas, Thanks for taking a look. I have submitted a change request, which is currently at +1 status (thanks Edward Wellborn) https://codereview.qt-project.org/#/c/158402/, and after a few rounds we have this text: The units are determined by the underlying paint device. The size is measured in logical pixels when painting to the screen, and in points (1/72 inch) when painting to a printer. I tried to add you as a reviewer, but didn’t find you in the system. Feel free to add yourself as a reviewer, or comment there. I Steve Schilz PASCO scientific - think science On 6/7/16, 7:04 AM, "Development on behalf of development-request at qt-project.org" wrote: >Message: 4 >Date: Tue, 7 Jun 2016 10:26:27 +0200 >From: Thomas Krenn >To: development at qt-project.org >Subject: [Development] Documentation for > QPagedPrintDevice::setPageSize should specify a unit >Message-ID: <57568533.1070701 at kabsi.at> >Content-Type: text/plain; charset="utf-8"; Format="flowed" > >Hello, >Steve Schilz requested on Wed, 4 May 2016: > >QPagedPrintDevice::setPageSize should specify a unit >QTextDocument::setPageSize (http://doc.qt.io/qt-5/qtextdocument.html#pageSize-prop) > >--- > >Looking at the source code and the generated PDF's my conclusion is >is that the numbers of the property pageSize dependent on the platform >because all internal calculations of QTextDocument are done with: 'qt_defaultDpi' > >Notably on Windows (qt_defaultDpi = 96 dpi) the produced PDF is to small >with a pageSize e.g.: > >fullRectPoints 595 / 842 (595,44) / (841,62) (72 dpi / A4) >and a PDF printer with: > > QString pdfName("hello.pdf") > QPrinter printer(QPrinter::HighResolution); > printer.setOutputFormat(QPrinter::PdfFormat); > printer.setOutputFileName(pdfName); > > printer.setResolution(1200); > QPageSize pageSizeA(QPageSize::A4); > printer.setPageSize(pageSizeA); > >// setting the printer margin to 0 (or full page mode) is important to avoid PDF page scaling. > QMarginsF margins(0, 0, 0, 0); > printer.setPageMargins(margins); > > >Best regards >Thomas Krenn > From Stephen.Chu at mathworks.com Tue Jun 7 18:01:03 2016 From: Stephen.Chu at mathworks.com (Stephen Chu) Date: Tue, 7 Jun 2016 16:01:03 +0000 Subject: [Development] QtWebKit is coming back In-Reply-To: <3364561465068014@web16m.yandex.ru> References: <3364561465068014@web16m.yandex.ru> Message-ID: I don’t see Mac mentioned in either links provided. Is Mac supported? Stephen Chu On 6/4/16, 3:20 PM, "Development on behalf of Konstantin Tokarev" wrote: >Hi all, > >As some of you may already know, there is an ongoing effort to revive QtWebKit by updating its WebKit engine to the current state of upstream at webkit.org [1]. > >While it still haven't reached feature parity with QtWebkit module hosted by Qt Project, its Widgets API is already in a good shape [2]. It also brings many new features, including support for large part of ES2015. It is binary compatible with QtWebKit 5.6 and can be used as drop-in replacement. > >In this regard I have following questions to the Qt community: > >1. Would you like to see this project as a part of Qt Project? > >QtWebKit used to be a part of Qt Essentials (at least before its removal in 5.6 release, I'm not sure what status does it have right now). I think it's neither feasible nor reasonable to restore this status it as a part of Qt Essentials, as it used to be before 5.6. We have a massive amount of 3rd party code so it would require much more work to support complete range of platforms and compilers, supported by Qt. In particular, full C++ 11 support is required from compiler, making minimal required GCC version as high as 4.8. (In the meanwhile, WebKit already started adoption of C++1y in trunk, though GCC 4.9 is still supported) > >Also it's likely that supported platforms won't have perfect feature parity, and it's not clear if we are going to support WebKit 2 on Windows at all (if somebody reading this is interested, please join us!) > >2. Is it OK to use "QtWebKit" name for this project, and if yes, how should it be versioned? > >Pros: >* It is a drop-in replacement for QtWebKit, so it would simplify its downstream adoption, e.g. Linux distros could replace old insecure QtWebKit 5.6 with this new offering. >* QtWebKit is a name of Qt port of WebKit. This project is basically a rebase of Qt port code to the newer revision of trunk, so I don't see it as a fork of original project, but mere update. > >Cons: >* Old QtWebKit will probably continue to exist, because range of supported platforms for new QtWebKit is more limited. Right now we have no plans to support Android, QNX or WinCE, it's also unclear if we will ever support WebKit 2 on Windows. That means we need a way to make a clear difference between branches of the project. >* Users may mistakenly report problems specific to the new version to Qt JIRA. This issue could be worked around if Qt Project kindly allowed us to have a project in Qt JIRA (maybe even resurrect old QTWEBKIT product), so I could simply move such reports to another project and reassign. OTOH, it's quite possible that bugs reported against new QtWebKit affect 5.6 as well, for example see QTBUG-53532. > >Of course, if anybody here is interested, any kind of help will be greatly appreciated. > >Thanks in advance! > > >[1] https://github.com/annulen/webkit/wiki >[2] https://lists.webkit.org/pipermail/webkit-qt/2016-May/004062.html >Latest development is in "qtwebkit-stable" branch, we are planning to release TP2 with many fixes and improvements really soon > >-- >Regards, >Konstantin >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Tue Jun 7 18:07:25 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 07 Jun 2016 19:07:25 +0300 Subject: [Development] QtWebKit is coming back In-Reply-To: References: <3364561465068014@web16m.yandex.ru> Message-ID: <5538211465315645@web6h.yandex.ru> 07.06.2016, 19:01, "Stephen Chu" : > I don’t see Mac mentioned in either links provided. Is Mac supported? Not yet, though a couple of changes needed to compile on OS X were already integrated. If you want to try building it, I can give you a few instructions. > > Stephen Chu > > On 6/4/16, 3:20 PM, "Development on behalf of Konstantin Tokarev" wrote: > >> Hi all, >> >> As some of you may already know, there is an ongoing effort to revive QtWebKit by updating its WebKit engine to the current state of upstream at webkit.org [1]. >> >> While it still haven't reached feature parity with QtWebkit module hosted by Qt Project, its Widgets API is already in a good shape [2]. It also brings many new features, including support for large part of ES2015. It is binary compatible with QtWebKit 5.6 and can be used as drop-in replacement. >> >> In this regard I have following questions to the Qt community: >> >> 1. Would you like to see this project as a part of Qt Project? >> >> QtWebKit used to be a part of Qt Essentials (at least before its removal in 5.6 release, I'm not sure what status does it have right now). I think it's neither feasible nor reasonable to restore this status it as a part of Qt Essentials, as it used to be before 5.6. We have a massive amount of 3rd party code so it would require much more work to support complete range of platforms and compilers, supported by Qt. In particular, full C++ 11 support is required from compiler, making minimal required GCC version as high as 4.8. (In the meanwhile, WebKit already started adoption of C++1y in trunk, though GCC 4.9 is still supported) >> >> Also it's likely that supported platforms won't have perfect feature parity, and it's not clear if we are going to support WebKit 2 on Windows at all (if somebody reading this is interested, please join us!) >> >> 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should it be versioned? >> >> Pros: >> * It is a drop-in replacement for QtWebKit, so it would simplify its downstream adoption, e.g. Linux distros could replace old insecure QtWebKit 5.6 with this new offering. >> * QtWebKit is a name of Qt port of WebKit. This project is basically a rebase of Qt port code to the newer revision of trunk, so I don't see it as a fork of original project, but mere update. >> >> Cons: >> * Old QtWebKit will probably continue to exist, because range of supported platforms for new QtWebKit is more limited. Right now we have no plans to support Android, QNX or WinCE, it's also unclear if we will ever support WebKit 2 on Windows. That means we need a way to make a clear difference between branches of the project. >> * Users may mistakenly report problems specific to the new version to Qt JIRA. This issue could be worked around if Qt Project kindly allowed us to have a project in Qt JIRA (maybe even resurrect old QTWEBKIT product), so I could simply move such reports to another project and reassign. OTOH, it's quite possible that bugs reported against new QtWebKit affect 5.6 as well, for example see QTBUG-53532. >> >> Of course, if anybody here is interested, any kind of help will be greatly appreciated. >> >> Thanks in advance! >> >> [1] https://github.com/annulen/webkit/wiki >> [2] https://lists.webkit.org/pipermail/webkit-qt/2016-May/004062.html >> Latest development is in "qtwebkit-stable" branch, we are planning to release TP2 with many fixes and improvements really soon >> >> -- >> Regards, >> Konstantin >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Wed Jun 8 07:59:39 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Jun 2016 22:59:39 -0700 Subject: [Development] qtbase 5.7.0 changelog help Message-ID: <4706428.1QG8xGjaJp@tjmaciei-mobl1> Please help with the following entries. They contain text that is either incorrect, hard to understand or not clear enough for users of Qt that are not familiar with the internals. For any entry listed here that doesn't get a reply from someone, it will be deleted from the changelog. - QWheelEvent::phase() now returns 0 rather than Qt::ScrollUpdate when the wheel event comes from an actual non-emulated mouse wheel and the environment variable QT_ENABLE_MOUSE_WHEEL_TRACKING is set. In Qt 5.6, this is required to enable the fix for QTBUG-50199. [What's this about 5.6?] * [QTBUG-53338] Fixed crash when comparing a initialized QAuthenticator with an uninitialized QAuthenticator. [What do you mean with uninitialized?] [Android section] - Allow the user to choose how much from Android theme is extracted. [how? A little more detail, please. And wrong tense] [moc section] - [QTBUG-53441] Fixed crash on file ending with \\\r [clarification needed on just what the file couldn't end in] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From announce at qt-project.org Wed Jun 8 12:08:34 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 8 Jun 2016 10:08:34 +0000 Subject: [Development] [Announce] Qt 5.6.1 & Qt Creator 4.0.1 released Message-ID: Hi all, Qt 5.6.1 has just been released, see http://blog.qt.io/blog/2016/06/08/qt-5-6-1-released/ In addition to Qt 5.6.1 we also released Qt Creator 4.0.1, see http://blog.qt.io/blog/2016/06/08/qt-creator-4-0-1-released/ Big thanks to everyone involved! Br, Jani [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From edward.welbourne at qt.io Wed Jun 8 16:24:23 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Jun 2016 14:24:23 +0000 Subject: [Development] Header review for 5.7.0 (vs 5.6.1) In-Reply-To: References: , Message-ID: > Following up on the earlier header review, comparing 5.6 to 5.7, I've > now prepared a review of 5.7.0 vs 5.6.1, following some moderate > refinements to the scripts. Hopefully various "not yet merged" changes > are now in 5.7.0 to fix blemishes noticed in the earlier review: > > https://codereview.qt-project.org/160661 – qtbase > https://codereview.qt-project.org/160662 – qtdeclarative > https://codereview.qt-project.org/160663 – qtactiveqt > https://codereview.qt-project.org/160664 – qtmultimedia > https://codereview.qt-project.org/160665 – qttools > https://codereview.qt-project.org/160666 – qtlocation > https://codereview.qt-project.org/160667 – qtconnectivity > https://codereview.qt-project.org/160668 – qtwayland > https://codereview.qt-project.org/160669 – qt3d (which no-one reviewed last time) > https://codereview.qt-project.org/160670 – qtquickcontrols > https://codereview.qt-project.org/160671 – qtserialport > https://codereview.qt-project.org/160672 – qtx11extras > https://codereview.qt-project.org/160673 – qtandroidextras > https://codereview.qt-project.org/160674 – qtwebsockets > https://codereview.qt-project.org/160675 – qtwebengine > https://codereview.qt-project.org/160676 – qtcanvas3d > https://codereview.qt-project.org/160677 – qtquickcontrols2 [...] > Please take a look at the modules you care about and point out anything > that's going to cause problems for the usual compatibility constraints, I've just re-run the script and pushed new patch-sets to these reviews, taking account of changes to 5.6.1 and 5.7.0 since then. These are (where relevant) rebased, I'm afraid, so you won't have nicely-behaved changes between patch-sets :-( A few modules seem to have had commit-metadata-only changes in this run; I'll try to work out why the script did that - it shouldn't have - but both qtbase and qt3d do indeed have material changes, Eddy. From edward.welbourne at qt.io Wed Jun 8 16:24:46 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Jun 2016 14:24:46 +0000 Subject: [Development] Header review for 5.7.0 (vs 5.6.1) Message-ID: > Following up on the earlier header review, comparing 5.6 to 5.7, I've > now prepared a review of 5.7.0 vs 5.6.1, following some moderate > refinements to the scripts. Hopefully various "not yet merged" changes > are now in 5.7.0 to fix blemishes noticed in the earlier review: > > https://codereview.qt-project.org/160661 – qtbase > https://codereview.qt-project.org/160662 – qtdeclarative > https://codereview.qt-project.org/160663 – qtactiveqt > https://codereview.qt-project.org/160664 – qtmultimedia > https://codereview.qt-project.org/160665 – qttools > https://codereview.qt-project.org/160666 – qtlocation > https://codereview.qt-project.org/160667 – qtconnectivity > https://codereview.qt-project.org/160668 – qtwayland > https://codereview.qt-project.org/160669 – qt3d (which no-one reviewed last time) > https://codereview.qt-project.org/160670 – qtquickcontrols > https://codereview.qt-project.org/160671 – qtserialport > https://codereview.qt-project.org/160672 – qtx11extras > https://codereview.qt-project.org/160673 – qtandroidextras > https://codereview.qt-project.org/160674 – qtwebsockets > https://codereview.qt-project.org/160675 – qtwebengine > https://codereview.qt-project.org/160676 – qtcanvas3d > https://codereview.qt-project.org/160677 – qtquickcontrols2 [...] > Please take a look at the modules you care about and point out anything > that's going to cause problems for the usual compatibility constraints, I've just re-run the script and pushed new patch-sets to these reviews, taking account of changes to 5.6.1 and 5.7.0 since then. These are (where relevant) rebased, I'm afraid, so you won't have nicely-behaved changes between patch-sets :-( A few modules seem to have had commit-metadata-only changes in this run; I'll try to work out why the script did that - it shouldn't have - but both qtbase and qt3d do indeed have material changes, Eddy. From kde at carewolf.com Wed Jun 8 21:49:28 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 8 Jun 2016 21:49:28 +0200 Subject: [Development] QtWebKit is coming back Message-ID: <201606082149.28876.kde@carewolf.com> I was asked how we used to structure and develop QtWebKit, and how it would relate to the new project. So here some background and my thoughts: The way QtWebKit used to be developed was upstream in WebKit, at some point a release was branched and squashed into the qt respository in one big commit, where we also removed all the layout tests which makes up the by far largest part of the webkit repo. The last branch of QtWebKit (originally branched for Qt 5.2) had three different repos: WebKit upsteam, a fork of upstream living in gitorious where our 5.2 git branch relative to upstream lived, and which was supposed to be identical to the Qt-repo except supporting layout tests, and finally the QtWebKit module in Qt repo. WebKit's build-system and CI ran on upstream (equivalent to Qt dev), and on the the fork (equivalent to 5.2). Qt's build- system and CI ran only on the Qt repo (basically only git tags). Such a structure while workable is obviously not optimal, and even if we did continue with such a 3 way model, it would be ideal if the upstream-fork could be hosted together with the official qt version. For an unofficial QtWebKit I would suggest just using an upstream fork on a friendly git host. Being kicked out of upstream WebKit also means it would be the only place of development. This is also how I maintained QtWebKit 2.3 which was a backport of modern QtWebKit to Qt4. Such as structure will however become a problem if QtWebKit-NG needs to integrate with Qt build/CI system again, since the repo would be a huge, unnecessary burden to check out, for anyone who needs to just build or test it. Note, it is not easy to split a WebKit repository and make the layout-tests a submodule due to the sensible WebKit policy of always maintaining and adding tests atomically with each commit that adds features that needs testing or changes test output. Best regards `Allan From annulen at yandex.ru Thu Jun 9 00:06:37 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 09 Jun 2016 01:06:37 +0300 Subject: [Development] QtWebKit is coming back In-Reply-To: <201606082149.28876.kde@carewolf.com> References: <201606082149.28876.kde@carewolf.com> Message-ID: <589561465423597@web13j.yandex.ru> Allan, Thanks for write-up, I'd like to add just a few side notes 08.06.2016, 22:49, "Allan Sandfeld Jensen" : >  I was asked how we used to structure and develop QtWebKit, and how it would >  relate to the new project. So here some background and my thoughts: > >  The way QtWebKit used to be developed was upstream in WebKit, at some point a >  release was branched and squashed into the qt respository in one big commit, >  where we also removed all the layout tests which makes up the by far largest >  part of the webkit repo. > >  The last branch of QtWebKit (originally branched for Qt 5.2) had three >  different repos: WebKit upsteam, a fork of upstream living in gitorious where >  our 5.2 git branch relative to upstream lived, and which was supposed to be >  identical to the Qt-repo except supporting layout tests, and finally the >  QtWebKit module in Qt repo. WebKit's build-system and CI ran on upstream >  (equivalent to Qt dev), and on the the fork (equivalent to 5.2). Qt's build- >  system and CI ran only on the Qt repo (basically only git tags). > >  Such a structure while workable is obviously not optimal, and even if we did >  continue with such a 3 way model, it would be ideal if the upstream-fork could >  be hosted together with the official qt version. > >  For an unofficial QtWebKit I would suggest just using an upstream fork on a >  friendly git host. Being kicked out of upstream WebKit also means it would be >  the only place of development. This is also how I maintained QtWebKit 2.3 >  which was a backport of modern QtWebKit to Qt4. If I understood correctly, in this thread Lars has agreed to make it "official", though it's not clear to me how will it map to existing structure of Qt Project. >  Such as structure will however >  become a problem if QtWebKit-NG needs to integrate with Qt build/CI system >  again, since the repo would be a huge, unnecessary burden to check out, for >  anyone who needs to just build or test it. While it's certainly true that full WebKit repo creates more burden, arguably it's not a showstopper: after repo is initially cloned it does not take a lot of time and traffic to update it, also problem with large clone size can be mitigated by limiting clone depth and by using sparse checkout feature of git. Though I'm not sure if Gerrit will perform well on the full repo. > >  Note, it is not easy to split a WebKit repository and make the layout-tests a >  submodule due to the sensible WebKit policy of always maintaining and adding >  tests atomically with each commit that adds features that needs testing or >  changes test output. > >  Best regards >  `Allan > >  _______________________________________________ >  Development mailing list >  Development at qt-project.org >  http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From annulen at yandex.ru Thu Jun 9 21:43:15 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 09 Jun 2016 22:43:15 +0300 Subject: [Development] QtWebKit is coming back In-Reply-To: References: <3364561465068014@web16m.yandex.ru> Message-ID: <455311465501395@web14j.yandex.ru> 07.06.2016, 19:01, "Stephen Chu" : > I don’t see Mac mentioned in either links provided. Is Mac supported? You can build qtwebkit-stable branch on OS X now, see instructions at [1]. Binaries will be available for TP2. [1] https://github.com/annulen/webkit/wiki/Building-QtWebKit-on-OS-X > > Stephen Chu > > On 6/4/16, 3:20 PM, "Development on behalf of Konstantin Tokarev" wrote: > >> Hi all, >> >> As some of you may already know, there is an ongoing effort to revive QtWebKit by updating its WebKit engine to the current state of upstream at webkit.org [1]. >> >> While it still haven't reached feature parity with QtWebkit module hosted by Qt Project, its Widgets API is already in a good shape [2]. It also brings many new features, including support for large part of ES2015. It is binary compatible with QtWebKit 5.6 and can be used as drop-in replacement. >> >> In this regard I have following questions to the Qt community: >> >> 1. Would you like to see this project as a part of Qt Project? >> >> QtWebKit used to be a part of Qt Essentials (at least before its removal in 5.6 release, I'm not sure what status does it have right now). I think it's neither feasible nor reasonable to restore this status it as a part of Qt Essentials, as it used to be before 5.6. We have a massive amount of 3rd party code so it would require much more work to support complete range of platforms and compilers, supported by Qt. In particular, full C++ 11 support is required from compiler, making minimal required GCC version as high as 4.8. (In the meanwhile, WebKit already started adoption of C++1y in trunk, though GCC 4.9 is still supported) >> >> Also it's likely that supported platforms won't have perfect feature parity, and it's not clear if we are going to support WebKit 2 on Windows at all (if somebody reading this is interested, please join us!) >> >> 2. Is it OK to use "QtWebKit" name for this project, and if yes, how should it be versioned? >> >> Pros: >> * It is a drop-in replacement for QtWebKit, so it would simplify its downstream adoption, e.g. Linux distros could replace old insecure QtWebKit 5.6 with this new offering. >> * QtWebKit is a name of Qt port of WebKit. This project is basically a rebase of Qt port code to the newer revision of trunk, so I don't see it as a fork of original project, but mere update. >> >> Cons: >> * Old QtWebKit will probably continue to exist, because range of supported platforms for new QtWebKit is more limited. Right now we have no plans to support Android, QNX or WinCE, it's also unclear if we will ever support WebKit 2 on Windows. That means we need a way to make a clear difference between branches of the project. >> * Users may mistakenly report problems specific to the new version to Qt JIRA. This issue could be worked around if Qt Project kindly allowed us to have a project in Qt JIRA (maybe even resurrect old QTWEBKIT product), so I could simply move such reports to another project and reassign. OTOH, it's quite possible that bugs reported against new QtWebKit affect 5.6 as well, for example see QTBUG-53532. >> >> Of course, if anybody here is interested, any kind of help will be greatly appreciated. >> >> Thanks in advance! >> >> [1] https://github.com/annulen/webkit/wiki >> [2] https://lists.webkit.org/pipermail/webkit-qt/2016-May/004062.html >> Latest development is in "qtwebkit-stable" branch, we are planning to release TP2 with many fixes and improvements really soon >> >> -- >> Regards, >> Konstantin >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From alexander.blasche at qt.io Fri Jun 10 12:17:07 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Fri, 10 Jun 2016 10:17:07 +0000 Subject: [Development] Nominating Frank Meerkoetter for Approver status In-Reply-To: References: Message-ID: Conratulations to Frank. The rights have been adjusted accordingly. -- Alex ________________________________________ From: Development on behalf of Simon Hausmann Sent: Friday, 20 May 2016 2:49:52 PM To: development at qt-project.org Subject: [Development] Nominating Frank Meerkoetter for Approver status Hi, I would like to nominate Frank for approver status. He has done a fair bit of surgery in the QML engine and also seems to be active on qtopcua/serialbus. I appreciate his input on my patches and I trust him to responsibly review. Simon From thiago.macieira at intel.com Fri Jun 10 19:53:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 10 Jun 2016 10:53:00 -0700 Subject: [Development] std::chrono getters in our API Message-ID: <1797177.exj0r56Drt@tjmaciei-mobl1> I've added a set of std::chrono API to QTimer[1] and QDeadlineTimer[2] and we're hitting a snag on what to name the getters. The setters are fine because they're just overloads: timer.setInterval(3); // Qt; milliseconds timer.setInterval(3ms); deadline.setRemainingTime(3600000); // milliseconds deadline.setRemainingTime(1h); deadline.setDeadline(QDeadlineTimer::current().deadline() + 3600000); deadline.setDeadline(std::chrono::steady_clock::now() + 1h); The problem are the getters: what do we call them? We can't overload on return value, so we can't use the standard getter name matching the setters above, as it's already used for the Qt-style API: int r = timer.remainingTime(); // milliseconds I implemented an overload by way of templates: auto r = timer.remainingTime(); But some reviewers didn't like it and want the function to be non-template, returning std::chrono::milliseconds, leaving the conversion to a different type left as an exercise to the user. So: what do we do? Option 1: - Use overload-by-template like I did - Cons: requires a template argument - Pros: avoids ugly std::chrono::duration_cast(timer.remainingTime()); Option 2: - Find a different name, not matching the setter name - Cons: doesn't match setter name - Pros: non-template Option 3: - Find a different name for both setters and getters - Cons: can't write deadline.setRemainingTime(250ms); - Pros: clean API, but with some surprise factor Option 4: - Find a different name for setters and getters, plus overload setters - Cons: a lot more template code in qtimer.h and qdeadlinetimer.h - Pros: clean API, but with some surprise factor Option 5: - Drop std::chrono API - Cons: no QTimer::singleShot(5s, ...); - Pros: easiest NON Option: - Use std::chrono only - Why: can't depend on it as the only way to access the time. Not to mention that QTimer already has ABI set. [1] https://codereview.qt-project.org/160889 [2] https://codereview.qt-project.org/159932 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Fri Jun 10 20:09:08 2016 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Fri, 10 Jun 2016 15:09:08 -0300 Subject: [Development] Acceptable CC licenses for Qt In-Reply-To: References: <4422295.9qpMLJGLRa@luna> Message-ID: On 11 May 2016 at 05:07, Simon Hausmann wrote: > > I have the strong feeling that perhaps there's an alternate solution, given that the file in question was probably produced by Pasi :) Hi Pasi! I don't see a reply to this in the thread. Is it possible to relicense the file? -- http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ From mwoehlke.floss at gmail.com Fri Jun 10 22:12:10 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 10 Jun 2016 16:12:10 -0400 Subject: [Development] std::chrono getters in our API In-Reply-To: <1797177.exj0r56Drt@tjmaciei-mobl1> References: <1797177.exj0r56Drt@tjmaciei-mobl1> Message-ID: On 2016-06-10 13:53, Thiago Macieira wrote: > I've added a set of std::chrono API to QTimer[1] and QDeadlineTimer[2] and > we're hitting a snag on what to name the getters. The setters are fine because > they're just overloads: > > timer.setInterval(3); // Qt; milliseconds > timer.setInterval(3ms); > deadline.setRemainingTime(3600000); // milliseconds > deadline.setRemainingTime(1h); > deadline.setDeadline(QDeadlineTimer::current().deadline() + 3600000); > deadline.setDeadline(std::chrono::steady_clock::now() + 1h); > > The problem are the getters: what do we call them? Qt6-only option... return a QTimeInterval or some such with (implicit) conversion operators. I expect there are issues with that, but feels worth mentioning at least for the sake of discussion. -- Matthew From konstantin at podsvirov.pro Fri Jun 10 22:54:23 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 10 Jun 2016 23:54:23 +0300 Subject: [Development] [ANNOUNCE] New Modules and Ports at DaD's House Message-ID: <4755441465592063@web10g.yandex.ru> Hi guys! Hello developers! My "DaD's Project" is based on CMake and QtIFW (specifically CPackIFW) continues its development: http://dad.podsvirov.pro - the official "DaD's House" website now. "DaD's House" is a resource where you can download the installers to install necessary dependencies and immediately begin developing their projects. Already declared support 40 the following modules: Curses, ZLib, LibPNG, Jpeg, Libxml2, LibTIFF, Perl, OpenSSL, LibSSH2, cURL, PCRE, PROJ, Expat, FreeType, SQLite, GEOS, GDAL, Boost, Qt, QtIFW, CMake KDSoap, OSG, osgEarth, osgQtQuick, PostgreSQL, Apache.Apr, The Apache.AprUtil, Apache.Httpd, Protobuf, gRPC, MapServer, Bullet, QCA, wxWidgets, LibXSLT, iconv, pgAdmin3, Wt, FreeGLUT. Also available in 4 port: - Windows Visual C++ Compiler 12.0 32bit - Windows Visual C++ Compiler 12.0 64bit and NEW - Windows 5.3.0 MinGW w64 32bit - Windows 5.3.0 MinGW w64 64bit The last 2 ports have appeared recently and there are still large but interesting work. All of this can be a good basis for your projects. All this is a good basis for my personal growth. I assess the status of the project as a Beta and write to lists for developers of basic technologies. Open the curtain. For each module I have a small CMakeLists.txt: http://git.podsvirov.pro/?a=project_list;pf=dad/mod These scripts help me to build the modules and create a repository of binary components. There is a need to spread content. All available here: http://download.podsvirov.pro My server is small and weak. I need help in distribution. I need a mirror "main" module: rsync://podsvirov.pro If there are interested parties and you give me the address of the mirror, then I can add them to MirrorBrain setup for more efficient distribution. If you are interested in developing this technology or already use my installers, I would like to hear your opinion and to get feedback. Have a great weekend and good luck in development of your projects! -- Regards, Konstantin Podsvirov From thiago.macieira at intel.com Sat Jun 11 01:27:18 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 10 Jun 2016 16:27:18 -0700 Subject: [Development] std::chrono getters in our API In-Reply-To: References: <1797177.exj0r56Drt@tjmaciei-mobl1> Message-ID: <4564607.cc6L2baFge@tjmaciei-mobl1> On sexta-feira, 10 de junho de 2016 16:12:10 PDT Matthew Woehlke wrote: > On 2016-06-10 13:53, Thiago Macieira wrote: > > I've added a set of std::chrono API to QTimer[1] and QDeadlineTimer[2] and > > we're hitting a snag on what to name the getters. The setters are fine > > because> > > they're just overloads: > > timer.setInterval(3); // Qt; milliseconds > > timer.setInterval(3ms); > > deadline.setRemainingTime(3600000); // milliseconds > > deadline.setRemainingTime(1h); > > deadline.setDeadline(QDeadlineTimer::current().deadline() + 3600000); > > deadline.setDeadline(std::chrono::steady_clock::now() + 1h); > > > > The problem are the getters: what do we call them? > > Qt6-only option... return a QTimeInterval or some such with (implicit) > conversion operators. QTimeInterval helps for std::chrono::duration, but not for the other use in QDeadlineTimer: deadline() returns the equivalent of a std::chrono::time_point. QDeadlineTimer *is* the equivalent of a std::chrono::time_point. > I expect there are issues with that, but feels worth mentioning at least > for the sake of discussion. So, you're suggesting not doing anything now, leave std::chrono support out in Qt 5, and do it only for Qt 6? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Jun 11 01:27:18 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 10 Jun 2016 16:27:18 -0700 Subject: [Development] std::chrono getters in our API In-Reply-To: References: <1797177.exj0r56Drt@tjmaciei-mobl1> Message-ID: <4564607.cc6L2baFge@tjmaciei-mobl1> On sexta-feira, 10 de junho de 2016 16:12:10 PDT Matthew Woehlke wrote: > On 2016-06-10 13:53, Thiago Macieira wrote: > > I've added a set of std::chrono API to QTimer[1] and QDeadlineTimer[2] and > > we're hitting a snag on what to name the getters. The setters are fine > > because> > > they're just overloads: > > timer.setInterval(3); // Qt; milliseconds > > timer.setInterval(3ms); > > deadline.setRemainingTime(3600000); // milliseconds > > deadline.setRemainingTime(1h); > > deadline.setDeadline(QDeadlineTimer::current().deadline() + 3600000); > > deadline.setDeadline(std::chrono::steady_clock::now() + 1h); > > > > The problem are the getters: what do we call them? > > Qt6-only option... return a QTimeInterval or some such with (implicit) > conversion operators. QTimeInterval helps for std::chrono::duration, but not for the other use in QDeadlineTimer: deadline() returns the equivalent of a std::chrono::time_point. QDeadlineTimer *is* the equivalent of a std::chrono::time_point. > I expect there are issues with that, but feels worth mentioning at least > for the sake of discussion. So, you're suggesting not doing anything now, leave std::chrono support out in Qt 5, and do it only for Qt 6? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Sat Jun 11 08:37:48 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 11 Jun 2016 08:37:48 +0200 Subject: [Development] std::chrono getters in our API In-Reply-To: <1797177.exj0r56Drt@tjmaciei-mobl1> References: <1797177.exj0r56Drt@tjmaciei-mobl1> Message-ID: <201606110837.50904.marc.mutz@kdab.com> On Friday 10 June 2016 19:53:00 Thiago Macieira wrote: > I've added a set of std::chrono API to QTimer[1] and QDeadlineTimer[2] and > we're hitting a snag on what to name the getters. The setters are fine > because they're just overloads: > > timer.setInterval(3); // Qt; milliseconds > timer.setInterval(3ms); > deadline.setRemainingTime(3600000); // milliseconds > deadline.setRemainingTime(1h); > deadline.setDeadline(QDeadlineTimer::current().deadline() + 3600000); > deadline.setDeadline(std::chrono::steady_clock::now() + 1h); > > The problem are the getters: what do we call them? We can't overload on > return value, so we can't use the standard getter name matching the > setters above, as it's already used for the Qt-style API: > > int r = timer.remainingTime(); // milliseconds > > I implemented an overload by way of templates: > > auto r = timer.remainingTime(); > > But some reviewers didn't like it and want the function to be non-template, > returning std::chrono::milliseconds, leaving the conversion to a different > type left as an exercise to the user. > > So: what do we do? > > Option 1: > - Use overload-by-template like I did > - Cons: > requires a template argument > - Pros: > avoids ugly > std::chrono::duration_cast(timer.remainingTime()); The external duration_cast isn't really necessary, because all calculations will work properly as long as you use auto: auto remaining = timer.timeRemainingAsDuration(); // Option 2 naming auto nextTimerStart = remaining + 1h; You only need to use duration_cast when you want to explicitly convert to a duration with less precision, usually only for display. > Option 2: > - Find a different name, not matching the setter name > - Cons: > doesn't match setter name > - Pros: > non-template To fill this abstracly-described option with life: we're talking about something like: std::chrono::milliseconds timeRemainingAsDuration() const > Option 3: > - Find a different name for both setters and getters > - Cons: > can't write > deadline.setRemainingTime(250ms); > - Pros: > clean API, but with some surprise factor > > Option 4: > - Find a different name for setters and getters, plus overload setters > - Cons: > a lot more template code in qtimer.h and qdeadlinetimer.h > - Pros: > clean API, but with some surprise factor > > Option 5: > - Drop std::chrono API > - Cons: > no QTimer::singleShot(5s, ...); > - Pros: > easiest > > NON Option: > - Use std::chrono only > - Why: > can't depend on it as the only way to access the time. Not to mention that > QTimer already has ABI set. > [1] https://codereview.qt-project.org/160889 > [2] https://codereview.qt-project.org/159932 -- 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 denis.shienkov at gmail.com Sat Jun 11 16:25:40 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sat, 11 Jun 2016 17:25:40 +0300 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? Message-ID: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> Hi all... Is it possible now? BR, Denis From thiago.macieira at intel.com Sun Jun 12 00:10:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 11 Jun 2016 15:10:12 -0700 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> Message-ID: <209452185.TcNEr94k6L@tjmaciei-mobl1> On sábado, 11 de junho de 2016 17:25:40 PDT Denis Shienkov wrote: > Hi all... > > Is it possible now? No, use of the C++11 Standard Library features is not permitted, outside of inline code with #ifdef. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From denis.shienkov at gmail.com Sun Jun 12 12:59:32 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sun, 12 Jun 2016 13:59:32 +0300 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: <209452185.TcNEr94k6L@tjmaciei-mobl1> References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <209452185.TcNEr94k6L@tjmaciei-mobl1> Message-ID: > No, use of the C++11 Standard Library features is not permitted Lousy to hear it... How to do then RAII to avoid a leaks e.g. for Windows handles (HANDLE, HKEY, HDEVINFO and other stuff)? BTW: But, I saw unique_ptr in qtbase and qt3d sources... 12.06.2016 1:10, Thiago Macieira пишет: > On sábado, 11 de junho de 2016 17:25:40 PDT Denis Shienkov wrote: >> Hi all... >> >> Is it possible now? > No, use of the C++11 Standard Library features is not permitted, outside of > inline code with #ifdef. > From perezmeyer at gmail.com Sun Jun 12 15:25:51 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Sun, 12 Jun 2016 10:25:51 -0300 Subject: [Development] QtSerialPort examples' license Message-ID: <2582371.2TkMKSxpAx@luna> I have just noted the QtSerialPort's examples' license are LGPL V2.1 or v3. Normally examples are BSD-licensed in order to let others reuse their code. Was this intentional or simply overlooked? Thanks in advance, Lisandro. -- 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 thiago.macieira at intel.com Sun Jun 12 20:42:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 12 Jun 2016 11:42:00 -0700 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <209452185.TcNEr94k6L@tjmaciei-mobl1> Message-ID: <1619963.Zc1x3TlNil@tjmaciei-mobl1> On domingo, 12 de junho de 2016 13:59:32 PDT Denis Shienkov wrote: > > No, use of the C++11 Standard Library features is not permitted > > Lousy to hear it... > > How to do then RAII to avoid a leaks e.g. for Windows handles (HANDLE, > HKEY, HDEVINFO and other stuff)? You can use it if you know all compilers compiling that code will support it. > BTW: But, I saw unique_ptr in qtbase and qt3d sources... In qtbase, it's found in: src/3rdparty/angle/src/libANGLE/Error.h src/3rdparty/angle/src/libANGLE/renderer/d3d/d3d11/Buffer11.cpp src/3rdparty/pcre/sljit/sljitNativeARM_32.c src/gui/text/qfontengine_p.h src/plugins/platforms/mirclient/qmirclientscreen.cpp src/plugins/platforms/mirclient/qmirclientwindow.cpp src/plugins/platforms/mirclient/qmirclientwindow.h And the qfontengine_p.h match is: class Holder { // replace by std::unique_ptr once available -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Sun Jun 12 23:54:01 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Sun, 12 Jun 2016 18:54:01 -0300 Subject: [Development] Making qtgraphicaleffects' tests work Message-ID: <3396580.urXCLd36ha@luna> Hi! As part of the Qt packaging effort we do with Qt we try, whenever possible, to run each submodule's unit tests. In qtgraphicaleffects we have come down to: FAIL! : tst_qtgraphicaleffects::blend() 'component.status() != QQmlComponent::Error' returned FALSE. (:3:1: Type Blend unavailable file:///<>/src/effects/Blend.qml:42:1: module "QtGraphicalEffects.private" is not installed) We are passing QML2_IMPORT_PATH=$(CURDIR)/qml to them (where CURDIR is of course the full path to the qml dir inside the build tree). Is there anything we are missing? Thanks in advance, Lisandro. -- 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 thiago.macieira at intel.com Mon Jun 13 04:39:28 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 12 Jun 2016 19:39:28 -0700 Subject: [Development] qtbase 5.7.0 changelog help In-Reply-To: <4706428.1QG8xGjaJp@tjmaciei-mobl1> References: <4706428.1QG8xGjaJp@tjmaciei-mobl1> Message-ID: <6792816.VlJtieR1S3@tjmaciei-mobl1> On terça-feira, 7 de junho de 2016 22:59:39 PDT Thiago Macieira wrote: > - QWheelEvent::phase() now returns 0 rather than Qt::ScrollUpdate when the > wheel event comes from an actual non-emulated mouse wheel and the > environment variable QT_ENABLE_MOUSE_WHEEL_TRACKING is set. In Qt 5.6, > this is required to enable the fix for QTBUG-50199. > [What's this about 5.6?] This has been fixed. The entries below will be deleted. > > * [QTBUG-53338] Fixed crash when comparing a initialized QAuthenticator > with an uninitialized QAuthenticator. > [What do you mean with uninitialized?] > > [Android section] > - Allow the user to choose how much from Android theme is extracted. > [how? A little more detail, please. And wrong tense] > > [moc section] > - [QTBUG-53441] Fixed crash on file ending with \\\r > [clarification needed on just what the file couldn't end in] -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From bo at vikingsoft.eu Mon Jun 13 06:47:44 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Mon, 13 Jun 2016 06:47:44 +0200 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <209452185.TcNEr94k6L@tjmaciei-mobl1> Message-ID: Den 12-06-2016 kl. 12:59 skrev Denis Shienkov: >> No, use of the C++11 Standard Library features is not permitted > > Lousy to hear it... > > How to do then RAII to avoid a leaks e.g. for Windows handles (HANDLE, > HKEY, HDEVINFO and other stuff)? QScopedPointer? Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From olivier at woboq.com Mon Jun 13 08:36:10 2016 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 13 Jun 2016 08:36:10 +0200 Subject: [Development] qtbase 5.7.0 changelog help In-Reply-To: <6792816.VlJtieR1S3@tjmaciei-mobl1> References: <4706428.1QG8xGjaJp@tjmaciei-mobl1> <6792816.VlJtieR1S3@tjmaciei-mobl1> Message-ID: <19288851.X2GYUASYfC@maurice> On Sonntag, 12. Juni 2016 19:39:28 CEST Thiago Macieira wrote: > On terça-feira, 7 de junho de 2016 22:59:39 PDT Thiago Macieira wrote: > > - QWheelEvent::phase() now returns 0 rather than Qt::ScrollUpdate when > > the > > > > wheel event comes from an actual non-emulated mouse wheel and the > > environment variable QT_ENABLE_MOUSE_WHEEL_TRACKING is set. In Qt 5.6, > > this is required to enable the fix for QTBUG-50199. > > > > [What's this about 5.6?] > > This has been fixed. > > The entries below will be deleted. > > > * [QTBUG-53338] Fixed crash when comparing a initialized QAuthenticator > > > > with an uninitialized QAuthenticator. > > > > [What do you mean with uninitialized?] > > > > [Android section] > > > > - Allow the user to choose how much from Android theme is extracted. > > > > [how? A little more detail, please. And wrong tense] > > > > [moc section] > > > > - [QTBUG-53441] Fixed crash on file ending with \\\r > > > > [clarification needed on just what the file couldn't end in] The file canot end in <0x0D> But this was a change for the 5.6.2 changelog From sean.harmer at kdab.com Mon Jun 13 09:51:48 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 13 Jun 2016 08:51:48 +0100 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> Message-ID: <12637396.GDoCKJdURm@titan> On Monday 13 June 2016 06:47:44 Bo Thorsen wrote: > Den 12-06-2016 kl. 12:59 skrev Denis Shienkov: > >> No, use of the C++11 Standard Library features is not permitted > > > > Lousy to hear it... > > > > How to do then RAII to avoid a leaks e.g. for Windows handles (HANDLE, > > HKEY, HDEVINFO and other stuff)? > > QScopedPointer? Not moveable. Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From abbapoh at gmail.com Mon Jun 13 10:10:00 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Mon, 13 Jun 2016 11:10:00 +0300 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: <12637396.GDoCKJdURm@titan> References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <12637396.GDoCKJdURm@titan> Message-ID: If we don't have unique_ptr, then, probably, we don't have move semantics too 2016-06-13 10:51 GMT+03:00 Sean Harmer : > On Monday 13 June 2016 06:47:44 Bo Thorsen wrote: > > Den 12-06-2016 kl. 12:59 skrev Denis Shienkov: > > >> No, use of the C++11 Standard Library features is not permitted > > > > > > Lousy to hear it... > > > > > > How to do then RAII to avoid a leaks e.g. for Windows handles (HANDLE, > > > HKEY, HDEVINFO and other stuff)? > > > > QScopedPointer? > > Not moveable. > > Sean > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Mon Jun 13 10:36:22 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 13 Jun 2016 08:36:22 +0000 Subject: [Development] QtSerialPort examples' license In-Reply-To: <2582371.2TkMKSxpAx@luna> References: <2582371.2TkMKSxpAx@luna> Message-ID: Hi, Which example/file you are talking about? License change should be done from 5.7 -> and I checked quickly the qtserialport examples & everything seems to be ok (like http://code.qt.io/cgit/qt/qtserialport.git/tree/examples/serialport/creaderasync/main.cpp?h=5.7.0) br, Jani ________________________________ From: Development on behalf of Lisandro Damián Nicanor Pérez Meyer Sent: Sunday, June 12, 2016 4:25 PM To: development at qt-project.org Subject: [Development] QtSerialPort examples' license I have just noted the QtSerialPort's examples' license are LGPL V2.1 or v3. Normally examples are BSD-licensed in order to let others reuse their code. Was this intentional or simply overlooked? Thanks in advance, Lisandro. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ Lisandro Damián Nicanor Pérez Meyer perezmeyer.com.ar open source web design by myhedspace.com - template available here © 2008 Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.m.winklmeier at gmail.com Mon Jun 13 10:42:19 2016 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Mon, 13 Jun 2016 10:42:19 +0200 Subject: [Development] Symbol strip warnings when installing release products on Mac OS X since 5.6.1 Message-ID: Dear list, I have upgraded my Mac OS X CI node to Qt 5.6.1. Since then I see several warnings at the build step 'make install' similar to: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: symbols referenced by indirect symbol table entries that can't be stripped in: /Users/jenkins/workspace/macosx_qt_5.6.1/build/dist/lib/ __ZN5QIconC1ERK7QPixmap __ZN6QBrushC1ERK6QColorN2Qt10BrushStyleE __ZN6QBrushD1Ev __ZN6QColor13setNamedColorERK7QString __ZN6QColor6setRgbEiiii __ZN6QColorC1EN2Qt11GlobalColorE __ZN6QImage4fillEN2Qt11GlobalColorE ... After some investigations, I found a difference between 5.6.0 and 5.6.1. 5.6.1 added a strip step for release builds, which was previously not there: -$(STRIP) $(INSTALL_ROOT)/Users/jenkins/workspace/macosx_qt_5.6.1/build/dist/lib/$(TARGET) After bit of googling I saw similar bug reports on KDE [1] and adding '-x' fixed it, but I'm not a strip expert. Question is now, am I doing anything wrong or was this an intentional change in 5.6.1? How can the warnings silenced best? Cheers Roland [1] https://bugs.kde.org/show_bug.cgi?id=288756 -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Mon Jun 13 12:16:12 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Mon, 13 Jun 2016 13:16:12 +0300 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <209452185.TcNEr94k6L@tjmaciei-mobl1> Message-ID: > QScopedPointer? Do you have real example? ;) 2016-06-13 7:47 GMT+03:00 Bo Thorsen : > Den 12-06-2016 kl. 12:59 skrev Denis Shienkov: > >> No, use of the C++11 Standard Library features is not permitted >>> >> >> Lousy to hear it... >> >> How to do then RAII to avoid a leaks e.g. for Windows handles (HANDLE, >> HKEY, HDEVINFO and other stuff)? >> > > QScopedPointer? > > Bo Thorsen, > Director, Viking Software. > > -- > Viking Software > Qt and C++ developers for hire > http://www.vikingsoft.eu > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Mon Jun 13 18:51:09 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 13 Jun 2016 13:51:09 -0300 Subject: [Development] QtSerialPort examples' license In-Reply-To: References: <2582371.2TkMKSxpAx@luna> Message-ID: <2200808.VMEVDBA8QZ@luna> On lunes, 13 de junio de 2016 8:36:22 A. M. ART you wrote: > Hi, > > > Which example/file you are talking about? License change should be done from > 5.7 -> and I checked quickly the qtserialport examples & everything seems > to be ok (like > http://code.qt.io/cgit/qt/qtserialport.git/tree/examples/serialport/creader > async/main.cpp?h=5.7.0) I'm looking at 5.6.1 here. Yes, licenses where cahnged in 5.7, sorry for not noticing it. -- The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. George Bernard Shaw 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 szehowe.koh at gmail.com Tue Jun 14 01:38:39 2016 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Tue, 14 Jun 2016 07:38:39 +0800 Subject: [Development] doc.qt.io: Camel-case URLs have stopped working In-Reply-To: References: Message-ID: Hello, One month ago, URLs that contain proper class names, e.g. http://doc.qt.io/qt-5/QObject.html, worked as expected. However, they now lead to Error 404. It looks like the server currently allows lowercase URLs only, e.g. http://doc.qt.io/qt-5/qobject.html This change might break bookmarks or links from external sources. Any chance of restoring the old behaviour? Regards, Sze-Howe -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Tue Jun 14 07:01:40 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 14 Jun 2016 05:01:40 +0000 Subject: [Development] Qt 5.7.0 Final packages available In-Reply-To: References: Message-ID: Hi all, We have now Qt 5.7.0 final packages available Windows: http://download.qt.io/snapshots/qt/5.7/5.7.0/505/ Linux: http://download.qt.io/snapshots/qt/5.7/5.7.0/450/ Mac: http://download.qt.io/snapshots/qt/5.7/5.7.0/386/ src: http://download.qt.io/snapshots/qt/5.7/5.7.0/latest_src Please test the packages & verify all works as expected. We are planning to release these packages as Qt 5.7.0 this Thursday if packages are good enough. So please take a tour immediately. Known issues in the packages: https://bugreports.qt.io/issues/?filter=17719 Please update the known issues page for the release as well: https://wiki.qt.io/Qt_5.7.0_Known_Issues Br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Tue Jun 14 09:29:30 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 14 Jun 2016 07:29:30 +0000 Subject: [Development] doc.qt.io: Camel-case URLs have stopped working In-Reply-To: References: , Message-ID: Sze Howe Koh > One month ago, URLs that contain proper class names, > e.g. http://doc.qt.io/qt-5/QObject.html, worked as expected. However, > they now lead to Error 404. It looks like the server currently allows > lowercase URLs only, e.g. http://doc.qt.io/qt-5/qobject.html > > This change might break bookmarks or links from external sources. Any > chance of restoring the old behaviour? If we're using Apache, mod_speling (sic) can handle that; enabling CheckCaseOnly should limit the cost of using it. Eddy. From szehowe.koh at gmail.com Tue Jun 14 13:22:27 2016 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Tue, 14 Jun 2016 19:22:27 +0800 Subject: [Development] Scope of source code license files In-Reply-To: <1c8d5145-e611-f3ef-1cd5-d2fda322b427@gmail.com> References: <2292E19B-3536-487A-AC63-FC8C3FE1031B@qt.io> <1c8d5145-e611-f3ef-1cd5-d2fda322b427@gmail.com> Message-ID: On 7 May 2016 at 12:20, Joseph Crowell wrote: > > On 4/05/2016 7:39 PM, Lars Knoll wrote: >> >> On 02/05/16 14:37, "Development on behalf of Sze Howe Koh" wrote: >> >> >> >>> Hello, >>> >>> The LICENSE.GPLvX and LICENSE.LGPLvX files from >>> http://code.qt.io/cgit/qt/qtbase.git/tree/ (and submodules) start with >>> "The Qt Toolkit is Copyright (C) 2015...", but then they go on to say >>> "You may use, distribute and copy the Qt GUI Toolkit under the terms >>> of..." >>> >>> Is this correct? What about non-GUI parts of the toolkit? >> >> The GUI in here is just a historical thing. It applies to Qt. > > > Wording should probably should be changed then as times have changed and Qt is certainly no longer just a GUI toolkit. Here's the first batch, targeting the "5.6" branch. If this is OK, I'll submit similar patches for the other repos too: https://codereview.qt-project.org/#/c/162394/ Some more questions: 1) What about http://code.qt.io/cgit/qt/qtbase.git/tree/LGPL_EXCEPTION.txt ? It's currently presented as additional permissions on top of LGPL v2.1. I presume LGPL v3.0 should be included too? 2) https://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ says that "Qt 5.7 will not be available under LGPLv2.1 anymore" -- Does that mean LICENSE.LGPLv21 should be removed from the 5.7 branch onwards? >> Cheers, >> Lars Regards, Sze-Howe From tero.kojo at qt.io Tue Jun 14 14:48:26 2016 From: tero.kojo at qt.io (Tero Kojo) Date: Tue, 14 Jun 2016 12:48:26 +0000 Subject: [Development] QtCon registration now open Message-ID: Hello, The registration for QtCon is now open at: http://conf.qtcon.org QtCon will take place in Berlin on 2-4th September. The event will be co-hosted with KDE, VideoLAN, FSFE, KDAB and Qt. For more information on QtCon go to: http://qtcon.org You can find the event schedule at: https://conf.qtcon.org/en/qtcon/public/schedule/2016-09-02 The schedule is a living document that is updated as more session chairs accept their slots. Right now is a good time to make sure you will participate in the event. Best regards, Tero -------------- next part -------------- An HTML attachment was scrubbed... URL: From vladstelmahovsky at gmail.com Tue Jun 14 15:34:02 2016 From: vladstelmahovsky at gmail.com (Vlad Stelmahovsky) Date: Tue, 14 Jun 2016 15:34:02 +0200 Subject: [Development] [Interest] QtLocation Map bearing and tilt Message-ID: Hi any plans to bring back bearing and tilt support for Map {} ? May be with Qt3D2 ? -- Best regards, Vlad -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo at vikingsoft.eu Tue Jun 14 17:03:15 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Tue, 14 Jun 2016 17:03:15 +0200 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <209452185.TcNEr94k6L@tjmaciei-mobl1> Message-ID: Den 13-06-2016 kl. 12:16 skrev Denis Shienkov: >> QScopedPointer? > > Do you have real example? ;) Well, as Sean wrote it lacks the move, but if all you're after is to use it for a pointer in a class or make a local dynamically allocated var exception safe, then QScopedPointer is fine. It's limited in it's use, but that doesn't mean it's unusable. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From annulen at yandex.ru Tue Jun 14 17:22:40 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 14 Jun 2016 18:22:40 +0300 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <209452185.TcNEr94k6L@tjmaciei-mobl1> Message-ID: <2473541465917760@web9m.yandex.ru> 14.06.2016, 18:03, "Bo Thorsen" : > Den 13-06-2016 kl. 12:16 skrev Denis Shienkov: >>>  QScopedPointer? >> >>  Do you have real example? ;) > > Well, as Sean wrote it lacks the move, but if all you're after is to use > it for a pointer in a class or make a local dynamically allocated var > exception safe, then QScopedPointer is fine. It's limited in it's use, > but that doesn't mean it's unusable. QScopedPointer lacks custom deleters which make it unusable for the purpose of managing Windows HANDLEs (see original post). However, author of [1] argues that managing non-pointer resources with unique_ptr + custom deleter is sub-par, and proposes different approach based on explicit specialization [1] http://accu.org/index.php/journals/2086 -- Regards, Konstantin From nospam at vuorela.dk Tue Jun 14 19:01:42 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Tue, 14 Jun 2016 17:01:42 +0000 (UTC) Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <209452185.TcNEr94k6L@tjmaciei-mobl1> <2473541465917760@web9m.yandex.ru> Message-ID: On 2016-06-14, Konstantin Tokarev wrote: > QScopedPointer lacks custom deleters which make it unusable for the purpose of managing Windows HANDLEs (see original post). You can pass your own classes as handlers, provided that they have a public static function void cleanup(T *pointer). - from the documentation. /Sune From jani.heikkinen at qt.io Wed Jun 15 08:26:47 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 15 Jun 2016 06:26:47 +0000 Subject: [Development] Qt 5.8 branching & Feature Freeze Message-ID: Hi all, It was agreed in yesterday's release team meeting to propose following schedule for Qt 5.8 branching and Feature Freeze: - Start branching '5.8' from 'dev': 2.8.2016 - Feature Freeze (and finalize branching): 9.8.2016 With that schedule we should be able to release Qt 5.8.0 before Christmas. Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of next year. Any objections? br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Wed Jun 15 09:15:16 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 15 Jun 2016 07:15:16 +0000 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: References: Message-ID: Hi, I would also like to have all new modules (if any) of Qt 5.8 as well as implement all (feasible) platform and compiler versions well before the feature freeze. Is it possible to agree that latest by 1.8. all these are completed? Preferably earlier, if possible. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 To: development at qt-project.org Subject: [Development] Qt 5.8 branching & Feature Freeze Hi all, It was agreed in yesterday's release team meeting to propose following schedule for Qt 5.8 branching and Feature Freeze: - Start branching '5.8' from 'dev': 2.8.2016 - Feature Freeze (and finalize branching): 9.8.2016 With that schedule we should be able to release Qt 5.8.0 before Christmas. Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of next year. Any objections? br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike.krus at kdab.com Wed Jun 15 10:51:08 2016 From: mike.krus at kdab.com (Mike Krus) Date: Wed, 15 Jun 2016 09:51:08 +0100 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: References: Message-ID: <1DBA0A7E-C597-49D5-870C-0336399D25F5@kdab.com> Hi would it be possible to have CI for tvOS in time for this too? Cheers, Mike > On 15 Jun 2016, at 08:15, Tuukka Turunen wrote: > > > Hi, > > I would also like to have all new modules (if any) of Qt 5.8 as well as implement all (feasible) platform and compiler versions well before the feature freeze. Is it possible to agree that latest by 1.8. all these are completed? Preferably earlier, if possible. > > Yours, > > Tuukka >   <> > From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Jani Heikkinen > Sent: keskiviikkona 15. kesäkuuta 2016 9.27 > To: development at qt-project.org > Subject: [Development] Qt 5.8 branching & Feature Freeze > > Hi all, > > It was agreed in yesterday's release team meeting to propose following schedule for Qt 5.8 branching and Feature Freeze: > > - Start branching '5.8' from 'dev': 2.8.2016 > - Feature Freeze (and finalize branching): 9.8.2016 > > With that schedule we should be able to release Qt 5.8.0 before Christmas. Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of next year. Any objections? > > br, > Jani > > > Jani Heikkinen > Release Manager > > The Qt Company > Elektroniikkatie 13 > 90590 Oulu Finland > jani.heikkinen at qt.io > +358 50 4873735 > http://qt.io > > > > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at qt.io Wed Jun 15 11:00:36 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 15 Jun 2016 09:00:36 +0000 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: <1DBA0A7E-C597-49D5-870C-0336399D25F5@kdab.com> References: <1DBA0A7E-C597-49D5-870C-0336399D25F5@kdab.com> Message-ID: +1. I requested this earlier as well. On Jun 15, 2016, at 1:51 AM, Mike Krus > wrote: Hi would it be possible to have CI for tvOS in time for this too? Cheers, Mike On 15 Jun 2016, at 08:15, Tuukka Turunen > wrote: Hi, I would also like to have all new modules (if any) of Qt 5.8 as well as implement all (feasible) platform and compiler versions well before the feature freeze. Is it possible to agree that latest by 1.8. all these are completed? Preferably earlier, if possible. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 To: development at qt-project.org Subject: [Development] Qt 5.8 branching & Feature Freeze Hi all, It was agreed in yesterday's release team meeting to propose following schedule for Qt 5.8 branching and Feature Freeze: - Start branching '5.8' from 'dev': 2.8.2016 - Feature Freeze (and finalize branching): 9.8.2016 With that schedule we should be able to release Qt 5.8.0 before Christmas. Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of next year. Any objections? br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Wed Jun 15 11:59:28 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 15 Jun 2016 09:59:28 +0000 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: References: <1DBA0A7E-C597-49D5-870C-0336399D25F5@kdab.com> Message-ID: Hi, Perhaps we could do without CI for tvOS for Qt 5.8 and fix issues when breakages happen. We are still quite stretched with the CI and adding tvOS increases the load of the CI and also risk of breakages for everyone. That of course is the role of CI, but since tvOS is not at the moment so critical, perhaps it is better to monitor it and fix afterwards when breakages do occur. Yours, Tuukka From: Jake Petroules Sent: keskiviikkona 15. kesäkuuta 2016 12.01 To: Mike Krus Cc: Tuukka Turunen ; development at qt-project.org Subject: Re: [Development] Qt 5.8 branching & Feature Freeze +1. I requested this earlier as well. On Jun 15, 2016, at 1:51 AM, Mike Krus > wrote: Hi would it be possible to have CI for tvOS in time for this too? Cheers, Mike On 15 Jun 2016, at 08:15, Tuukka Turunen > wrote: Hi, I would also like to have all new modules (if any) of Qt 5.8 as well as implement all (feasible) platform and compiler versions well before the feature freeze. Is it possible to agree that latest by 1.8. all these are completed? Preferably earlier, if possible. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 To: development at qt-project.org Subject: [Development] Qt 5.8 branching & Feature Freeze Hi all, It was agreed in yesterday's release team meeting to propose following schedule for Qt 5.8 branching and Feature Freeze: - Start branching '5.8' from 'dev': 2.8.2016 - Feature Freeze (and finalize branching): 9.8.2016 With that schedule we should be able to release Qt 5.8.0 before Christmas. Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of next year. Any objections? br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From fabrice.salvaire at orange.fr Wed Jun 15 13:28:39 2016 From: fabrice.salvaire at orange.fr (Fabrice Salvaire) Date: Wed, 15 Jun 2016 13:28:39 +0200 Subject: [Development] How to add OpenSSL support on Qt Android? Message-ID: Dear All, I tried to follow http://doc.qt.io/qt-5/opensslsupport.html but I couldn't succeed to have https working on Android. It seems this note is not up to date for 5.6 and later. Apparently Qt configure disables the OpenSSL Qt code due to the cross-compilation environment and if I try to force the OpenSSL library using the options I get a conflict with boringssl from webengine. I believe most devices have an openssl system library as on Linux (which should be boringssl on Android ?). Thus it should be just a configuration/cross-compilation issue. That is quite annoying since https is mandatory for some network services. Sincerely yours, Fabrice From bogdan.vatra at kdab.com Wed Jun 15 13:39:13 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Wed, 15 Jun 2016 14:39:13 +0300 Subject: [Development] How to add OpenSSL support on Qt Android? In-Reply-To: References: Message-ID: <14098193.CLaUQtgUjU@zmeu> Hi, That page is only for adding OpenSSL support to Qt SDK. If you're building Qt yourself, then you need to add "-openssl -I /path/to/openssl/headres" to configure params. Yours, BogDan. On Wednesday 15 June 2016 13:28:39 Fabrice Salvaire wrote: > Dear All, > > I tried to follow http://doc.qt.io/qt-5/opensslsupport.html but I > couldn't succeed to have https working on Android. > > It seems this note is not up to date for 5.6 and later. > > Apparently Qt configure disables the OpenSSL Qt code due to the > cross-compilation environment and if I try to force the OpenSSL library > using the options I get a conflict with boringssl from webengine. > > I believe most devices have an openssl system library as on Linux (which > should be boringssl on Android ?). Thus it should be just a > configuration/cross-compilation issue. > > That is quite annoying since https is mandatory for some network services. > > Sincerely yours, > > Fabrice > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From giuseppe.dangelo at kdab.com Wed Jun 15 15:44:09 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 15 Jun 2016 15:44:09 +0200 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <209452185.TcNEr94k6L@tjmaciei-mobl1> <2473541465917760@web9m.yandex.ru> Message-ID: <57615BA9.8010803@kdab.com> Il 14/06/2016 19:01, Sune Vuorela ha scritto: > You can pass your own classes as handlers, provided that they have a > public static function void cleanup(T *pointer). > > - from the documentation. However, you can't pass a per-QScopedPointer unique deleter object, which also makes this part of the API sub-par compared with the Standard... Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From Maurice.Kalinowski at qt.io Wed Jun 15 15:51:16 2016 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Wed, 15 Jun 2016 13:51:16 +0000 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: References: <1DBA0A7E-C597-49D5-870C-0336399D25F5@kdab.com> Message-ID: Hi, Another option might be to do it the same way like we do for UWP currently due to limited resources on the CI system. There we have at least a compile check every time qt5.git integration is supposed to happen. This is bare minimum, but at least guarantees that compilation will work for release. The rest still needs to be manually tested and/or is covered by Windows 8.1 WinRT test coverage (which isn't too high either). BR, Maurice Von: Development [mailto:development-bounces+maurice.kalinowski=qt.io at qt-project.org] Im Auftrag von Tuukka Turunen Gesendet: Wednesday, June 15, 2016 11:59 AM An: Jake Petroules ; Mike Krus Cc: development at qt-project.org Betreff: Re: [Development] Qt 5.8 branching & Feature Freeze Hi, Perhaps we could do without CI for tvOS for Qt 5.8 and fix issues when breakages happen. We are still quite stretched with the CI and adding tvOS increases the load of the CI and also risk of breakages for everyone. That of course is the role of CI, but since tvOS is not at the moment so critical, perhaps it is better to monitor it and fix afterwards when breakages do occur. Yours, Tuukka From: Jake Petroules Sent: keskiviikkona 15. kesäkuuta 2016 12.01 To: Mike Krus > Cc: Tuukka Turunen >; development at qt-project.org Subject: Re: [Development] Qt 5.8 branching & Feature Freeze +1. I requested this earlier as well. On Jun 15, 2016, at 1:51 AM, Mike Krus > wrote: Hi would it be possible to have CI for tvOS in time for this too? Cheers, Mike On 15 Jun 2016, at 08:15, Tuukka Turunen > wrote: Hi, I would also like to have all new modules (if any) of Qt 5.8 as well as implement all (feasible) platform and compiler versions well before the feature freeze. Is it possible to agree that latest by 1.8. all these are completed? Preferably earlier, if possible. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 To: development at qt-project.org Subject: [Development] Qt 5.8 branching & Feature Freeze Hi all, It was agreed in yesterday's release team meeting to propose following schedule for Qt 5.8 branching and Feature Freeze: - Start branching '5.8' from 'dev': 2.8.2016 - Feature Freeze (and finalize branching): 9.8.2016 With that schedule we should be able to release Qt 5.8.0 before Christmas. Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of next year. Any objections? br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jun 15 17:01:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Jun 2016 08:01:47 -0700 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: <57615BA9.8010803@kdab.com> References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <57615BA9.8010803@kdab.com> Message-ID: <2577181.JKBhG8X3Pj@tjmaciei-mobl1> On quarta-feira, 15 de junho de 2016 15:44:09 PDT Giuseppe D'Angelo wrote: > Il 14/06/2016 19:01, Sune Vuorela ha scritto: > > You can pass your own classes as handlers, provided that they have a > > public static function void cleanup(T *pointer). > > > > - from the documentation. > > However, you can't pass a per-QScopedPointer unique deleter object, > which also makes this part of the API sub-par compared with the Standard... Or, if you look at the same problem from a different angle, since QScopedPointer has the same size as a regular pointer, allowing you to replace a regular pointer in a class with it, without causing a binary compatibility break, its API is better than the Standard. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Jun 15 17:07:25 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 15 Jun 2016 18:07:25 +0300 Subject: [Development] Can we use std::unique_ptr in Qt base/modules sources since Qt5.7 ? In-Reply-To: <2577181.JKBhG8X3Pj@tjmaciei-mobl1> References: <50a791a3-f746-c3c5-f2bb-b1b924ce27ff@gmail.com> <57615BA9.8010803@kdab.com> <2577181.JKBhG8X3Pj@tjmaciei-mobl1> Message-ID: <5629831466003245@web11m.yandex.ru> 15.06.2016, 18:02, "Thiago Macieira" : > On quarta-feira, 15 de junho de 2016 15:44:09 PDT Giuseppe D'Angelo wrote: >>  Il 14/06/2016 19:01, Sune Vuorela ha scritto: >>  > You can pass your own classes as handlers, provided that they have a >>  > public static function void cleanup(T *pointer). >>  > >>  > - from the documentation. >> >>  However, you can't pass a per-QScopedPointer unique deleter object, >>  which also makes this part of the API sub-par compared with the Standard... > > Or, if you look at the same problem from a different angle, since > QScopedPointer has the same size as a regular pointer, allowing you to replace > a regular pointer in a class with it, without causing a binary compatibility > break, its API is better than the Standard. std::unique_ptr always has the same size as pointer. std::unique_ptr is different type (thought it also has the same size as pointer if Deleter is stateless) -- Regards, Konstantin From prashantpurohit025 at gmail.com Wed Jun 15 19:41:24 2016 From: prashantpurohit025 at gmail.com (Prashant Purohit) Date: Wed, 15 Jun 2016 23:11:24 +0530 Subject: [Development] Multiple Windows Dead-Lock Observed on QNX with Qt-5.3.2 Message-ID: Hi all, I am new to QT and using QT with QNX. I am using two different windows in my application (It is not possible for me to use single window). When I switch from one window to another window, My screen is not responding due to deadlock. Though there is no crash observed. My situation is similar to bug (https://bugreports.qt.io/browse/QTBUG-47553) which is already reported. By referencing above bug, when I set QSG_RENDER_LOOP=basic, the dead lock condition is prevented but then the animation which is being shown after every button press is not smooth anymore. Is there any better solution for above problem? If QSG_RENDER_LOOP=basic is the only solution then what I need to do to make the animation (sequencialAnimation on every button press) smooth as it was before setting the QSG_RENDER_LOOP environment variable? Also is there any alternative which I can use in my code other than setting QSG_RENDER_LOOP environment variable? Thanks, Prashant From thiago.macieira at intel.com Wed Jun 15 19:54:54 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Jun 2016 10:54:54 -0700 Subject: [Development] Multiple Windows Dead-Lock Observed on QNX with Qt-5.3.2 In-Reply-To: References: Message-ID: <2726381.rVxRQ2xRzH@tjmaciei-mobl1> On quarta-feira, 15 de junho de 2016 23:11:24 PDT Prashant Purohit wrote: > Hi all, > > I am new to QT and using QT with QNX. > I am using two different windows in my application (It is not possible > for me to use single window). > > When I switch from one window to another window, My screen is not > responding due to deadlock. Though there is no crash observed. > > My situation is similar to bug > (https://bugreports.qt.io/browse/QTBUG-47553) which is already > reported. > > By referencing above bug, when I set QSG_RENDER_LOOP=basic, the dead > lock condition is prevented but then the animation which is being > shown after every button press is not smooth anymore. > > Is there any better solution for above problem? > If QSG_RENDER_LOOP=basic is the only solution then what I need to do > to make the animation (sequencialAnimation on every button press) > smooth as it was before setting the QSG_RENDER_LOOP environment > variable? > > Also is there any alternative which I can use in my code other than > setting QSG_RENDER_LOOP environment variable? Hello Prashant Please upgrade. 5.3.2 is a year and a half old. We've just released 5.6.1 and we're about to release 5.7.0. Please try those. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jmcdonnell at blackberry.com Wed Jun 15 20:18:20 2016 From: jmcdonnell at blackberry.com (James McDonnell) Date: Wed, 15 Jun 2016 18:18:20 +0000 Subject: [Development] Multiple Windows Dead-Lock Observed on QNX with Qt-5.3.2 In-Reply-To: <2726381.rVxRQ2xRzH@tjmaciei-mobl1> References: <2726381.rVxRQ2xRzH@tjmaciei-mobl1> Message-ID: Hi Prashant, Can you provide the output for a ³pidin -p ² and a "pidin -p screen² when the system is in this state? James On 2016-06-15, 1:54 PM, "Development on behalf of Thiago Macieira" wrote: >On quarta-feira, 15 de junho de 2016 23:11:24 PDT Prashant Purohit wrote: >> Hi all, >> >> I am new to QT and using QT with QNX. >> I am using two different windows in my application (It is not possible >> for me to use single window). >> >> When I switch from one window to another window, My screen is not >> responding due to deadlock. Though there is no crash observed. >> >> My situation is similar to bug >> (https://bugreports.qt.io/browse/QTBUG-47553) which is already >> reported. >> >> By referencing above bug, when I set QSG_RENDER_LOOP=basic, the dead >> lock condition is prevented but then the animation which is being >> shown after every button press is not smooth anymore. >> >> Is there any better solution for above problem? >> If QSG_RENDER_LOOP=basic is the only solution then what I need to do >> to make the animation (sequencialAnimation on every button press) >> smooth as it was before setting the QSG_RENDER_LOOP environment >> variable? >> >> Also is there any alternative which I can use in my code other than >> setting QSG_RENDER_LOOP environment variable? > >Hello Prashant > >Please upgrade. 5.3.2 is a year and a half old. We've just released 5.6.1 >and >we're about to release 5.7.0. Please try 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 kfunk at kde.org Thu Jun 16 00:19:10 2016 From: kfunk at kde.org (Kevin Funk) Date: Thu, 16 Jun 2016 00:19:10 +0200 Subject: [Development] QtSingleApplication in Qt proper? Message-ID: <5472058.zq4xmWj7P0@kerberos> Heya, "We" as in the KDE developers now focus on bringing KDE software towards more platforms such as Mac OS X & Windows nowadays. We have discussed various ideas to ensure unique application instances on these platforms. Traditionally, KDE software is Linux focused and uses classes such as KUniqueApplication [1] and KDBusService [2] to ensure this; both of them requiring DBus for inter-process communication. This is usually not an option on said platforms and we're favoring the QtSingleApplication [3] approach for those. QtCreator is just one of its users. To come to the point: We'd like to be able to use QtSingleApplication, without having to copy it to every KDE application's repository out there and building it ourselves. Several KDE applications (KDevelop, Krita, Kate) already do so. Quite a few people asked for "how to implement single instance Qt applications" already and being pointed to QtSingleApplication: - http://stackoverflow.com/questions/5006547/qt-best-practice-for-a-single-instance-app-protection - http://www.qtcentre.org/threads/19661-Single-Application-Instance Question: Is there an interest in having QtSingleApplication in Qt proper? Say qtbase? We'd love to do the work if there's a chance for it being accepted. Alternative for us is to stick it into one of our KDE Frameworks, which does not directly benefit the Qt community. Opinions? Cheers, Kevin [1] https://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/ classKUniqueApplication.html [2] https://api.kde.org/frameworks/kdbusaddons/html/classKDBusService.html [3] http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/shared/ qtsingleapplication/ -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Thu Jun 16 00:38:33 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Jun 2016 15:38:33 -0700 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <5472058.zq4xmWj7P0@kerberos> References: <5472058.zq4xmWj7P0@kerberos> Message-ID: <18593794.FbyL7gGOHP@tjmaciei-mobl1> On quinta-feira, 16 de junho de 2016 00:19:10 PDT Kevin Funk wrote: > Is there an interest in having QtSingleApplication in Qt proper? Say > qtbase? We'd love to do the work if there's a chance for it being > accepted. I'd like it in QtCore, without being a derivation of QCoreApplication, and with the file ending up in $XDG_RUNTIME_DIR so it doesn't pollute my /tmp. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Thu Jun 16 03:43:29 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 16 Jun 2016 03:43:29 +0200 Subject: [Development] QtSingleApplication in Qt proper? References: <5472058.zq4xmWj7P0@kerberos> Message-ID: Kevin Funk wrote: > To come to the point: We'd like to be able to use QtSingleApplication, > without having to copy it to every KDE application's repository out there > and building it ourselves. Several KDE applications (KDevelop, Krita, > Kate) already do so. Why can't you simply require it as an external dependency? GNU/Linux distributions already package it as a standalone package. (See e.g. http://pkgs.fedoraproject.org/cgit/rpms/qtsingleapplication.git/tree/ which builds both the Qt 4 version and the Qt 5 version from the same upstream source code.) Kevin Kofler From tony.sarajarvi at qt.io Thu Jun 16 08:57:50 2016 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 16 Jun 2016 06:57:50 +0000 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: References: <1DBA0A7E-C597-49D5-870C-0336399D25F5@kdab.com> Message-ID: Hi, Our aim was to get new platforms in immediately after the previous platforms branched away from dev branch. Meaning, when 5.7 branch was created and it branched away from dev branch, all new platforms aiming for 5.8 should have been put into dev branch. However, in practice it didn't quite go as expected. Not to blame anyone, but all focus was to get 5.6.x and 5.7.x out. Meaning, dev branch was left broken for several months. The individual submodules did pass in the CI, but the last time Qt5 has passed is 4 months ago. To tackle this we agreed that we can start inserting new platforms submodule by submodule, but right after that we froze Coin setup so that we don't break 5.7.x by accident. And by having several branches, with alphas, betas, release candidates and releases themselves we have a lot of these freezes, which means that the time window, where we can put in any new platform, is very short. And if the submodule in dev don't happen to have everything merged from earlier branches and finally work, an insertion won't happen. This is why we've not been successful in bringing openSUSE 42.1, Ubuntu 16.04, RHEL 7.2, OS X 10.11 in into dev branch albeit trying to do that for months. So back to this day. Currently we can't put anything new in, since Coin setup is frozen. We have holidays coming up and we have a skeleton crew working the entire summer. Right as we get back to work, we have 5.8 branch coming up and feature freeze right after that. When did you expect us to push in these new platforms? According to process, we shouldn't put them into 5.8 after FF. If we bend this rule (as we usually do), we might get them in there as people focus on fixing issues there, or the same thing happens as happened with 5.7: the new platforms simply never passed autotests so that they could be brought in (we actually did try to get them into 5.7 early on, but not lately due to release being too close). Ok...perhaps I should propose something. Let's postpone branching 5.8. As much as I like the motto of Blizzard Entertainment "done when it's done" , I've found that people like time schedules as well. Alas, I have to suggest that we postpone it as much as possible. I think that we can fix the things we want to fix in 5.8 in dev branch as well. When we get a more mature dev branch that actually works, we can generate the alpha package for 5.8 much faster after the branch, as 5.8 already worked right of the bat (because dev worked). Also, we'll get a working dev branch as well simultaneously. Also, we've noticed that often when people fix problems found in autotests, being it a bug in the autotest itself or as it actually more often is, a problem in Qt sources themselves, people push the fix to the most mature branch available. In this case, when we report that we can't get openSUSE 42.1 in, because this and that fails, the fix is pushed into 5.6 as it already appears there but haven't been found or studied before. Then we have to sit down and in worst case wait for a 5.6.1 -> 5.6 -> 5.7 -> dev merge. With all the general flakiness in the system, that usually takes a fortnight at least. So by fixing dev, we can skip doing merges from 5.8 -> dev when we eventually find the problems for these new platforms. With regards, -Tony PS: The list with new platforms actually increases yet with OS X...ehm macOS Sierra (10.12) beta coming up, tvOS etc... From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Maurice Kalinowski Sent: 15. kesäkuuta 2016 16:51 To: Tuukka Turunen ; Jake Petroules ; Mike Krus Cc: development at qt-project.org Subject: Re: [Development] Qt 5.8 branching & Feature Freeze Hi, Another option might be to do it the same way like we do for UWP currently due to limited resources on the CI system. There we have at least a compile check every time qt5.git integration is supposed to happen. This is bare minimum, but at least guarantees that compilation will work for release. The rest still needs to be manually tested and/or is covered by Windows 8.1 WinRT test coverage (which isn't too high either). BR, Maurice Von: Development [mailto:development-bounces+maurice.kalinowski=qt.io at qt-project.org] Im Auftrag von Tuukka Turunen Gesendet: Wednesday, June 15, 2016 11:59 AM An: Jake Petroules ; Mike Krus Cc: development at qt-project.org Betreff: Re: [Development] Qt 5.8 branching & Feature Freeze Hi, Perhaps we could do without CI for tvOS for Qt 5.8 and fix issues when breakages happen. We are still quite stretched with the CI and adding tvOS increases the load of the CI and also risk of breakages for everyone. That of course is the role of CI, but since tvOS is not at the moment so critical, perhaps it is better to monitor it and fix afterwards when breakages do occur. Yours, Tuukka From: Jake Petroules Sent: keskiviikkona 15. kesäkuuta 2016 12.01 To: Mike Krus > Cc: Tuukka Turunen >; development at qt-project.org Subject: Re: [Development] Qt 5.8 branching & Feature Freeze +1. I requested this earlier as well. On Jun 15, 2016, at 1:51 AM, Mike Krus > wrote: Hi would it be possible to have CI for tvOS in time for this too? Cheers, Mike On 15 Jun 2016, at 08:15, Tuukka Turunen > wrote: Hi, I would also like to have all new modules (if any) of Qt 5.8 as well as implement all (feasible) platform and compiler versions well before the feature freeze. Is it possible to agree that latest by 1.8. all these are completed? Preferably earlier, if possible. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 To: development at qt-project.org Subject: [Development] Qt 5.8 branching & Feature Freeze Hi all, It was agreed in yesterday's release team meeting to propose following schedule for Qt 5.8 branching and Feature Freeze: - Start branching '5.8' from 'dev': 2.8.2016 - Feature Freeze (and finalize branching): 9.8.2016 With that schedule we should be able to release Qt 5.8.0 before Christmas. Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of next year. Any objections? br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [Image removed by sender.] [Image removed by sender.] [Image removed by sender.] [Image removed by sender.] [Image removed by sender.] [Image removed by sender.] _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 437 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 347 bytes Desc: image002.jpg URL: From cavendish.qi at gmail.com Thu Jun 16 09:44:33 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Thu, 16 Jun 2016 09:44:33 +0200 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: References: <1DBA0A7E-C597-49D5-870C-0336399D25F5@kdab.com> Message-ID: "Currently we can’t put anything new in, since Coin setup is frozen." Due to my limited knowledge with coin, I don't understand this. Coin, the new CI, should not bind with any paticular branch of Qt, but some options and scripts could. For the listed new OSes, openSUSE 42.1, Ubuntu 16.04, RHEL 7.2, OS X 10.11, if qt libs built failed, it should be P1 or P0 in current development branches, from 5.6. And for autotest failures, most could be blacklisted or skipped in the first step. The work for adding new untested platforms, need to be done in 5.6, as lower as possible. Like now, working with dev, then a fix need to be in 5.6, and a few more merges after that. I don't think it's smart. tvOS is a different story. For the integration of qt5.git dev branch was not a priority job before, because it will not be a blocker of near future releases. After a new 5.x branch out, it has more priority. And who is/are the integrator is also not very clear. Perhaps the thing is changing now. And recently 5.6, 5.6.1, 5.7, 5.7.0, dev, five branches and two releases together, some critical issues were found in 5.6.1, then needed to be in 5.7.0 too... Not a very good experience, at least for me. Perhaps it's because lacking of binaries for 5.6 snapshots, then not enough usage and testing. Best Regards, Liang On 16 June 2016 at 08:57, Tony Sarajärvi wrote: > Hi, > > > > Our aim was to get new platforms in immediately after the previous > platforms branched away from dev branch. Meaning, when 5.7 branch was > created and it branched away from dev branch, all new platforms aiming for > 5.8 should have been put into dev branch. However, in practice it didn’t > quite go as expected. Not to blame anyone, but all focus was to get 5.6.x > and 5.7.x out. Meaning, dev branch was left broken for several months. The > individual submodules did pass in the CI, but the last time Qt5 has passed > is 4 months ago. > > > > To tackle this we agreed that we can start inserting new platforms > submodule by submodule, but right after that we froze Coin setup so that we > don’t break 5.7.x by accident. And by having several branches, with alphas, > betas, release candidates and releases themselves we have a lot of these > freezes, which means that the time window, where we can put in any new > platform, is very short. And if the submodule in dev don’t happen to have > everything merged from earlier branches and finally work, an insertion > won’t happen. > > > > This is why we’ve not been successful in bringing openSUSE 42.1, Ubuntu > 16.04, RHEL 7.2, OS X 10.11 in into dev branch albeit trying to do that for > months. > > > > So back to this day. Currently we can’t put anything new in, since Coin > setup is frozen. We have holidays coming up and we have a skeleton crew > working the entire summer. Right as we get back to work, we have 5.8 branch > coming up and feature freeze right after that. When did you expect us to > push in these new platforms? According to process, we shouldn’t put them > into 5.8 after FF. If we bend this rule (as we usually do), we might get > them in there as people focus on fixing issues there, or the same thing > happens as happened with 5.7: the new platforms simply never passed > autotests so that they could be brought in (we actually did try to get them > into 5.7 early on, but not lately due to release being too close). > > > > Ok...perhaps I should propose something. Let’s postpone branching 5.8. As > much as I like the motto of Blizzard Entertainment “done when it’s done” , > I’ve found that people like time schedules as well. Alas, I have to suggest > that we postpone it as much as possible. I think that we can fix the things > we want to fix in 5.8 in dev branch as well. When we get a more mature dev > branch that actually works, we can generate the alpha package for 5.8 much > faster after the branch, as 5.8 already worked right of the bat (because > dev worked). Also, we’ll get a working dev branch as well simultaneously. > > > > Also, we’ve noticed that often when people fix problems found in > autotests, being it a bug in the autotest itself or as it actually more > often is, a problem in Qt sources themselves, people push the fix to the > most mature branch available. In this case, when we report that we can’t > get openSUSE 42.1 in, because this and that fails, the fix is pushed into > 5.6 as it already appears there but haven’t been found or studied before. > Then we have to sit down and in worst case wait for a 5.6.1 -> 5.6 -> 5.7 > -> dev merge. With all the general flakiness in the system, that usually > takes a fortnight at least. > > > > So by fixing dev, we can skip doing merges from 5.8 -> dev when we > eventually find the problems for these new platforms. > > > > With regards, > > -Tony > > > > PS: The list with new platforms actually increases yet with OS X…ehm macOS > Sierra (10.12) beta coming up, tvOS etc… > > > > *From:* Development [mailto:development-bounces+tony.sarajarvi= > qt.io at qt-project.org] *On Behalf Of *Maurice Kalinowski > *Sent:* 15. kesäkuuta 2016 16:51 > *To:* Tuukka Turunen ; Jake Petroules < > Jake.Petroules at qt.io>; Mike Krus > *Cc:* development at qt-project.org > > *Subject:* Re: [Development] Qt 5.8 branching & Feature Freeze > > > > Hi, > > > > Another option might be to do it the same way like we do for UWP currently > due to limited resources on the CI system. There we have at least a compile > check every time qt5.git integration is supposed to happen. > > > > This is bare minimum, but at least guarantees that compilation will work > for release. The rest still needs to be manually tested and/or is covered > by Windows 8.1 WinRT test coverage (which isn’t too high either). > > > > BR, > > Maurice > > > > *Von:* Development [mailto:development-bounces+maurice.kalinowski= > qt.io at qt-project.org] *Im Auftrag von *Tuukka Turunen > *Gesendet:* Wednesday, June 15, 2016 11:59 AM > *An:* Jake Petroules ; Mike Krus > > *Cc:* development at qt-project.org > *Betreff:* Re: [Development] Qt 5.8 branching & Feature Freeze > > > > > > Hi, > > > > Perhaps we could do without CI for tvOS for Qt 5.8 and fix issues when > breakages happen. We are still quite stretched with the CI and adding tvOS > increases the load of the CI and also risk of breakages for everyone. That > of course is the role of CI, but since tvOS is not at the moment so > critical, perhaps it is better to monitor it and fix afterwards when > breakages do occur. > > > > Yours, > > > > Tuukka > > > > > > *From:* Jake Petroules > *Sent:* keskiviikkona 15. kesäkuuta 2016 12.01 > *To:* Mike Krus > *Cc:* Tuukka Turunen ; development at qt-project.org > *Subject:* Re: [Development] Qt 5.8 branching & Feature Freeze > > > > +1. I requested this earlier as well. > > > > On Jun 15, 2016, at 1:51 AM, Mike Krus wrote: > > > > Hi > > > > would it be possible to have CI for tvOS in time for this too? > > > > > > Cheers, > > > > Mike > > > > > > On 15 Jun 2016, at 08:15, Tuukka Turunen wrote: > > > > > > Hi, > > > > I would also like to have all new modules (if any) of Qt 5.8 as well as > implement all (feasible) platform and compiler versions well before the > feature freeze. Is it possible to agree that latest by 1.8. all these are > completed? Preferably earlier, if possible. > > > > Yours, > > > > Tuukka > > > > *From:* Development [ > mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org > ] *On Behalf Of *Jani > Heikkinen > *Sent:* keskiviikkona 15. kesäkuuta 2016 9.27 > *To:* development at qt-project.org > *Subject:* [Development] Qt 5.8 branching & Feature Freeze > > > > Hi all, > > > > It was agreed in yesterday's release team meeting to propose following > schedule for Qt 5.8 branching and Feature Freeze: > > > > - Start branching '5.8' from 'dev': 2.8.2016 > > - Feature Freeze (and finalize branching): 9.8.2016 > > > > With that schedule we should be able to release Qt 5.8.0 before Christmas. > Delaying these would cause Qt 5.8.0 release to be delayed to the beginning > of next year. Any objections? > > > > br, > > Jani > > > > > > Jani Heikkinen > Release Manager > > The Qt Company > Elektroniikkatie 13 > 90590 Oulu Finland > jani.heikkinen at qt.io > +358 50 4873735 > http://qt.io > > > [image: Image removed by sender.] > > [image: Image removed by sender.] > > [image: Image removed by sender.] > > [image: Image removed by sender.] > > > [image: Image removed by sender.] > > > [image: Image removed by sender.] > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > -- > Mike Krus | mike.krus at kdab.com | Senior Software Engineer > KDAB (UK) Ltd., a KDAB Group company > Tel: UK +44-1625-809908 Mobile: +44 7833 491941 > KDAB - The Qt Experts > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > -- > Jake Petroules - jake.petroules at qt.io > Consulting Services Engineer - The Qt Company > > Qbs build system evangelist - qbs.io > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 347 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 437 bytes Desc: not available URL: From kfunk at kde.org Thu Jun 16 10:06:45 2016 From: kfunk at kde.org (Kevin Funk) Date: Thu, 16 Jun 2016 10:06:45 +0200 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: References: <5472058.zq4xmWj7P0@kerberos> Message-ID: <34116657.oWfQvrtZ9G@kerberos> On Donnerstag, 16. Juni 2016 03:43:29 CEST Kevin Kofler wrote: > Kevin Funk wrote: > > To come to the point: We'd like to be able to use QtSingleApplication, > > without having to copy it to every KDE application's repository out there > > and building it ourselves. Several KDE applications (KDevelop, Krita, > > Kate) already do so. > > Why can't you simply require it as an external dependency? GNU/Linux > distributions already package it as a standalone package. (See e.g. > http://pkgs.fedoraproject.org/cgit/rpms/qtsingleapplication.git/tree/ which > builds both the Qt 4 version and the Qt 5 version from the same upstream > source code.) I did not realize there are ready packages on some distributions out there. There isn't on Ubuntu at least (which is fixable of course). I also just now realize that qt-solutions.git has a maintained version of qtsingleapplication: https://code.qt.io/cgit/qt-solutions/qt-solutions.git/log/ qtsingleapplication I'd like to hear more opinions about whether there's still interest in having it in Qt proper. There are obviously advantages to it: CI coverage (qt- solutions.git isn't covered by CI, right?), and QtSA getting a bit of exposure so it does not feel like a, well, 3rdparty Qt solution. qt-solutions.git seems a place where deprecated components are kept alive, but not experiencing feature development in my book. Regards, Kevin > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From tim at klingt.org Thu Jun 16 11:05:42 2016 From: tim at klingt.org (Tim Blechmann) Date: Thu, 16 Jun 2016 11:05:42 +0200 Subject: [Development] 5.7.0-rc compile error Message-ID: hi all, compiling 5.7.0-rc (sometimes) fails with the following error when building qt as static library: > error 15-Jun-2016 20:04:06 make[4]: *** No rule to make target `/Volumes/build/bamboo-build/THIRDP-QT9-BUILDMAC/build-Qt-5.7.0-rc-macx-clang-static/qt3d/lib/libQt53DQuick_debug.a', needed by `../../../../qml/Qt3D/Extras/libquick3dextrasplugin_debug.a'. Stop. > error 15-Jun-2016 20:04:06 make[3]: *** [debug-all] Error 2 > error 15-Jun-2016 20:04:06 make[2]: *** [sub-quick3d-imports-extras-make_first] Error 2 probably an missing dependency for parallel builds as it doesn't happen all the time ... would be nice if this could be fixed before 5.7.0 comes out. thanks a lot, tim From jani.heikkinen at qt.io Thu Jun 16 11:27:45 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 16 Jun 2016 09:27:45 +0000 Subject: [Development] 5.7.0-rc compile error In-Reply-To: References: Message-ID: >>would be nice if this could be fixed before 5.7.0 comes out. Unfortunately impossible, Qt 5.7.0 is coming out today br, Jani ________________________________ From: Development on behalf of Tim Blechmann Sent: Thursday, June 16, 2016 12:05 PM To: development at qt-project.org Subject: [Development] 5.7.0-rc compile error hi all, compiling 5.7.0-rc (sometimes) fails with the following error when building qt as static library: > error 15-Jun-2016 20:04:06 make[4]: *** No rule to make target `/Volumes/build/bamboo-build/THIRDP-QT9-BUILDMAC/build-Qt-5.7.0-rc-macx-clang-static/qt3d/lib/libQt53DQuick_debug.a', needed by `../../../../qml/Qt3D/Extras/libquick3dextrasplugin_debug.a'. Stop. > error 15-Jun-2016 20:04:06 make[3]: *** [debug-all] Error 2 > error 15-Jun-2016 20:04:06 make[2]: *** [sub-quick3d-imports-extras-make_first] Error 2 probably an missing dependency for parallel builds as it doesn't happen all the time ... would be nice if this could be fixed before 5.7.0 comes out. thanks a lot, tim _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development Development Info Page - Qt lists.qt-project.org To see the collection of prior postings to the list, visit the Development Archives. Using Development: To post a message to all the list members ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From heliocastro at gmail.com Thu Jun 16 11:45:19 2016 From: heliocastro at gmail.com (Helio Chissini de Castro) Date: Thu, 16 Jun 2016 11:45:19 +0200 Subject: [Development] 5.7.0-rc compile error In-Reply-To: References: Message-ID: Are you trying out of the source builds ? I opened a ticket yesterday for this, specifically Qt3D, but it can compiles if you run from the root tree on the source. Regards On Thu, Jun 16, 2016 at 11:27 AM, Jani Heikkinen wrote: > >>would be nice if this could be fixed before 5.7.0 comes out. > > Unfortunately impossible, Qt 5.7.0 is coming out today > > > br, > > Jani > > > ------------------------------ > *From:* Development qt.io at qt-project.org> on behalf of Tim Blechmann > *Sent:* Thursday, June 16, 2016 12:05 PM > *To:* development at qt-project.org > *Subject:* [Development] 5.7.0-rc compile error > > hi all, > > compiling 5.7.0-rc (sometimes) fails with the following error when > building qt as static library: > > > error 15-Jun-2016 20:04:06 make[4]: *** No rule to make target > `/Volumes/build/bamboo-build/THIRDP-QT9-BUILDMAC/build-Qt-5.7.0-rc-macx-clang-static/qt3d/lib/libQt53DQuick_debug.a', > needed by `../../../../qml/Qt3D/Extras/libquick3dextrasplugin_debug.a'. > Stop. > > error 15-Jun-2016 20:04:06 make[3]: *** [debug-all] Error 2 > > error 15-Jun-2016 20:04:06 make[2]: *** > [sub-quick3d-imports-extras-make_first] Error 2 > > probably an missing dependency for parallel builds as it doesn't happen > all the time ... would be nice if this could be fixed before 5.7.0 comes > out. > > thanks a lot, > tim > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Development Info Page - Qt > > lists.qt-project.org > To see the collection of prior postings to the list, visit the Development > Archives. Using Development: To post a message to all the list members ... > > > _______________________________________________ > 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 tim at klingt.org Thu Jun 16 11:48:33 2016 From: tim at klingt.org (Tim Blechmann) Date: Thu, 16 Jun 2016 11:48:33 +0200 Subject: [Development] 5.7.0-rc compile error In-Reply-To: References: Message-ID: <1aa2de13-fd39-98ae-01d5-b07e42cbc968@klingt.org> > Are you trying out of the source builds ? that's my usual workflow as i need to compile static and dynamic libs from the same source folder ... > I opened a ticket yesterday for this, specifically Qt3D, but it can > compiles if you run from the root tree on the source. it also compiles fine when retrying a few times ... but that's not exactly an elegant workflow :P From announce at qt-project.org Thu Jun 16 12:18:55 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 16 Jun 2016 10:18:55 +0000 Subject: [Development] [Announce] Qt 5.7 is out Message-ID: Hi everybody, Just wanted to let you all know that Qt 5.7 is now released. For all the details, check out the blog post at http://blog.qt.io/blog/2016/06/16/qt-5-7-released/ and the web pages at http://www.qt.io/qt5-7/ Enjoy! Cheers, Lars _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From frederik.gladhorn at qt.io Thu Jun 16 12:22:02 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 16 Jun 2016 12:22:02 +0200 Subject: [Development] Qt 5.8 branching & Feature Freeze - Qt Speech TTS In-Reply-To: References: Message-ID: <1917414.azYWVMVJRv@frederik-thinkcentre-m93p> On onsdag 15. juni 2016 07.15.16 CEST Tuukka Turunen wrote: > Hi, > > I would also like to have all new modules (if any) of Qt 5.8 as well as > implement all (feasible) platform and compiler versions well before the > feature freeze. Is it possible to agree that latest by 1.8. all these are > completed? Preferably earlier, if possible. > I'd like to finally get Qt Speech in as Tech Preview in Qt 5.8. Only the text to speech parts, unless someone does major work on future proofing the speech recognition parts before the release. I'll start adding it to qt5.git - it already got green light for Qt 5.6 and got pushed further and further out since it had some compile issues at the time and everything got too tight schedule wise. Please let me know if there's some reason not to add it. Please also look through the API for inconsistencies and general blunders. It's a really small API, so shouldn't take much time. Maybe there's also stuff missing - I know there was a request to serialize and deserialize the current voice selection, that might for example be nice to add if anyone wants to work on a fun small module ;-) Cheers, Frederik > Yours, > > Tuukka > > From: Development > [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf > Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 > To: development at qt-project.org > Subject: [Development] Qt 5.8 branching & Feature Freeze > > > Hi all, > > > > It was agreed in yesterday's release team meeting to propose following > schedule for Qt 5.8 branching and Feature Freeze: > > > > - Start branching '5.8' from 'dev': 2.8.2016 > > - Feature Freeze (and finalize branching): 9.8.2016 > > > > With that schedule we should be able to release Qt 5.8.0 before Christmas. > Delaying these would cause Qt 5.8.0 release to be delayed to the beginning > of next year. Any objections? > > > > br, > > Jani > > > > > Jani Heikkinen > Release Manager > > The Qt Company > Elektroniikkatie 13 > 90590 Oulu Finland > jani.heikkinen at qt.io > +358 50 4873735 > http://qt.io > > > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rg > b_400x141.png] > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] p://www.facebook.com/Qt> > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] //www.twitter.com/qtproject> > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] s://www.linkedin.com/company/the-qt-company/> > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] tps://plus.google.com/104580575722059274792> > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] ://www.youtube.com/QtStudios> From tuukka.turunen at qt.io Thu Jun 16 12:51:39 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 16 Jun 2016 10:51:39 +0000 Subject: [Development] Qt 5.8 branching & Feature Freeze - Qt Speech TTS In-Reply-To: <1917414.azYWVMVJRv@frederik-thinkcentre-m93p> References: <1917414.azYWVMVJRv@frederik-thinkcentre-m93p> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Frederik > Gladhorn > Sent: torstaina 16. kesäkuuta 2016 13.22 > To: development at qt-project.org > Subject: Re: [Development] Qt 5.8 branching & Feature Freeze - Qt Speech > TTS > > On onsdag 15. juni 2016 07.15.16 CEST Tuukka Turunen wrote: > > Hi, > > > > I would also like to have all new modules (if any) of Qt 5.8 as well > > as implement all (feasible) platform and compiler versions well before > > the feature freeze. Is it possible to agree that latest by 1.8. all > > these are completed? Preferably earlier, if possible. > > > > I'd like to finally get Qt Speech in as Tech Preview in Qt 5.8. Only the text to > speech parts, unless someone does major work on future proofing the > speech recognition parts before the release. > There is some implementation for the speech recognition API as well for using a local recognizer. It would be nice to get that also polished, but if it is not feasible yet at least we can have the text to speech parts. But in case anyone is interested in the speech recognition as well, there is already a start to look into and polish. Yours, Tuukka > I'll start adding it to qt5.git - it already got green light for Qt 5.6 and got > pushed further and further out since it had some compile issues at the time > and everything got too tight schedule wise. > Please let me know if there's some reason not to add it. > > Please also look through the API for inconsistencies and general blunders. > It's a really small API, so shouldn't take much time. Maybe there's also stuff > missing - I know there was a request to serialize and deserialize the current > voice selection, that might for example be nice to add if anyone wants to > work on a fun small module ;-) > > Cheers, > Frederik > > > > Yours, > > > > Tuukka > > > > From: Development > > [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On > > Behalf Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 > > To: development at qt-project.org > > Subject: [Development] Qt 5.8 branching & Feature Freeze > > > > > > Hi all, > > > > > > > > It was agreed in yesterday's release team meeting to propose following > > schedule for Qt 5.8 branching and Feature Freeze: > > > > > > > > - Start branching '5.8' from 'dev': 2.8.2016 > > > > - Feature Freeze (and finalize branching): 9.8.2016 > > > > > > > > With that schedule we should be able to release Qt 5.8.0 before Christmas. > > Delaying these would cause Qt 5.8.0 release to be delayed to the > > beginning of next year. Any objections? > > > > > > > > br, > > > > Jani > > > > > > > > > > Jani Heikkinen > > Release Manager > > > > The Qt Company > > Elektroniikkatie 13 > > 90590 Oulu Finland > > jani.heikkinen at qt.io > > +358 50 4873735 > > http://qt.io > > > > > > > > [http://s3-eu-west-1.amazonaws.com/qt- > files/logos/qt_logo_with_text_gr > > een_rg > > b_400x141.png] > > [http://s3-eu-west-1.amazonaws.com/qt- > files/logos/SoMe/qt_facebook.png > > ] > p://www.facebook.com/Qt> > > > > [http://s3-eu-west-1.amazonaws.com/qt- > files/logos/SoMe/qt_twitter.png] > //www.twitter.com/qtproject> > > > > [http://s3-eu-west-1.amazonaws.com/qt- > files/logos/SoMe/qt_linkedin.png > > ] > > > > [http://s3-eu-west-1.amazonaws.com/qt- > files/logos/SoMe/qt_googleplus.p > > ng] > > > > [http://s3-eu-west-1.amazonaws.com/qt- > files/logos/SoMe/qt_youtube.png] > > > ://www.youtube.com/QtStudios> > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From philwave at gmail.com Thu Jun 16 12:53:29 2016 From: philwave at gmail.com (Philippe) Date: Thu, 16 Jun 2016 12:53:29 +0200 Subject: [Development] Qt 5.8 branching & Feature Freeze - Qt Speech TTS In-Reply-To: <1917414.azYWVMVJRv@frederik-thinkcentre-m93p> References: <1917414.azYWVMVJRv@frederik-thinkcentre-m93p> Message-ID: <20160616125327.2D9B.6F0322A@gmail.com> +1 Philippe On Thu, 16 Jun 2016 12:22:02 +0200 Frederik Gladhorn wrote: > On onsdag 15. juni 2016 07.15.16 CEST Tuukka Turunen wrote: > > Hi, > > > > I would also like to have all new modules (if any) of Qt 5.8 as well as > > implement all (feasible) platform and compiler versions well before the > > feature freeze. Is it possible to agree that latest by 1.8. all these are > > completed? Preferably earlier, if possible. > > > > I'd like to finally get Qt Speech in as Tech Preview in Qt 5.8. Only the text > to speech parts, unless someone does major work on future proofing the speech > recognition parts before the release. > > I'll start adding it to qt5.git - it already got green light for Qt 5.6 and > got pushed further and further out since it had some compile issues at the > time and everything got too tight schedule wise. > Please let me know if there's some reason not to add it. > > Please also look through the API for inconsistencies and general blunders. > It's a really small API, so shouldn't take much time. Maybe there's also stuff > missing - I know there was a request to serialize and deserialize the current > voice selection, that might for example be nice to add if anyone wants to work > on a fun small module ;-) > > Cheers, > Frederik > > > > Yours, > > > > Tuukka > > > > From: Development > > [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf > > Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 > > To: development at qt-project.org > > Subject: [Development] Qt 5.8 branching & Feature Freeze > > > > > > Hi all, > > > > > > > > It was agreed in yesterday's release team meeting to propose following > > schedule for Qt 5.8 branching and Feature Freeze: > > > > > > > > - Start branching '5.8' from 'dev': 2.8.2016 > > > > - Feature Freeze (and finalize branching): 9.8.2016 > > > > > > > > With that schedule we should be able to release Qt 5.8.0 before Christmas. > > Delaying these would cause Qt 5.8.0 release to be delayed to the beginning > > of next year. Any objections? > > > > > > > > br, > > > > Jani > > > > > > > > > > Jani Heikkinen > > Release Manager > > > > The Qt Company > > Elektroniikkatie 13 > > 90590 Oulu Finland > > jani.heikkinen at qt.io > > +358 50 4873735 > > http://qt.io > > > > > > > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rg > > b_400x141.png] > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] > p://www.facebook.com/Qt> > > > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] > //www.twitter.com/qtproject> > > > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] > s://www.linkedin.com/company/the-qt-company/> > > > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] > tps://plus.google.com/104580575722059274792> > > > > [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] > ://www.youtube.com/QtStudios> > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at qt.io Thu Jun 16 12:57:58 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 16 Jun 2016 10:57:58 +0000 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: References: <1DBA0A7E-C597-49D5-870C-0336399D25F5@kdab.com> Message-ID: Hi, Another approach for tvOS and other items that we can not have in by Qt 5.8 FF (or shortly after), would be to add these into dev after 5.8 has branched and have these in good time for Qt 5.9. Although we are constantly improving, we are not yet where we want in the CI flexibility and Qt is a complex platform. There are many important new features coming with Qt 5.8 and I would not want to risk getting these out in time by adding a lot of new platforms to CI at a late phase. Yours, Tuukka From: Tony Sarajärvi Sent: torstaina 16. kesäkuuta 2016 9.58 To: Maurice Kalinowski ; Tuukka Turunen ; Jake Petroules ; Mike Krus Cc: development at qt-project.org Subject: RE: [Development] Qt 5.8 branching & Feature Freeze Hi, Our aim was to get new platforms in immediately after the previous platforms branched away from dev branch. Meaning, when 5.7 branch was created and it branched away from dev branch, all new platforms aiming for 5.8 should have been put into dev branch. However, in practice it didn't quite go as expected. Not to blame anyone, but all focus was to get 5.6.x and 5.7.x out. Meaning, dev branch was left broken for several months. The individual submodules did pass in the CI, but the last time Qt5 has passed is 4 months ago. To tackle this we agreed that we can start inserting new platforms submodule by submodule, but right after that we froze Coin setup so that we don't break 5.7.x by accident. And by having several branches, with alphas, betas, release candidates and releases themselves we have a lot of these freezes, which means that the time window, where we can put in any new platform, is very short. And if the submodule in dev don't happen to have everything merged from earlier branches and finally work, an insertion won't happen. This is why we've not been successful in bringing openSUSE 42.1, Ubuntu 16.04, RHEL 7.2, OS X 10.11 in into dev branch albeit trying to do that for months. So back to this day. Currently we can't put anything new in, since Coin setup is frozen. We have holidays coming up and we have a skeleton crew working the entire summer. Right as we get back to work, we have 5.8 branch coming up and feature freeze right after that. When did you expect us to push in these new platforms? According to process, we shouldn't put them into 5.8 after FF. If we bend this rule (as we usually do), we might get them in there as people focus on fixing issues there, or the same thing happens as happened with 5.7: the new platforms simply never passed autotests so that they could be brought in (we actually did try to get them into 5.7 early on, but not lately due to release being too close). Ok...perhaps I should propose something. Let's postpone branching 5.8. As much as I like the motto of Blizzard Entertainment "done when it's done" , I've found that people like time schedules as well. Alas, I have to suggest that we postpone it as much as possible. I think that we can fix the things we want to fix in 5.8 in dev branch as well. When we get a more mature dev branch that actually works, we can generate the alpha package for 5.8 much faster after the branch, as 5.8 already worked right of the bat (because dev worked). Also, we'll get a working dev branch as well simultaneously. Also, we've noticed that often when people fix problems found in autotests, being it a bug in the autotest itself or as it actually more often is, a problem in Qt sources themselves, people push the fix to the most mature branch available. In this case, when we report that we can't get openSUSE 42.1 in, because this and that fails, the fix is pushed into 5.6 as it already appears there but haven't been found or studied before. Then we have to sit down and in worst case wait for a 5.6.1 -> 5.6 -> 5.7 -> dev merge. With all the general flakiness in the system, that usually takes a fortnight at least. So by fixing dev, we can skip doing merges from 5.8 -> dev when we eventually find the problems for these new platforms. With regards, -Tony PS: The list with new platforms actually increases yet with OS X...ehm macOS Sierra (10.12) beta coming up, tvOS etc... From: Development [mailto:development-bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Maurice Kalinowski Sent: 15. kesäkuuta 2016 16:51 To: Tuukka Turunen >; Jake Petroules >; Mike Krus > Cc: development at qt-project.org Subject: Re: [Development] Qt 5.8 branching & Feature Freeze Hi, Another option might be to do it the same way like we do for UWP currently due to limited resources on the CI system. There we have at least a compile check every time qt5.git integration is supposed to happen. This is bare minimum, but at least guarantees that compilation will work for release. The rest still needs to be manually tested and/or is covered by Windows 8.1 WinRT test coverage (which isn't too high either). BR, Maurice Von: Development [mailto:development-bounces+maurice.kalinowski=qt.io at qt-project.org] Im Auftrag von Tuukka Turunen Gesendet: Wednesday, June 15, 2016 11:59 AM An: Jake Petroules >; Mike Krus > Cc: development at qt-project.org Betreff: Re: [Development] Qt 5.8 branching & Feature Freeze Hi, Perhaps we could do without CI for tvOS for Qt 5.8 and fix issues when breakages happen. We are still quite stretched with the CI and adding tvOS increases the load of the CI and also risk of breakages for everyone. That of course is the role of CI, but since tvOS is not at the moment so critical, perhaps it is better to monitor it and fix afterwards when breakages do occur. Yours, Tuukka From: Jake Petroules Sent: keskiviikkona 15. kesäkuuta 2016 12.01 To: Mike Krus > Cc: Tuukka Turunen >; development at qt-project.org Subject: Re: [Development] Qt 5.8 branching & Feature Freeze +1. I requested this earlier as well. On Jun 15, 2016, at 1:51 AM, Mike Krus > wrote: Hi would it be possible to have CI for tvOS in time for this too? Cheers, Mike On 15 Jun 2016, at 08:15, Tuukka Turunen > wrote: Hi, I would also like to have all new modules (if any) of Qt 5.8 as well as implement all (feasible) platform and compiler versions well before the feature freeze. Is it possible to agree that latest by 1.8. all these are completed? Preferably earlier, if possible. Yours, Tuukka From: Development [mailto:development-bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Jani Heikkinen Sent: keskiviikkona 15. kesäkuuta 2016 9.27 To: development at qt-project.org Subject: [Development] Qt 5.8 branching & Feature Freeze Hi all, It was agreed in yesterday's release team meeting to propose following schedule for Qt 5.8 branching and Feature Freeze: - Start branching '5.8' from 'dev': 2.8.2016 - Feature Freeze (and finalize branching): 9.8.2016 With that schedule we should be able to release Qt 5.8.0 before Christmas. Delaying these would cause Qt 5.8.0 release to be delayed to the beginning of next year. Any objections? br, Jani Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io [Image removed by sender.] [Image removed by sender.] [Image removed by sender.] [Image removed by sender.] [Image removed by sender.] [Image removed by sender.] _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 437 bytes Desc: image001.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image002.jpg Type: image/jpeg Size: 347 bytes Desc: image002.jpg URL: From jedrzej.nowacki at qt.io Thu Jun 16 13:16:59 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 16 Jun 2016 13:16:59 +0200 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: References: Message-ID: <13210002.JkO6No2ATJ@42> On Thursday 16 of June 2016 06:57:50 Tony Sarajärvi wrote: > Hi, > > Our aim was to get new platforms in immediately after the previous platforms > branched away from dev branch. Meaning, when 5.7 branch was created and it > branched away from dev branch, all new platforms aiming for 5.8 should have > been put into dev branch. However, in practice it didn't quite go as > expected. Not to blame anyone, but all focus was to get 5.6.x and 5.7.x > out. Meaning, dev branch was left broken for several months. The individual > submodules did pass in the CI, but the last time Qt5 has passed is 4 months > ago. > > To tackle this we agreed that we can start inserting new platforms submodule > by submodule, but right after that we froze Coin setup so that we don't > break 5.7.x by accident. And by having several branches, with alphas, > betas, release candidates and releases themselves we have a lot of these > freezes, which means that the time window, where we can put in any new > platform, is very short. And if the submodule in dev don't happen to have > everything merged from earlier branches and finally work, an insertion > won't happen. > > This is why we've not been successful in bringing openSUSE 42.1, Ubuntu > 16.04, RHEL 7.2, OS X 10.11 in into dev branch albeit trying to do that for > months. > > So back to this day. Currently we can't put anything new in, since Coin > setup is frozen. We have holidays coming up and we have a skeleton crew > working the entire summer. Right as we get back to work, we have 5.8 branch > coming up and feature freeze right after that. When did you expect us to > push in these new platforms? According to process, we shouldn't put them > into 5.8 after FF. If we bend this rule (as we usually do), we might get > them in there as people focus on fixing issues there, or the same thing > happens as happened with 5.7: the new platforms simply never passed > autotests so that they could be brought in (we actually did try to get them > into 5.7 early on, but not lately due to release being too close). > > Ok...perhaps I should propose something. Let's postpone branching 5.8. As > much as I like the motto of Blizzard Entertainment "done when it's done" , > I've found that people like time schedules as well. Alas, I have to suggest > that we postpone it as much as possible. I think that we can fix the things > we want to fix in 5.8 in dev branch as well. When we get a more mature dev > branch that actually works, we can generate the alpha package for 5.8 much > faster after the branch, as 5.8 already worked right of the bat (because > dev worked). Also, we'll get a working dev branch as well simultaneously. > > Also, we've noticed that often when people fix problems found in autotests, > being it a bug in the autotest itself or as it actually more often is, a > problem in Qt sources themselves, people push the fix to the most mature > branch available. In this case, when we report that we can't get openSUSE > 42.1 in, because this and that fails, the fix is pushed into 5.6 as it > already appears there but haven't been found or studied before. Then we > have to sit down and in worst case wait for a 5.6.1 -> 5.6 -> 5.7 -> dev > merge. With all the general flakiness in the system, that usually takes a > fortnight at least. > > So by fixing dev, we can skip doing merges from 5.8 -> dev when we > eventually find the problems for these new platforms. > > With regards, > -Tony > > PS: The list with new platforms actually increases yet with OS X...ehm macOS > Sierra (10.12) beta coming up, tvOS etc... Hi, Ok, the process here is suboptimal, let' me extract certain aspects that can be handled separately. Qt5 dev is in disastrous state, nobody managed to pass CI from February. Having Qt5 working is crucial because otherwise, how can we distinguish between regressions in a new platform and just standard regressions. As you wrote Qt5 dev was not prioritized, because of two concurrent releases. That has to change, because state of Qt5 dev directly affects a next release. We have to accept the fact that we are doing 3-4 releases in parallel: LTS, current (potentially could be two of them) and next. Down-prioritizing one is just moving problems in time, which doesn't work with time based releases. We were not updating Coin in any way for last 2 weeks. That is an exceptional situation. I strongly believe that in future it will not be requested and we will limit such freeze just to test configurations not the whole system. New platforms are features, they affect releases in exactly the same way as code. So feature freeze should apply to them too and it is great that it was enforced. Now, porting to new platform also should be done as a feature development. No need to wait for branching. Technically waiting for merges is not necessary. Coin is able to test arbitrary refs from gerrit, I encourage you to not wait for the system, but just make bunch of changes and tests the expected combination, before it gets merged from stable branches. You can also request a feature branch for testing if you want to work that way. In the same time I agree, the merge cycle is too slow, it is just annoying. In my opinion the system should automatically create merge patches after each successful integration and warn if it was not possible because of conflicts. It seems also that I'm extremist in that area, but one merge per day seems to be a reasonable compromise. Sometimes it also makes sense to start porting to a new platform from LTS branch. Then you do not need to wait for merges at all and most of fixes goes to LTS anyway. Last, but probably the most important thing. Every time someone asks for a new platform, the request has to come together with resources. New platforms are not coming for free. I'm sure that Tony is willing to help as much as possible, but porting should be a team effort and expecting him to solve all tests problems is a bit unfair. So please coordinate such tasks :-) Cheers, Jędrek From rsanjuan at facing.uho.edu.cu Thu Jun 16 15:13:26 2016 From: rsanjuan at facing.uho.edu.cu (Reynaldo San Juan) Date: Thu, 16 Jun 2016 09:13:26 -0400 Subject: [Development] Building Always on same path? Message-ID: <5762A5F6.7010001@facing.uho.edu.cu> Hi I'm developing a litle app and I want to build always inside the user Home path. on Unix based systems is very easy puting the "~"char at the begining of the path, but o Windows "~" doesn't work, I used instead "%userprofile%" , like enviroment variable, but isn't working neither. Could you tell me how could I do that and use inside the .pro file to refer to enviroment vars? regards, Rey San Juan PD: Be nice with me, I'm a new one here :D & sorry my english. From Kai.Koehne at qt.io Thu Jun 16 15:25:50 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 16 Jun 2016 13:25:50 +0000 Subject: [Development] Building Always on same path? In-Reply-To: <5762A5F6.7010001@facing.uho.edu.cu> References: <5762A5F6.7010001@facing.uho.edu.cu> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Reynaldo San Juan > Sent: Thursday, June 16, 2016 3:13 PM > To: development at qt-project.org > Subject: [Development] Building Always on same path? > > Hi > I'm developing a litle app and > I want to build always inside the user Home path. on Unix based systems is > very easy puting the "~"char at the begining of the path, but o Windows "~" > doesn't work, I used instead "%userprofile%" , like enviroment variable, but > isn't working neither. > > Could you tell me how could I do that and use inside the .pro file to refer to > enviroment vars? > You can write $$getenv(USERPROFILE), or just $$(USERPROFILE) to get the contents of %USERPROFILE% environment variable http://doc.qt.io/qt-4.8/qmake-advanced-usage.html#variables > regards, > Rey San Juan > PD: Be nice with me, I'm a new one here :D & sorry my english. Let me just point out that this is the mailing list where things regarding Qt development itself are discussed. For questions on how to use Qt, please use to interest at qt-project.org Regards Kai From jedrzej.nowacki at qt.io Thu Jun 16 16:22:15 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 16 Jun 2016 16:22:15 +0200 Subject: [Development] Coin will be down on Tuesday 21st of June (6am-8am UTC+3) Message-ID: <2620124.1ofY3KSeSH@42> There is datacenter hardware maintenance break on Tuesday 21st of June (6am-8am UTC+3), Coin will be shutdown a bit earlier and hopefully restart after. Cheers, Jędrek From annulen at yandex.ru Thu Jun 16 19:03:09 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 16 Jun 2016 20:03:09 +0300 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <34116657.oWfQvrtZ9G@kerberos> References: <5472058.zq4xmWj7P0@kerberos> <34116657.oWfQvrtZ9G@kerberos> Message-ID: <3151466096589@web27o.yandex.ru> 16.06.2016, 11:07, "Kevin Funk" : > On Donnerstag, 16. Juni 2016 03:43:29 CEST Kevin Kofler wrote: >>  Kevin Funk wrote: >>  > To come to the point: We'd like to be able to use QtSingleApplication, >>  > without having to copy it to every KDE application's repository out there >>  > and building it ourselves. Several KDE applications (KDevelop, Krita, >>  > Kate) already do so. >> >>  Why can't you simply require it as an external dependency? GNU/Linux >>  distributions already package it as a standalone package. (See e.g. >>  http://pkgs.fedoraproject.org/cgit/rpms/qtsingleapplication.git/tree/ which >>  builds both the Qt 4 version and the Qt 5 version from the same upstream >>  source code.) > > I did not realize there are ready packages on some distributions out there. > There isn't on Ubuntu at least (which is fixable of course). > > I also just now realize that qt-solutions.git has a maintained version of > qtsingleapplication: >   https://code.qt.io/cgit/qt-solutions/qt-solutions.git/log/ > qtsingleapplication > > I'd like to hear more opinions about whether there's still interest in having > it in Qt proper. There are obviously advantages to it: CI coverage (qt- > solutions.git isn't covered by CI, right?), and QtSA getting a bit of exposure > so it does not feel like a, well, 3rdparty Qt solution. > > qt-solutions.git seems a place where deprecated components are kept alive, but > not experiencing feature development in my book. +1, it should be promoted to add-on at least. > > Regards, > Kevin > >>          Kevin Kofler >> >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > -- > Kevin Funk | kfunk at kde.org | http://kfunk.org > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From perezmeyer at gmail.com Thu Jun 16 19:18:22 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 16 Jun 2016 14:18:22 -0300 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <34116657.oWfQvrtZ9G@kerberos> References: <5472058.zq4xmWj7P0@kerberos> <34116657.oWfQvrtZ9G@kerberos> Message-ID: <3174235.uXZc8ugi6c@luna> On jueves, 16 de junio de 2016 10:06:45 A. M. ART Kevin Funk wrote: [snip] > I'd like to hear more opinions about whether there's still interest in > having it in Qt proper. There are obviously advantages to it: CI coverage > (qt- solutions.git isn't covered by CI, right?), and QtSA getting a bit of > exposure so it does not feel like a, well, 3rdparty Qt solution. +1. It used to be packaged in qt-solutions in Debian (and thus Ubuntu), but I would really love to see this part of Qt proper non the less. -- #exclude 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 thiago.macieira at intel.com Thu Jun 16 20:47:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Jun 2016 11:47:40 -0700 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <3151466096589@web27o.yandex.ru> References: <5472058.zq4xmWj7P0@kerberos> <34116657.oWfQvrtZ9G@kerberos> <3151466096589@web27o.yandex.ru> Message-ID: <2271361.cjpTf2nOvD@tjmaciei-mobl1> On quinta-feira, 16 de junho de 2016 20:03:09 PDT Konstantin Tokarev wrote: > +1, it should be promoted to add-on at least. As I said, I'd welcome it in QtCore, but a separate module is fine too. I've been wondering whether QtCore needs to be split in Qt 6. It's grown too big. At least the animation framework and state machine should move out, possibly the item models too. I'd like to move XML out too, but that would require moving MIME types out. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at qt.io Thu Jun 16 21:23:04 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Thu, 16 Jun 2016 19:23:04 +0000 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <2271361.cjpTf2nOvD@tjmaciei-mobl1> References: <5472058.zq4xmWj7P0@kerberos> <34116657.oWfQvrtZ9G@kerberos> <3151466096589@web27o.yandex.ru> <2271361.cjpTf2nOvD@tjmaciei-mobl1> Message-ID: <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> On 16/06/16 20:47, "Development on behalf of Thiago Macieira" wrote: >On quinta-feira, 16 de junho de 2016 20:03:09 PDT Konstantin Tokarev wrote: >> +1, it should be promoted to add-on at least. > >As I said, I'd welcome it in QtCore, but a separate module is fine too. I’d say Qt Core. This should not really require a large addition to it. > >I've been wondering whether QtCore needs to be split in Qt 6. It's grown too >big. At least the animation framework and state machine should move out, >possibly the item models too. It most certainly should. But how exactly is something we’ll need to discuss a bit more. > >I'd like to move XML out too, but that would require moving MIME types out. MIME types would be one of my primary candidates to move out. But we should consider removing the dependency of mimetypes onto XML in any case, by moving the conversion from XML to binary database into a compile step. Cheers, Lars > >-- >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 Jun 17 00:31:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Jun 2016 15:31:16 -0700 Subject: [Development] XML Mimetypes In-Reply-To: <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> References: <5472058.zq4xmWj7P0@kerberos> <2271361.cjpTf2nOvD@tjmaciei-mobl1> <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> Message-ID: <1665467.c0ceOP5Mzk@tjmaciei-mobl1> On quinta-feira, 16 de junho de 2016 19:23:04 PDT Lars Knoll wrote: > MIME types would be one of my primary candidates to move out. But we should > consider removing the dependency of mimetypes onto XML in any case, by > moving the conversion from XML to binary database into a compile step. Not sure that's a valid implementation of the spec. It's true that most systems will fall into one of two categories: 1) no system-wide XDG mime data at all 2) has both XML and binary data The question is whether there's a third category that has the XML data but no binary cache. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Fri Jun 17 01:31:15 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 16 Jun 2016 20:31:15 -0300 Subject: [Development] Documenting 3rd party license code (with SPDX?) In-Reply-To: References: Message-ID: <1789151.Z7tHbh5quT@luna> On lunes, 6 de junio de 2016 7:20:21 A. M. ART Kai Koehne wrote: > tl;dr: Does anyone have experience with SPDX? Not here, but... > Qt modules contain quite some 3rd party code under various (permissible) > licenses. We've been listening these in the documentation, but this is > certainly improvable - while the list is (hopefully) comprehensive, it > gives users little help in where the 3rd party code is actually used > (library, plugin, platform), what to do to avoid it (configure arguments?), > how to acknowledge distribution requirements ... > > The list is also managed centrally in qtdoc.git, which requires a lot of > effort to keep up to date with the other modules. My first step to > improve the situation is therefore to move the documentation to where the > code is actually located. At the same time I think it's a good idea not to > just write .qdoc, but use a more specific format that then can be > processed. > What I'd like to suggest eventually is that > - every code in our git modules where we don't have the relicensing rights > for needs to be under a '3rdparty' folder - every folder needs a > structured document that describes things like the license(s), copyright, > where the code originated ... > And that we then automatically process the documents to generate the > documentation. With my Debian maintainer hat on I would really love to see this implemented not only because of 3rd party licenses (because we will still need to recheck non the less) but because it might become possible to: - Now exactly how to avoid using the embedded code where possible - Now which code can not be (currently) de embedded (an area we packagers would surely like to help with). > Anyhow, first we have to settle on a file format. So far I have had a look > at two file formats: [snip] For the sake of completeness, here's another one: Definitely not the panacea but just another option. The "possible" plus is that the initial work is already done, but can definitely be improved. Some examples: We in Debian also have some tools to help us check for this kind of stuff (licensecheck, for example). Again, not panacea, but... > Personally I'm leaning > towards defining our own customized JSON format that uses the best things > from SPDX (standardized license id's) and README.Chromium. But I'd be glad > to discuss with people interested in the topic :) Personally I would prefer to avoid defining a new standard *except* there is a good reason to do so. -- 6: Cual es el boton del mouse que permite acceder a las acciones mas comunes del manejo de archivos * Depende el tipo de accion mas comun Damian Nadales http://mx.grulic.org.ar/lurker/message/20080307.141449.a70fb2fc.es.html Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From Jake.Petroules at qt.io Fri Jun 17 05:24:52 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 17 Jun 2016 03:24:52 +0000 Subject: [Development] VirtualBox 5.1 will migrate to Qt 5 Message-ID: <899A45FB-F67B-4E25-99F1-0E0F2A0F3CEC@qt.io> Hi all, Interesting little tidbit I thought I'd share with the community -- looks like VirtualBox is finally upgrading to Qt 5 (5.5.1, to be precise) in the upcoming 5.1 release. Nice to see some major Qt 4 users making the switch! https://forums.virtualbox.org/viewtopic.php?f=15&t=77998 strings VirtualBox.app/Contents/Frameworks/QtCoreVBox.framework/Versions/5/QtCoreVBox | grep 'Qt 5' Qt 5.5.1 (x86_64-little_endian-lp64 shared (dynamic) release build; by Clang 6.0 (clang-600.0.57) (Apple)) -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From denis.shienkov at gmail.com Fri Jun 17 07:15:15 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 17 Jun 2016 08:15:15 +0300 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> References: <5472058.zq4xmWj7P0@kerberos> <34116657.oWfQvrtZ9G@kerberos> <3151466096589@web27o.yandex.ru> <2271361.cjpTf2nOvD@tjmaciei-mobl1> <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> Message-ID: <92661711-5639-f1be-a4df-32c2d15a5fcc@gmail.com> > I’d say Qt Core. This should not really require a large addition to it. Do you mean QtSingleApplication or QtSolutions to QtCore? Because then QtSingleApplication should be removed from QtQtSolutions, as it will be in QtCore... :) And, what about QtService from QtSolutions ? BR, Denis 16.06.2016 22:23, Lars Knoll пишет: > On 16/06/16 20:47, "Development on behalf of Thiago Macieira" wrote: > >> On quinta-feira, 16 de junho de 2016 20:03:09 PDT Konstantin Tokarev wrote: >>> +1, it should be promoted to add-on at least. >> As I said, I'd welcome it in QtCore, but a separate module is fine too. > I’d say Qt Core. This should not really require a large addition to it. >> I've been wondering whether QtCore needs to be split in Qt 6. It's grown too >> big. At least the animation framework and state machine should move out, >> possibly the item models too. > It most certainly should. But how exactly is something we’ll need to discuss a bit more. >> I'd like to move XML out too, but that would require moving MIME types out. > MIME types would be one of my primary candidates to move out. But we should consider removing the dependency of mimetypes onto XML in any case, by moving the conversion from XML to binary database into a compile step. > > Cheers, > Lars > >> -- >> 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 Fri Jun 17 08:26:39 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Jun 2016 23:26:39 -0700 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <92661711-5639-f1be-a4df-32c2d15a5fcc@gmail.com> References: <5472058.zq4xmWj7P0@kerberos> <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> <92661711-5639-f1be-a4df-32c2d15a5fcc@gmail.com> Message-ID: <1820080.JoIe8Q6UKd@tjmaciei-mobl1> On sexta-feira, 17 de junho de 2016 08:15:15 PDT Denis Shienkov wrote: > > I’d say Qt Core. This should not really require a large addition to it. > > Do you mean QtSingleApplication or QtSolutions to QtCore? QtSingleApplication. I don't know what else is in Solutions, so I can't welcome them yet. > Because then QtSingleApplication should be removed from QtQtSolutions, > as it will be in QtCore... :) Probably not immediately, because like KStandardDirs, the API is likely to change when entering QtCore. > And, what about QtService from QtSolutions ? I don't know what that does. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From denis.shienkov at gmail.com Fri Jun 17 08:52:08 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 17 Jun 2016 09:52:08 +0300 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <1820080.JoIe8Q6UKd@tjmaciei-mobl1> References: <5472058.zq4xmWj7P0@kerberos> <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> <92661711-5639-f1be-a4df-32c2d15a5fcc@gmail.com> <1820080.JoIe8Q6UKd@tjmaciei-mobl1> Message-ID: <1350b687-23e8-f097-d9a6-c5f244cbaa72@gmail.com> >> And, what about QtService from QtSolutions ? > I don't know what that does. You can look to sources.. ;) "The QtService component is useful for developing Windows services and Unix daemons." BR, Denis 17.06.2016 9:26, Thiago Macieira пишет: > On sexta-feira, 17 de junho de 2016 08:15:15 PDT Denis Shienkov wrote: >> > I’d say Qt Core. This should not really require a large addition to it. >> >> Do you mean QtSingleApplication or QtSolutions to QtCore? > QtSingleApplication. I don't know what else is in Solutions, so I can't > welcome them yet. > >> Because then QtSingleApplication should be removed from QtQtSolutions, >> as it will be in QtCore... :) > Probably not immediately, because like KStandardDirs, the API is likely to > change when entering QtCore. > >> And, what about QtService from QtSolutions ? > I don't know what that does. > From annulen at yandex.ru Fri Jun 17 12:17:23 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 17 Jun 2016 13:17:23 +0300 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: <7347780.CP7BdC7Lnk@portia.local> 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> <7347780.CP7BdC7Lnk@portia.local> Message-ID: <2576451466158643@web23o.yandex.ru> 18.03.2016, 21:25, "René J. V. Bertin" : > 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? Hi René, This error was caused by a real problem in QtWebKit sources when it is compiled with -mmacosx-version-min=10.9 or higher. Fix for this bug and fix for another OS X 10.9 issue will be included in 5.6.2 release. -- Regards, Konstantin From bo at vikingsoft.eu Fri Jun 17 12:30:19 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Fri, 17 Jun 2016 12:30:19 +0200 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <1820080.JoIe8Q6UKd@tjmaciei-mobl1> References: <5472058.zq4xmWj7P0@kerberos> <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> <92661711-5639-f1be-a4df-32c2d15a5fcc@gmail.com> <1820080.JoIe8Q6UKd@tjmaciei-mobl1> Message-ID: Den 17-06-2016 kl. 08:26 skrev Thiago Macieira: >> And, what about QtService from QtSolutions ? > I don't know what that does. On Windows it implements the interface so you can register a Qt application as a service and the users can control from the standard windows services panel - starting, stopping, automatic startup etc. It also provides methods for controlling this from code. It works very well. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From pisoengracia at gmail.com Fri Jun 17 12:55:20 2016 From: pisoengracia at gmail.com (Jordi Pujol Foyo) Date: Fri, 17 Jun 2016 12:55:20 +0200 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: References: <5472058.zq4xmWj7P0@kerberos> <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> <92661711-5639-f1be-a4df-32c2d15a5fcc@gmail.com> <1820080.JoIe8Q6UKd@tjmaciei-mobl1> Message-ID: <5763D718.1000406@gmail.com> From QtService.cpp : "The QtService is a convenient template class that allows you to create a service for a particular application type. A Windows service or Unix daemon (a "service"), is a program that runs "in the background" independently of whether a user is logged in or not. A service is often set up to start when the machine boots up, and will typically run continuously as long as the machine is on. Services are usually non-interactive console applications. User interaction, if required, is usually implemented in a separate, normal GUI application that communicates with the service through an IPC channel. For simple communication, QtServiceController::sendCommand() and QtService::processCommand() may be used, possibly in combination with a shared settings file. For more complex, interactive communication, a custom IPC channel should be used, e.g. based on Qt's networking classes. (In certain circumstances, a service may provide a GUI itself, ref. the "interactive" example documentation)." +1 from me to add this to QtCore El 17/06/16 a les 12:30, Bo Thorsen ha escrit: > Den 17-06-2016 kl. 08:26 skrev Thiago Macieira: >>> And, what about QtService from QtSolutions ? >> I don't know what that does. > > On Windows it implements the interface so you can register a Qt > application as a service and the users can control from the standard > windows services panel - starting, stopping, automatic startup etc. > It also provides methods for controlling this from code. It works very > well. > > Bo Thorsen, > Director, Viking Software. > From Maurice.Kalinowski at qt.io Fri Jun 17 13:36:00 2016 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Fri, 17 Jun 2016 11:36:00 +0000 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <5763D718.1000406@gmail.com> References: <5472058.zq4xmWj7P0@kerberos> <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> <92661711-5639-f1be-a4df-32c2d15a5fcc@gmail.com> <1820080.JoIe8Q6UKd@tjmaciei-mobl1> <5763D718.1000406@gmail.com> Message-ID: > > +1 from me to add this to QtCore [Kalinowski Maurice] What is the purpose of adding those items to QtCore? Is it that it "feels" more stable when it is inside that module, or because you need this feature on a regular basis? At least personally, I never needed to implement a service, yet see it is useful to have a supported API in case I had to develop on such. But would I want to carry it around with every project I work on? Probably not... One can also follow previous discussions about bloating Qt Core with items and features that clearly were not meant for 90% of use-cases, still they got added to the module. This causes projects like Qt Lite to arise where you can leave those out again, coming with the cost of manually compiling Qt for your project and potentially losing support. Maurice From Lars.Knoll at qt.io Fri Jun 17 13:44:02 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Fri, 17 Jun 2016 11:44:02 +0000 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: References: <5472058.zq4xmWj7P0@kerberos> <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> <92661711-5639-f1be-a4df-32c2d15a5fcc@gmail.com> <1820080.JoIe8Q6UKd@tjmaciei-mobl1> <5763D718.1000406@gmail.com> Message-ID: <8FB3CD2E-7FF7-47C6-AB26-B9573514FD91@qt.io> On 17/06/16 13:36, "Development on behalf of Maurice Kalinowski" wrote: >> >> +1 from me to add this to QtCore >[Kalinowski Maurice] > >What is the purpose of adding those items to QtCore? >Is it that it "feels" more stable when it is inside that module, or because you need this feature on a regular basis? > >At least personally, I never needed to implement a service, yet see it is useful to have a supported API in case I had to develop on such. But would I want to carry it around with every project I work on? Probably not... > >One can also follow previous discussions about bloating Qt Core with items and features that clearly were not meant for 90% of use-cases, still they got added to the module. This causes projects like Qt Lite to arise where you can leave those out again, coming with the cost of manually compiling Qt for your project and potentially losing support. Yes, the purpose of QtCore is to provide the foundations. The stuff that most apps need. So features that are only useful for 10% of the applications should be in separate modules, unless they are tightly couples to stuff that’s already in Qt Core. And as Thiago already said, we’ll need to think about restructuring parts of Qt Core for Qt 6 (once we get there…), because it starts feeling a bit like a kitchen sink ;-) Cheers, Lars From Eike.Ziller at qt.io Fri Jun 17 13:52:49 2016 From: Eike.Ziller at qt.io (Eike Ziller) Date: Fri, 17 Jun 2016 11:52:49 +0000 Subject: [Development] Proposing David Schulz as maintainer for QtC text editors and CDB integration Message-ID: <83DCFB6D-97B8-4F1D-A855-436469E5E66B@qt.io> I propose David Schulz for Maintainer status for Qt Creator text editors and CDB integration. He has a long history in Qt Creator and factually maintained these areas for a long time now. https://codereview.qt-project.org/#/q/owner:%22David+Schulz+%253Cdavid.schulz%2540theqtcompany.com%253E%22,n,z Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From orgads at gmail.com Fri Jun 17 13:53:51 2016 From: orgads at gmail.com (Orgad Shaneh) Date: Fri, 17 Jun 2016 14:53:51 +0300 Subject: [Development] [Qt-creator] Proposing David Schulz as maintainer for QtC text editors and CDB integration In-Reply-To: <83DCFB6D-97B8-4F1D-A855-436469E5E66B@qt.io> References: <83DCFB6D-97B8-4F1D-A855-436469E5E66B@qt.io> Message-ID: +1 On Fri, Jun 17, 2016 at 2:52 PM, Eike Ziller wrote: > I propose David Schulz for Maintainer status for Qt Creator text editors > and CDB integration. > > He has a long history in Qt Creator and factually maintained these areas > for a long time now. > > > https://codereview.qt-project.org/#/q/owner:%22David+Schulz+%253Cdavid.schulz%2540theqtcompany.com%253E%22,n,z > > Br, Eike > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.ziller at qt.io > +123 45 6789012 > http://qt.io > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > > > > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at qt.io Fri Jun 17 14:06:06 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Fri, 17 Jun 2016 12:06:06 +0000 Subject: [Development] Revisiting high-DPI configuration options Message-ID: Hi all, After shipping the high-dpi update in 5.6 we’ve gotten several reports that application scaling does not always come out as intended (see QTBUG-52318, QTBUG-53416, QTBUG-53500, and QTBUG-54144). I’d like to take a look at this again. There are a lot of different configurations out there so I think one of the things we need is field testing to verify that what we are implementing works as intended. Ideally testers should be willing to apply patches and recompile Qt. The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to focus on two aspects: 1) Automatic scale factor configuration based on system settings. 2) Handling fractional scale factors (rounding). 1) Scale factor configuration. This is an issue on some platforms: - (Windows has landed on using per-screen logical DPI and should be fine.) - Android: We have some reports of Qt on some devices getting incorrect scale factors. If you have such as device available for testing I’d like to hear from you. - X11: Currently uses _both_ logical and physical DPI. This means the application comes out wrong if either are incorrectly set. Physical DPI is great for getting an accurate per-screen scale factor but has two flaws: We can’t always trust it (and we don’t know _when_ we can trust it), and it does not respect user settings (including our own QT_FONT_DPI). I suggest we move x11 over to using logical DPI (similar to Windows), perhaps having physical DPI as an option. It is my impression that getting per-screen logical DPI values from X11 is difficult. I’d very much appreciate feed back here from users on various desktops (KDE, GONME, other): Are there settings we can use? We need an API or read a config file. 2) Handling fractional scale factors This is relevant for e.g. a Windows setting of 250%, corresponding to a scale factor of 2.5. Presenting a fractional scale factor to the app may cause graphics glitches, so we round it to the nearest integer, using qRound. However, mathematically correct rounding may not be the best kind of correct in this case. In particular we should consider rounding factors of .5 down instead of up. The effect would be presenting an UI that is visually slightly smaller than it should be, over the current behavior of presenting an UI that is slightly larger. In addition we have the option of tweaking the DPI reported to the application to account for the remainder from the rounding. So for the 250% case we can report a devicePixelRatio of 2 and a DPI of 144. This relies on the existing DPI handling support (fonts scale automatically, rest of UI may not), but since the offset from the base DPI is small it might be OK. Finally, we should consider adding an option to simply let the fractional scale factor through. We have user reports of applications that work fine with such factors, save for one or two bugs in Qt. These are typically custom-styled applications that do not rely on the Qt platform styles. Allowing this as an option would not mean that fractional factors are supported in Qt (for the formal meaning of “supported"), nor that we necessarily spend time on fixing related issues. How do I test the new implementation? - Check out the patches for 5.6: (this is the last change in the series) https://codereview.qt-project.org/#/c/157175/ - Compile qtbase and tests/manual/highdpi - Run "./highdpi --metrics", or test with an application. - X11: Check if using the logical or physical DPI works for your displays QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_USE_PHYSICAL_DPI=0|1 ./highdpi --metrics - X11/Windows: Test how fractional scale factors work (if applicable) QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough ./applicaiton - X11 (mostly): Are you using non-Qt applications on the high-DPI displays? How do you configure them? As before, QT_SCALE_FACTOR can be used to set any scale factor for testing, and QT_FONT_DPI can be use the set the logical DPI (now expanded to work on Windows and macOS in addition to X11). Please report back here, or directly to me, or on tracking bug QTBUG-53022. Both reports of success or brokenness are interesting. Include the output from "./highdpi —metrics” with the report. Also feel free to ask questions if anything is unclear. Thanks! Morten From nikolai.kosjar at qt.io Fri Jun 17 14:29:50 2016 From: nikolai.kosjar at qt.io (Nikolai Kosjar) Date: Fri, 17 Jun 2016 14:29:50 +0200 Subject: [Development] Proposing David Schulz as maintainer for QtC text editors and CDB integration In-Reply-To: <83DCFB6D-97B8-4F1D-A855-436469E5E66B@qt.io> References: <83DCFB6D-97B8-4F1D-A855-436469E5E66B@qt.io> Message-ID: <5763ED3E.9090102@qt.io> On 06/17/2016 01:52 PM, Eike Ziller wrote: > I propose David Schulz for Maintainer status for Qt Creator text editors and CDB integration. +1 From rjvbertin at gmail.com Fri Jun 17 14:34:09 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 17 Jun 2016 14:34:09 +0200 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: <2576451466158643@web23o.yandex.ru> References: <2000886.r6WD1beTJ9@patux> <7347780.CP7BdC7Lnk@portia.local> <2576451466158643@web23o.yandex.ru> Message-ID: <7965572.Oa5fDHQiPp@portia.local> On Friday June 17 2016 13:17:23 Konstantin Tokarev wrote: Hi Konstantin, > > This error was caused by a real problem in QtWebKit sources when it is compiled > with -mmacosx-version-min=10.9 or higher. Fix for this bug and fix for another > OS X 10.9 issue will be included in 5.6.2 release. Hmmm, what 10.9 issue? I've just updated my Qt5 port to 5.6.1 and QtWebkit commit b889f460280ad98c89ede179bd3b9ce; is the fix you mention already included in there? Also, 5.6.2? Now that 5.7.0 is out? I'm a bit confused, are there reasons not to update to 5.7 apart from the fact it came really hot on the heels of 5.6.1 and sometimes it's nice not spending one's time doing updates? Regards, R. From pgorszkowski at gmail.com Fri Jun 17 14:42:20 2016 From: pgorszkowski at gmail.com (Przemyslaw Gorszkowski) Date: Fri, 17 Jun 2016 14:42:20 +0200 Subject: [Development] [Qt-creator] Proposing David Schulz as maintainer for QtC text editors and CDB integration In-Reply-To: References: <83DCFB6D-97B8-4F1D-A855-436469E5E66B@qt.io> Message-ID: +1 On Fri, Jun 17, 2016 at 1:53 PM, Orgad Shaneh wrote: > +1 > > On Fri, Jun 17, 2016 at 2:52 PM, Eike Ziller wrote: > >> I propose David Schulz for Maintainer status for Qt Creator text editors >> and CDB integration. >> >> He has a long history in Qt Creator and factually maintained these areas >> for a long time now. >> >> >> https://codereview.qt-project.org/#/q/owner:%22David+Schulz+%253Cdavid.schulz%2540theqtcompany.com%253E%22,n,z >> >> Br, Eike >> >> -- >> Eike Ziller >> Principal Software Engineer >> >> The Qt Company GmbH >> Rudower Chaussee 13 >> D-12489 Berlin >> eike.ziller at qt.io >> +123 45 6789012 >> http://qt.io >> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja >> Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht >> Charlottenburg, HRB 144331 B >> >> >> >> _______________________________________________ >> Qt-creator mailing list >> Qt-creator at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/qt-creator >> > > > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator > > -- Best regards/Pozdrawiam Przemyslaw Gorszkowski -------------- next part -------------- An HTML attachment was scrubbed... URL: From frank at hemer.org Fri Jun 17 14:54:45 2016 From: frank at hemer.org (Frank Hemer) Date: Fri, 17 Jun 2016 14:54:45 +0200 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: References: Message-ID: <2096409.Vgqk0hXBa4@master> Hi Morten, On Friday 17 June 2016 12:06:06 Morten Sorvig wrote: > Hi all, > > After shipping the high-dpi update in 5.6 we’ve gotten several reports > that application scaling does not always come out as intended (see > QTBUG-52318, QTBUG-53416, QTBUG-53500, and QTBUG-54144). I’d like to > take a look at this again. > > There are a lot of different configurations out there so I think one of > the things we need is field testing to verify that what we are implementing > works as intended. Ideally testers should be willing to apply patches and > recompile Qt. > > The scope of this is the Qt::AA_EnanbleHighDpiScaling mode. I’d like to > focus on two aspects: > > 1) Automatic scale factor configuration based on system settings. > 2) Handling fractional scale factors (rounding). > > > 1) Scale factor configuration. This is an issue on some platforms: > > - (Windows has landed on using per-screen logical DPI and should be fine.) > > - Android: We have some reports of Qt on some devices getting incorrect > scale factors. If you have such as device available for testing I’d like > to hear from you. > > - X11: Currently uses _both_ logical and physical DPI. This means the > application comes out wrong if either are incorrectly set. > > Physical DPI is great for getting an accurate per-screen scale factor > but has two flaws: We can’t always trust it (and we don’t know _when_ > we can trust it), and it does not respect user settings (including our > own QT_FONT_DPI). > > I suggest we move x11 over to using logical DPI (similar to Windows), > perhaps having physical DPI as an option. > > It is my impression that getting per-screen logical DPI values from X11 > is difficult. I’d very much appreciate feed back here from users on > various desktops (KDE, GONME, other): Are there settings we can use? We > need an API or read a config file. > > > 2) Handling fractional scale factors > > This is relevant for e.g. a Windows setting of 250%, corresponding to > a scale factor of 2.5. Presenting a fractional scale factor to the app > may cause graphics glitches, so we round it to the nearest integer, > using qRound. Can you give a hint on what causes these glitches and how to avoid them? I'm not talking about general usage of fractional methods for painting here. For example when drawing to a pixmap (sized for the 'real' screen resolution) and then updating just a sub-rectangle of this pixmap, for some (and really only some) fractional scale factor values there are glitches around that sub- rectangle where the background color of the window shines through. What is causing this? > However, mathematically correct rounding may not be the best kind of > correct in this case. In particular we should consider rounding factors > of .5 down instead of up. The effect would be presenting an UI that > is visually slightly smaller than it should be, over the current > behavior of presenting an UI that is slightly larger. > > In addition we have the option of tweaking the DPI reported to the > application to account for the remainder from the rounding. > So for the 250% case we can report a devicePixelRatio of 2 and a > DPI of 144. This relies on the existing DPI handling support (fonts > scale automatically, rest of UI may not), but since the offset from > the base DPI is small it might be OK. > > Finally, we should consider adding an option to simply let the fractional > scale factor through. We have user reports of applications that work > fine with such factors, save for one or two bugs in Qt. These are typically > custom-styled applications that do not rely on the Qt platform styles. > Allowing this as an option would not mean that fractional factors are > supported in Qt (for the formal meaning of “supported"), nor that we > necessarily spend time on fixing related issues. What is the reason for not aiming towards supporting fractional scale factors on the long run? What is the real challenge here? > How do I test the new implementation? > > - Check out the patches for 5.6: (this is the last change in the series) > https://codereview.qt-project.org/#/c/157175/ > > - Compile qtbase and tests/manual/highdpi > > - Run "./highdpi --metrics", or test with an application. > > - X11: Check if using the logical or physical DPI works for your displays > QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_USE_PHYSICAL_DPI=0|1 ./highdpi > --metrics > - X11/Windows: Test how fractional scale factors work (if applicable) > QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough > ./applicaiton > - X11 (mostly): Are you using non-Qt applications on the high-DPI displays? > How do you configure them? > > As before, QT_SCALE_FACTOR can be used to set any scale factor for testing, > and QT_FONT_DPI can be use the set the logical DPI (now expanded to work > on Windows and macOS in addition to X11). > > Please report back here, or directly to me, or on tracking bug QTBUG-53022. > Both reports of success or brokenness are interesting. Include the output > from "./highdpi —metrics” with the report. I really appreciate your effort in improving this:-) Frank From Tobias.Hunger at qt.io Fri Jun 17 14:56:26 2016 From: Tobias.Hunger at qt.io (Tobias Hunger) Date: Fri, 17 Jun 2016 12:56:26 +0000 Subject: [Development] Proposing David Schulz as maintainer for QtC text editors and CDB integration In-Reply-To: <83DCFB6D-97B8-4F1D-A855-436469E5E66B@qt.io> References: <83DCFB6D-97B8-4F1D-A855-436469E5E66B@qt.io> Message-ID: <1466168184.811.248.camel@qt.io> On Fr, 2016-06-17 at 11:52 +0000, Eike Ziller wrote: > I propose David Schulz for Maintainer status for Qt Creator text editors and > CDB integration. > > He has a long history in Qt Creator and factually maintained these areas for a > long time now. > > https://codereview.qt-project.org/#/q/owner:%22David+Schulz+%253Cdavid.schulz% > 2540theqtcompany.com%253E%22,n,z +1 from my side. Best Regards, Tobias -- Tobias Hunger, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From ritt.ks at gmail.com Fri Jun 17 15:42:33 2016 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Fri, 17 Jun 2016 17:42:33 +0400 Subject: [Development] Qt 5.7.0 Official Installer Message-ID: > The QtGamepad module is a technology preview of the API which provides classes and functions to access *CAN and ModBus*. ;) Regards, Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From vincent.seneclauze at spie.com Fri Jun 17 17:01:49 2016 From: vincent.seneclauze at spie.com (SENECLAUZE Vincent) Date: Fri, 17 Jun 2016 17:01:49 +0200 Subject: [Development] QtSerialBus : Function Code 20 and 21 not implemented Message-ID: <3EE8BD12F03211438C0D787CCD1B49150132A5474BAE@CCREX002.ce.int.amecspie.com> Hi everyone, I try to use the new QtSerialBus with the Qt 5.7.0, and during my test, the Function Code 20 and 21 answer Illegal Function. When I opened source code, I saw this : Line 662, File qmodbusserver.cpp : case QModbusRequest::ReadFileRecord: // TODO: Implement. case QModbusRequest::WriteFileRecord: // TODO: Implement. return QModbusExceptionResponse(request.functionCode(), QModbusExceptionResponse::IllegalFunction); My questions are : Why the documentation do not precise that this Function Code is not implemented ? And Is there a plan to finish this implementation in the next release ? or is someone have a kind of begining of source code or patch ? Best regards, Vincent SENECLAUZE ________________________________ ______________________________________________________________ Ce message et toutes les pi?ces jointes (ci-apr?s le "message") sont confidentiels et ?tablis ? l'intention exclusive de ses destinataires. Toute modification, ?dition, utilisation ou diffusion non autoris?e est interdite. Tout message ?lectronique est susceptible d'alt?ration. SPIE et ses filiales d?clinent toute responsabilit? au titre de ce message s'il a ?t? alt?r?, d?form?, falsifi?, ?dit? ou diffus? sans autorisation. This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised alteration , printing , use or dissemination is prohibited. E-mails are susceptible to alteration. SPIE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed, falsified, printed or disseminated without authorisation. ______________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Jun 17 17:41:35 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Jun 2016 08:41:35 -0700 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: References: Message-ID: <1897081.r3VhaQ2nYP@tjmaciei-mobl1> On sexta-feira, 17 de junho de 2016 12:06:06 PDT Morten Sorvig wrote: > It is my impression that getting per-screen logical DPI values from X11 > is difficult. I’d very much appreciate feed back here from users on > various desktops (KDE, GONME, other): Are there settings we can use? We > need an API or read a config file. There are expicitly no global settings on X11. There are two main settings, one for each of those environments: one in GSettings and the other is Qt's own. And as far as I can tell from the GTK side, it does not support mixing HiDPI monitors with non-HiDPI ones, something that Qt does. However, since it doesn't, it means I can't use Qt's feature. The other problem is that environment variables are not dynamic enough. What happens if I frequently connect to a HiDPI external monitor and a non-HiDPI one? (e.g., one in the office, the other at home) Everyone I ask about this gives the same answer: Wayland. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Fri Jun 17 18:30:15 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Fri, 17 Jun 2016 18:30:15 +0200 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <5763D718.1000406@gmail.com> References: <5472058.zq4xmWj7P0@kerberos> <47BAE389-BD4B-46AE-8EBE-20CF28E768FC@qt.io> <92661711-5639-f1be-a4df-32c2d15a5fcc@gmail.com> <1820080.JoIe8Q6UKd@tjmaciei-mobl1> <5763D718.1000406@gmail.com> Message-ID: <20160617163015.GA1376@klara.mpi.htwm.de> On Fri, Jun 17, 2016 at 12:55:20PM +0200, Jordi Pujol Foyo wrote: > From QtService.cpp : > > "The QtService is a convenient template class that allows > you to create a service for a particular application type. > > A Windows service or Unix daemon (a "service"), is a program that > runs "in the background" independently of whether a user is logged > in or not. A service is often set up to start when the machine > boots up, and will typically run continuously as long as the > machine is on. > > Services are usually non-interactive console applications. User > interaction, if required, is usually implemented in a separate, > normal GUI application that communicates with the service through > an IPC channel. For simple communication, > QtServiceController::sendCommand() and QtService::processCommand() > may be used, possibly in combination with a shared settings file. For > more complex, interactive communication, a custom IPC channel > should be used, e.g. based on Qt's networking classes. (In certain > circumstances, a service may provide a GUI itself, ref. the > "interactive" example documentation)." > > +1 from me to add this to QtCore ORLY? Maybe directly inline it in qglobal.h so it won't be overlooked? Andre' From mwoehlke.floss at gmail.com Fri Jun 17 21:54:28 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 17 Jun 2016 15:54:28 -0400 Subject: [Development] std::chrono getters in our API In-Reply-To: <4564607.cc6L2baFge@tjmaciei-mobl1> References: <1797177.exj0r56Drt@tjmaciei-mobl1> <4564607.cc6L2baFge@tjmaciei-mobl1> Message-ID: On 2016-06-10 19:27, Thiago Macieira wrote: > On sexta-feira, 10 de junho de 2016 16:12:10 PDT Matthew Woehlke wrote: >> On 2016-06-10 13:53, Thiago Macieira wrote: >>> I've added a set of std::chrono API to QTimer[1] and QDeadlineTimer[2] and >>> we're hitting a snag on what to name the getters. The setters are fine >>> because> >>> they're just overloads: >>> timer.setInterval(3); // Qt; milliseconds >>> timer.setInterval(3ms); >>> deadline.setRemainingTime(3600000); // milliseconds >>> deadline.setRemainingTime(1h); >>> deadline.setDeadline(QDeadlineTimer::current().deadline() + 3600000); >>> deadline.setDeadline(std::chrono::steady_clock::now() + 1h); >>> >>> The problem are the getters: what do we call them? >> >> Qt6-only option... return a QTimeInterval or some such with (implicit) >> conversion operators. > > QTimeInterval helps for std::chrono::duration, but not for the other use in > QDeadlineTimer: deadline() returns the equivalent of a > std::chrono::time_point. > > QDeadlineTimer *is* the equivalent of a std::chrono::time_point. > >> I expect there are issues with that, but feels worth mentioning at least >> for the sake of discussion. > > So, you're suggesting not doing anything now, leave std::chrono support out in > Qt 5, and do it only for Qt 6? I'm suggesting that a possible solution to the problem is to return a single complex type¹ that can be converted - perhaps implicitly - into the desired simple types (e.g. int milliseconds, std::chrono types). I wouldn't go so far as to claim that as the *best* solution :-). (¹ Or, the appropriate of several such types, as needed.) -- Matthew From thiago.macieira at intel.com Fri Jun 17 22:49:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Jun 2016 13:49:59 -0700 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: References: Message-ID: <23309410.drzYhCSC6U@tjmaciei-mobl1> > - Run "./highdpi --metrics", or test with an application. See 3 scenarios attached. I'll send a fourth scenario later, when I try at home with my 45" TV that reports its size as 160 x 90 mm. Software scaling (scenario 3) is achieved with: $ xrandr --output DP-1 --mode 1920x1080 --scale 2x2 --panning 3840x2160+3200+0 Note that 3840x2160 = 2 * 1920x1080 and 3200 is the width of my left (HighDPI) monitor. > - X11: Check if using the logical or physical DPI works for your displays > QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_USE_PHYSICAL_DPI=0|1 ./highdpi > --metrics See above. > - X11/Windows: Test how fractional scale factors work (if applicable) > QT_AUTO_SCREEN_SCALE_FACTOR=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough > ./applicaiton > - X11 (mostly): Are you using non-Qt applications on the high-DPI displays? > How do you configure them? Yes. Chromium and Firefox apparently configured themselves, after I set the X DPI (X is started with the option -dpi 216). I tried an extension to Firefox, but it wasn't necessary and only made things worse. I didn't try to restart X without the -dpi option, I only used xrandr to set it back to 96 when I calculated Scenario 2, so YMMV. For other GTK applications, I had to set the environment: $ cat ~/.config/plasma-workspace/env/var.sh export CLUTTER_SCALE=2 export GDK_SCALE=2 export QT_MESSAGE_PATTERN='[%{time boot}] %{appname}(%{pid} %{threadid}):%{if- category} %{category}:%{endif} %{message}' export QT_SCREEN_SCALE_FACTORS='2;2' For Qt 4 applications still left in the system, the only thing that worked was setting the X DPI to 216. The value 216 is lower than the actual screen DPI, but provides a reasonable experience. It was trial and error. Also, 216/96 = 2.25, which should help with rounding down. All non-Qt apps only work in Scenario 3 (software scaling of the external monitor). In Scenario 1 with QT_SCREEN_SCALE_FACTORS='2;1', Qt 5.6+ apps work fine, but non-Qt apps look huge on the external, normal-DPI monitor. Creator is also a bad citizen (worst of all Qt 5 applications I've tested), but I did not test it again in the scenarios above. When I tested before, I had to find the right combination that would make both the QML and non-QML parts of the UI look reasonable. Under some configurations, the text editor was the right size but the Welcome screen, the left and bottom panels would look too big, etc. > As before, QT_SCALE_FACTOR can be used to set any scale factor for testing, > and QT_FONT_DPI can be use the set the logical DPI (now expanded to work > on Windows and macOS in addition to X11). But you apparently removed the ability to set the scaling per-monitor. So this brings Qt back on par with other X11 HiDPI-aware applications. Hence the reply I get from everyone: use Wayland. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- == Scenario 1 == * High-DPI laptop screen, regular DPI external monitor * No X scaling * Monitors report correct size eDP-1 connected primary 3200x1800+0+0 (normal left inverted right x axis y axis) 294mm x 165mm DP-1 connected 1920x1080+3200+0 (normal left inverted right x axis y axis) 598mm x 336mm panning 1920x1080+3200+0 $ xdpyinfo| grep dots resolution: 217x218 dots per inch === With clear environment: === eDP-1: widget devicePixelRatio: 1 widget logicalDpi: 217 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 1 widget logicalDpi: 217 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: The window looks normal on the high-DPI screen, but huge on the normal monitor. === With QT_AUTO_SCREEN_SCALE_FACTOR=1: === eDP-1: widget devicePixelRatio: 4 widget logicalDpi: 121 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 4 widget logicalDpi: 121 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: The window looks huge on the high-DPI screen and "huger" on the normal one. === With QT_SCREEN_SCALE_FACTORS='2;1' === Same as with clear environment. With current Qt 5.7, this is the only case that works properly in this environment. === With QT_USE_PHYSICAL_DPI=1 === eDP-1: widget devicePixelRatio: 1 widget logicalDpi: 217 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 1 widget logicalDpi: 217 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: === With QT_USE_PHYSICAL_DPI=1 QT_AUTO_SCREEN_SCALE_FACTOR=1 === eDP-1: widget devicePixelRatio: 6 widget logicalDpi: 96 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 2 widget logicalDpi: 96 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: It's big on both and the window much larger than it needs to be. Can't be resized. === With QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough QT_AUTO_SCREEN_SCALE_FACTOR=1 === eDP-1: widget devicePixelRatio: 4.52309 widget logicalDpi: 96 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 4.52309 widget logicalDpi: 96 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: Big and huge. === QT_USE_PHYSICAL_DPI=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough QT_AUTO_SCREEN_SCALE_FACTOR=1 === eDP-1: widget devicePixelRatio: 5.76617 widget logicalDpi: 96 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 5.76617 widget logicalDpi: 96 platform screen logicalDpi: 217.109 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: Huge and big. -------------- next part -------------- A non-text attachment was scrubbed... Name: spectacle-scenario-2-drawing-errors.png Type: image/png Size: 56033 bytes Desc: not available URL: -------------- next part -------------- == Scenario 2 == * High-DPI laptop screen, regular DPI external monitor * No X scaling * Monitors report correct size eDP-1 connected primary 3200x1800+0+0 (normal left inverted right x axis y axis) 294mm x 165mm DP-1 connected 1920x1080+3200+0 (normal left inverted right x axis y axis) 598mm x 336mm panning 1920x1080+3200+0 $ xdpyinfo| grep dots resolution: 96x96 dots per inch Note: Firefox and Chromium are unusable in this scenario, so it's not acceptable. === With clear environment: === eDP-1: widget devicePixelRatio: 1 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 1 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: The window looks tiny (unreadable) on the high-DPI screen, but normal on the normal monitor. === With QT_AUTO_SCREEN_SCALE_FACTOR=1: === eDP-1: widget devicePixelRatio: 1 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 1 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: The window looks tiny on the high-DPI screen and normal on the normal one. === With QT_SCREEN_SCALE_FACTORS='2;1' === Same as with clear environment. With current Qt 5.7, this is the only case that works properly in this environment. === With QT_USE_PHYSICAL_DPI=1 === eDP-1: widget devicePixelRatio: 1 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 1 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: Same as above (tiny; normal). === With QT_USE_PHYSICAL_DPI=1 QT_AUTO_SCREEN_SCALE_FACTOR=1 === eDP-1: widget devicePixelRatio: 3 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 1 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: It's slightly too big on the high-DPI monitor; the font size is just right on the normal monitor, but the window is too big. === With QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough QT_AUTO_SCREEN_SCALE_FACTOR=1 === eDP-1: widget devicePixelRatio: 1.00049 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 1.00049 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: Tiny and normal. === QT_USE_PHYSICAL_DPI=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough QT_AUTO_SCREEN_SCALE_FACTOR=1 === eDP-1: widget devicePixelRatio: 2.88309 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 0.84996 widget logicalDpi: 96 platform screen logicalDpi: 96.0473 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 81.5973 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: Slightly too big on the High DPI monitor; just right on the normal one, but with lots of drawing errors when selecting the text. -------------- next part -------------- == Scenario 3 == * High-DPI laptop screen * Regular DPI external monitor, with software scaling down * Monitors report correct size eDP-1 connected primary 3200x1800+0+0 (normal left inverted right x axis y axis) 294mm x 165mm DP-1 connected 3840x2160+3200+0 (normal left inverted right x axis y axis) 598mm x 336mm panning 3840x2160+3200+0 $ xdpyinfo| grep dots resolution: 218x218 dots per inch Note: this is my current, normal environment in the office. The software scaling is SLOW, but works. === With clear environment: === eDP-1: widget devicePixelRatio: 1 widget logicalDpi: 218 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 1 widget logicalDpi: 218 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 163.195 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: Text has the correct size on both monitors. The window is created too small. === With QT_AUTO_SCREEN_SCALE_FACTOR=1: === eDP-1: widget devicePixelRatio: 4 widget logicalDpi: 122 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 4 widget logicalDpi: 122 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 163.195 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: Text is big on both. Window is created with the right size. === With QT_USE_PHYSICAL_DPI=1 === eDP-1: widget devicePixelRatio: 1 widget logicalDpi: 218 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 1 widget logicalDpi: 218 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 163.195 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 0 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: Text is normal on both, window is created too small. === With QT_USE_PHYSICAL_DPI=1 QT_AUTO_SCREEN_SCALE_FACTOR=1 === eDP-1: widget devicePixelRatio: 6 widget logicalDpi: 96 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 2 widget logicalDpi: 163 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 163.195 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: QT_DPI_ADJUSTMENT_POLICY: Text is huge on the High DPI monitor and just too big on the normal monitor. Window is created too large. === With QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough QT_AUTO_SCREEN_SCALE_FACTOR=1 === eDP-1: widget devicePixelRatio: 4.53755 widget logicalDpi: 96 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 4.53755 widget logicalDpi: 96 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 163.195 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: Text is a little too big on both monitors. Window is created at the right size. === QT_USE_PHYSICAL_DPI=1 QT_SCALE_FACTOR_ROUNDING_POLICY=PassThrough QT_AUTO_SCREEN_SCALE_FACTOR=1 === eDP-1: widget devicePixelRatio: 5.76617 widget logicalDpi: 96 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 276.777 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: DP-1: widget devicePixelRatio: 3.39989 widget logicalDpi: 96 platform screen logicalDpi: 217.803 platform screen logicalBaseDpi: 96 platform screen devicePixelRatio: 1 platform screen physicalDpi: 163.195 QT_FONT_DPI: QT_SCALE_FACTOR: QT_AUTO_SCREEN_SCALE_FACTOR: 1 QT_USE_PHYSICAL_DPI: 1 QT_SCALE_FACTOR_ROUNDING_POLICY: PassThrough QT_DPI_ADJUSTMENT_POLICY: Text is huge on the High DPI monitor and a little too big on the normal monitor. The window is created too large on the normal monitor and flashes huge text before changing to just-too-big. From thiago.macieira at intel.com Fri Jun 17 23:36:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Jun 2016 14:36:45 -0700 Subject: [Development] Reminder: Embedded Linux Conference Europe / OpenIoT Summit Europe CFP Message-ID: <8227507.f9pd7roFuk@tjmaciei-mobl1> Deadline is next Sunday, June 26. Both events happen in Berlin, on Oct 11-13, so I think there's not really any excuse for not having Qt sessions there. The deadline for LinuxCon Europe is today and it also happens in Berlin, the week before (Oct 4-6). I hope people submitted talks about Qt (I haven't). If you have a great idea but forgot to send something, do it over the weekend. http://events.linuxfoundation.org/events/linuxcon-europe http://events.linuxfoundation.org/events/linuxcon-europe/program/cfp http://events.linuxfoundation.org/events/embedded-linux-conference-europe/ program/cfp -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 17 23:40:24 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 17 Jun 2016 14:40:24 -0700 Subject: [Development] std::chrono getters in our API In-Reply-To: References: <1797177.exj0r56Drt@tjmaciei-mobl1> <4564607.cc6L2baFge@tjmaciei-mobl1> Message-ID: <1592924.bR4DfJ8BW6@tjmaciei-mobl1> On sexta-feira, 17 de junho de 2016 15:54:28 PDT Matthew Woehlke wrote: > > So, you're suggesting not doing anything now, leave std::chrono support > > out in Qt 5, and do it only for Qt 6? > > I'm suggesting that a possible solution to the problem is to return a > single complex type¹ that can be converted - perhaps implicitly - into > the desired simple types (e.g. int milliseconds, std::chrono types). I > wouldn't go so far as to claim that as the *best* solution :-). > > (¹ Or, the appropriate of several such types, as needed.) First of all, returning complex types that cast to the right value doesn't work for people using auto. You'd be storing this intermediate type instead of the correct one. Second, it can't be done in Qt 5 for QTimer. I'd rather not create difference between QTimer and QDeadlineTimer: the API should be the same. It's also unlikely we'll change it in Qt 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From massimocallegari at yahoo.it Sat Jun 18 16:41:34 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Sat, 18 Jun 2016 14:41:34 +0000 (UTC) Subject: [Development] Many congratulations and one question References: <666035978.9003066.1466260894705.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <666035978.9003066.1466260894705.JavaMail.yahoo@mail.yahoo.com> Hi everyone, today, instead of being the usual "complaining guy" I'd like to explicit my biggest congratulations and gratitude to all the people behind the Qt3D module. In particular to Sean Harmer and Paul Lemire at KDAB, who have been doing a monumental job working during weekends, fighting against CI breakage and taking care of an infinite number of JIRA issues and reports. I've been following the Qt3D developments for a couple of years and I have to say Qt3D is going to be an awesome addition to the Qt features set. I tried as much as I could to support the developments by testing patches and reporting issues and I hope I've been somehow helpful for the project. I'm also very excited by the Qt3D editor and I'd like to congratulate with all the Qt people behind it as well. Even if it's in a very early stage, you can already feel it is going to be an awesome tool ! So, well done everybody ! Now I've got a question for the Qt3D guys who knows all the techy bits of the current status of the module. It is my intention to implement the technique described in these AMD slides: https://developer.amd.com/wordpress/media/2012/10/Mitchell_LightShafts.pdf I am wondering if Qt3D can already cover such usage or if there are missing bits that are still not there or not planned at all. A plus for my project is if that technique can work in a deferred rendering pipeline. If KDAB/Qt is interested in such usage case, I am more than willing to contribute to the developments or even support a developer more skilled than me in the 3D area with a monetary contribution. Thanks again ! Massimo From annulen at yandex.ru Sat Jun 18 19:36:51 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 18 Jun 2016 20:36:51 +0300 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: <7965572.Oa5fDHQiPp@portia.local> References: <2000886.r6WD1beTJ9@patux> <7347780.CP7BdC7Lnk@portia.local> <2576451466158643@web23o.yandex.ru> <7965572.Oa5fDHQiPp@portia.local> Message-ID: <1991411466271411@web1h.yandex.ru> 17.06.2016, 15:34, "René J.V. Bertin" : > On Friday June 17 2016 13:17:23 Konstantin Tokarev wrote: > > Hi Konstantin, > >>  This error was caused by a real problem in QtWebKit sources when it is compiled >>  with -mmacosx-version-min=10.9 or higher. Fix for this bug and fix for another >>  OS X 10.9 issue will be included in 5.6.2 release. > > Hmmm, what 10.9 issue? I've just updated my Qt5 port to 5.6.1 and QtWebkit commit b889f460280ad98c89ede179bd3b9ce; is the fix you mention already included in there? No > > Also, 5.6.2? Now that 5.7.0 is out? I'm a bit confused, are there reasons not to update to 5.7 apart from the fact it came really hot on the heels of 5.6.1 and sometimes it's nice not spending one's time doing updates? Of course, 5.7.1 will also have these fixes > > Regards, > R. -- Regards, Konstantin From rjvbertin at gmail.com Sat Jun 18 20:37:45 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 18 Jun 2016 20:37:45 +0200 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: <1991411466271411@web1h.yandex.ru> References: <2000886.r6WD1beTJ9@patux> <7965572.Oa5fDHQiPp@portia.local> <1991411466271411@web1h.yandex.ru> Message-ID: <10265420.v8vWBT4eTP@portia.local> On Saturday June 18 2016 20:36:51 Konstantin Tokarev wrote: > > Also, 5.6.2? Now that 5.7.0 is out? I'm a bit confused, are there reasons not to update to 5.7 apart from the fact it came really hot on the heels of 5.6.1 and sometimes it's nice not spending one's time doing updates? > > Of course, 5.7.1 will also have these fixes Erm, I'd hope so, but what I meant was why release 5.6.2 after 5.7.0? That kind of suggests that there are platforms that 5.6 supports but not 5.7 ... R. From annulen at yandex.ru Sat Jun 18 20:39:58 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 18 Jun 2016 21:39:58 +0300 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: <10265420.v8vWBT4eTP@portia.local> References: <2000886.r6WD1beTJ9@patux> <7965572.Oa5fDHQiPp@portia.local> <1991411466271411@web1h.yandex.ru> <10265420.v8vWBT4eTP@portia.local> Message-ID: <2093491466275198@web17h.yandex.ru> 18.06.2016, 21:37, "René J.V. Bertin" : > On Saturday June 18 2016 20:36:51 Konstantin Tokarev wrote: > >>  > Also, 5.6.2? Now that 5.7.0 is out? I'm a bit confused, are there reasons not to update to 5.7 apart from the fact it came really hot on the heels of 5.6.1 and sometimes it's nice not spending one's time doing updates? >> >>  Of course, 5.7.1 will also have these fixes > > Erm, I'd hope so, but what I meant was why release 5.6.2 after 5.7.0? That kind of suggests that there are platforms that 5.6 supports but not 5.7 ... Qt 5.6 is LTS release: https://blog.qt.io/blog/2015/12/18/introducing-long-term-support/ -- Regards, Konstantin From annulen at yandex.ru Sun Jun 19 00:07:22 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 19 Jun 2016 01:07:22 +0300 Subject: [Development] [Announcement] QtWebKit Technology Preview 2 Message-ID: <1993301466287642@web29j.yandex.ru> Hi all, We are pleased to announce QtWebKit Technology Preview 2. You can find download links below [1]. This release includes bug fixes and improvements as compared to Technology Preview 1 [2]. Restored Web APIs to improve feature parity with QtWebKit 5.7: -------------------------------------------------------------- * Indexed Database. This is completely new implementation, which doesn't depend on LevelDB anymore, and is more compliant to modern W3C standards. * Media Source Extensions (only when GStreamer is used). This is still experimental, known issue is that some YouTube video with preroll advertisment are not playing, though it works fine in other cases. To enable it, use new attribute QWebSettings::MediaSourceEnabled. * Device motion and orientation API. * Gamepad API (on Linux only). * Enabled support like it was done in previous releases. Other improvements ------------------ * Support for OS X (>= 10.10) added. You can find build instructions at [3], or use binary build. * Integrations for qmake, cmake, and pkg-config are now installed. You can find instructions how to use them in your projects at [4]. * Enabled print support. * Documentation in HTML and QCH formats is now generated and installed. Prominent bug fixes ------------------- * Fixed missing text rendering on some sites. * Fixed copying to clipboard from web views. * Fixed some ABI compatibility issues. --------------------------------------------------- We are constantly progressing towards restoring feature parity with QtWebKit releases based on old WebKit branch, i.e. QtWebKit 5.6 and 5.7. You can track this progress at page [5]. -------------- Your help is very much needed! If you want to have your favorite features to be implemented faster, don't hesitate to join our team. There are a lot of different tasks, and many of them don't require knowledge of WebKit internals. For example it would be great if you helped us to review and improve our CMake code. Happy hacking, and stay tuned! --------------- [1] Source code: https://github.com/annulen/webkit/archive/qtwebkit-tp2.tar.gz https://github.com/annulen/webkit/archive/qtwebkit-tp2.zip Or use qtwebkit-tp2 tag from https://github.com/annulen/webkit git repository Binaries: Windows x86: https://dl.dropboxusercontent.com/u/30021413/qtwebkit-tp2-msvc2015-x86.zip Windows x64: https://www.dropbox.com/s/wmfbwzf0ygcafr1/qtwebkit-tp2-msvc2015-x64.zip OS X: https://dl.dropboxusercontent.com/u/30021413/QtWebKit.zip [2] https://lists.webkit.org/pipermail/webkit-qt/2016-May/004062.html [3] https://github.com/annulen/webkit/wiki/Building-QtWebKit-on-OS-X [4] https://github.com/annulen/webkit/wiki/Using-QtWebKit-in-your-project [5] https://github.com/annulen/webkit/wiki/Comparison-with-QtWebKit-5.6 -- Regards, Konstantin From mitya57.ml at gmail.com Sun Jun 19 10:05:58 2016 From: mitya57.ml at gmail.com (Dmitry Shachnev) Date: Sun, 19 Jun 2016 11:05:58 +0300 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <34116657.oWfQvrtZ9G@kerberos> References: <5472058.zq4xmWj7P0@kerberos> <34116657.oWfQvrtZ9G@kerberos> Message-ID: <20160619080558.GA1875@mitya57.me> Hi all, On Thu, Jun 16, 2016 at 10:06:45AM +0200, Kevin Funk wrote: > I did not realize there are ready packages on some distributions out there. > There isn't on Ubuntu at least (which is fixable of course). > > I also just now realize that qt-solutions.git has a maintained version of > qtsingleapplication: > https://code.qt.io/cgit/qt-solutions/qt-solutions.git/log/ > qtsingleapplication > > I'd like to hear more opinions about whether there's still interest in having > it in Qt proper. There are obviously advantages to it: CI coverage (qt- > solutions.git isn't covered by CI, right?), and QtSA getting a bit of exposure > so it does not feel like a, well, 3rdparty Qt solution. I would very much appreciate having it promoted as a proper part of Qt, either in qtbase or as a separate module. Another advantage of that will be its inclusion in bindings packages, such as PyQt. > qt-solutions.git seems a place where deprecated components are kept alive, but > not experiencing feature development in my book. One potential problem with that code is that QtLockedFile from QtSolutions duplicates the functionality of QLockFile in qtcore (introduced in Qt 5.1). The QtSingleApplication will probably need to be ported to QLockFile instead. -- 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 sean.harmer at kdab.com Sun Jun 19 10:55:54 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Sun, 19 Jun 2016 09:55:54 +0100 Subject: [Development] Many congratulations and one question In-Reply-To: <666035978.9003066.1466260894705.JavaMail.yahoo@mail.yahoo.com> References: <666035978.9003066.1466260894705.JavaMail.yahoo.ref@mail.yahoo.com> <666035978.9003066.1466260894705.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi Massimo, On 18/06/2016 15:41, Massimo Callegari via Development wrote: > Hi everyone, > today, instead of being the usual "complaining guy" I'd like to explicit my biggest congratulations and gratitude to all the people behind the Qt3D module. > In particular to Sean Harmer and Paul Lemire at KDAB, who have been doing a monumental job working during weekends, fighting against CI breakage and taking care of an infinite number of JIRA issues and reports. > > I've been following the Qt3D developments for a couple of years and I have to say Qt3D is going to be an awesome addition to the Qt features set. > I tried as much as I could to support the developments by testing patches and reporting issues and I hope I've been somehow helpful for the project. Thank you for your kind words. Yes, please do keep the bug reports coming and prodding us when needed. > I'm also very excited by the Qt3D editor and I'd like to congratulate with all the Qt people behind it as well. > Even if it's in a very early stage, you can already feel it is going to be an awesome tool ! +1. It's already shaping up to be a nice addition. I hope it can continue to be extended and hopefully one day become a great plugin for Qt Creator > So, well done everybody ! Thank you and I'd like to echo my own thanks to everybody who has helped with code, reporting bugs, asking questions that pushed us to make sure Qt 3D is flexible enough to work with as many rendering algorithms as possible. I already have plenty of ideas on how to continue extending the frame graph in 5.8 and beyond plus a whole bunch of other additions that we discussed with Pasi and his team in Oulu recently. > Now I've got a question for the Qt3D guys who knows all the techy bits of the current status of the module. > It is my intention to implement the technique described in these AMD slides: > https://developer.amd.com/wordpress/media/2012/10/Mitchell_LightShafts.pdf > > I am wondering if Qt3D can already cover such usage or if there are missing bits that are still not there or not planned at all. I don't see anything in there that Qt 3D can't do with a suitable configuration. > A plus for my project is if that technique can work in a deferred rendering pipeline. That technique relies upon alpha blended, view-aligned quads. It would need to be applied after the deferred portion of the rendering as alpha blending doesn't play nicely with deferred. So something like this might be something to try: 1) G-buffer pass 2) Lighting pass of opaque geometry 3) Light shafts pass for the brightest n lights, where n is tuned to what your hardware can handle. Depending upon the scene you want to render you may be able to hand select which lights trigger light shafts. For example, if you have 10 bright spot lights, use those with light shafts and just rely upon some other post-processing effect like bloom for the dimmer lights or point lights which can be done in a single post-proc pass. > If KDAB/Qt is interested in such usage case, I am more than willing to contribute to the developments or even support a developer more skilled than me in the 3D area with a monetary contribution. Sounds like an interesting algorithm to implement. If you'd like to do it on a commercial basis then feel free to contact us. Have a nice weekend and thank you again for your kind words and help! Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From thiago.macieira at intel.com Sun Jun 19 17:37:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 19 Jun 2016 08:37:47 -0700 Subject: [Development] tarball fetches from code.qt.io? In-Reply-To: <10265420.v8vWBT4eTP@portia.local> References: <2000886.r6WD1beTJ9@patux> <1991411466271411@web1h.yandex.ru> <10265420.v8vWBT4eTP@portia.local> Message-ID: <8274374.2ldreS4ds0@tjmaciei-mobl1> On sábado, 18 de junho de 2016 20:37:45 PDT René J.V. Bertin wrote: > On Saturday June 18 2016 20:36:51 Konstantin Tokarev wrote: > > > Also, 5.6.2? Now that 5.7.0 is out? I'm a bit confused, are there > > > reasons not to update to 5.7 apart from the fact it came really hot on > > > the heels of 5.6.1 and sometimes it's nice not spending one's time > > > doing updates?> > > Of course, 5.7.1 will also have these fixes > > Erm, I'd hope so, but what I meant was why release 5.6.2 after 5.7.0? That > kind of suggests that there are platforms that 5.6 supports but not 5.7 ... There are. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nassian at bitshift-dynamics.de Sun Jun 19 17:44:21 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Sun, 19 Jun 2016 17:44:21 +0200 Subject: [Development] Qt 5.7.0 Toolchain on RasPI2 Message-ID: <8CE90257-AACC-4032-B27A-732E7DC8ECE5@bitshift-dynamics.de> Hi, Currently I’m doing a 5.7.0 build for RasPI 2 with Raspian using the „official“ toolchain (arm-linux-gnueabihf-g++ (crosstool-NG linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)). EGLFS wasn’t detected (don’t need it atm either) and the build stopped with a linker error because of missing clock_gettime in QElapsedTimer. The common recommendation adding -lrt to the linker options didn’t work because configure will then don’t detect C++11 support. So I started a 5.5.1 build as a reference and suddenly EGLFS support was automagically detected and it went perfectly over the linking of QtCore. I didn’t find anything related in the bug tracker (or maybe I searched the wrong way). For this reason I wanted to ask here if this is a known problem, or a known wrong configuration thing? If not I would be happy to provide configuration, compiler output, etc.. Beste Grüße / Best regards, Alexander Nassian -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Jun 19 21:12:52 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 19 Jun 2016 12:12:52 -0700 Subject: [Development] Need review: https://codereview.qt-project.org/158428 Message-ID: <8923500.VYHzsfEzuE@tjmaciei-mobl1> Pushed May 7 pinged May 13 re-pinged May 23 re-re-pinged June 8 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jun 19 21:18:17 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 19 Jun 2016 12:18:17 -0700 Subject: [Development] Qt 5.7.0 Toolchain on RasPI2 In-Reply-To: <8CE90257-AACC-4032-B27A-732E7DC8ECE5@bitshift-dynamics.de> References: <8CE90257-AACC-4032-B27A-732E7DC8ECE5@bitshift-dynamics.de> Message-ID: <9747468.38CjMbOq9Y@tjmaciei-mobl1> On domingo, 19 de junho de 2016 17:44:21 PDT Alexander Nassian wrote: > Hi, > > Currently I’m doing a 5.7.0 build for RasPI 2 with Raspian using the > „official“ toolchain (arm-linux-gnueabihf-g++ (crosstool-NG > linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)). > EGLFS wasn’t detected (don’t need it atm either) configure -v output showing why it was discarded missing. > and the build stopped with > a linker error because of missing clock_gettime in QElapsedTimer. You didn't include the error message. Please include the link command-line too. > The > common recommendation adding -lrt to the linker options didn’t work because > configure will then don’t detect C++11 support. Information missing. > I didn’t find anything related in the bug tracker (or maybe I searched the > wrong way). For this reason I wanted to ask here if this is a known > problem, or a known wrong configuration thing? If not I would be happy to > provide configuration, compiler output, etc.. None of those are known issues. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nassian at bitshift-dynamics.de Sun Jun 19 21:36:21 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Sun, 19 Jun 2016 21:36:21 +0200 Subject: [Development] Qt 5.7.0 Toolchain on RasPI2 In-Reply-To: <9747468.38CjMbOq9Y@tjmaciei-mobl1> References: <8CE90257-AACC-4032-B27A-732E7DC8ECE5@bitshift-dynamics.de> <9747468.38CjMbOq9Y@tjmaciei-mobl1> Message-ID: The configure command is:  ../qt-everywhere-opensource-src-5.7.0/configure -opensource -confirm-license -no-pch -no-xcb -nomake tests -make libs -device linux-rasp-pi2-g++ -nomake examples -device-option CROSS_COMPILE=/home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/current_toolchain/arm-linux-gnueabihf- -sysroot /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs -no-gcc-sysroot -prefix /usr/local/qt-5.7.0 -v EGLFS and others were disabled because of the already mentioned linker error. /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/libpthread.so.0: undefined reference to `__mktemp at GLIBC_PRIVATE' /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/librt.so.1: undefined reference to `__clock_settime at GLIBC_PRIVATE' /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/librt.so.1: undefined reference to `__clock_getcpuclockid at GLIBC_PRIVATE' /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/libpthread.so.0: undefined reference to `__call_tls_dtors at GLIBC_PRIVATE' /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/libpthread.so.0: undefined reference to `__madvise at GLIBC_PRIVATE' /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/librt.so.1: undefined reference to `__clock_nanosleep at GLIBC_PRIVATE' /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/libpthread.so.0: undefined reference to `__ctype_init at GLIBC_PRIVATE' /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/librt.so.1: undefined reference to `__clock_getres at GLIBC_PRIVATE' /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-gnueabihf/librt.so.1: undefined reference to `__clock_gettime at GLIBC_PRIVATE’ Please find attached the complete configure log. Beste Grüße / Best regards, Alexander Nassian > Am 19.06.2016 um 21:18 schrieb Thiago Macieira : > > On domingo, 19 de junho de 2016 17:44:21 PDT Alexander Nassian wrote: >> Hi, >> >> Currently I’m doing a 5.7.0 build for RasPI 2 with Raspian using the >> „official“ toolchain (arm-linux-gnueabihf-g++ (crosstool-NG >> linaro-1.13.1+bzr2650 - Linaro GCC 2014.03) 4.8.3 20140303 (prerelease)). >> EGLFS wasn’t detected (don’t need it atm either) > > configure -v output showing why it was discarded missing. > >> and the build stopped with >> a linker error because of missing clock_gettime in QElapsedTimer. > > You didn't include the error message. Please include the link command-line > too. > >> The >> common recommendation adding -lrt to the linker options didn’t work because >> configure will then don’t detect C++11 support. > > Information missing. > >> I didn’t find anything related in the bug tracker (or maybe I searched the >> wrong way). For this reason I wanted to ask here if this is a known >> problem, or a known wrong configuration thing? If not I would be happy to >> provide configuration, compiler output, etc.. > > None of those are known issues. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.log Type: application/octet-stream Size: 90092 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfunk at kde.org Mon Jun 20 07:59:32 2016 From: kfunk at kde.org (Kevin Funk) Date: Mon, 20 Jun 2016 07:59:32 +0200 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <5472058.zq4xmWj7P0@kerberos> References: <5472058.zq4xmWj7P0@kerberos> Message-ID: <1633567.Gjv0RzWHuI@kerberos> On Donnerstag, 16. Juni 2016 00:19:10 CEST Kevin Funk wrote: > (snip) > > Question: > Is there an interest in having QtSingleApplication in Qt proper? Say > qtbase? We'd love to do the work if there's a chance for it being accepted. Heya, Thanks for all the comments, I'll work on introducing QtSingleApplication into QtCore, including porting it to QLockFile, including porting it away from the QCoreApplication base. Hopefully within the upcoming weeks if I find the time. Cheers, Kevin > (snip) -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Mon Jun 20 09:02:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Jun 2016 00:02:01 -0700 Subject: [Development] Qt 5.7.0 Toolchain on RasPI2 In-Reply-To: References: <8CE90257-AACC-4032-B27A-732E7DC8ECE5@bitshift-dynamics.de> <9747468.38CjMbOq9Y@tjmaciei-mobl1> Message-ID: <1764834.OkrEVpHR5E@tjmaciei-mobl1> On domingo, 19 de junho de 2016 21:36:21 PDT Alexander Nassian wrote: > EGLFS and others were disabled because of the already mentioned linker > error. > > /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-g > nueabihf/libpthread.so.0: undefined reference to `__mktemp at GLIBC_PRIVATE' This is a toolchain error. Fix your toolchain. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Karsten.Heimrich at qt.io Mon Jun 20 11:41:36 2016 From: Karsten.Heimrich at qt.io (Karsten Heimrich) Date: Mon, 20 Jun 2016 09:41:36 +0000 Subject: [Development] QtSerialBus : Function Code 20 and 21 not implemented In-Reply-To: <3EE8BD12F03211438C0D787CCD1B49150132A5474BAE@CCREX002.ce.int.amecspie.com> References: <3EE8BD12F03211438C0D787CCD1B49150132A5474BAE@CCREX002.ce.int.amecspie.com> Message-ID: Hi Vincent, we just didn't manage to implement all functionallity provided by the specification. Right now there is no pending patch or implementation I know of, but we are definitifly looking into finishing it for a later release. Of course, if you need the functionality you can implement it on your own by inheriting from one of the QModbusServer descendants. We are also open for patches that provide the missing implementation. Obviously you found the issue on jira already: https://bugreports.qt.io/browse/QTBUG-49510?filter=17150 Regards, Karsten Heimrich Senior Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin karsten.heimrich at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] From: Development [mailto:development-bounces+karsten.heimrich=qt.io at qt-project.org] On Behalf Of SENECLAUZE Vincent Sent: Freitag, 17. Juni 2016 17:02 To: development at qt-project.org Subject: [Development] QtSerialBus : Function Code 20 and 21 not implemented Hi everyone, I try to use the new QtSerialBus with the Qt 5.7.0, and during my test, the Function Code 20 and 21 answer Illegal Function. When I opened source code, I saw this : Line 662, File qmodbusserver.cpp : case QModbusRequest::ReadFileRecord: // TODO: Implement. case QModbusRequest::WriteFileRecord: // TODO: Implement. return QModbusExceptionResponse(request.functionCode(), QModbusExceptionResponse::IllegalFunction); My questions are : Why the documentation do not precise that this Function Code is not implemented ? And Is there a plan to finish this implementation in the next release ? or is someone have a kind of begining of source code or patch ? Best regards, Vincent SENECLAUZE ________________________________ ______________________________________________________________ Ce message et toutes les pièces jointes (ci-après le "message") sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute modification, édition, utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. SPIE et ses filiales déclinent toute responsabilité au titre de ce message s'il a été altéré, déformé, falsifié, édité ou diffusé sans autorisation. This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised alteration , printing , use or dissemination is prohibited. E-mails are susceptible to alteration. SPIE nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed, falsified, printed or disseminated without authorisation. ______________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image007.png Type: image/png Size: 7152 bytes Desc: image007.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image008.png Type: image/png Size: 779 bytes Desc: image008.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image009.png Type: image/png Size: 942 bytes Desc: image009.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image010.png Type: image/png Size: 872 bytes Desc: image010.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image011.png Type: image/png Size: 1007 bytes Desc: image011.png URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image012.png Type: image/png Size: 831 bytes Desc: image012.png URL: From stefbon at gmail.com Mon Jun 20 11:45:23 2016 From: stefbon at gmail.com (Stef Bon) Date: Mon, 20 Jun 2016 11:45:23 +0200 Subject: [Development] QStorageinfo changes: a bug. Message-ID: Hi, I've found aout that the qstorageinfo has changed recently. I'v got a fuse filesystem and a qt gui using that filesystem. To detect the mountpoint the gui uses QStorageInfo::mountedVolumes() and walk this list. This worked until recently, now the fuse is not found anymore. I've found out that the function isPseudoFs has been changed, and every fs where the device does not start with a slash is a pseudofs. Huhhh? This is far too strict. The manpage of mount describes for the device (or source): mount() attaches the filesystem specified by source (which is often a device name, but can also be a directory name or a dummy) to the directory specified by target. So there are no restrictions here it has to start with a slash. And the source --can-- be something abstract, and not a device. Stef See: http://fossies.org/diffs/qt-everywhere-opensource-src/5.6.0_vs_5.6.1/qtbase/src/corelib/io/qstorageinfo_unix.cpp-diff.html From jani.heikkinen at qt.io Mon Jun 20 14:07:26 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 20 Jun 2016 12:07:26 +0000 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: <13210002.JkO6No2ATJ@42> References: , <13210002.JkO6No2ATJ@42> Message-ID: Hi all, It seems there isn't that much objections to proposed schedule. Tony's points are valid but after discussion with several persons we agree it isn't necessary to postpone feature freeze because of missing platforms/versions from CI. So let's proceed with proposed schedule to be able to release Qt 5.8.0 still during this year: - Branching from 'dev' to '5.8' starts 2.8.2016 - Qt 5.8 feature freeze 9.8.2016 Please make sure all new features are really in 'dev' well before actual feature freeze date (and fulfilling the FF criteria: https://wiki.qt.io/Qt5_feature_freeze). Also make sure all new submodules (also technology preview ones) are in qt5.git (.gitmodules) early enough. By default all modules missing at FF date will be out from Qt 5.8 release (Lars can give an exception by request but we should really avoid that). Please start updating Qt 5.8.0 new features page here: https://wiki.qt.io/New_Features_in_Qt_5.8 . br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From heikki.halmet at qt.io Mon Jun 20 14:15:32 2016 From: heikki.halmet at qt.io (Heikki Halmet) Date: Mon, 20 Jun 2016 12:15:32 +0000 Subject: [Development] Proposal For Qt 5.8 Platforms And SW Updates Message-ID: Hi, Below is our proposal for target platforms and sw updates in Qt 5.8 release. Some might come after feature freeze or some changes might not happen at all. OpenSUSE 42.1 x86_64 ( - OpenSUSE 13.1 will be dropped after 42.1 is in) * Openssl: 1.0.2h Rhel 6.6 (build's packages) & Rhel 7.2 x86_64 (will appear as a developer build) * Openssl: 1.0.2h * Android ndk r10e * Android sdk 25.1.7 * Python-devel (or python-dev) Ubuntu 16.04 x86_64 ( - Will drop Ubuntu 14.04 and 15.04 when it's in) * Openssl: 1.0.2h * Python-devel (or python-dev) OS X 10.12 beta * Xcode 8 beta & command line tools * Android ndk r10e * Android sdk 25.1.7 OS X 10.11.5 x86_64 * Xcode 7.3.1 & command line tools * Android ndk r10e * Android sdk 25.1.7 OS X 10.10 x86_64 OS X 10.9 x86_64 OSX 10.8 will be dropped! Windows 10 x86 * Openssl: 1.0.2h * Visual Studio 2015 update 2 Windows 10 x86_64 * Openssl: 1.0.2h * Visual Studio 2015 update 2 Windows 7 x86 * Openssl: 1.0.2h * Android ndk r10e * Android sdk 25.1.7 * MinGw 5.3.0 Windows 8.1 x86 * Openssl: 1.0.2h * Visual Studio 2013 update 5 Windows 8.1 x86_64 * Openssl: 1.0.2h (latest) * Visual Studio 2013 update 5 Best regards Heikki Halmet The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland Email: heikki.halmet at qt.io Phone: +358408672112 www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt -------------- next part -------------- An HTML attachment was scrubbed... URL: From milla.pohjanheimo at qt.io Mon Jun 20 14:28:26 2016 From: milla.pohjanheimo at qt.io (Milla Pohjanheimo) Date: Mon, 20 Jun 2016 12:28:26 +0000 Subject: [Development] Common consensus about isExposed()? Message-ID: It looks like isExposed() has it's own interpretation of the implementation on each platform. See bug: https://bugreports.qt.io/browse/QTBUG-53252 "isExposed() returns true also if window minimized or completely covered". Our autotests are heavily relying on the result of qWaitForWindowExposed() (in qtbase/src/testlib/qtestsystem.h) which gets the result from isExposed(). This causes flakiness in the tests. See also this task: https://bugreports.qt.io/browse/QTBUG-52594 "Make a platform-aware qWaitForWindowExposed()/Active()". I would like to raise discussion on how do you think this should be addressed. See Gatis's last comment in the bug report: "1) Agree on what exposed means -> improve documentation -> fix code in all platform plugins. 2) Deprecate API and find some other alternative for auto tests? 3) Something else?" What do you think? - Milla -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Mon Jun 20 14:48:34 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 20 Jun 2016 12:48:34 +0000 Subject: [Development] QStorageinfo changes: a bug. In-Reply-To: References: Message-ID: <5A085F4C-F2C1-472B-97EA-324F3178353A@qt.io> > On 20 Jun 2016, at 11:45, Stef Bon wrote: > > Hi, > > I've found aout that the qstorageinfo has changed recently. I'v got a > fuse filesystem and a qt gui using that filesystem. To detect the > mountpoint the gui uses QStorageInfo::mountedVolumes() and walk this > list. > > This worked until recently, now the fuse is not found anymore. I've > found out that the function > isPseudoFs has been changed, and every fs where the device does not > start with a slash is a pseudofs. Huhhh? This is far too strict. > > The manpage of mount describes for the device (or source): > > mount() attaches the filesystem specified by source (which is often a > device name, but can also be a directory name or a dummy) to the > directory specified by target. > > So there are no restrictions here it has to start with a slash. And > the source --can-- be something abstract, and not a device. Apparently you are referring to https://codereview.qt-project.org/#/c/141217/ Please report a bug, and give any ideas you have for deciding what is a pseudo-fs and what isn’t. I don’t think we can say that every FUSE filesystem falls into either category, right? From stefbon at gmail.com Mon Jun 20 14:55:38 2016 From: stefbon at gmail.com (Stef Bon) Date: Mon, 20 Jun 2016 14:55:38 +0200 Subject: [Development] QStorageinfo changes: a bug. In-Reply-To: <5A085F4C-F2C1-472B-97EA-324F3178353A@qt.io> References: <5A085F4C-F2C1-472B-97EA-324F3178353A@qt.io> Message-ID: 2016-06-20 14:48 GMT+02:00 Shawn Rutledge : > > > Apparently you are referring to https://codereview.qt-project.org/#/c/141217/ > Yes. > Please report a bug, and give any ideas you have for deciding what is a pseudo-fs and what isn’t. I don’t think we can say that every FUSE filesystem falls into either category, right? > I've reported a bug/suggestion just right now: https://bugreports.qt.io/browse/QTBUG-54235 The suggestion I do is adding filters simular to QDir::entryInfoList, where the default without filters is the current. And maybe the whole name "storageinfo" is misleading. Just QFilesystemsInfo would be better. Stef From Morten.Sorvig at qt.io Mon Jun 20 15:00:16 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Mon, 20 Jun 2016 13:00:16 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <2096409.Vgqk0hXBa4@master> References: <2096409.Vgqk0hXBa4@master> Message-ID: <7B33DF3E-E384-46E0-AA0E-DDB66DB1228A@qt.io> > On 17 Jun 2016, at 14:54, Frank Hemer wrote: > > Can you give a hint on what causes these glitches and how to avoid them? > I'm not talking about general usage of fractional methods for painting here. > > For example when drawing to a pixmap (sized for the 'real' screen resolution) > and then updating just a sub-rectangle of this pixmap, for some (and really > only some) fractional scale factor values there are glitches around that sub- > rectangle where the background color of the window shines through. > What is causing this? I have not analyzed these in detail, but my guess would be rounding errors due to fractional coordinates. So you could look at the update code (in QPainter or the paint engine) and make sure coordinates are rounded to _include_ partially covered pixels. > > What is the reason for not aiming towards supporting fractional scale factors > on the long run? What is the real challenge here? > Good question! If you ask me I think the Qt project should move towards supporting this (taking care to avoid maintenance traps such as the native styles). One of the challenges is simply available time and resources for doing the work. But even today Qt Creator at QT_SCALE_FACTOR=1.3 is a usable application. Another reason to not spend time on it would be that integer is, or is going to be, the dominating use case. Wayland and Apple is integer, so are most of the Android device categories. For Windows and desktop in general there are currently lots of fractional hardware and configurations. Morten From Morten.Sorvig at qt.io Mon Jun 20 15:13:16 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Mon, 20 Jun 2016 13:13:16 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <1897081.r3VhaQ2nYP@tjmaciei-mobl1> References: <1897081.r3VhaQ2nYP@tjmaciei-mobl1> Message-ID: <5CEC79AE-0A4B-4ABE-B1FF-DA413318C485@qt.io> > On 17 Jun 2016, at 17:41, Thiago Macieira wrote: > > > Everyone I ask about this gives the same answer: Wayland. I agree, Wayland solves the problem at the correct place in the software stack. So in this light what we are doing for Qt on X11 can be considered a workaround while we wait for proper windowing system support. Of course X11 is going to be in use for a long time and we should make Qt work as well as possible here, even if we have to give up automatic configuration. Morten From Shawn.Rutledge at qt.io Mon Jun 20 16:30:19 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 20 Jun 2016 14:30:19 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <23309410.drzYhCSC6U@tjmaciei-mobl1> References: <23309410.drzYhCSC6U@tjmaciei-mobl1> Message-ID: <30521F13-8226-4DC8-86BE-8BA421D96E15@qt.io> > On 17 Jun 2016, at 22:49, Thiago Macieira wrote: > >> - Run "./highdpi --metrics", or test with an application. > > See 3 scenarios attached. I'll send a fourth scenario later, when I try at > home with my 45" TV that reports its size as 160 x 90 mm. Don’t you think there should be a quirks database somewhere (outside of Qt) which corrects these cases? The TV model can be identified, right? X does it, but that’s not a broad enough scope to cover Wayland. https://wiki.ubuntu.com/X/Quirks#Monitor_Quirks Maybe it could be done with udev rules or something. If there is really not yet a proper solution on Linux, there should be, IMO. From Jake.Petroules at qt.io Mon Jun 20 17:52:32 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 20 Jun 2016 15:52:32 +0000 Subject: [Development] Proposal For Qt 5.8 Platforms And SW Updates In-Reply-To: References: Message-ID: <0613E02F-9760-43E1-B159-95B02EE55B82@qt.io> Looks good to me. Note that it's macOS now, not OS X. On Jun 20, 2016, at 5:15 AM, Heikki Halmet > wrote: Hi, Below is our proposal for target platforms and sw updates in Qt 5.8 release. Some might come after feature freeze or some changes might not happen at all. OpenSUSE 42.1 x86_64 ( - OpenSUSE 13.1 will be dropped after 42.1 is in) • Openssl: 1.0.2h Rhel 6.6 (build's packages) & Rhel 7.2 x86_64 (will appear as a developer build) • Openssl: 1.0.2h • Android ndk r10e • Android sdk 25.1.7 • Python-devel (or python-dev) Ubuntu 16.04 x86_64 ( - Will drop Ubuntu 14.04 and 15.04 when it's in) • Openssl: 1.0.2h • Python-devel (or python-dev) OS X 10.12 beta • Xcode 8 beta & command line tools • Android ndk r10e • Android sdk 25.1.7 OS X 10.11.5 x86_64 • Xcode 7.3.1 & command line tools • Android ndk r10e • Android sdk 25.1.7 OS X 10.10 x86_64 OS X 10.9 x86_64 OSX 10.8 will be dropped! Windows 10 x86 • Openssl: 1.0.2h • Visual Studio 2015 update 2 Windows 10 x86_64 • Openssl: 1.0.2h • Visual Studio 2015 update 2 Windows 7 x86 • Openssl: 1.0.2h • Android ndk r10e • Android sdk 25.1.7 • MinGw 5.3.0 Windows 8.1 x86 • Openssl: 1.0.2h • Visual Studio 2013 update 5 Windows 8.1 x86_64 • Openssl: 1.0.2h (latest) • Visual Studio 2013 update 5 Best regards Heikki Halmet The Qt Company, Elektroniikkatie 13, 90590 Oulu, Finland Email: heikki.halmet at qt.io Phone: +358408672112 www.qt.io | Qt Blog: http://blog.qt.io/ | Twitter: @qtproject, @Qtproject Facebook: www.facebook.com/qt _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io Consulting Services Engineer - The Qt Company Qbs build system evangelist - qbs.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Jun 20 18:04:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Jun 2016 09:04:12 -0700 Subject: [Development] QStorageinfo changes: a bug. In-Reply-To: References: Message-ID: <2039399.UzKqmo6GMt@tjmaciei-mobl1> On segunda-feira, 20 de junho de 2016 11:45:23 PDT Stef Bon wrote: > This worked until recently, now the fuse is not found anymore. I've > found out that the function > isPseudoFs has been changed, and every fs where the device does not > start with a slash is a pseudofs. Huhhh? This is far too strict. That matches all the cases of pseudo-fs for me. It's not required, though, as you can mount anything in a pseudo-fs and it will be ignored. > The manpage of mount describes for the device (or source): > > mount() attaches the filesystem specified by source (which is often a > device name, but can also be a directory name or a dummy) to the > directory specified by target. > > So there are no restrictions here it has to start with a slash. And > the source --can-- be something abstract, and not a device. You're reading it upside down, mistaking "sufficient" condition for "required". As you and I both said, it's not required to start with something other than a slash. But it is sufficient for me, as a real FS will require a real device to be mounted and a real device requires a device node or another file path. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jun 20 18:09:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Jun 2016 09:09:51 -0700 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <30521F13-8226-4DC8-86BE-8BA421D96E15@qt.io> References: <23309410.drzYhCSC6U@tjmaciei-mobl1> <30521F13-8226-4DC8-86BE-8BA421D96E15@qt.io> Message-ID: <3508170.C7N1dtNIcX@tjmaciei-mobl1> On segunda-feira, 20 de junho de 2016 14:30:19 PDT Shawn Rutledge wrote: > Don’t you think there should be a quirks database somewhere (outside of Qt) > which corrects these cases? The TV model can be identified, right? > X does it, but that’s not a broad enough scope to cover Wayland. > > https://wiki.ubuntu.com/X/Quirks#Monitor_Quirks > > Maybe it could be done with udev rules or something. If there is really not > yet a proper solution on Linux, there should be, IMO. We would need a correction database, not just a quirks one. 160x90 mm is a valid screen size, correspoding to a 7.2" monitor. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From charleyb123 at gmail.com Mon Jun 20 20:50:36 2016 From: charleyb123 at gmail.com (charleyb123) Date: Mon, 20 Jun 2016 12:50:36 -0600 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <1633567.Gjv0RzWHuI@kerberos> References: <5472058.zq4xmWj7P0@kerberos> <1633567.Gjv0RzWHuI@kerberos> Message-ID: +1, I've found many good uses for QtSingleApplication, and think this is a good (highly practical) feature for "Qt-proper". --charley On Sun, Jun 19, 2016 at 11:59 PM, Kevin Funk wrote: > On Donnerstag, 16. Juni 2016 00:19:10 CEST Kevin Funk wrote: > > (snip) > > > > Question: > > Is there an interest in having QtSingleApplication in Qt proper? Say > > qtbase? We'd love to do the work if there's a chance for it being > accepted. > > Heya, > > Thanks for all the comments, I'll work on introducing QtSingleApplication > into > QtCore, including porting it to QLockFile, including porting it away from > the > QCoreApplication base. > > Hopefully within the upcoming weeks if I find the time. > > Cheers, > Kevin > > > (snip) > > -- > Kevin Funk | kfunk at kde.org | http://kfunk.org > _______________________________________________ > 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 nassian at bitshift-dynamics.de Mon Jun 20 21:30:09 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Mon, 20 Jun 2016 21:30:09 +0200 Subject: [Development] Qt 5.7.0 Toolchain on RasPI2 In-Reply-To: <1764834.OkrEVpHR5E@tjmaciei-mobl1> References: <8CE90257-AACC-4032-B27A-732E7DC8ECE5@bitshift-dynamics.de> <9747468.38CjMbOq9Y@tjmaciei-mobl1> <1764834.OkrEVpHR5E@tjmaciei-mobl1> Message-ID: <4FC8AD95-F42F-4348-AECA-7D6CDA10200E@bitshift-dynamics.de> Hi Thiago, Would be great if you could be a little bit more specific. I’m using exactly the same toolchain and the same sysroot for 5.5.1 and 5.7.0. The 5.5.1 build works perfectly, the 5.7.0 build fails while linking. Is the GCC 4.8.3 which is used for Raspian not supported anymore? Beste Grüße / Best regards, Alexander Nassian > Am 20.06.2016 um 09:02 schrieb Thiago Macieira : > > On domingo, 19 de junho de 2016 21:36:21 PDT Alexander Nassian wrote: >> EGLFS and others were disabled because of the already mentioned linker >> error. >> >> /home/picaschaf/workspace/RATIO-Elektronik_AlignmentTrap/rfs/lib/arm-linux-g >> nueabihf/libpthread.so.0: undefined reference to `__mktemp at GLIBC_PRIVATE' > > This is a toolchain error. Fix your toolchain. > > > -- > 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 apoenitz at t-online.de Mon Jun 20 22:57:38 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Mon, 20 Jun 2016 22:57:38 +0200 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <1633567.Gjv0RzWHuI@kerberos> References: <5472058.zq4xmWj7P0@kerberos> <1633567.Gjv0RzWHuI@kerberos> Message-ID: <20160620205738.GA1586@klara.mpi.htwm.de> On Mon, Jun 20, 2016 at 07:59:32AM +0200, Kevin Funk wrote: > On Donnerstag, 16. Juni 2016 00:19:10 CEST Kevin Funk wrote: > > (snip) > > > > Question: Is there an interest in having QtSingleApplication in Qt > > proper? Say qtbase? We'd love to do the work if there's a chance for > > it being accepted. > > Heya, > > Thanks for all the comments, I'll work on introducing > QtSingleApplication into QtCore, including porting it to QLockFile, > including porting it away from the QCoreApplication base. You mean port away from QApplication? Anyway, I don't quite get it: - QtSingleApplication is as easily accessible as other "bread and butter" parts of Qt via git, hosted by the same entity, - no other parts of Qt depend on QtSingleApplication nor would see any kind of UX/Performance/whatever boost if they did, - we jump through major hoops and put major effort to have something resembling a modular system with independent repos, - every now and than we have the feeling that Qt Core / Qt Base grows too much fat/looks like a dumping ground of nice-to-have feeatures/whatever and we are not happy and still we move stuff *needlessly* to Qt Core? Why? Because Qt Solutions "feel unmaintained"? Wouldn't be the natural solution to maintain QtSingleApplication *there*? Andre' From thiago.macieira at intel.com Mon Jun 20 23:16:37 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Jun 2016 14:16:37 -0700 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <20160620205738.GA1586@klara.mpi.htwm.de> References: <5472058.zq4xmWj7P0@kerberos> <1633567.Gjv0RzWHuI@kerberos> <20160620205738.GA1586@klara.mpi.htwm.de> Message-ID: <41956508.DnfbKpXgnX@tjmaciei-mobl1> On segunda-feira, 20 de junho de 2016 22:57:38 PDT André Pönitz wrote: > On Mon, Jun 20, 2016 at 07:59:32AM +0200, Kevin Funk wrote: > > On Donnerstag, 16. Juni 2016 00:19:10 CEST Kevin Funk wrote: > > > (snip) > > > > > > Question: Is there an interest in having QtSingleApplication in Qt > > > proper? Say qtbase? We'd love to do the work if there's a chance for > > > it being accepted. > > > > Heya, > > > > Thanks for all the comments, I'll work on introducing > > QtSingleApplication into QtCore, including porting it to QLockFile, > > including porting it away from the QCoreApplication base. > > You mean port away from QApplication? > > Anyway, I don't quite get it: > > - QtSingleApplication is as easily accessible as other "bread and > butter" parts of Qt via git, hosted by the same entity, > > - no other parts of Qt depend on QtSingleApplication nor would > see any kind of UX/Performance/whatever boost if they did, > > - we jump through major hoops and put major effort to have something > resembling a modular system with independent repos, > > - every now and than we have the feeling that Qt Core / Qt Base > grows too much fat/looks like a dumping ground of nice-to-have > feeatures/whatever and we are not happy > > and still we move stuff *needlessly* to Qt Core? I'd like to see KUniqueApplication deprecated, as it relies on some undocumented and fragile QtDBus functionality (namely, connecting to the bus before QCoreApplication is created). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jun 20 23:21:27 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Jun 2016 14:21:27 -0700 Subject: [Development] Qt 5.7.0 Toolchain on RasPI2 In-Reply-To: <4FC8AD95-F42F-4348-AECA-7D6CDA10200E@bitshift-dynamics.de> References: <8CE90257-AACC-4032-B27A-732E7DC8ECE5@bitshift-dynamics.de> <1764834.OkrEVpHR5E@tjmaciei-mobl1> <4FC8AD95-F42F-4348-AECA-7D6CDA10200E@bitshift-dynamics.de> Message-ID: <1649971.HAF6xWutM4@tjmaciei-mobl1> On segunda-feira, 20 de junho de 2016 21:30:09 PDT Alexander Nassian wrote: > Hi Thiago, > > Would be great if you could be a little bit more specific. I’m using exactly > the same toolchain and the same sysroot for 5.5.1 and 5.7.0. The 5.5.1 > build works perfectly, the 5.7.0 build fails while linking. Is the GCC > 4.8.3 which is used for Raspian not supported anymore? I don't know what differs, but this one you're using, at least the way you're using it, is broken. I can't offer more advice as I have never used, developed for or even touched a Raspberry Pi, nor Raspbian, nor have I ever used the "-device" option for configure. Your libpthread.so.0 and librt.so.1 are looking for symbols in your libc.so.6 that they can't find. Qt didn't ship with those libraries, therefore the problem is in the toolchain or the way you're using it. Please make a program that calls clock_gettime(), compiles and links with this toolchain (with the -Wl,--no-undefined flag) and will run. Then compare the compiler and linker command-lines that you used to the ones that Qt's configure script is trying. Find out what's different, then fix the source of those files. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Tue Jun 21 01:17:07 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 21 Jun 2016 01:17:07 +0200 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <41956508.DnfbKpXgnX@tjmaciei-mobl1> References: <5472058.zq4xmWj7P0@kerberos> <1633567.Gjv0RzWHuI@kerberos> <20160620205738.GA1586@klara.mpi.htwm.de> <41956508.DnfbKpXgnX@tjmaciei-mobl1> Message-ID: <20160620231707.GA1915@klara.mpi.htwm.de> On Mon, Jun 20, 2016 at 02:16:37PM -0700, Thiago Macieira wrote: > > You mean port away from QApplication? > > > > Anyway, I don't quite get it: > > > > - QtSingleApplication is as easily accessible as other "bread and > > butter" parts of Qt via git, hosted by the same entity, > > > > - no other parts of Qt depend on QtSingleApplication nor would > > see any kind of UX/Performance/whatever boost if they did, > > > > - we jump through major hoops and put major effort to have something > > resembling a modular system with independent repos, > > > > - every now and than we have the feeling that Qt Core / Qt Base > > grows too much fat/looks like a dumping ground of nice-to-have > > feeatures/whatever and we are not happy > > > > and still we move stuff *needlessly* to Qt Core? > > I'd like to see KUniqueApplication deprecated, as it relies on some > undocumented and fragile QtDBus functionality (namely, connecting to > the bus before QCoreApplication is created). That's a reason that I have missed so far, but to be honest, I don't find it convincing. There's surely a way on the Qt side to overcome the "undocumented" part of the issue, and the "fragile ... before QCoreApplication is created" problem is a bit more generic than DBus-only, and, if taken seriously, might warrant a more generic solution than "incorporate some code to appease the worst offender". What irks me more here is the inconsistent reasoning. I seem to get messages of "we need to use this super-duper-but-unreadable XYZ construct to save 42.3 bytes in code size" and "well, you know, that's just a few hundred lines extra, you won't notice" at the same time lately. Andre' From thiago.macieira at intel.com Tue Jun 21 03:06:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Jun 2016 18:06:55 -0700 Subject: [Development] QtSingleApplication in Qt proper? In-Reply-To: <20160620231707.GA1915@klara.mpi.htwm.de> References: <5472058.zq4xmWj7P0@kerberos> <41956508.DnfbKpXgnX@tjmaciei-mobl1> <20160620231707.GA1915@klara.mpi.htwm.de> Message-ID: <3989284.8cHn5OZvUv@tjmaciei-mobl1> On terça-feira, 21 de junho de 2016 01:17:07 PDT André Pönitz wrote: > > I'd like to see KUniqueApplication deprecated, as it relies on some > > undocumented and fragile QtDBus functionality (namely, connecting to > > the bus before QCoreApplication is created). > > That's a reason that I have missed so far, but to be honest, I don't > find it convincing. > > There's surely a way on the Qt side to overcome the "undocumented" part > of the issue, and the "fragile ... before QCoreApplication is created" > problem is a bit more generic than DBus-only, and, if taken seriously, > might warrant a more generic solution than "incorporate some code to > appease the worst offender". It's the whole problem of delivering events before and after QCoreApplication's lifetime. The event dispatcher checks if QCoreApplication exists and, if not, drops all events on the floor[*]. That's required so that the event filter can work. I solved this for Qt 5.6 by creating QDaemonThread, which has no such limitation and does not filter events (and advising everyone that this will be the default for all aux threads in Qt 6). But by moving the handling of D-Bus events to another thread, we exposed other problems in KUniqueApplication's code that assumed that some events would be handled but not some other ones, until later. > What irks me more here is the inconsistent reasoning. I seem to get > messages of "we need to use this super-duper-but-unreadable XYZ > construct to save 42.3 bytes in code size" and "well, you know, that's > just a few hundred lines extra, you won't notice" at the same time > lately. Maybe, but that's not the case here. I'm saying that a proper QtSingleApplication implementation in QtCore may be better integrated with QCoreApplication / QGuiApplication / QApplication and do away with fragile code that tries to control the lifetime of QCoreApplication. [*] possibly including QEvent::DeferredDelete. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Erik.Verbruggen at qt.io Tue Jun 21 10:01:22 2016 From: Erik.Verbruggen at qt.io (Erik Verbruggen) Date: Tue, 21 Jun 2016 08:01:22 +0000 Subject: [Development] Proposing David Schulz as maintainer for QtC text editors and CDB integration In-Reply-To: <83DCFB6D-97B8-4F1D-A855-436469E5E66B@qt.io> References: <83DCFB6D-97B8-4F1D-A855-436469E5E66B@qt.io> Message-ID: cdb integration: +1 text editors: +2 (he should have taken over maintainership from me ages ago...) -- Erik. ________________________________ From: Development on behalf of Eike Ziller Sent: 17 June 2016 13:52:49 To: Cc: qt-creator Subject: [Development] Proposing David Schulz as maintainer for QtC text editors and CDB integration I propose David Schulz for Maintainer status for Qt Creator text editors and CDB integration. He has a long history in Qt Creator and factually maintained these areas for a long time now. https://codereview.qt-project.org/#/q/owner:%22David+Schulz+%253Cdavid.schulz%2540theqtcompany.com%253E%22,n,z Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From jedrzej.nowacki at qt.io Tue Jun 21 10:47:29 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Tue, 21 Jun 2016 10:47:29 +0200 Subject: [Development] Coin will be down on Tuesday 21st of June (6am-8am UTC+3) In-Reply-To: <2620124.1ofY3KSeSH@42> References: <2620124.1ofY3KSeSH@42> Message-ID: <10552463.DAjPVnCrBO@42> On Thursday 16 of June 2016 16:22:15 Jędrzej Nowacki wrote: > There is datacenter hardware maintenance break on Tuesday 21st of June > (6am-8am UTC+3), Coin will be shutdown a bit earlier and hopefully restart > after. > Cheers, > Jędrek Seems that something got completely broken, Coin is down. Sorry. Cheers, Jędrek From rjvbertin at gmail.com Tue Jun 21 12:36:02 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 21 Jun 2016 12:36:02 +0200 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget In-Reply-To: <2C3604B5-99B7-4B55-A570-35559686479D@qt.io> References: <2448170.ne5phv0VbN@portia.local> <1628121.IXcUYpztAk@patux.local> <2C3604B5-99B7-4B55-A570-35559686479D@qt.io> Message-ID: <2188527.dtqgTZKnXT@bola> On Tuesday June 21 2016 09:50:52 Eike Ziller wrote: >I think this would be more a question to the Qt/macOS developers, to be asked on the development@ mailing list ;) OK then :) I've, erm, borrowed some code from Qt Creator to add a Dock icon progressbar to KDevelop, adding a minimal API (only static methods as an app has only a single Dock icon) as well as a poor man's indeterminate mode. The code is still under review (https://git.reviewboard.kde.org/r/128188) so I wonder if I shouldn't instead by proposing it as a QtMacExtras addition. What do you think? Any suggestions how to integrate this into QtMacExtras, as a standalone class or as additional QtMac methods? R From jedrzej.nowacki at qt.io Tue Jun 21 12:43:52 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Tue, 21 Jun 2016 12:43:52 +0200 Subject: [Development] Coin will be down on Tuesday 21st of June (6am-8am UTC+3) In-Reply-To: <10552463.DAjPVnCrBO@42> References: <2620124.1ofY3KSeSH@42> <10552463.DAjPVnCrBO@42> Message-ID: <6269230.WCBrAXnsBT@42> On Tuesday 21 of June 2016 10:47:29 Jędrzej Nowacki wrote: > On Thursday 16 of June 2016 16:22:15 Jędrzej Nowacki wrote: > > There is datacenter hardware maintenance break on Tuesday 21st of June > > (6am-8am UTC+3), Coin will be shutdown a bit earlier and hopefully restart > > after. > > Cheers, > > > > Jędrek > > Seems that something got completely broken, Coin is down. Sorry. > > Cheers, > Jędrek Seems to work Ok for last 50 min :-) From Shawn.Rutledge at qt.io Tue Jun 21 14:15:29 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 21 Jun 2016 12:15:29 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <3508170.C7N1dtNIcX@tjmaciei-mobl1> References: <23309410.drzYhCSC6U@tjmaciei-mobl1> <30521F13-8226-4DC8-86BE-8BA421D96E15@qt.io> <3508170.C7N1dtNIcX@tjmaciei-mobl1> Message-ID: <8F895D17-8089-4BCB-B6E3-7C3EE65E49CE@qt.io> > On 20 Jun 2016, at 18:09, Thiago Macieira wrote: > > On segunda-feira, 20 de junho de 2016 14:30:19 PDT Shawn Rutledge wrote: >> Don’t you think there should be a quirks database somewhere (outside of Qt) >> which corrects these cases? The TV model can be identified, right? > >> X does it, but that’s not a broad enough scope to cover Wayland. >> >> https://wiki.ubuntu.com/X/Quirks#Monitor_Quirks >> >> Maybe it could be done with udev rules or something. If there is really not >> yet a proper solution on Linux, there should be, IMO. > > We would need a correction database, not just a quirks one. I thought that in common usage in the context of device drivers and their configuration, “quirks” are certain characteristics that are overridden/corrected for certain identifiable devices. > 160x90 mm is a valid screen size, correspoding to a 7.2" monitor. Of course, it’s just suspicious (being a fallback value, apparently), but not impossible. But assuming the model of your TV is unique and can also be read over EDID (like most monitors), the size could be corrected. I have the same issue with a Samsung SyncMaster 2494HM at the office, and have been wondering why X doesn’t “quirk” it by default. From the xorg log on Arch Linux: [ 266.313] (II) RADEON(0): EDID for output HDMI-0 [ 266.313] (II) RADEON(0): Manufacturer: SAM Model: 4d5 Serial#: 1263088180 [ 266.313] (II) RADEON(0): Year: 2010 Week: 38 … [ 266.313] (II) RADEON(0): Supported detailed timing: [ 266.313] (II) RADEON(0): clock: 148.5 MHz Image Size: 160 x 90 mm [ 266.313] (II) RADEON(0): h_active: 1920 h_sync: 2008 h_sync_end 2052 h_blank_end 2200 h_border: 0 [ 266.313] (II) RADEON(0): v_active: 1080 v_sync: 1084 v_sync_end 1089 v_blanking: 1125 v_border: 0 … I’m guessing that "Manufacturer: SAM Model: 4d5” is probably enough to identify it. Or use the year and week if necessary. There would need to be a web site to give feedback to add to the quirks database (similar to the way you can register unidentified USB devices on linux-usb.org): if various people with the same monitor, with different production dates, report the same problem, a pattern would emerge: for what period of time was this company making this mistake. Then it could go into the quirks. Or some distros could auto-report the EDIDs that are discovered - then it would be a matter of auditing them to see how many are uniquely identifiable and which of those are likely to contain wrong values for physical size. I do also see several cases like this in the log: [ 266.313] (II) Quirked EDID physical size to 0x0 cm which is not very useful… But quirks should IMO belong to the kernel, or to udev (depending whether udev can see when any kind of monitor is hotplugged), or to some library that corrects monitor EDIDs, not just to X. Qt could do it, cross-platform even, but we shouldn’t have to. Ah (googles it again) here we go: https://wiki.ubuntu.com/X/MonitorsDatabaseOnline Sounds good. But somehow it hasn’t resulted in corrected EDIDs being available everywhere. But Ubuntu 16.04 does correct the EDID for my monitor! I hadn’t noticed before. (Maybe it knows about your TV too?) And the qscreen manual test reports correct dimensions. So, the other distros ought to be reusing Ubuntu's quirks database, I guess. But maybe it’s only an online database so far. On KDE though, http://www.simonzone.com/software/guidance/ was supposed to be using it (although I don’t see evidence of that in the code). But I suppose there’s a political problem with having the latest (e.g.) KDE control panel depend on some Ubuntu online service to look up monitor EDID corrections. (So far I’m having trouble finding the URL for that service.) So ideally Canonical ought to give permission to package up their database and allow shipping it with other distros too; or maybe it can start to be hosted on a wider-community website. The downside is that the updates to the quirks that ship with distros would tend to be slow (like adding USB IDs so that lsusb knows about them - it takes at least a few months, typically). http://forums.fedoraforum.org/showpost.php?s=4dd2d2dbdc3131f2ad45a3f23b82d2d6&p=1695752 has some different info. I found that this works as a way of reading the EDID at any time: parse-edid < /sys/devices/pci0000:00/0000:00:07.0/0000:05:00.0/drm/card0/card0-HDMI-A-1/edid It seems that nVidia X drivers have a config option for overriding EDID, but the others apparently don’t. If they all did, the quirks could go in /usr/share/X11/xorg.conf.d/10-quirks.conf. But anyway, we want a solution that goes beyond X. Microsoft also has inf files for correcting EDID: https://msdn.microsoft.com/en-us/library/windows/hardware/jj133967(v=vs.85).aspx so if manufacturers (sometimes) already provide the inf files, maybe Linux ought to be able to use those somehow. https://wiki.ubuntu.com/X/MonitorsDatabaseOnline says that DisplayConfigGtk can do that. There’s even a utility to rewrite the EDID info on the monitor, if one dares: https://github.com/bulletmark/edid-rw Anyway it looks like Ubuntu did something good for their own users, and then it didn’t get any further, so far. Does anyone know who is in a position to negotiate a solution for all distros? Otherwise Qt will continue to have ongoing trouble with this. I don’t want to accept that there is no solution, and that monitor sizes will never be trustworthy. From Maurice.Kalinowski at qt.io Tue Jun 21 14:21:21 2016 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Tue, 21 Jun 2016 12:21:21 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: References: Message-ID: > 2) Handling fractional scale factors > > This is relevant for e.g. a Windows setting of 250%, corresponding to a scale > factor of 2.5. Presenting a fractional scale factor to the app may cause > graphics glitches, so we round it to the nearest integer, using qRound. > > However, mathematically correct rounding may not be the best kind of > correct in this case. In particular we should consider rounding factors of .5 > down instead of up. The effect would be presenting an UI that is visually > slightly smaller than it should be, over the current behavior of presenting an > UI that is slightly larger. > > In addition we have the option of tweaking the DPI reported to the > application to account for the remainder from the rounding. > So for the 250% case we can report a devicePixelRatio of 2 and a DPI of 144. > This relies on the existing DPI handling support (fonts scale automatically, > rest of UI may not), but since the offset from the base DPI is small it might be > OK. > > Finally, we should consider adding an option to simply let the fractional scale > factor through. We have user reports of applications that work fine with such > factors, save for one or two bugs in Qt. These are typically custom-styled > applications that do not rely on the Qt platform styles. > Allowing this as an option would not mean that fractional factors are > supported in Qt (for the formal meaning of “supported"), nor that we > necessarily spend time on fixing related issues. > [Kalinowski Maurice] +1 from my side. On WinRT / Windows Phone / UWP, you will hardly see an integer scale factor. That causes troubles when developers want to have native scaling and we forbid this internally. As you mentioned, we have users who patches this part and they seem to be happy with what works then already. If painting glitches appear, we need to be sure to document why that is and what potential workarounds one could apply. BR, Maurice From andrewponomarenko at yandex.ru Tue Jun 21 15:14:50 2016 From: andrewponomarenko at yandex.ru (Ponomarenko Andrey) Date: Tue, 21 Jun 2016 16:14:50 +0300 Subject: [Development] Binary compatibility report for Qt 5.7.0 Message-ID: <4233551466514890@web29h.yandex.ru> Hello, The binary compatibility report for the Qt 5.7.0 is ready: http://abi-laboratory.pro/tracker/timeline/qt/ Thank you. From s.stirtzel at googlemail.com Tue Jun 21 15:24:03 2016 From: s.stirtzel at googlemail.com (Samuel Stirtzel) Date: Tue, 21 Jun 2016 15:24:03 +0200 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <8F895D17-8089-4BCB-B6E3-7C3EE65E49CE@qt.io> References: <23309410.drzYhCSC6U@tjmaciei-mobl1> <30521F13-8226-4DC8-86BE-8BA421D96E15@qt.io> <3508170.C7N1dtNIcX@tjmaciei-mobl1> <8F895D17-8089-4BCB-B6E3-7C3EE65E49CE@qt.io> Message-ID: 2016-06-21 14:15 GMT+02:00 Shawn Rutledge : > >> On 20 Jun 2016, at 18:09, Thiago Macieira wrote: >> 160x90 mm is a valid screen size, correspoding to a 7.2" monitor. > > Of course, it’s just suspicious (being a fallback value, apparently), but not impossible. Unfortunately it's not a fallback value, instead TV manufacturers commonly only set the aspect ratio (in cm) because one EDID for all devices is cheaper. See bullet point d of Adam Jacksons mail about the EDID -> DPI topic: https://lists.fedoraproject.org/pipermail/devel/2011-October/157671.html -- Regards Samuel From Morten.Sorvig at qt.io Tue Jun 21 20:02:05 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Tue, 21 Jun 2016 18:02:05 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <23309410.drzYhCSC6U@tjmaciei-mobl1> References: <23309410.drzYhCSC6U@tjmaciei-mobl1> Message-ID: <8CD8418A-96E2-4312-A111-04A0B820BF54@qt.io> > On 17 Jun 2016, at 22:49, Thiago Macieira wrote: > > > Creator is also a bad citizen (worst of all Qt 5 applications I've tested), > but I did not test it again in the scenarios above. When I tested before, I > had to find the right combination that would make both the QML and non-QML > parts of the UI look reasonable. Under some configurations, the text editor was > the right size but the Welcome screen, the left and bottom panels would look > too big, etc. Creator’s lot in life - taking the fall for bugs in Qt :) Anyway, inconsistencies like these is something I’m seeking to avoid with the new patches: we want to have uniform scaling for all app content where everything comes out either correct or not. This should make it easier to judge what effects setting options has. If you’re still seeing things like this even with the most recent patches (see update below) that’s something I think we should take a closer look at. > But you apparently removed the ability to set the scaling per-monitor. So this > brings Qt back on par with other X11 HiDPI-aware applications. Hence the reply > I get from everyone: use Wayland. Yes. I left that one out in my description, the code was still there. I made a couple of the changes to the implementaton (see commit de827565) and included it in the --metrics output. The configuration workflow is now: 1) Set Qt::AA_EnableHighDpiScaling or QT_AUTO_SCREEN_SCALE_FACTOR=1 This will use the per-screen logical DPI as reported by the platform plugin. 2) If not happy then 2a) Override the global logical DPI: QT_FONT_DPI=N 2b) Use physical DPI: QT_USE_PHYSICAL_DPI=1 2c) Set scale factors manually: QT_SCREEN_SCALE_FACTORS=2;1; QT_SCREEN_SCALE_FACTORS="externalMonitor=2” This will disregard the DPI values the platform plugin reports for the screens in question. The screen name in the second form is QScreen::name(). (Using the screen name is possible already in 5.6). 2d) Perhaps tweak the rounding policy. (factors directly specified in env. variables are not rounded). I think using screen names can be a good match for cases where you are sometimes connecting to external screens, provided that the string returned by name() is unique for each screen. Morten From thiago.macieira at intel.com Tue Jun 21 21:26:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Jun 2016 12:26:50 -0700 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <8CD8418A-96E2-4312-A111-04A0B820BF54@qt.io> References: <23309410.drzYhCSC6U@tjmaciei-mobl1> <8CD8418A-96E2-4312-A111-04A0B820BF54@qt.io> Message-ID: <15176666.iefUvhM14u@tjmaciei-mobl1> On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote: > I think using screen names can be a good match for cases where you are > sometimes connecting to external screens, provided that the string returned > by name() is unique for each screen. It's not. It's always "DP-1" (it reports the connection, not the monitor). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jun 22 01:37:36 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Jun 2016 16:37:36 -0700 Subject: [Development] v5.6.1-1 tag should have been v5.6.2 Message-ID: <1863824.yxbtdSSHUM@tjmaciei-mobl1> There's no reason to invent new naming schemes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jun 22 01:42:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Jun 2016 16:42:14 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: Message-ID: <2002755.ggY99F3WFB@tjmaciei-mobl1> On quinta-feira, 16 de junho de 2016 10:38:02 PDT Jani Heikkinen wrote: > Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is > actually a brown paper bag issue for Qt 5.6.1 release. That's why we need > to update release packages with change > https://codereview.qt-project.org/#/c/162677/ . We will "release" new > packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and > tested the packages from new content. It is much easier and safer to select > that option instead of releasing Qt 5.6.2 before summer vacations. I've just noticed this email. QTBUG-53761 is not P0, so it did not warrant new packages. The naming for the new tag is totally unacceptable. It should have been v5.6.2. We own up to our errors. If 5.6.1 wasn't good enough for anyone, then we release v5.6.2 immediately after. And if for some reason it was too difficult to bump everything that was scheduled for 5.6.2 to 5.6.3, then at the very least we should have used v5.6.1.1, which is probably what everyone making Qt packages will need to use since a dash is completely unacceptable in release versions. I propose that we delete the bad tag, retag and rerelease with a better name. Let's not make rash decisions again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Wed Jun 22 07:03:28 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 22 Jun 2016 05:03:28 +0000 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <2002755.ggY99F3WFB@tjmaciei-mobl1> References: , <2002755.ggY99F3WFB@tjmaciei-mobl1> Message-ID: Hi! Actually https://bugreports.qt.io/browse/QTBUG-53761 is a blocker. Priority isn't correct at the moment but in reality the bug is preventing any bigger and a bit complex applications working correctly. Unfortunately bug isn't describing that well enough :( That's why we need to update the packages just with that one fix. And that's why it isn't new 5.6.2 release (in my opinion), it is just 5.6.1 + hotfix. There was already request 'because you are doing new release please include this fixes' etc :) and that is unfortunately impossible now, just before summer holidays, sorry. And what comes to tag: we have used '-1' tag earlier (in enterprise repositories) and we didn't see any reason to change that 'hotfix' tagging scheme. It was discussed in irc as well but at least for me no-one really says why '-1' pattern is wrong. There was just opinions for and against and because we have used '-1' tag earlier it was selected this time as well. Another reason was the package naming: We have some tools which cannot handle 5.6.1.1 but can handle 5.6.1-1 in package names and it is better to use same format in the tag what is used in package names. But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1 would work then it is really ok for me to change the tag. But let's don't change that just because of opinions... br, Jani ________________________________ From: Development on behalf of Thiago Macieira Sent: Wednesday, June 22, 2016 2:42 AM To: releasing at qt-project.org Cc: development at qt-project.org Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages On quinta-feira, 16 de junho de 2016 10:38:02 PDT Jani Heikkinen wrote: > Unfortunately we noticed https://bugreports.qt.io/browse/QTBUG-53761 is > actually a brown paper bag issue for Qt 5.6.1 release. That's why we need > to update release packages with change > https://codereview.qt-project.org/#/c/162677/ . We will "release" new > packages (Qt 5.6.1-1) as soon as fix is in qt5.git & we have created and > tested the packages from new content. It is much easier and safer to select > that option instead of releasing Qt 5.6.2 before summer vacations. I've just noticed this email. QTBUG-53761 is not P0, so it did not warrant new packages. The naming for the new tag is totally unacceptable. It should have been v5.6.2. We own up to our errors. If 5.6.1 wasn't good enough for anyone, then we release v5.6.2 immediately after. And if for some reason it was too difficult to bump everything that was scheduled for 5.6.2 to 5.6.3, then at the very least we should have used v5.6.1.1, which is probably what everyone making Qt packages will need to use since a dash is completely unacceptable in release versions. I propose that we delete the bad tag, retag and rerelease with a better name. Let's not make rash decisions again. -- 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 nolden at kde.org Wed Jun 22 07:25:51 2016 From: nolden at kde.org (Ralf Nolden) Date: Wed, 22 Jun 2016 07:25:51 +0200 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <2002755.ggY99F3WFB@tjmaciei-mobl1> Message-ID: <1841456.8SPAP2gX7T@w530.nolden.freebsd> Am Mittwoch, 22. Juni 2016, 05:03:28 schrieb Jani Heikkinen: > Hi! > But if there is really some reason why v5.6.1-1 don't work and v.5.6.1.1 > would work then it is really ok for me to change the tag. But let's don't > change that just because of opinions... The naming scheme for alpha, beta, rc's is - so the packager scripts get all confused up assuming it's non-standard and not a patch release. If 5.6.2 is impossible, please go with 5.6.1.1 > And if for some reason it was too difficult to bump everything that was > scheduled for 5.6.2 to 5.6.3, then at the very least we should have used > v5.6.1.1, which is probably what everyone making Qt packages will need to > use since a dash is completely unacceptable in release versions. Ack > > I propose that we delete the bad tag, retag and rerelease with a better > name. Ack > > Let's not make rash decisions again. > > -- > 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 -- Kind regards, Ralf Nolden From Simon.Hausmann at qt.io Wed Jun 22 07:29:35 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 22 Jun 2016 05:29:35 +0000 Subject: [Development] v5.6.1-1 tag should have been v5.6.2 In-Reply-To: <1863824.yxbtdSSHUM@tjmaciei-mobl1> References: <1863824.yxbtdSSHUM@tjmaciei-mobl1> Message-ID: Hi, As an advocate of the -1 release I can elaborate on what I thought was a series of convincing reasons. The problem: The bug affects a surprisingly large number of Qt Quick applications. People not using Qt Quick are not affected. The objective: Get just that one fix for qtdeclarative into the hands of our users as quickly as possible. Approach 1: Roll 5.6.2 by branching 5.6 into 5.6.2. That will bring in a lot more changes into the release and certainly requires a broad testing effort. That is in contrary to the goal of getting a fix into the hands of the users quickly. Approach 2: Branch 5.6.2 off of 5.6.1, bump the version qglobal.h etc. to 5.6.2 but just include the one fix in qtdeclarative. That is a better approach IMO, but it still means a full rebuild of all modules. It's faster than (1) but not as quick as (3). Approach 3: Include the one declarative fix in 5.6.1, create a new tag and rebuild declarative and all the modules that depend on it. That is the quickest way of getting the release into the hands of the users (qtbase was not rebuilt nor any other module not depending in declarative). We had binaries ready for testing in under 24 hours. Note: When I wrote "rebuilt" I mean re-compile and also re-run the auto-tests. With a big module like qtbase you this can take a few iterations. And once qtbase changes all depending modules undergo the same. So when you say that there was no "reason" I disagree. I think there were reasons and I was one of the people in favor of (3) that implies a -1 suffix. Simon ________________________________ From: Development on behalf of Thiago Macieira Sent: Wednesday, June 22, 2016 1:37:36 AM To: development at qt-project.org Subject: [Development] v5.6.1-1 tag should have been v5.6.2 There's no reason to invent new naming schemes. -- 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 konstantin at podsvirov.pro Wed Jun 22 07:41:46 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 22 Jun 2016 08:41:46 +0300 Subject: [Development] [QtIFW] [Review Request] Relocatable Repository Set Message-ID: <1169021466574106@web16o.yandex.ru> An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jun 22 08:31:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Jun 2016 23:31:07 -0700 Subject: [Development] v5.6.1-1 tag should have been v5.6.2 In-Reply-To: References: <1863824.yxbtdSSHUM@tjmaciei-mobl1> Message-ID: <3917139.6xsH8ZLch9@tjmaciei-mobl1> On quarta-feira, 22 de junho de 2016 05:29:35 PDT Simon Hausmann wrote: > Approach 1: Roll 5.6.2 by branching 5.6 into 5.6.2. That will bring in a lot > more changes into the release and certainly requires a broad testing > effort. That is in contrary to the goal of getting a fix into the hands of > the users quickly. Agreed, not a good idea. > Approach 2: Branch 5.6.2 off of 5.6.1, bump the version qglobal.h etc. to > 5.6.2 but just include the one fix in qtdeclarative. That is a better > approach IMO, but it still means a full rebuild of all modules. It's faster > than (1) but not as quick as (3). That would be my option. I really think we should rebuild either way. > Approach 3: Include the one declarative fix in 5.6.1, create a new tag and > rebuild declarative and all the modules that depend on it. That is the > quickest way of getting the release into the hands of the users (qtbase was > not rebuilt nor any other module not depending in declarative). We had > binaries ready for testing in under 24 hours. Note: When I wrote "rebuilt" > I mean re-compile and also re-run the auto-tests. With a big module like > qtbase you this can take a few iterations. And once qtbase changes all > depending modules undergo the same. Approach 4: change only the qtdeclarative version number (.qmake.conf) to 5.6.2 and rebuild that. All the rest stays at 5.6.1. We skip 5.6.2 on the other repositories. Drawback: this has never been tested, even though it's supposed to work. Approach 5: change qtdeclarative version number to 5.6.1.1. Same problem. > So when you say that there was no "reason" I disagree. I think there were > reasons and I was one of the people in favor of (3) that implies a -1 > suffix. I meant the use of the dash. That has nothing to do with the approach to rebuilding the affected packages. We could have used 5.6.1.1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jun 22 08:37:57 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Jun 2016 23:37:57 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <2002755.ggY99F3WFB@tjmaciei-mobl1> References: <2002755.ggY99F3WFB@tjmaciei-mobl1> Message-ID: <1595018.V9QeEXHkkO@tjmaciei-mobl1> On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote: > I propose that we delete the bad tag, retag and rerelease with a better > name. Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be different from the original 5.6.1 version. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at qt.io Wed Jun 22 08:48:39 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Wed, 22 Jun 2016 06:48:39 +0000 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <1595018.V9QeEXHkkO@tjmaciei-mobl1> References: <2002755.ggY99F3WFB@tjmaciei-mobl1> <1595018.V9QeEXHkkO@tjmaciei-mobl1> Message-ID: On 22/06/16 08:37, "Development on behalf of Thiago Macieira" wrote: >On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote: >> I propose that we delete the bad tag, retag and rerelease with a better >> name. > >Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be different >from the original 5.6.1 version. Why? It’s one patch for a bug that can hit quite some of our users, otherwise everything is identical. Let’s for a second assume, we had not released an update, but added this to the known issues page and released 5.6.2 some time later this year. What would have happened is that all Linux distributions would have picked up that one patch, added it to their packages, and recompiled 5.6.1. The .so version number inside the distributions would still be 5.6.1, and you wouldn’t know the difference looking from the outside. The only thing that changes when the Linux distributions do such an update is the version number of the package, not of the .so’s inside. We basically do the same here. Yes, we can argue whether the tag should be 5.6.1-1 or 5.6.1.1, but it doesn’t change the fact that I don’t really see a problem in keeping the .so version for this case. Cheers, Lars From tuukka.turunen at qt.io Wed Jun 22 08:54:54 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 22 Jun 2016 06:54:54 +0000 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <2002755.ggY99F3WFB@tjmaciei-mobl1> <1595018.V9QeEXHkkO@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Lars Knoll > Sent: keskiviikkona 22. kesäkuuta 2016 9.49 > To: Thiago Macieira ; development at qt- > project.org > Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 > packages > > > On 22/06/16 08:37, "Development on behalf of Thiago Macieira" > thiago.macieira at intel.com> wrote: > > >On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote: > >> I propose that we delete the bad tag, retag and rerelease with a > >> better name. > > > >Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be > >different from the original 5.6.1 version. > > Why? > > It’s one patch for a bug that can hit quite some of our users, otherwise > everything is identical. > > Let’s for a second assume, we had not released an update, but added this to > the known issues page and released 5.6.2 some time later this year. What > would have happened is that all Linux distributions would have picked up > that one patch, added it to their packages, and recompiled 5.6.1. The .so > version number inside the distributions would still be 5.6.1, and you wouldn’t > know the difference looking from the outside. The only thing that changes > when the Linux distributions do such an update is the version number of the > package, not of the .so’s inside. > > We basically do the same here. Yes, we can argue whether the tag should be > 5.6.1-1 or 5.6.1.1, but it doesn’t change the fact that I don’t really see a > problem in keeping the .so version for this case. > +1 The issue is severe and due to the summer holidays and work needed to prepare for Qt 5.8 it is not possible to make Qt 5.6.2 full release. Furthermore, we have now everything ready and tested for releasing the Qt 5.6.1-1 today, including full offline and online binary packages. Users need it and it is ready, so we really need to release this now. Yours, Tuukka > Cheers, > Lars > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Wed Jun 22 09:17:47 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 22 Jun 2016 07:17:47 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <15176666.iefUvhM14u@tjmaciei-mobl1> References: <23309410.drzYhCSC6U@tjmaciei-mobl1> <8CD8418A-96E2-4312-A111-04A0B820BF54@qt.io> <15176666.iefUvhM14u@tjmaciei-mobl1> Message-ID: <1CBC73B4-5507-464A-9022-7BB84C637987@qt.io> > On 21 Jun 2016, at 21:26, Thiago Macieira wrote: > > On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote: >> I think using screen names can be a good match for cases where you are >> sometimes connecting to external screens, provided that the string returned >> by name() is unique for each screen. > > It's not. It's always "DP-1" (it reports the connection, not the monitor). So far that’s a difference between OS X (which reports the monitor’s model name) and Linux (which reports the output name). If we could get both, on all OSes (which I’m not sure of), maybe we could format it like “SyncMaster on HDMI-1” or some such. From Morten.Sorvig at qt.io Wed Jun 22 10:21:40 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Wed, 22 Jun 2016 08:21:40 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <1CBC73B4-5507-464A-9022-7BB84C637987@qt.io> References: <23309410.drzYhCSC6U@tjmaciei-mobl1> <8CD8418A-96E2-4312-A111-04A0B820BF54@qt.io> <15176666.iefUvhM14u@tjmaciei-mobl1> <1CBC73B4-5507-464A-9022-7BB84C637987@qt.io> Message-ID: > On 22 Jun 2016, at 09:17, Shawn Rutledge wrote: > > >> On 21 Jun 2016, at 21:26, Thiago Macieira wrote: >> >> On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote: >>> I think using screen names can be a good match for cases where you are >>> sometimes connecting to external screens, provided that the string returned >>> by name() is unique for each screen. >> >> It's not. It's always "DP-1" (it reports the connection, not the monitor). > > So far that’s a difference between OS X (which reports the monitor’s model name) and Linux (which reports the output name). If we could get both, on all OSes (which I’m not sure of), maybe we could format it like “SyncMaster on HDMI-1” or some such. I was unable to find any API for getting the make or model of the monitor. Someone who is more familiar with XCB could give the authoritative answer here. If this is indeed impossible then users with multiple monitor setups have to manually maintain multiple QT_SCREEN_SCALE_FACTORS configs, based on either screen index or connection name. Morten From michael.zanetti at canonical.com Wed Jun 22 10:30:21 2016 From: michael.zanetti at canonical.com (Michael Zanetti) Date: Wed, 22 Jun 2016 10:30:21 +0200 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <7B33DF3E-E384-46E0-AA0E-DDB66DB1228A@qt.io> References: <2096409.Vgqk0hXBa4@master> <7B33DF3E-E384-46E0-AA0E-DDB66DB1228A@qt.io> Message-ID: <576A4C9D.3020207@canonical.com> On 20.06.2016 15:00, Morten Sorvig wrote: > >> On 17 Jun 2016, at 14:54, Frank Hemer wrote: >> >> Can you give a hint on what causes these glitches and how to avoid them? >> I'm not talking about general usage of fractional methods for painting here. >> >> For example when drawing to a pixmap (sized for the 'real' screen resolution) >> and then updating just a sub-rectangle of this pixmap, for some (and really >> only some) fractional scale factor values there are glitches around that sub- >> rectangle where the background color of the window shines through. >> What is causing this? > > I have not analyzed these in detail, but my guess would be rounding errors > due to fractional coordinates. So you could look at the update code (in QPainter > or the paint engine) and make sure coordinates are rounded to _include_ > partially covered pixels. > >> >> What is the reason for not aiming towards supporting fractional scale factors >> on the long run? What is the real challenge here? >> > > Good question! > > If you ask me I think the Qt project should move towards supporting this (taking > care to avoid maintenance traps such as the native styles). One of the challenges > is simply available time and resources for doing the work. But even today Qt Creator > at QT_SCALE_FACTOR=1.3 is a usable application. > > Another reason to not spend time on it would be that integer is, or is going > to be, the dominating use case. Wayland and Apple is integer, so are most of > the Android device categories. For Windows and desktop in general there are > currently lots of fractional hardware and configurations. I don't think this is true. From all the devices (phones/tablets) we support Ubuntu on, none is a full integer multiplier. I really don't see how it is going to fly if only full integers are supported. After all, all the Ubuntu Devices are actually based on Android hardware, so surely there the same issue would happen, no? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: From Shawn.Rutledge at qt.io Wed Jun 22 10:43:14 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 22 Jun 2016 08:43:14 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: References: <23309410.drzYhCSC6U@tjmaciei-mobl1> <8CD8418A-96E2-4312-A111-04A0B820BF54@qt.io> <15176666.iefUvhM14u@tjmaciei-mobl1> <1CBC73B4-5507-464A-9022-7BB84C637987@qt.io> Message-ID: <0876E476-8F40-4391-8777-50849E985B17@qt.io> > On 22 Jun 2016, at 10:21, Morten Sorvig wrote: > > >> On 22 Jun 2016, at 09:17, Shawn Rutledge wrote: >> >> >>> On 21 Jun 2016, at 21:26, Thiago Macieira wrote: >>> >>> On terça-feira, 21 de junho de 2016 18:02:05 PDT Morten Sorvig wrote: >>>> I think using screen names can be a good match for cases where you are >>>> sometimes connecting to external screens, provided that the string returned >>>> by name() is unique for each screen. >>> >>> It's not. It's always "DP-1" (it reports the connection, not the monitor). >> >> So far that’s a difference between OS X (which reports the monitor’s model name) and Linux (which reports the output name). If we could get both, on all OSes (which I’m not sure of), maybe we could format it like “SyncMaster on HDMI-1” or some such. > > I was unable to find any API for getting the make or model of the monitor. I’m not worried much about X11; it’s possible to get the whole EDID via xrandr —-props, which presumably either uses xrandr xcb API or reads it from /sys. What about getting the output connector name on OS X? If you connect two monitors of the same model, the name won’t be unique there, whereas at least the output name is unique on X11. From rjvbertin at gmail.com Wed Jun 22 10:48:05 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 22 Jun 2016 10:48:05 +0200 Subject: [Development] LTS and the "free"/non-commercial license In-Reply-To: <2093491466275198@web17h.yandex.ru> References: <2000886.r6WD1beTJ9@patux> <10265420.v8vWBT4eTP@portia.local> <2093491466275198@web17h.yandex.ru> Message-ID: <14244004.kny4yGbM9p@bola> On Saturday June 18 2016 21:39:58 Konstantin Tokarev wrote: Hi, >Qt 5.6 is LTS release: > >https://blog.qt.io/blog/2015/12/18/introducing-long-term-support/ Quick question: it looks like the long term support isn't interesting for users with commercial licenses only? IOW, Linux distributions or projects like MacPorts might want to consider to propose the choice between 5.6.x LTS and 5.7+ installation variants? R. From Morten.Sorvig at qt.io Wed Jun 22 10:53:48 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Wed, 22 Jun 2016 08:53:48 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: References: <23309410.drzYhCSC6U@tjmaciei-mobl1> <30521F13-8226-4DC8-86BE-8BA421D96E15@qt.io> <3508170.C7N1dtNIcX@tjmaciei-mobl1> <8F895D17-8089-4BCB-B6E3-7C3EE65E49CE@qt.io> Message-ID: > On 21 Jun 2016, at 15:24, Samuel Stirtzel via Development wrote: > > 2016-06-21 14:15 GMT+02:00 Shawn Rutledge : >> >>> On 20 Jun 2016, at 18:09, Thiago Macieira wrote: >>> 160x90 mm is a valid screen size, correspoding to a 7.2" monitor. >> >> Of course, it’s just suspicious (being a fallback value, apparently), but not impossible. > > Unfortunately it's not a fallback value, instead TV manufacturers > commonly only set the aspect ratio (in cm) because one EDID for all > devices is cheaper. > See bullet point d of Adam Jacksons mail about the EDID -> DPI topic: > https://lists.fedoraproject.org/pipermail/devel/2011-October/157671.html > I would also like to add that even if you _do_ get a trustable screen size, using physical DPI as a general purpose solution has flaws: * Physical sizes do not account for viewing distance, logical DPI/scale usually do. For example, a 2x iPhone has a higher pixel density than a 2x MacBook. The base Android DPI is 160. * You actually want some amount of quantization, at least for the general desktop use case. I use two 1x class screens with slightly different physical DPI. What happens when you move a window from one screen to another? If content size is based on physical DPI you get a shift in content logical size, and possibly a resize of the window, which is unexpected. Similarly windows scaling happens in 25% increments. Physical DPI is fine as a special purpose solution where the user or developer is in complete control of the hardware. For Qt I think this translates to that we can support using physical DPI, but it can’t be the default. Morten From marc.mutz at kdab.com Wed Jun 22 11:50:04 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 22 Jun 2016 11:50:04 +0200 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget In-Reply-To: <2188527.dtqgTZKnXT@bola> References: <2448170.ne5phv0VbN@portia.local> <2C3604B5-99B7-4B55-A570-35559686479D@qt.io> <2188527.dtqgTZKnXT@bola> Message-ID: <201606221150.07492.marc.mutz@kdab.com> On Tuesday 21 June 2016 12:36:02 René J.V. Bertin wrote: > On Tuesday June 21 2016 09:50:52 Eike Ziller wrote: > >I think this would be more a question to the Qt/macOS developers, to be > >asked on the development@ mailing list ;) > > OK then :) > > I've, erm, borrowed some code from Qt Creator to add a Dock icon > progressbar to KDevelop, adding a minimal API (only static methods as an > app has only a single Dock icon) as well as a poor man's indeterminate > mode. The code is still under review > (https://git.reviewboard.kde.org/r/128188) so I wonder if I shouldn't > instead by proposing it as a QtMacExtras addition. > > What do you think? Any suggestions how to integrate this into QtMacExtras, > as a standalone class or as additional QtMac methods? Windows also has taskbar progress. Not sure about KDE/Linux. It probably makes sense to add a couple of slots to QSystemTrayIcon (is there something similar in GUI?). Thanks, Mard -- 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 Eike.Ziller at qt.io Wed Jun 22 12:08:03 2016 From: Eike.Ziller at qt.io (Eike Ziller) Date: Wed, 22 Jun 2016 10:08:03 +0000 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget In-Reply-To: <201606221150.07492.marc.mutz@kdab.com> References: <2448170.ne5phv0VbN@portia.local> <2C3604B5-99B7-4B55-A570-35559686479D@qt.io> <2188527.dtqgTZKnXT@bola> <201606221150.07492.marc.mutz@kdab.com> Message-ID: > On Jun 22, 2016, at 11:50 AM, Marc Mutz wrote: > > On Tuesday 21 June 2016 12:36:02 René J.V. Bertin wrote: >> On Tuesday June 21 2016 09:50:52 Eike Ziller wrote: >>> I think this would be more a question to the Qt/macOS developers, to be >>> asked on the development@ mailing list ;) >> >> OK then :) >> >> I've, erm, borrowed some code from Qt Creator to add a Dock icon >> progressbar to KDevelop, adding a minimal API (only static methods as an >> app has only a single Dock icon) as well as a poor man's indeterminate >> mode. The code is still under review >> (https://git.reviewboard.kde.org/r/128188) so I wonder if I shouldn't >> instead by proposing it as a QtMacExtras addition. >> >> What do you think? Any suggestions how to integrate this into QtMacExtras, >> as a standalone class or as additional QtMac methods? > > Windows also has taskbar progress. Not sure about KDE/Linux. Qt Creator has an implementation for windows too http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/coreplugin/progressmanager/progressmanager_win.cpp Nobody of us found a sensible way to do something similar on various Linux desktops though. Br, Eike > It probably makes sense to add a couple of slots to QSystemTrayIcon (is there > something similar in GUI?). > > Thanks, > Mard > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - Qt, C++ and OpenGL Experts > _______________________________________________ > Qt-creator mailing list > Qt-creator at qt-project.org > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io +123 45 6789012 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From kfunk at kde.org Wed Jun 22 12:17:58 2016 From: kfunk at kde.org (Kevin Funk) Date: Wed, 22 Jun 2016 12:17:58 +0200 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget In-Reply-To: References: <2448170.ne5phv0VbN@portia.local> <201606221150.07492.marc.mutz@kdab.com> Message-ID: <1790332.79rtq79Uco@kerberos> On Mittwoch, 22. Juni 2016 10:08:03 CEST Eike Ziller wrote: > > On Jun 22, 2016, at 11:50 AM, Marc Mutz wrote: > > > > On Tuesday 21 June 2016 12:36:02 René J.V. Bertin wrote: > >> On Tuesday June 21 2016 09:50:52 Eike Ziller wrote: > >>> I think this would be more a question to the Qt/macOS developers, to be > >>> asked on the development@ mailing list ;) > >> > >> OK then :) > >> > >> I've, erm, borrowed some code from Qt Creator to add a Dock icon > >> progressbar to KDevelop, adding a minimal API (only static methods as an > >> app has only a single Dock icon) as well as a poor man's indeterminate > >> mode. The code is still under review > >> (https://git.reviewboard.kde.org/r/128188) so I wonder if I shouldn't > >> instead by proposing it as a QtMacExtras addition. > >> > >> What do you think? Any suggestions how to integrate this into > >> QtMacExtras, > >> as a standalone class or as additional QtMac methods? > > > > Windows also has taskbar progress. Not sure about KDE/Linux. > > Qt Creator has an implementation for windows too > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/coreplugin > /progressmanager/progressmanager_win.cpp > > Nobody of us found a sensible way to do something similar on various Linux > desktops though. The closest thing on Linux is probably the Unity Launcher API. I only know it because Plasma started to support it (read: use it) in Plasma 5.6. More information here: http://blog.broulik.de/2016/01/on-being-more-convenient/ https://wiki.ubuntu.com/Unity/LauncherAPI A platform agnostic wrapper for all this would be indeed great to have! Cheers, Kevin > > Br, Eike > > > It probably makes sense to add a couple of slots to QSystemTrayIcon (is > > there something similar in GUI?). > > > > Thanks, > > Mard -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From rjvbertin at gmail.com Wed Jun 22 12:26:09 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 22 Jun 2016 12:26:09 +0200 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget In-Reply-To: <201606221150.07492.marc.mutz@kdab.com> References: <2448170.ne5phv0VbN@portia.local> <2188527.dtqgTZKnXT@bola> <201606221150.07492.marc.mutz@kdab.com> Message-ID: <5338370.Zr7kzJvgZ0@bola> On Wednesday June 22 2016 11:50:04 Marc Mutz wrote: >It probably makes sense to add a couple of slots to QSystemTrayIcon (is there >something similar in GUI?). Except that the tray icon isn't related to the Dock icon on OS X ... It shows up in the menubar and is much too small to add a sensible progressbar to it. >Windows also has taskbar progress. Not sure about KDE/Linux. On Wednesday June 22 2016 10:08:03 Eike Ziller wrote: >Nobody of us found a sensible way to do something similar on various Linux desktops though. As Kevin said, there's something in Unity that could be used (cf https://git.reviewboard.kde.org/r/127050), but closer to home you can also find a progressbar via the KNotifications systray icon/menu. At least there's one in KDE4 showing the progress of certain file copy operations. Whether it's useful to have such a display in a GUI element that you have to expose explicitly is a bit of a question; if the application providing the progress info has a progressbar of its own (like Creator) you could just as well expose or switch to that application. >Qt Creator has an implementation for windows too >http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/plugins/coreplugin/progressmanager/progressmanager_win.cpp Yeah, but without a proper MSWin dev rig I'm not going to propose anything to provide it via an upstream patch/class ;) R. From oswald.buddenhagen at qt.io Wed Jun 22 13:21:37 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 22 Jun 2016 13:21:37 +0200 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: Message-ID: <20160622112137.GA21404@troll08.intra.qt.io> On Wed, Jun 22, 2016 at 06:48:39AM +0000, Lars Knoll wrote: > The only thing that changes when the Linux distributions do such an > update is the version number of the package, not of the .so’s inside. > > We basically do the same here. > but we can't, because we are upstream. if the qt company's release team does not act directly on behalf of the qt project, then this must be reflected in the version control system, as explicitly stated in the branch policy: the tag is v5.6.1-tqtc-1, and it is *not* forward-merged to 5.6. On Wed, Jun 22, 2016 at 06:54:54AM +0000, Tuukka Turunen wrote: > Users need it and it is ready, so we really need to release this now. > it's undoubtedly necessary, but the fact that it is ready does not authorize us as a company to violate the agreed upon rules. the rest of the mail dissects the technicalities. it's unnecessary to read it if you accept the conclusions reached so far. On Wed, Jun 22, 2016 at 06:28:12AM +0000, Jani Heikkinen wrote: > To be clear: There isn't version bump in qt, it is still 5.6.1. We > just re-packed the release from '5.6.1' branch with that new change > for fixing QTBUG-53761 included. > you're kinda trying to make the argument that the packages are a patched downstream version, but that seems quite unconvincing: we *are* upstream. this is reinforced by the fact that our installers are the primary advertized distribution medium. and it's sealed by you creating an upstream tag in the mainline repository. > In my opinion bumping version numbers and doing totally new release > because of just one fix is too heavy. I think we should have a way to > produce this kind of update with 'simple hot fix' easily and quickly > without re-doing whole release in case of this kind of blocker. > you're trying to both eat the cake and have it. it has different contents (which is reflected by a different tag), so it *is* a different version. it doesn't matter how small the difference is. On Wed, Jun 22, 2016 at 10:20:15AM +0000, Jani Heikkinen wrote: > Actually there is quite many things to do for the new release (agree > the content, get the agreed content in etc.) but if we are assuming > content is agreed to be one change + version bumps then the flow is > pretty much as follows: > > 1. Create new branch for the release (not needed if updating existing > release) > not necessary, as already pointed out. the existence of a release branch is a convenience, not a requirement. the name matching the released version is luxury (we could have release and release-lts branches just as well). > 2. Do version bumps for submodules in that new branch + create a fix > in that new branch (not needed if updating existing release) > while it would be somewhat weird, we could bump only qtdeclarative and qt5, keeping the version number of the other modules the same. but anyway, see next point. > 3. Integrate fix + version bumps. When we are doing new release we > need to bump version in each submodule as well. Knowing our CI > stability it will take a while when all version bumps are in > submodules. Without version bump we just need to integrate that one > change in one submodule > as you could have figured out by just looking at the commits, version bumps are direct-pushed by my script (except repos that happen to be busy for extended periods of time while i do the bumping, typically qtbase). so this is a non-argument. > 4. Integrate submodule changes in qt5.git. If all modules are changed > this step will most probably fail few times because of CI instability > (flaky tests, network issues etc). With change in one submodule this > is most probably much easier & will go through much quicker > i don't see how changing at most the version number in all other modules could delay the integration. > 5. Merge qt5.git in our super repository containing qt5.git + > enterprise features. > > 6. Run packaging tools for src and binary packages (patch content, > package content in suitable form for installers). > > 7. Update packaging configurations. If we are doing new release we > need to create all new packaging configurations for that. > i'll buy that, but this indicates just how broken the system is. cloning a branch config should be a matter of a single near-trivial commit. the previous two points also just show how bad our system is. luckily, this is finally being worked on. > 8. Update release test automation configurations and tests. (not > needed if updating existing release) > > 9. Create packages for the release (Online repository and offline > inataller packages, LGPL and commercial ones) > same again. broken infrastructure. > 10. Test the release. If we update existing release with one change it > is much easier to test. > see point 4. From Morten.Sorvig at qt.io Wed Jun 22 14:46:09 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Wed, 22 Jun 2016 12:46:09 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <576A4C9D.3020207@canonical.com> References: <2096409.Vgqk0hXBa4@master> <7B33DF3E-E384-46E0-AA0E-DDB66DB1228A@qt.io> <576A4C9D.3020207@canonical.com> Message-ID: <5E0A3AB2-97CC-4F23-A361-FEBCA4AFA7FE@qt.io> > On 22 Jun 2016, at 10:30, Michael Zanetti wrote: > > > > On 20.06.2016 15:00, Morten Sorvig wrote: >> >> Another reason to not spend time on it would be that integer is, or is going >> to be, the dominating use case. Wayland and Apple is integer, so are most of >> the Android device categories. For Windows and desktop in general there are >> currently lots of fractional hardware and configurations. > > I don't think this is true. From all the devices (phones/tablets) we > support Ubuntu on, none is a full integer multiplier. I really don't see > how it is going to fly if only full integers are supported. After all, > all the Ubuntu Devices are actually based on Android hardware, so surely > there the same issue would happen, no? > What I have for Android devices are tables like this: (there are various sources, see below) 0.75 - ldpi 1.0 - dpi 1.5 - hdpi 2.0 - xhdpi 3.0 - xxhdpi 4.0 - xxxhdpi The factor here is DisplayMetrics.density. This suggests integer factors, or at least a convergence towards integer factors if we allow that new Android devices are xhdpi or better. It think what is happening is that the hardware may be non-integer, but then Android maps that to a device class with a fixed scale factor. We can use that scale factor in Qt - any error introduced by it (if the hardware is some fraction between classes) will be matched by the native UI. If Qt applications are going to see fractional factors on Ubuntu then that’s a point in favor of making Qt work better in that configuration. Morten http://stackoverflow.com/questions/3166501/getting-the-screen-density-programmatically-in-android https://groups.google.com/forum/#!msg/android-developers/g56jV0Hora0/9d8p8QJg1ksJ From michael.zanetti at canonical.com Wed Jun 22 15:30:52 2016 From: michael.zanetti at canonical.com (Michael Zanetti) Date: Wed, 22 Jun 2016 15:30:52 +0200 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <5E0A3AB2-97CC-4F23-A361-FEBCA4AFA7FE@qt.io> References: <2096409.Vgqk0hXBa4@master> <7B33DF3E-E384-46E0-AA0E-DDB66DB1228A@qt.io> <576A4C9D.3020207@canonical.com> <5E0A3AB2-97CC-4F23-A361-FEBCA4AFA7FE@qt.io> Message-ID: <576A930C.5030800@canonical.com> On 22.06.2016 14:46, Morten Sorvig wrote: > >> On 22 Jun 2016, at 10:30, Michael Zanetti wrote: >> >> >> >> On 20.06.2016 15:00, Morten Sorvig wrote: >>> >>> Another reason to not spend time on it would be that integer is, or is going >>> to be, the dominating use case. Wayland and Apple is integer, so are most of >>> the Android device categories. For Windows and desktop in general there are >>> currently lots of fractional hardware and configurations. >> >> I don't think this is true. From all the devices (phones/tablets) we >> support Ubuntu on, none is a full integer multiplier. I really don't see >> how it is going to fly if only full integers are supported. After all, >> all the Ubuntu Devices are actually based on Android hardware, so surely >> there the same issue would happen, no? >> > > What I have for Android devices are tables like this: (there are various > sources, see below) > > 0.75 - ldpi > 1.0 - dpi > 1.5 - hdpi > 2.0 - xhdpi > 3.0 - xxhdpi > 4.0 - xxxhdpi > > The factor here is DisplayMetrics.density. This suggests integer factors, or > at least a convergence towards integer factors if we allow that new Android > devices are xhdpi or better. > > It think what is happening is that the hardware may be non-integer, but then > Android maps that to a device class with a fixed scale factor. We can use that > scale factor in Qt - any error introduced by it (if the hardware is some fraction > between classes) will be matched by the native UI. > > If Qt applications are going to see fractional factors on Ubuntu then that’s > a point in favor of making Qt work better in that configuration. Hmm, I see... So what we are using is this: Nexus 4: 2.25 Nexus 7: 2.25 Nexus 10: 2.5 bq E4.5: 1.625 Meizu Pro 5: 2.625 Because of this we're currently not using the devicePixelRatio() API. Instead, that one is set to 1 and we add an additional layer in our toolkit on top. So we'd use units.gu(1) on the application level to express 8 pixels on a scale factor of 1. That method then returns device pixels based on the scale factor, rounding it to full integers after the scaling. Those values are calculated in a way that we'd get as close as possible to a consistent look and feel of the platform. For example, for a 4 to 5 inch screen we try to have 40 grid units (units.gu(40)) in width. 5 to 6 inch devices would have 50 grid units in width and so on. This gives a rather consistent look and feel of the platform across different sizes and pixel densities. Using this method in our toolkit on top of Qt is obviously not ideal for a (rather big) number of reasons and we *really* would like to drop this in favor of the in-Qt high dpi mechanism. For that however, it would need to match a number of requirements: * floating point scaling * different scale factor per window * dynamically changing scale factor * some sort of language that allows developers to use virtual sizes, ideally we'd be able to register our grid unit stuff as that's what all our design has evolved around. I really think that in the mid to long run, all of those requirements will become natural on all platforms. Now that people start connecting external displays to their phones, or now that desktop monitors come with different pixel densities, dragging a window from one screen to another with a different pixel density will become something we encounter more and more often. Some more details on this can be found in an earlier mail on this topic: http://lists.qt-project.org/pipermail/development/2016-February/024954.html Best regards, Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 246 bytes Desc: OpenPGP digital signature URL: From ekke at ekkes-corner.org Wed Jun 22 15:32:24 2016 From: ekke at ekkes-corner.org (ekke) Date: Wed, 22 Jun 2016 15:32:24 +0200 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <5E0A3AB2-97CC-4F23-A361-FEBCA4AFA7FE@qt.io> References: <2096409.Vgqk0hXBa4@master> <7B33DF3E-E384-46E0-AA0E-DDB66DB1228A@qt.io> <576A4C9D.3020207@canonical.com> <5E0A3AB2-97CC-4F23-A361-FEBCA4AFA7FE@qt.io> Message-ID: <8e753797-ec06-8183-8289-fe1cdc073de4@ekkes-corner.org> Am 22.06.16 um 14:46 schrieb Morten Sorvig: >> On 22 Jun 2016, at 10:30, Michael Zanetti wrote: >> >> >> >> On 20.06.2016 15:00, Morten Sorvig wrote: >>> Another reason to not spend time on it would be that integer is, or is going >>> to be, the dominating use case. Wayland and Apple is integer, so are most of >>> the Android device categories. For Windows and desktop in general there are >>> currently lots of fractional hardware and configurations. >> I don't think this is true. From all the devices (phones/tablets) we >> support Ubuntu on, none is a full integer multiplier. I really don't see >> how it is going to fly if only full integers are supported. After all, >> all the Ubuntu Devices are actually based on Android hardware, so surely >> there the same issue would happen, no? >> > What I have for Android devices are tables like this: (there are various > sources, see below) > > 0.75 - ldpi > 1.0 - dpi > 1.5 - hdpi > 2.0 - xhdpi > 3.0 - xxhdpi > 4.0 - xxxhdpi > > The factor here is DisplayMetrics.density. This suggests integer factors, or > at least a convergence towards integer factors if we allow that new Android > devices are xhdpi or better. my android device reports 3.5 for qApp->primaryScreen()->devicePixelRatio() Does this mean Qt is using 4.0 and not 3.5 as scale factor ? Images are correctly used from @4 ekke > It think what is happening is that the hardware may be non-integer, but then > Android maps that to a device class with a fixed scale factor. We can use that > scale factor in Qt - any error introduced by it (if the hardware is some fraction > between classes) will be matched by the native UI. > > If Qt applications are going to see fractional factors on Ubuntu then that’s > a point in favor of making Qt work better in that configuration. > > Morten > > http://stackoverflow.com/questions/3166501/getting-the-screen-density-programmatically-in-android > https://groups.google.com/forum/#!msg/android-developers/g56jV0Hora0/9d8p8QJg1ksJ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Jun 22 17:32:17 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 22 Jun 2016 08:32:17 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <1595018.V9QeEXHkkO@tjmaciei-mobl1> Message-ID: <4529096.sZYpHiLvaz@tjmaciei-mobl1> On quarta-feira, 22 de junho de 2016 06:48:39 PDT Lars Knoll wrote: > >Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be different > > from the original 5.6.1 version. > > Why? So that when someone reports an issue, we can tell from the sources whether it included the fix or not. > It’s one patch for a bug that can hit quite some of our users, otherwise > everything is identical. Hence updating only qtdeclarative's version number, not everything else. > Let’s for a second assume, we had not released an update, but added this to > the known issues page and released 5.6.2 some time later this year. What > would have happened is that all Linux distributions would have picked up > that one patch, added it to their packages, and recompiled 5.6.1. The .so > version number inside the distributions would still be 5.6.1, and you > wouldn’t know the difference looking from the outside. The only thing that > changes when the Linux distributions do such an update is the version > number of the package, not of the .so’s inside. Exactly. The .so don't need to have their number changed, but the package does. So we need to update .qmake.conf. Whether that updates the .so file names or not is irrelevant. MODULE_VERSION = 5.6.1.1 will produce .so.5.6.1 > We basically do the same here. Yes, we can argue whether the tag should be > 5.6.1-1 or 5.6.1.1, but it doesn’t change the fact that I don’t really see > a problem in keeping the .so version for this case. Nor I. So let's change the tag and the MODULE_VERSION. It's important that if I ask a user, they can check their source code and see which one of the sources they downloaded, after they removed the original .tar.gz file. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jun 22 18:31:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 22 Jun 2016 09:31:13 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <9706243.cgEQ5ABx34@tjmaciei-mobl1> Message-ID: <7696335.zP9oOx0sL1@tjmaciei-mobl1> On quarta-feira, 22 de junho de 2016 06:28:12 PDT Jani Heikkinen wrote: > Hi, > > > To be clear: There isn't version bump in qt, it is still 5.6.1. Are the source packages the same? No? Then it's a new version. > We just > re-packed the release from '5.6.1' branch with that new change for fixing > QTBUG-53761 included (https://codereview.qt-project.org/#/c/162677/). In > tags & packages we used 5.6.1-1 to make difference with original and > updated ones & to be able to identify if user has original or re-packed > version in the use. Of course we could just move v5.6.1 tag in declarative > and ignore v5.6.1-1 and that's it... We could do that, yes: * no new qtdeclarative source package * cherry-pick the patch to the tree used for the binaries, release * update the binary relase version I just think it's a bad idea and would cause confusion too. But I'm asking that we Do The Right Thing, instead of trying to find the solution with the least amount of effort. We own up to our mistakes and then we fix the correctly. > But It has done this way now. Ok, if tag or something is really broken let's > just correct that but otherwise just live with this now. And for the future > lets just agree the way to work with this kind of 'brown paper bug issue'. Let's agree on no more "brown paper bag fixes". Let's not rush into more mistakes. This only happened because we tried to find the solution with the least amount of effort instead of doing the proper, established way of creating new releases. > In my opinion bumping version numbers and doing totally new release because > of just one fix is too heavy. I think we should have a way to produce this > kind of update with 'simple hot fix ' easily and quickly without re-doing > whole release in case of this kind of blocker. If we have a light-weight procedure, great, let's use it. But we don't. And creating one the moment we need a quick fix is a bad idea, because we're going down untested paths and creating more problems in the process, as the current case has shown. I think we should have a light-weight procedure. Let's investigate it when we have the time to do it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From prashantpurohit025 at gmail.com Wed Jun 22 19:29:52 2016 From: prashantpurohit025 at gmail.com (Prashant Purohit) Date: Wed, 22 Jun 2016 22:59:52 +0530 Subject: [Development] Multiple Windows Dead-Lock Observed on QNX with Qt-5.3.2 In-Reply-To: References: <2726381.rVxRQ2xRzH@tjmaciei-mobl1> Message-ID: Hi James, Thanks for your reply. Sorry that it took me few days to try these commands . I have tried the mentioned command by you and below is the output for the same: Output of pidin -p : ------------------------------------------------------------------------------ pid tid name prio STATE Blocked 630842 1 myprocess 11r CONDVAR (0xb534478) 630842 2 myprocess 31r CONDVAR (0x807574c) 630842 3 myprocess 57r RECEIVE 4 630842 4 myprocess 11r SEM ad611854 630842 5 myprocess 11r SIGWAITINFO 630842 6 myprocess 11r CONDVAR (0x9ce6ed8) 630842 7 myprocess 31r REPLY 118804 630842 8 myprocess 11r MUTEX (0xba91210) 630842-09 #1 630842 9 myprocess 31r MUTEX (0x807573c) 630842-02 #1 ------------------------------------------------------------------------------ Output of pidin -p screen: ------------------------------------------------------------------------------ pid tid name prio STATE Blocked 118804 1 sbin/screen 10r SIGWAITINFO 118804 2 sbin/screen 21r RECEIVE 1 118804 3 sbin/screen 20r RECEIVE 10 118804 4 sbin/screen 31r RECEIVE 6 118804 5 sbin/screen 15r CONDVAR (0x80993c4) 118804 6 sbin/screen 10r RECEIVE 15 118804 7 sbin/screen 11r RECEIVE 15 118804 8 sbin/screen 10r NANOSLEEP 118804 9 sbin/screen 10r RECEIVE 15 118804 10 sbin/screen 11r RECEIVE 15 118804 11 sbin/screen 21r RECEIVE 20 118804 12 sbin/screen 21r CONDVAR (0x80c4010) ------------------------------------------------------------------------------ Please suggest if you know a work-around to solve this issue. Also I tried setting QSG_RENDER_LOOP=windows but the animation is still not looking as good as it was without setting this flag. Regards, Prashant On 6/15/16, James McDonnell wrote: > Hi Prashant, > > Can you provide the output for a ³pidin -p ² and a "pidin > -p screen² when the system is in this state? > > James > > On 2016-06-15, 1:54 PM, "Development on behalf of Thiago Macieira" > thiago.macieira at intel.com> wrote: > >>On quarta-feira, 15 de junho de 2016 23:11:24 PDT Prashant Purohit wrote: >>> Hi all, >>> >>> I am new to QT and using QT with QNX. >>> I am using two different windows in my application (It is not possible >>> for me to use single window). >>> >>> When I switch from one window to another window, My screen is not >>> responding due to deadlock. Though there is no crash observed. >>> >>> My situation is similar to bug >>> (https://bugreports.qt.io/browse/QTBUG-47553) which is already >>> reported. >>> >>> By referencing above bug, when I set QSG_RENDER_LOOP=basic, the dead >>> lock condition is prevented but then the animation which is being >>> shown after every button press is not smooth anymore. >>> >>> Is there any better solution for above problem? >>> If QSG_RENDER_LOOP=basic is the only solution then what I need to do >>> to make the animation (sequencialAnimation on every button press) >>> smooth as it was before setting the QSG_RENDER_LOOP environment >>> variable? >>> >>> Also is there any alternative which I can use in my code other than >>> setting QSG_RENDER_LOOP environment variable? >> >>Hello Prashant >> >>Please upgrade. 5.3.2 is a year and a half old. We've just released 5.6.1 >>and >>we're about to release 5.7.0. Please try 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 > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From Morten.Sorvig at qt.io Thu Jun 23 08:29:22 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Thu, 23 Jun 2016 06:29:22 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <8e753797-ec06-8183-8289-fe1cdc073de4@ekkes-corner.org> References: <2096409.Vgqk0hXBa4@master> <7B33DF3E-E384-46E0-AA0E-DDB66DB1228A@qt.io> <576A4C9D.3020207@canonical.com> <5E0A3AB2-97CC-4F23-A361-FEBCA4AFA7FE@qt.io> <8e753797-ec06-8183-8289-fe1cdc073de4@ekkes-corner.org> Message-ID: <5A200F7A-13EF-4C09-9C2B-F0BA691954DB@qt.io> > On 22 Jun 2016, at 15:32, ekke wrote: > > Am 22.06.16 um 14:46 schrieb Morten Sorvig: >>> >> What I have for Android devices are tables like this: (there are various >> sources, see below) >> >> 0.75 - ldpi >> 1.0 - dpi >> 1.5 - hdpi >> 2.0 - xhdpi >> 3.0 - xxhdpi >> 4.0 - xxxhdpi >> >> The factor here is DisplayMetrics.density. This suggests integer factors, or >> at least a convergence towards integer factors if we allow that new Android >> devices are xhdpi or better. >> > my android device reports 3.5 for > > qApp->primaryScreen()->devicePixelRatio() > > Does this mean Qt is using 4.0 and not 3.5 as scale factor ? > Images are correctly used from @4 In this case Qt is indeed using 3.5. And when loading images we round up and use the @4 version. You could double check that this actually the value DisplayMetrics.density() returns, but I think we’ll find that it is. This data point suggests that the Android world is not as simple as the above table. Morten From Lars.Knoll at qt.io Thu Jun 23 09:29:56 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Thu, 23 Jun 2016 07:29:56 +0000 Subject: [Development] New configuration system Message-ID: <4D7485AB-6F17-49F7-B5A6-DAA776FE613A@qt.io> Hi, As some of you might know, I’ve been working for some time now on developing a new configuration system for Qt. As the first large change went in yesterday evening, I guess it’s time I describe it a little, and also tell you a bit about what’s still coming. The goal of the new system is twofold. First of all, we are seeing a large need, especially with our embedded users, to customise how Qt is being built. Many of them have size restrictions ore rather hard testing requirements, where being able to limit the functionality available in Qt is extremely helpful. We had such a system (see src/corelib/global/qfeatures.txt) before, but it was disconnected from the configure script, wasn’t really maintained since Qt 4 times, and had quite many limitations that I hope to solve with the new system. Secondly, we have had to deal for a long time with two different configuration systems. We had a monster of a shell script for unix, and an Qt based executable on Windows. Changes to Qt often required changing both, and it was very easy to sneak subtle errors in. Maintainability of the old system was in general very poor. So with that comes the new system. As I said, the first (but largest) patch went yesterday evening (see https://codereview.qt-project.org/#/c/149202/). It basically moves most of the configuration handling from the shell script over to a declarative json file (currently configure.json) that is being processed by qmake. This currently only affects Unix, Windows platforms are still being configured through configure.exe. The change aims to be a 1 to 1 (or at least as close as possible) mapping of the old shell script to the new system. So if you find that some configuration you’re using is suddenly broken let me know. I’ll send out a separate email describing the new system in more detail for those who are interested. For everybody else, there are a couple of changes that will still come in over the next couple of weeks: * Give every module a qtmoduleglobal.h and qtmoduleglobal_p.h file We already have per module global files for many modules (they are often required for the export/import handling of classes/symbols). With the new system we will add a public and private global file per module. I’ll start requiring that all public headers of the module include the public global file first, all private headers the private global file. This is needed some steps below to modularise the configuration system and to allow us to track whether a certain feature we rely upon in code is actually available or not. See https://codereview.qt-project.org/#/c/161143 and subsequent changes (the change adding global_p.h is still missing here, but will come as well) * Saner handling of 3rd party libs Currently all our dependencies to external libs are handled in a rather ad-hoc way in the pro files. The goal is to unify this, see https://codereview.qt-project.org/#/c/161660/ * Modularisation of the new configuration system I have some patches pending to modularise the new system. We will basically have one json configuration file per module/shared library. This will also allow us to use the system fully on repositories outside of qtbase, who currently have rather limited support for being configured. With this change, we will start creating a qtmodule-config.h and qtmodule-config_p.h file as well as a corresponding public and private .pri files for each module. qtmodule-config.h will get included from the public global header for the module, qtmodule-config_p.h from the private one. The public pro file will contain definitions for the features that are being exported by the module, the private one for features that are only relevant in the context of the module itself. As an example, ‘mimetypes’ would be a public feature of QtCore (as it changes the set of available API), whereas ‘glib’ would be most likely a private one (as it only determines which event loop to use and doesn’t change API). See change https://codereview.qt-project.org/#/c/159604/40 and the following commit * Integration of the old feature system As said above, there is the old feature system (see qfeatures.txt in corelib/global). With the work above done, integrating it into the system will be trivial (change https://codereview.qt-project.org/#/c/159763/) * With this done, I will also want to introduce a new mechanism to handle features in our cpp and header files. The current double negated #ifndef QT_NO_FOO is hard to read and unsafe. By unsafe, I mean that the compiler won’t error out or warn us if the feature ‘foo’ isn’t available (because of a typo or because the feature is actually defined in widgets and you tried using it in gui). I have some pending work that would change this to use a macro function "#if QT_HAS_FEATURE(foo)” where we would actually get a compile error if the feature foo isn’t known to the system. As a nice side effect I’m planning on having the same names for features between .pro and c++ files. * Further reduce the shell script The longer term goal will be to reduce the shell script further, until it’s basically a bootstrapping step for qmake, and hand all the other configuration work over to qmake. Some more patches for this are pending, but further help here would be appreciated. * Get rid of configure.exe Finally, I’d also like to get rid of configure.exe, and do the same thing on Windows (ie. Bootstrap qmake from a small script, like we bootstrap configure.exe today) and then let qmake deal with the rest. With that we should be able to get to one cross-platform configuration system. For this task I’d be looking for volunteers :) Cheers, Lars From Lars.Knoll at qt.io Thu Jun 23 10:13:26 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Thu, 23 Jun 2016 08:13:26 +0000 Subject: [Development] New configuration system (details) Message-ID: <8831E763-29D4-4F6F-AEBE-A43517E6FA6B@qt.io> Hi, here’s the promised look at the details of the new system, in case you need to implement your own configure tests or want to add configurability to Qt. We now have one global configuration file qtbase/configure.json, that contains the details about how Qt can be configured. Actually I’m slightly lying with that, as there also is a configure.pri file that contains some qmake methods to handle special cases (specialised tests our output handling). You can find the infrastructure for the whole system in qt_configure.prf. The system basically works through two main systems. The first one is a callback infrastructure, where all “type” fields provided in the json file actually refer to callback functions in qmake that do the actual handling. This allows you to e.g. Implement your own custom test function in a .pri file and refer to that from the json. qt_configure has callbacks for the most common tasks, so you won’t need this feature in most cases. If you want to know how such custom callbacks can look like, have a look at configure.pri. The other central piece is an expression evaluator, that is being used to evaluate conditions. It allows you to test for rather complex conditions (like e.g. “config.win32 && tests.mysql && features.opengl”) and is being used in many places. The evaluator understands boolean operators (!, && and ||), comparison operators (== and !=), braces and different types of arguments: frue/false: boolean values ‘foo’: The string literal foo config.foo: Variables in the qmake CONFIG var (usually used for platform dependent stuff like config.unix) tests.foo: Boolean whether the test foo succeeded tests.foo.bar: Variable bar, set by tests.foo features.foo: boolean whether feature foo is available features.foo.bar: variable bar set by features.foo arch.foo: architecture (like x86, arm, etc) input.foo: input variable (set by command line handling) far.foo: Any variable set in qmake call.foo: return value of the replace function foo in qmake This gives you quite some options to define conditions and dependencies between features. The system automatically runs the configure test, if you ask for tests.foo, so dependency handling is fully transparent. Now let’s have a look at configure.json: The file contains a couple of sections. The first one is called “files”, and contains definitions for the output files. You should not need to touch this one. The next section contains the command line parameters that you can pass to the configuration system. It basically defines the valid command line arguments that configure will recognise. They are being mapped to a config.input.option value in qmake, that is then being used in the next step of defining the features we will use for Qt. Typical entries looks like "harfbuzz": { "type": "enum", "values": [ "no", "qt", "system" ] }, "headersclean": "boolean", This means harfbuzz is an option that can take a selection of args (-no/-qt/-system), whereas headersclean is a boolean argument (-headersclean and -no-headersclean accepted). The second form is a shorthand for "headersclean”: { “type”: “boolean” } Note that the type variable refers to a callback. In this case a test function qtConfCommandline_boolean. Then comes a section with tests. Those define all the configure tests that so far have been executed by the shell script. The definition of a typical test looks like: "fontconfig": { "description": "Fontconfig”, "type": "compile”, "test": "unix/fontconfig”, "pkg-config-args": "fontconfig freetype2”, "libs": "-lfontconfig -lfreetype" } This basically defines a configure test for fontconfig. It’s a compile test, the test being in config.tests/unix/fontconfig. It’ll try to use pig-config to determine the correct LIBS and CFLAGS to compile and link against the library, and there is a fallback for the libs in case fontconfig can’t be found. Again, the type variable refers to a callback (qtConfTest_compile in this case). After that we have the central section that defines all the features. Let’s take one example: "icu": { "description": "ICU”, "autoDetect": "!config.win32”, "condition": "tests.icu”, "output": [ "publicQtConfig” ] }, This defines the icu feature. It’s not auto-detected on windows, requires the ice configure test to pass, and will then generate one output called publicQtConfig. Here are some details of the fields: description: A short description of the feature. Used by the summary section below autoDetect: Should evaluate to a boolean value whether to automatically detect the feature. Defaults to true emitIf: Skip the feature completely if this evaluated to false (don’t evaluate conditions or outputs). Defaults to true. enable: Evaluates to a condition that will enable the feature (defaults to “input.feature == yes”) disable: the opposite, (defaults to “input.feature == no”) condition: A condition that determines whether the feature is enabled/disabled. Will generate an error if it conflicts with the enable field above output: Different types of output to generate Output deserves a separate section. Also here you can define arbitrary callbacks, but the standard types should cover most needs: “publicQtConfig": Add the feature name to the QT_CONFIG variable in the public pri file (here qconfig.pri) “publicConfig": Add the feature name to the CONFIG variable in the public pri file (here qconfig.pri) "privateConfig": Same for the private pri (qmodule.pri) “feature”: Defines a feature. Adds it to QT_CONFIG if available, sets QT_NO_FEATURE otherwise { “type”: “define”, “name”: “FOO”, “value”: “expression” } #define FOO expression in the public header file, expression is evaluated { “type”: “libs”, “test”: “configtest” } Output QMAKE_LIBS/CFLAGS_FEATURE defining parameters required to use an external library An addition, there are varAssign, varAppend and varRemove to assign, append and remove values from qmake variables All outputs can have a ‘negative’: true/false field (default false), that would reverse when output is being generated (usually only if the feature is available, and a ‘condition’ field. Finally there are two sections called ‘earlyReport’ and ‘report’. Use ‘report’ unless you know what you’re doing. These sections allow you to define conditions under which notes, warnings or errors are being reported back to the user. Finally, there’s a summary section, that defines the configure summary we’re reporting back to the user. I’ll leave figuring out the details here as an exercise to the reader ;-) Cheers, Lars From mike.krus at kdab.com Thu Jun 23 12:15:02 2016 From: mike.krus at kdab.com (Mike Krus) Date: Thu, 23 Jun 2016 11:15:02 +0100 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget In-Reply-To: <1790332.79rtq79Uco@kerberos> References: <2448170.ne5phv0VbN@portia.local> <201606221150.07492.marc.mutz@kdab.com> <1790332.79rtq79Uco@kerberos> Message-ID: > On 22 Jun 2016, at 11:17, Kevin Funk wrote: > A platform agnostic wrapper for all this would be indeed great to have! If QtWinExtra has it, QtMacExtra can have it, and it’s doable on Linux, why not add static methods on QProgressBar? Mike -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK +44-1625-809908 Mobile: +44 7833 491941 KDAB - The Qt Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Jun 24 02:12:30 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Jun 2016 17:12:30 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <1595018.V9QeEXHkkO@tjmaciei-mobl1> References: <2002755.ggY99F3WFB@tjmaciei-mobl1> <1595018.V9QeEXHkkO@tjmaciei-mobl1> Message-ID: <2875351.7iyjDlFit0@tjmaciei-mobl1> On terça-feira, 21 de junho de 2016 23:37:57 PDT Thiago Macieira wrote: > On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote: > > I propose that we delete the bad tag, retag and rerelease with a better > > name. > > Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be different > from the original 5.6.1 version. What action is going to be taken to fix this mistake? Suggestion: * delete the v5.6.1-1 tag immediately * immediately retract all source and binary releases with "-1" in the name * modify qtdeclarative's .qmake.conf to say MODULE_VERSION = 5.6.2 * tag that v5.6.2, update qt5.git and tag it v5.6.2 * rebuild binaries * release them and source The tag v5.6.2 will be skipped in all the other modules. We update all of their MODULE_VERSION to 5.6.3. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 24 05:31:20 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Jun 2016 20:31:20 -0700 Subject: [Development] Notice to all packagers: Qt 4 mistakenly detects GCC6 as a different ABI Message-ID: <2207354.PKFgvh1W5k@tjmaciei-mobl1> You may start getting this error once you upgrade the compiler: Plugin uses incompatible Qt library expected build key "x86_64 linux g++-6 full-config", got "x86_64 linux g++-4 full-config" "The plugin '/usr/lib64/kde4/plugins/styles/breeze.so' uses incompatible Qt library. Expected build key "x86_64 linux g++-6 full-config", got "x86_64 linux g++-4 full-config"" The configure script needs a simple patch to recognise GCC 6 as the same ABI as GCC 4 and 5. Please apply it to your Qt 4 builds if your distro is switching to GCC 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- A non-text attachment was scrubbed... Name: configure.diff Type: text/x-diff Size: 261 bytes Desc: not available URL: From Lars.Knoll at qt.io Fri Jun 24 08:49:56 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Fri, 24 Jun 2016 06:49:56 +0000 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <2875351.7iyjDlFit0@tjmaciei-mobl1> References: <2002755.ggY99F3WFB@tjmaciei-mobl1> <1595018.V9QeEXHkkO@tjmaciei-mobl1> <2875351.7iyjDlFit0@tjmaciei-mobl1> Message-ID: <301E19B5-1193-40A4-B58E-654CB8403C30@qt.io> On 24/06/16 02:12, "Development on behalf of Thiago Macieira" wrote: >On terça-feira, 21 de junho de 2016 23:37:57 PDT Thiago Macieira wrote: >> On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote: >> > I propose that we delete the bad tag, retag and rerelease with a better >> > name. >> >> Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be different >> from the original 5.6.1 version. > >What action is going to be taken to fix this mistake? > >Suggestion: > * delete the v5.6.1-1 tag immediately > * immediately retract all source and binary releases with "-1" in the name > * modify qtdeclarative's .qmake.conf to say MODULE_VERSION = 5.6.2 > * tag that v5.6.2, update qt5.git and tag it v5.6.2 > * rebuild binaries > * release them and source > >The tag v5.6.2 will be skipped in all the other modules. We update all of >their MODULE_VERSION to 5.6.3. What’s the point? Create ourselves man weeks worth of work and completely confuse all our users for what exactly? Let’s have a discussion at QtCS how to best do things in the future, but this is not worth it. Lars From thiago.macieira at intel.com Fri Jun 24 09:41:25 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 24 Jun 2016 00:41:25 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <301E19B5-1193-40A4-B58E-654CB8403C30@qt.io> References: <2875351.7iyjDlFit0@tjmaciei-mobl1> <301E19B5-1193-40A4-B58E-654CB8403C30@qt.io> Message-ID: <3250075.1QZH7qfuxE@tjmaciei-mobl1> On sexta-feira, 24 de junho de 2016 06:49:56 PDT Lars Knoll wrote: > On 24/06/16 02:12, "Development on behalf of Thiago Macieira" > thiago.macieira at intel.com> wrote: > > >On terça-feira, 21 de junho de 2016 23:37:57 PDT Thiago Macieira wrote: > > > >> On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote: > >> > >> > I propose that we delete the bad tag, retag and rerelease with a > >> > better > >> > name. > >> > >> > >> Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be > >> different from the original 5.6.1 version. > > > > > >What action is going to be taken to fix this mistake? > > > >Suggestion: > > > > * delete the v5.6.1-1 tag immediately > > * immediately retract all source and binary releases with "-1" in the > > name > > * modify qtdeclarative's .qmake.conf to say MODULE_VERSION = 5.6.2 > > * tag that v5.6.2, update qt5.git and tag it v5.6.2 > > * rebuild binaries > > * release them and source > > > > > >The tag v5.6.2 will be skipped in all the other modules. We update all of > >their MODULE_VERSION to 5.6.3. > > > What’s the point? Create ourselves man weeks worth of work and completely > confuse all our users for what exactly? For two reasons: 1) because every Linux packager will call it 5.6.1.1, not 5.6.1-1. The tag is *wrong*. Please delete the tag, regardless of whether new packages are created, recreate it with the *right* name. 2) because the .qmake.conf file in qtdeclarative contains the same version number for two releases. It's impossible for regular people to tell us which version they have compiled if they have already erased the source tarballs. > Let’s have a discussion at QtCS how to best do things in the future, but > this is not worth it. We already have a procedure for making a release and all we had to do was follow it. In any case, my problem was the release number, not the procedure. All I want is the proper number now. At the very least, BRING BACK 5.6.1 to http://download.qt.io/official_releases/qt/5.6/ Don't EVER delete releases. That's poor release practice and poor open source practice. This is the same rule as "never silently replace release files". I'm serious. Bring it back, now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sean.harmer at kdab.com Fri Jun 24 10:23:12 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 24 Jun 2016 09:23:12 +0100 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <3250075.1QZH7qfuxE@tjmaciei-mobl1> References: <301E19B5-1193-40A4-B58E-654CB8403C30@qt.io> <3250075.1QZH7qfuxE@tjmaciei-mobl1> Message-ID: <3169505.IQ7K87i83b@cartman> On Friday 24 June 2016 00:41:25 Thiago Macieira wrote: > On sexta-feira, 24 de junho de 2016 06:49:56 PDT Lars Knoll wrote: > > On 24/06/16 02:12, "Development on behalf of Thiago Macieira" > > > > > thiago.macieira at intel.com> wrote: > > >On terça-feira, 21 de junho de 2016 23:37:57 PDT Thiago Macieira wrote: > > >> On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote: > > >> > I propose that we delete the bad tag, retag and rerelease with a > > >> > better > > >> > name. > > >> > > >> Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be > > >> different > > from the original 5.6.1 version. > > > >What action is going to be taken to fix this mistake? > > > > > >Suggestion: > > > * delete the v5.6.1-1 tag immediately > > > * immediately retract all source and binary releases with "-1" in the > > > name > > > * modify qtdeclarative's .qmake.conf to say MODULE_VERSION = 5.6.2 > > > * tag that v5.6.2, update qt5.git and tag it v5.6.2 > > > * rebuild binaries > > > * release them and source > > > > > >The tag v5.6.2 will be skipped in all the other modules. We update all of > > >their MODULE_VERSION to 5.6.3. > > > > What’s the point? Create ourselves man weeks worth of work and completely > > confuse all our users for what exactly? > > For two reasons: > > 1) because every Linux packager will call it 5.6.1.1, not 5.6.1-1. The tag > is *wrong*. Please delete the tag, regardless of whether new packages are > created, recreate it with the *right* name. > > 2) because the .qmake.conf file in qtdeclarative contains the same version > number for two releases. It's impossible for regular people to tell us which > version they have compiled if they have already erased the source tarballs. > > Let’s have a discussion at QtCS how to best do things in the future, but > > this is not worth it. > > We already have a procedure for making a release and all we had to do was > follow it. In any case, my problem was the release number, not the > procedure. All I want is the proper number now. > > At the very least, BRING BACK 5.6.1 to > http://download.qt.io/official_releases/qt/5.6/ > > Don't EVER delete releases. That's poor release practice and poor open > source practice. This is the same rule as "never silently replace release > files". > > I'm serious. Bring it back, now. I agree. This really should have been 5.6.2. If this impacts on somebody's vacation then so be it. Sometimes we have to make sacrifices. It's the reality. This is why we have a process. How is this situation compatible with TQC's ISO 9001 certification?! Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From Lars.Knoll at qt.io Fri Jun 24 10:33:39 2016 From: Lars.Knoll at qt.io (Lars Knoll) Date: Fri, 24 Jun 2016 08:33:39 +0000 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <3250075.1QZH7qfuxE@tjmaciei-mobl1> References: <2875351.7iyjDlFit0@tjmaciei-mobl1> <301E19B5-1193-40A4-B58E-654CB8403C30@qt.io> <3250075.1QZH7qfuxE@tjmaciei-mobl1> Message-ID: On 24/06/16 09:41, "Development on behalf of Thiago Macieira" wrote: >On sexta-feira, 24 de junho de 2016 06:49:56 PDT Lars Knoll wrote: >> On 24/06/16 02:12, "Development on behalf of Thiago Macieira" >> > thiago.macieira at intel.com> wrote: > >> >> >On terça-feira, 21 de junho de 2016 23:37:57 PDT Thiago Macieira wrote: >> > >> >> On terça-feira, 21 de junho de 2016 16:42:14 PDT Thiago Macieira wrote: >> >> >> >> > I propose that we delete the bad tag, retag and rerelease with a >> >> > better >> >> > name. >> >> >> >> >> >> Also: update MODULE_VERSION qtdeclarative/.qmake.conf. It MUST be >> >> different > from the original 5.6.1 version. >> > >> > >> >What action is going to be taken to fix this mistake? >> > >> >Suggestion: >> > >> > * delete the v5.6.1-1 tag immediately >> > * immediately retract all source and binary releases with "-1" in the >> > name >> > * modify qtdeclarative's .qmake.conf to say MODULE_VERSION = 5.6.2 >> > * tag that v5.6.2, update qt5.git and tag it v5.6.2 >> > * rebuild binaries >> > * release them and source >> > >> > >> >The tag v5.6.2 will be skipped in all the other modules. We update all of >> >their MODULE_VERSION to 5.6.3. >> >> >> What’s the point? Create ourselves man weeks worth of work and completely >> confuse all our users for what exactly? > >For two reasons: > >1) because every Linux packager will call it 5.6.1.1, not 5.6.1-1. The tag is >*wrong*. Please delete the tag, regardless of whether new packages are >created, recreate it with the *right* name. Yes, Linux packagers will call it 5.6.1.1, and I agree that’s what we should have called it as well. I have nothing fundamental against changing the tag to 5.6.1.1, but I don’t see a huge gain neither. It’s just a tag in our repo’s. >2) because the .qmake.conf file in qtdeclarative contains the same version >number for two releases. It's impossible for regular people to tell us which >version they have compiled if they have already erased the source tarballs. True, but I don’t think it’ll be a problem in practice. Let’s however make sure we get this right next time. > >> Let’s have a discussion at QtCS how to best do things in the future, but >> this is not worth it. > >We already have a procedure for making a release and all we had to do was >follow it. In any case, my problem was the release number, not the procedure. >All I want is the proper number now. > >At the very least, BRING BACK 5.6.1 to >http://download.qt.io/official_releases/qt/5.6/ > >Don't EVER delete releases. That's poor release practice and poor open source >practice. This is the same rule as "never silently replace release files". > >I'm serious. Bring it back, now. Well, I didn’t know 5.6.1 is gone. That’s clearly wrong. Lars From bo at vikingsoft.eu Fri Jun 24 11:18:47 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Fri, 24 Jun 2016 11:18:47 +0200 Subject: [Development] [Interest] Native event filter in QtService In-Reply-To: <002601d1cdf6$4e7a45a0$eb6ed0e0$@rightsoft.com.au> References: <14d88328af064489833e5d12f1cbbf08@SRV1.asctec.local> <002601d1cdf6$4e7a45a0$eb6ed0e0$@rightsoft.com.au> Message-ID: <60602fa4-4020-b64b-1a97-699911198db1@vikingsoft.eu> Hi all, I'm copying this to devel, because it fits in a discussion a week or two ago. Den 24-06-2016 kl. 10:56 skrev Tony Rietwyk: > qtservice_win.cpp around line 830 at your reference [1] installs its own > nativeEventFilter - probably displacing yours. > > I suspect you'll need to merge the Qt filter into yours, and get rid of > that install. That is impossible for commercial projects because the solutions are LGPL only. You can't copy LGPL code into your own code base unless you are using GPL or LGPL yourself. And that's why I copied this message to devel, because there was a discussion on whether to add solutions to Qt Core or not. And one of the arguments against is that people can just use the solutions as they are. This is one case, where apparently that's not (at least currently) possible. I can come up with a couple of workarounds for this, sure. But these are all brittle and may not work if the solutions code is changed. > *From:*Interest > [mailto:interest-bounces+tony=rightsoft.com.au at qt-project.org] *On > Behalf Of *Julius Bullinger > *Sent:* Friday, 24 June 2016 5:25 PM > *To:* interest at qt-project.org Interest > *Subject:* [Interest] Native event filter in QtService > > I’m trying to write a small (windows only) service based on QtService > [1] listening for some USB device events. For this, I created a > NativeDeviceEventFilterclass based on QAbstractNativeEventFilter. It > works perfectly when used in a QCoreApplication. > > Now, when installing this event filter in my UpdaterServiceclass, it > isn’t being called. > > I tried each of: > > application()->installNativeEventFilter(deviceEvent_); > > QCoreApplication::instance()->installNativeEventFilter(deviceEvent_); > > QAbstractEventDispatcher::instance()->installNativeEventFilter(deviceEvent_); > > both in the service’s constructor and start()method, as well as using a > local instance of NativeDeviceEventFilter, > > but none of these worked. The event just isn’t registered at all. > > Has anyone ever done something like this? Or is there another way to > receive native messages (MSG structs) in a QtService? Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From rjvbertin at gmail.com Fri Jun 24 11:19:53 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gIFYu?= Bertin) Date: Fri, 24 Jun 2016 11:19:53 +0200 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget References: <2448170.ne5phv0VbN@portia.local> <201606221150.07492.marc.mutz@kdab.com> <1790332.79rtq79Uco@kerberos> Message-ID: <1693816.BNyYA6UWdc@patux.local> Mike Krus wrote: > >> On 22 Jun 2016, at 11:17, Kevin Funk wrote: >> A platform agnostic wrapper for all this would be indeed great to have! > If QtWinExtra has it, QtMacExtra can have it, and it’s doable on Linux, why > not add static methods on QProgressBar? Why would you add Linux-only methods to QProgressBar? It would make more sense to add something to QtX11Extras if there's a sensible way to do this under X11. Otherwise you'd be adding to QtKDEExtras, oops, that's called KF5 :) R. From nolden at kde.org Fri Jun 24 11:43:08 2016 From: nolden at kde.org (Ralf Nolden) Date: Fri, 24 Jun 2016 11:43:08 +0200 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <3250075.1QZH7qfuxE@tjmaciei-mobl1> Message-ID: <3501962.NgPFM2FghQ@w530.nolden.freebsd> Am Freitag, 24. Juni 2016, 08:33:39 schrieb Lars Knoll: > On 24/06/16 09:41, "Development on behalf of Thiago Macieira" > thiago.macieira at intel.com> wrote: > >At the very least, BRING BACK 5.6.1 to > >http://download.qt.io/official_releases/qt/5.6/ > > > >Don't EVER delete releases. That's poor release practice and poor open > >source practice. This is the same rule as "never silently replace > >release files". > >I'm serious. Bring it back, now. > > > Well, I didn’t know 5.6.1 is gone. That’s clearly wrong. Can that please be fixed before the weekend ? Thanks. > > Lars > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Kind regards, Ralf Nolden From tuukka.turunen at qt.io Fri Jun 24 12:26:37 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 24 Jun 2016 10:26:37 +0000 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <3501962.NgPFM2FghQ@w530.nolden.freebsd> References: <3250075.1QZH7qfuxE@tjmaciei-mobl1> , <3501962.NgPFM2FghQ@w530.nolden.freebsd> Message-ID: Hi, I do not know why 5.6.1 has been deleted, but it is of course a mistake. However, we need to make sure no-one accidentally takes it, so maybe moving to archive is good approach? Let's fix that next week the latest. Today is a national holiday in Finland, so we'll need to survive through the weekend. Yours, Tuukka ________________________________ Lähettäjä: Ralf Nolden Lähetetty: ‎24.‎6.‎2016 12:43 Vastaanottaja: development at qt-project.org Aihe: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages Am Freitag, 24. Juni 2016, 08:33:39 schrieb Lars Knoll: > On 24/06/16 09:41, "Development on behalf of Thiago Macieira" > thiago.macieira at intel.com> wrote: > >At the very least, BRING BACK 5.6.1 to > >http://download.qt.io/official_releases/qt/5.6/ > > > >Don't EVER delete releases. That's poor release practice and poor open > >source practice. This is the same rule as "never silently replace > >release files". > >I'm serious. Bring it back, now. > > > Well, I didn’t know 5.6.1 is gone. That’s clearly wrong. Can that please be fixed before the weekend ? Thanks. > > Lars > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Kind regards, Ralf Nolden _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Fri Jun 24 12:31:36 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 24 Jun 2016 10:31:36 +0000 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget In-Reply-To: <1693816.BNyYA6UWdc@patux.local> References: <2448170.ne5phv0VbN@portia.local> <201606221150.07492.marc.mutz@kdab.com> <1790332.79rtq79Uco@kerberos> <1693816.BNyYA6UWdc@patux.local> Message-ID: <4C34B8D9-6F69-426C-9A95-9ECB251DFEE6@qt.io> > On 24 Jun 2016, at 11:19, René J. V. Bertin wrote: > > Mike Krus wrote: > >> >>> On 22 Jun 2016, at 11:17, Kevin Funk wrote: >>> A platform agnostic wrapper for all this would be indeed great to have! >> If QtWinExtra has it, QtMacExtra can have it, and it’s doable on Linux, why >> not add static methods on QProgressBar? > > Why would you add Linux-only methods to QProgressBar? It would make more sense > to add something to QtX11Extras if there's a sensible way to do this under X11. > Otherwise you'd be adding to QtKDEExtras, oops, that's called KF5 :) I thought he meant to add it as a cross-platform feature, not leave it in the extras modules. Static in QProgressBar only makes sense if one application can only have one icon. But why not have this feature available on each minimized window, in case multiple windows are busy? (Well, some docks collapse multiple windows into one icon anyway.) But then the API needs more thought; maybe we can do better than clutter up the API of QWindow or QProgressBar or QGuiApplication. And BTW QtQuick Controls 2 is adding support for native menus, tray icons and such, so it would make sense to have QML API for this feature too, I suppose. On Unity the D-Bus protocol is apparently this https://wiki.ubuntu.com/Unity/LauncherAPI and apparently work in progress on KDE: https://git.reviewboard.kde.org/r/127050/ but we haven’t implemented any part of that protocol in Qt, yet. It could be done. There is an annoying warning which got mentioned on that KDE page: "While the libunity API is stable, the DBus protocol underneath is not. We strongly discourage anyone from relying on it" Philosophically I think that’s wrong. (But it’s not the first time I’ve seen that attitude.) A D-Bus protocol is a specification (just like say, a WiFi or Bluetooth specification, or any network RFC): revisions should be few and far between, while implementations naturally tend to be more numerous, and need more frequent fixes. We really expect the authors of such things to think them through before the D-Bus protocol has “final specification” status. And we don’t want to depend on yet another library, especially one which will not exist except on an Ubuntu system, and would therefore need to be dynamically loaded. When we implement D-Bus protocols in our platform plugins, we do that with QtDBus, not by linking other libraries. In that case, we are obliged to ignore any warnings about the protocol being unstable (or else allow the warning to dissuade us from doing anything at all). So whether Canonical or Gnome likes it or not, every time they change a protocol which we’ve implemented, our implementation will lag behind. They had better do any protocol changes in backwards-compatible ways. Anything else is unrealistic, IMO. Isn’t it the same issue for KDE implementing those? Maybe we should treat KDE interest in implementing a Unity protocol as a sign that the specification can be considered frozen, and the warning is moot. The tendency for third parties to make adjunct Qt plugins (such as style plugins) to add such features, like KDE and Unity have been doing, also has side effects: the feature is not portable. When they bundle behavior changes and styling changes together, those plugins are left behind when users build or install new versions of Qt on their own: the plugin is only for the minor version of Qt that it was built for. And then users wonder why the nifty features that those plugins added don’t work anymore. This is why we independently added support for the D-Bus tray icons, their menus, and the unified menubar: those features began to be widely available on multiple desktops, and thus expected, regardless of Qt version. It’s not a great use of time though, that different people implemented the same features in different ways. It would be better if people would contribute patches for such things to Qt in the first place. But for new features, hammering out proper API is important work, and takes time and patience. It seems like the progress bar could be a cross-platform feature. So we just need to think up a sufficiently general API that doesn’t look like it will be too limiting later, if the feature is expanded in some way. The same story will probably repeat in the context of system notifications, BTW, and we’ll see what else. There is work in progress on a pluggable notification system. In general, these interfaces to the rest of the desktop (which use D-Bus on Linux) are slowly proliferating. In another thread we are discussing how to handle communications and data sharing between apps on mobile platforms. My hunch is that the good ideas from there will tend to end up being D-Bus specifications on desktop Linux, too, to bring them cross-platform instead of only on mobile devices. From perezmeyer at gmail.com Fri Jun 24 15:10:59 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 24 Jun 2016 10:10:59 -0300 Subject: [Development] Notice to all packagers: Qt 4 mistakenly detects GCC6 as a different ABI In-Reply-To: <2207354.PKFgvh1W5k@tjmaciei-mobl1> References: <2207354.PKFgvh1W5k@tjmaciei-mobl1> Message-ID: <3123485.mMjHKXjU4g@luna> On jueves, 23 de junio de 2016 8:31:20 P. M. ART Thiago Macieira wrote: > You may start getting this error once you upgrade the compiler: > > Plugin uses incompatible Qt library > expected build key "x86_64 linux g++-6 full-config", got "x86_64 linux > g++-4 full-config" > "The plugin '/usr/lib64/kde4/plugins/styles/breeze.so' uses incompatible Qt > library. Expected build key "x86_64 linux g++-6 full-config", got "x86_64 > linux g++-4 full-config"" > > The configure script needs a simple patch to recognise GCC 6 as the same ABI > as GCC 4 and 5. Please apply it to your Qt 4 builds if your distro is > switching to GCC 6. Thanks *a lot* for the notice, patch applied. -- 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 andre at familiesomers.nl Fri Jun 24 15:54:50 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 24 Jun 2016 15:54:50 +0200 Subject: [Development] [Interest] Native event filter in QtService In-Reply-To: <60602fa4-4020-b64b-1a97-699911198db1@vikingsoft.eu> References: <14d88328af064489833e5d12f1cbbf08@SRV1.asctec.local> <002601d1cdf6$4e7a45a0$eb6ed0e0$@rightsoft.com.au> <60602fa4-4020-b64b-1a97-699911198db1@vikingsoft.eu> Message-ID: <6605c7a7-4c85-f006-8baf-5f64c91ee82e@familiesomers.nl> Op 24/06/2016 om 11:18 schreef Bo Thorsen: > Hi all, > > I'm copying this to devel, because it fits in a discussion a week or > two ago. > > Den 24-06-2016 kl. 10:56 skrev Tony Rietwyk: >> qtservice_win.cpp around line 830 at your reference [1] installs its own >> nativeEventFilter - probably displacing yours. >> >> I suspect you'll need to merge the Qt filter into yours, and get rid of >> that install. > > That is impossible for commercial projects because the solutions are > LGPL only. You can't copy LGPL code into your own code base unless you > are using GPL or LGPL yourself. > > And that's why I copied this message to devel, because there was a > discussion on whether to add solutions to Qt Core or not. And one of > the arguments against is that people can just use the solutions as > they are. This is one case, where apparently that's not (at least > currently) possible. > > I can come up with a couple of workarounds for this, sure. But these > are all brittle and may not work if the solutions code is changed. In a previous company I worked for, we simply created an LGPL lib for all the stuff we borrowed this way. I really don't see why one can't use an LGPL-ed lib for most situations. André From thiago.macieira at intel.com Fri Jun 24 17:50:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 24 Jun 2016 08:50:01 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <3250075.1QZH7qfuxE@tjmaciei-mobl1> Message-ID: <3152647.zdLgNqpmXz@tjmaciei-mobl1> On sexta-feira, 24 de junho de 2016 08:33:39 PDT Lars Knoll wrote: > >2) because the .qmake.conf file in qtdeclarative contains the same version > > number for two releases. It's impossible for regular people to tell us > >which version they have compiled if they have already erased the source > >tarballs. > > True, but I don’t think it’ll be a problem in practice. Let’s however make > sure we get this right next time. I disagree. This problem is going to affect Support a lot more, as it will be difficult to get the actual version number from people. When customers come for support and say they have 5.6.1, Support will have to tell the customer "please re-download and install the new version" because they won't be sure that the customer didn't download the old version last week. As for support on the IRC channel and mailing list,s if we don't change the .qmake.conf file, I will simply tell people to *downgrade* to 5.6.0 or wait for 5.6.2. Think of packagers that don't pay that good an attention to this mailing list. They may not realise that it's a different version and may simply call it 5.6.1. I will disavow any and all QML-related problems in 5.6.1 in IRC and the interest ML if it sticks to the same version number. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 24 17:51:51 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 24 Jun 2016 08:51:51 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <3501962.NgPFM2FghQ@w530.nolden.freebsd> Message-ID: <3106066.eL2LTxgl0P@tjmaciei-mobl1> On sexta-feira, 24 de junho de 2016 10:26:37 PDT Tuukka Turunen wrote: > Hi, > > I do not know why 5.6.1 has been deleted, but it is of course a mistake. > However, we need to make sure no-one accidentally takes it, so maybe moving > to archive is good approach? No, keep it in http://download.qt.io/official_releases/qt/5.6/, since it's an official release. Source code is enough though, we don't need the binaries. The solution for "make sure no one accidentally takes it" is to name the other release 5.6.2... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Fri Jun 24 18:12:25 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2E__V=2E?= Bertin) Date: Fri, 24 Jun 2016 18:12:25 +0200 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget References: <2448170.ne5phv0VbN@portia.local> <201606221150.07492.marc.mutz@kdab.com> <1790332.79rtq79Uco@kerberos> <1693816.BNyYA6UWdc@patux.local> <4C34B8D9-6F69-426C-9A95-9ECB251DFEE6@qt.io> Message-ID: <4929178.37KF4n3Wu8@portia.local> Shawn Rutledge wrote: > I thought he meant to add it as a cross-platform feature, not leave it in the > extras modules. Ah, yes, that would be a possibility if the feature can be implemented in such a way that a platform-agnostic API makes sense. Which it should, there really isn't that much to control in a simple progressbar widget :) > > Static in QProgressBar only makes sense if one application can only have one > icon. But why not have this feature available on each minimized window, in > case multiple windows are busy? (Well, some docks collapse multiple windows > into one icon anyway.) I am not aware that this would make sense on OS X. You have the choice whether minimised windows are shown individually or not, but even if they are I don't think you can even access their icons (tiles). I've never tried though. > loaded. When we implement D-Bus protocols in our platform plugins, we do that > with QtDBus, not by linking other libraries. In that case, we are obliged to To take this a bit further away from the original topic: I have seen multiple remarks off late about how DBus is a "fish out of the water" everywhere else but on FreeDesktop-based systems. While it's true that DBus isn't a "native" service on those platforms there's a clear intention for it to work and integrate properly (without 3rd party patches) at least on OS X and MS Windows. Personally I thus consider it a cross-platform desktop bus implementation. The remark above did make me wonder if QtDBus couldn't use a platform-native backend transparently. It seems unlikely (just as you probably cannot replace dbus itself by something that isn't ... dbus) but it cannot hurt to ask :) > The same story will probably repeat in the context of system notifications, KF5's KNotifications? R. From thiago.macieira at intel.com Fri Jun 24 18:20:52 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 24 Jun 2016 09:20:52 -0700 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget In-Reply-To: <4929178.37KF4n3Wu8@portia.local> References: <2448170.ne5phv0VbN@portia.local> <4C34B8D9-6F69-426C-9A95-9ECB251DFEE6@qt.io> <4929178.37KF4n3Wu8@portia.local> Message-ID: <1687137.c0nW9rkVGV@tjmaciei-mobl1> On sexta-feira, 24 de junho de 2016 18:12:25 PDT René J. V. Bertin wrote: > The remark above did make me wonder if QtDBus couldn't use a > platform-native backend transparently. It seems unlikely (just as you > probably cannot replace dbus itself by something that isn't ... dbus) but > it cannot hurt to ask :) What do you mean by that? What is a "platform-native backend"? How would it be used transparently? And more importantly, what is any of that different than what QtDBus does right now? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From konstantin at podsvirov.pro Fri Jun 24 18:23:50 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Fri, 24 Jun 2016 19:23:50 +0300 Subject: [Development] [ANNOUNCE] DaD's House Standalone Installers In-Reply-To: <4755441465592063@web10g.yandex.ru> References: <4755441465592063@web10g.yandex.ru> Message-ID: <4898291466785430@web5j.yandex.ru> Hello dear developers! Standalone installers for some DaD's House releases now available at SF mirror: https://sourceforge.net/projects/dad-mirror/files/standalone/2015/dad-0.3.1-windows-vc12x64-2015-standalone.exe/download https://sourceforge.net/projects/dad-mirror/files/standalone/2015/dad-0.3.1-windows-vc12x86-2015-standalone.exe/download https://sourceforge.net/projects/dad-mirror/files/standalone/2014/dad-0.3.1-windows-vc12x64-2014-standalone.exe/download https://sourceforge.net/projects/dad-mirror/files/standalone/2014/dad-0.3.1-windows-vc12x86-2014-standalone.exe/download This info also available at installers page: http://dad.podsvirov.pro/house/installers 10.06.2016, 23:54, "Konstantin Podsvirov" : > Hi guys! Hello developers! > > My "DaD's Project" is based on CMake and QtIFW (specifically CPackIFW) continues its development: > > http://dad.podsvirov.pro - the official "DaD's House" website now. > > "DaD's House" is a resource where you can download the installers to install necessary dependencies > and immediately begin developing their projects. > > Already declared support 40 the following modules: > > Curses, ZLib, LibPNG, Jpeg, Libxml2, LibTIFF, Perl, OpenSSL, LibSSH2, cURL, > PCRE, PROJ, Expat, FreeType, SQLite, GEOS, GDAL, Boost, Qt, QtIFW, > CMake KDSoap, OSG, osgEarth, osgQtQuick, PostgreSQL, Apache.Apr, The Apache.AprUtil, Apache.Httpd, Protobuf, > gRPC, MapServer, Bullet, QCA, wxWidgets, LibXSLT, iconv, pgAdmin3, Wt, FreeGLUT. > > Also available in 4 port: > >  - Windows Visual C++ Compiler 12.0 32bit >  - Windows Visual C++ Compiler 12.0 64bit > > and NEW > >  - Windows 5.3.0 MinGW w64 32bit >  - Windows 5.3.0 MinGW w64 64bit > > The last 2 ports have appeared recently and there are still large but interesting work. > > All of this can be a good basis for your projects. > All this is a good basis for my personal growth. > > I assess the status of the project as a Beta and write to lists for developers of basic technologies. > > Open the curtain. > > For each module I have a small CMakeLists.txt: > > http://git.podsvirov.pro/?a=project_list;pf=dad/mod > > These scripts help me to build the modules and create a repository of binary components. > > There is a need to spread content. All available here: > > http://download.podsvirov.pro > > My server is small and weak. I need help in distribution. I need a mirror "main" module: > > rsync://podsvirov.pro > > If there are interested parties and you give me the address of the mirror, then I can add them to MirrorBrain setup > for more efficient distribution. > > If you are interested in developing this technology or already use my installers, I would like to hear your opinion > and to get feedback. > > Have a great weekend and good luck in development of your projects! > > -- > Regards, > Konstantin Podsvirov > -- > > Powered by www.kitware.com > > Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ > > Kitware offers various services to support the CMake community. For more information on each offering, please visit: > > CMake Support: http://cmake.org/cmake/help/support.html > CMake Consulting: http://cmake.org/cmake/help/consulting.html > CMake Training Courses: http://cmake.org/cmake/help/training.html > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/cmake-developers Regards, Konstantin Podsvirov From sean.harmer at kdab.com Fri Jun 24 19:42:12 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 24 Jun 2016 18:42:12 +0100 Subject: [Development] Interesting CI failure: Fwd: Change in qt/qt3d[5.7]: Entity: add simple method to check for components In-Reply-To: <20160624160440.274CF50202@mx.qt-project.org> References: <20160624160440.274CF50202@mx.qt-project.org> Message-ID: Well, that's a new one but fits quite well with the news today. Sean -------- Forwarded Message -------- Subject: Change in qt/qt3d[5.7]: Entity: add simple method to check for components Date: Fri, 24 Jun 2016 16:04:39 +0000 From: Qt CI Bot (Code Review) Reply-To: qt_ci_bot at qt-project.org To: Paul Lemire CC: Qt Sanity Bot , Sean Harmer , Robert Brock Qt CI Bot has posted comments on this change. Change subject: Entity: add simple method to check for components ...................................................................... Continuous Integration: Failed Module "qt/qt3d" (3524e549c48edf4f6c90ba1e8f8af24d864b4afb) Failed test(s): /Users/qt/work/qt/qt3d/tests/auto/core/qaspectengine: quit quit ^D ^D ^D quit quit ^D ^D ^D quit quit ^D ^D ^D quit quit quit quit quit ^D ^D ^D quit quit quit ^D quit quit ^D ^D ^D ^D quit quit ^D ^D ^D quit quit quit ^D quit quit ^D quit quit ^D ^D ^D quit quit quit ^D ^D ^D quit ^D ^D quit quit ^D quit quit ^D quit quit ^D quit ^D ^D ^D quit quit ^D quit quit ^D quit ^D quit Attaching to process with: process attach -p 3095 ^D ^D ^D ^D ^D ^D ^D ^D ^D ^D ^D quit quit quit quit quit quit quit quit quit quit quit ^D quit ^D ^D ^D quit quit quit ^D ^D quit quit ^D ^D ^D quit quit ^D quit ^D quit quit ^D quit ^D quit ^D ^D ^D ^D quit quit quit quit ^D ^D ^D ^D quit quit quit ^D quit quit ^D quit ^D quit ^D quit ^D quit ^D ^D ^D quit quit quit ^D quit ^D ^D ^D quit quit quit ^D ^D ^D ^D ^D quit quit quit quit quit ^D ^D quit quit ^D ^D ^D ^D ^D ^D ^D quit quit quit quit quit quit ^D quit quit ^D ^D ^D quit quit ^D ^D quit quit ^D ^D quit ^D quit quit ^D quit quit ^D ^D ^D quit quit ^D ^D quit quit quit ^D quit ^D ^D quit quit ^D quit ^D ^D ^D ^D ^D ^D quit quit quit quit quit quit ^D ^D quit ^D quit ^D ^D ^D quit quit ^D quit quit quit ^D ^D ^D quit quit ^D quit ^D quit quit ^D ^D ^D ^D quit quit quit quit ^D ^D ^D quit quit ^D ^D ^D quit quit ^D quit quit ^D quit quit ^D ^D ^D quit quit ^D ^D quit ^D ^D quit quit quit ^D ^D ^D quit ^D quit quit quit quit ^D quProcess 3095 stopped Executable module set to "/Users/qt/work/qt/qt3d/tests/auto/core/qaspectengine/tst_qaspectengine.app/Contents/MacOS/tst_qaspectengine". Architecture set to: x86_64-apple-macosx. (lldb) quit ^D (lldb) quitquit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit quit agent:2016/06/24 19:04:33 build.go:221: Killed process after timeout (total time) agent:2016/06/24 19:04:34 agent.go:170: Test failed agent:2016/06/24 19:04:34 build.go:158: Error reading from stdout/err: Timeout after 15m0s: Maximum duration reached agent:2016/06/24 19:04:34 agent.go:127: ERROR building: Timeout after 15m0s: Maximum duration reached Build log: http://testresults.qt.io/logs/qt/qt3d/224055f620a8fc4ed6bcf965832b26d79e39b965/OSXOSX_10_08x86_64OSXOSX_10_08x86_64ClangRelease_NoFramework/f5928a8f6f410b5c920089ab39348d986238c96e/testrun_1466782347/testlog.txt.gz Details: http://testresults.qt.io/coin/integration/qt/qt3d/tasks/1466782347.thrift_bin Tested changes (refs/builds/qtci/5.7/1466782346): https://codereview.qt-project.org/#/q/9746c18738d3191120f51ff08d259c05bd5f2d83,n,z Entity: add simple method to check for components https://codereview.qt-project.org/#/q/cb1fdc35938a70acc56054d363476690abac2e89,n,z Entity: use QVector for componentsHandle/renderComponents https://codereview.qt-project.org/#/q/fbc7ea5d2d64ec2fa229a326a5e8ce2caa9145cd,n,z FrameGraphNode: make children() return a QVector -- To view, visit https://codereview.qt-project.org/159282 To unsubscribe, visit https://codereview.qt-project.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I560089e499aa8e98415b00b3131a5e9923c1a551 Gerrit-PatchSet: 13 Gerrit-Project: qt/qt3d Gerrit-Branch: 5.7 Gerrit-Owner: Paul Lemire Gerrit-Reviewer: Paul Lemire Gerrit-Reviewer: Qt Sanity Bot Gerrit-Reviewer: Robert Brock Gerrit-Reviewer: Sean Harmer Gerrit-HasComments: No -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.terrier at gmail.com Fri Jun 24 20:02:03 2016 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Fri, 24 Jun 2016 20:02:03 +0200 Subject: [Development] Scope of source code license files In-Reply-To: References: <2292E19B-3536-487A-AC63-FC8C3FE1031B@qt.io> <1c8d5145-e611-f3ef-1cd5-d2fda322b427@gmail.com> Message-ID: Le 14 juin 2016 13:22, "Sze Howe Koh" a écrit : > > On 7 May 2016 at 12:20, Joseph Crowell wrote: > > > > On 4/05/2016 7:39 PM, Lars Knoll wrote: > >> > >> On 02/05/16 14:37, "Development on behalf of Sze Howe Koh" wrote: > >> > >> > >> > >>> Hello, > >>> > >>> The LICENSE.GPLvX and LICENSE.LGPLvX files from > >>> http://code.qt.io/cgit/qt/qtbase.git/tree/ (and submodules) start with > >>> "The Qt Toolkit is Copyright (C) 2015...", but then they go on to say > >>> "You may use, distribute and copy the Qt GUI Toolkit under the terms > >>> of..." > >>> > >>> Is this correct? What about non-GUI parts of the toolkit? > >> > >> The GUI in here is just a historical thing. It applies to Qt. > > > > > > Wording should probably should be changed then as times have changed and Qt is certainly no longer just a GUI toolkit. > > Here's the first batch, targeting the "5.6" branch. If this is OK, > I'll submit similar patches for the other repos too: > > https://codereview.qt-project.org/#/c/162394/ > > Some more questions: > > 1) What about http://code.qt.io/cgit/qt/qtbase.git/tree/LGPL_EXCEPTION.txt > ? It's currently presented as additional permissions on top of LGPL > v2.1. I presume LGPL v3.0 should be included too? I'd like to get an answer to this question. If the exception doesn't apply to LGPLv3 then people might not be able to make proprietary applications with Qt. Because without it, the LGPLv3 only give exception for inline functions of less than 10 lines, meaning that developers would have to check every Qt header for every release to ensure there are no 11+ line long inline functions. Also without the exception, I see no points in using LGPL as I guess there should be at least one inline/template function breaking the 10 line limit. > 2) https://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/ > says that "Qt 5.7 will not be available under LGPLv2.1 anymore" -- > Does that mean LICENSE.LGPLv21 should be removed from the 5.7 branch > onwards? > I'm wondering if having these license files still in there doesn't automatically make Qt 5.7 available under LGPLv2.1? Maybe Dr Till Jaeger has an answer. > > >> Cheers, > >> Lars > > > Regards, > Sze-Howe > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development BR Benjamin Terrier -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Jun 24 20:02:57 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 24 Jun 2016 11:02:57 -0700 Subject: [Development] Interesting CI failure: Fwd: Change in qt/qt3d[5.7]: Entity: add simple method to check for components In-Reply-To: References: <20160624160440.274CF50202@mx.qt-project.org> Message-ID: <2591977.DleicqiMy5@tjmaciei-mobl1> http://www.gnu.org/fun/jokes/ed-msg.html ==== Let's look at a typical novice's session with the mighty ed: golem$ ed ? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ? === Note that I can't reproduce the last one. Ctrl+D quits ed for me. (I'd seen those CI quit errors before) On sexta-feira, 24 de junho de 2016 18:42:12 PDT Sean Harmer wrote: > Well, that's a new one but fits quite well with the news today. > > Sean > > -------- Forwarded Message -------- > Subject: Change in qt/qt3d[5.7]: Entity: add simple method to check for > components > Date: Fri, 24 Jun 2016 16:04:39 +0000 > From: Qt CI Bot (Code Review) > Reply-To: qt_ci_bot at qt-project.org > To: Paul Lemire > CC: Qt Sanity Bot , Sean Harmer > , Robert Brock > > > > Qt CI Bot has posted comments on this change. > > Change subject: Entity: add simple method to check for components > ...................................................................... > > > Continuous Integration: Failed > > Module "qt/qt3d" (3524e549c48edf4f6c90ba1e8f8af24d864b4afb) Failed > test(s): /Users/qt/work/qt/qt3d/tests/auto/core/qaspectengine: quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > ^D > quit > quit > quit > quit > quit > ^D > ^D > ^D > quit > quit > quit > ^D > quit > quit > ^D > ^D > ^D > ^D > quit > quit > ^D > ^D > ^D > quit > quit > quit > ^D > quit > quit > ^D > quit > quit > ^D > ^D > ^D > quit > quit > quit > ^D > ^D > ^D > quit > ^D > ^D > quit > quit > ^D > quit > quit > ^D > quit > quit > ^D > quit > ^D > ^D > ^D > quit > quit > ^D > quit > quit > ^D > quit > ^D > quit > Attaching to process with: > process attach -p 3095 > ^D > ^D > ^D > ^D > ^D > ^D > ^D > ^D > ^D > ^D > ^D > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > ^D > quit > ^D > ^D > ^D > quit > quit > quit > ^D > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > quit > ^D > quit > quit > ^D > quit > ^D > quit > ^D > ^D > ^D > ^D > quit > quit > quit > quit > ^D > ^D > ^D > ^D > quit > quit > quit > ^D > quit > quit > ^D > quit > ^D > quit > ^D > quit > ^D > quit > ^D > ^D > ^D > quit > quit > quit > ^D > quit > ^D > ^D > ^D > quit > quit > quit > ^D > ^D > ^D > ^D > ^D > quit > quit > quit > quit > quit > ^D > ^D > quit > quit > ^D > ^D > ^D > ^D > ^D > ^D > ^D > quit > quit > quit > quit > quit > quit > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > quit > quit > ^D > ^D > quit > ^D > quit > quit > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > quit > quit > quit > ^D > quit > ^D > ^D > quit > quit > ^D > quit > ^D > ^D > ^D > ^D > ^D > ^D > quit > quit > quit > quit > quit > quit > ^D > ^D > quit > ^D > quit > ^D > ^D > ^D > quit > quit > ^D > quit > quit > quit > ^D > ^D > ^D > quit > quit > ^D > quit > ^D > quit > quit > ^D > ^D > ^D > ^D > quit > quit > quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > quit > quit > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > quit > ^D > ^D > quit > quit > quit > ^D > ^D > ^D > quit > ^D > quit > quit > quit > quit > ^D > quProcess 3095 stopped > Executable module set to > "/Users/qt/work/qt/qt3d/tests/auto/core/qaspectengine/tst_qaspectengine.app > /Contents/MacOS/tst_qaspectengine". Architecture set to: > x86_64-apple-macosx. > (lldb) quit > ^D > (lldb) quitquit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > > agent:2016/06/24 19:04:33 build.go:221: Killed process after timeout > (total time) agent:2016/06/24 19:04:34 agent.go:170: Test failed > agent:2016/06/24 19:04:34 build.go:158: Error reading from stdout/err: > Timeout after 15m0s: Maximum duration reached agent:2016/06/24 19:04:34 > agent.go:127: ERROR building: Timeout after 15m0s: Maximum duration reached > > Build log: > http://testresults.qt.io/logs/qt/qt3d/224055f620a8fc4ed6bcf965832b26d79e39b > 965/OSXOSX_10_08x86_64OSXOSX_10_08x86_64ClangRelease_NoFramework/f5928a8f6f4 > 10b5c920089ab39348d986238c96e/testrun_1466782347/testlog.txt.gz > > Details: > http://testresults.qt.io/coin/integration/qt/qt3d/tasks/1466782347.thrift_b > in > > Tested changes (refs/builds/qtci/5.7/1466782346): > > https://codereview.qt-project.org/#/q/9746c18738d3191120f51ff08d259c05bd5f2 > d83,n,z Entity: add simple method to check for components > https://codereview.qt-project.org/#/q/cb1fdc35938a70acc56054d363476690abac2 > e89,n,z Entity: use QVector for componentsHandle/renderComponents > https://codereview.qt-project.org/#/q/fbc7ea5d2d64ec2fa229a326a5e8ce2caa914 > 5cd,n,z FrameGraphNode: make children() return a QVector -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Morten.Sorvig at qt.io Fri Jun 24 23:39:49 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Fri, 24 Jun 2016 21:39:49 +0000 Subject: [Development] Revisiting high-DPI configuration options In-Reply-To: <576A930C.5030800@canonical.com> References: <2096409.Vgqk0hXBa4@master> <7B33DF3E-E384-46E0-AA0E-DDB66DB1228A@qt.io> <576A4C9D.3020207@canonical.com> <5E0A3AB2-97CC-4F23-A361-FEBCA4AFA7FE@qt.io> <576A930C.5030800@canonical.com> Message-ID: > On 22 Jun 2016, at 15:30, Michael Zanetti wrote: > > > * floating point scaling > * different scale factor per window > * dynamically changing scale factor > * some sort of language that allows developers to use virtual sizes, > ideally we'd be able to register our grid unit stuff as that's what all > our design has evolved around. > This may be in reach for a future version of Qt. * Floating point scaling has already been discussed. Qt uses qreal to store and access the scale factor so support is mostly limited by rendering and style code. * The main scale factor accessor is QWindow::devicePixelRatio(), which dynamically update on screen changes. There are currently some code paths that have to use QScreen::devicePixelRatio() or even QGuiApplication::devicePixelRatio(), but I would like us to gravitate towards the QWindow accessor as much as possible. (QWindow::devicePixelRatio() has aliases such as QPaintDevice::devicePixelRatioF() and QQuickWindow::effectiveDevicePixelRatio() higher up in the stack.) There are two approaches to detect devicePixelRatio changes: either a spesific dprChanged event, or use expose events where rendering code queries devicePixelRatio(). We did have support for _setting_ a per-window scale factor from application code at one point during development, but it was removed since we were not sure we could make it work in all cases. (I don’t remember the exact reasoning) * Grid units for QML: looks interesting, but I can’t really comment on the feasibility of implementing it in Qt. Morten From thiago.macieira at intel.com Sat Jun 25 02:02:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 24 Jun 2016 17:02:00 -0700 Subject: [Development] Scope of source code license files In-Reply-To: References: Message-ID: <4977291.O86AQbmObB@tjmaciei-mobl1> On sexta-feira, 24 de junho de 2016 20:02:03 PDT Benjamin TERRIER wrote: > > 2) > > https://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-founda > tion/ > > says that "Qt 5.7 will not be available under LGPLv2.1 anymore" -- > > Does that mean LICENSE.LGPLv21 should be removed from the 5.7 branch > > onwards? > > I'm wondering if having these license files still in there doesn't > automatically make Qt 5.7 available under LGPLv2.1? > Maybe Dr Till Jaeger has an answer. It does not. There are still some files that are LGPLv2.1, either in third- party or for other reasons. But that doesn't mean the entire works is. The vast majority of files has an updated and very clear licence header saying that they are under LGPLv3, GPLv2 and the commercial licences. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From filippocucchetto at gmail.com Sat Jun 25 15:15:10 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Sat, 25 Jun 2016 15:15:10 +0200 Subject: [Development] Input events handling ideas and feedback Message-ID: hi everyone, this is going to be a lengthy email so i'd like to thank those who will read it and maybe give me their opinions. The topic here is throwing some ideas for improving QtQuick event handling (both for mouse and keyboard). First let's take a look at some simple/silly keyboard examples that will make us introduce the main topic and some issue with the current way of handling events. First example (here)[http://pastebin.com/jiGJimGS]. Here the user would like to count how many times the right key has been pressed. Try it and you will see that the Keys.onPressed handler will be called twice when the caret is at the end of the TextField but it will work when the caret moves inside the text. I know that once the final user discover this, he can workaround it and fix the counter but this is not the point. The reason why the Keys.onPressed is called twice is caused by the TextField implementation. In fact a TextField is a composed Control made of a TextInput plus a Text. At the same time, the end user doesn't know this and he can only interact with the whole TextField (in theory he doesn't have to know that the TextField contains a inner TextInput). For this reason the developer of the TextField control added a Keys.forward[root] inside the inner TextInput toward the parent TextField. This is correct in the current state of things because this allows the end user to override the key handling of the the TextField. But why we see two events? This comes by the fact that: 1 The right pressed event is delivered to the inner TextInput (because it has activeFocus) 2 The event is forward to the TextField before being processed by the TextInput (because of Keys.forward[]) 3 The TextField calls the Keys.onPressed handler of the user (that simply ignores the event) 4 The event is processed by the TextInput that ignores it (because the caret is at the end) 5 The event bubble up to the TextField again and the Keys.onPressed event handler will be called for the second time. This example shows us that the actual way of handling events doesn't play well with item composition. Furthermore the event forwarding is very error prone given that without attention is very easy to create loops or unexpected chain of calls (due to bubbling and forwarding). Obviously there could be several ways to solve this, for example 1) Find some way of disabling the call to the event handler (during bubbling) since it has been called once 2) Find some way for making a complex object (made of sub controls) to be seen as a unique entity for the sake of event handling 3) Let the user monitor the events before they reach a child. 4) <--- your ideas here Let's take a look to another example (here)[http://pastebin.com/9s36E6bm]. Here the user would like to disable the ComboBox event handling, for example because the ComboBox is inside a ListView or TableView and he doesn't want to break the View event handling (up ad down keys). If you try it you will see that it doesn't work. Even if the events are accepted they're still delivered to the ComboBox. This is due (probably) by the fact the a Keys.forward[] directive is missing inside the ComboBox implementation. Another broader example is allowing a ListView to handle mouse clicks and events even if the delegate has a MouseArea on top. This letter case can be implemented by using the filterChildMouseEvents api. I've taken a look at what other frameworks do, in particular WPF (this doesn't mean the design of WPF is better or clever). In WPF it seems there are three mechanism 1) Event tunneling. The events first make a down path from the UI root node to the target node 2) Event bubbling. The events are bubbled from the target node up to the UI root node 3) Event flagged as handled (accepted) still make their way up (bubbling) because some nodes could be interested in a event even if it has been flagged (rare ma usefull). Point 1 it's basically a child monitor. Point 2 is what we already do. Point 3 is usefull because at point 1 you know that an event is being delivered to a child but you don't know if it'll be accepted or not. Point 3 can be used for this purpose. Just for fun i pushed two wip code reviews for event tunneling for keys events: one in QtCore https://codereview.qt-project.org/#/c/163502/ and one in QtDeclarative https://codereview.qt-project.org/#/c/163502/ With this patch the example 1 and 2 can be written like this: http://pastebin.com/t0ewNrxC and http://pastebin.com/LqvPZkZN Further informations about tunneling and wpf event handling can be found here https://msdn.microsoft.com/it-it/library/ms742806(v=vs.110).aspx#how_event_processing_works My patches are just wips and if there's interest i can work further on them. For example i would like to have some sort of Mouse attacched object, like Keys and implementing bubbling even for handled events. Finally maybe we need some sort of QEP for writing long term ideas and discuss them in public. Best regards, F -------------- next part -------------- An HTML attachment was scrubbed... URL: From harald.vistnes at gmail.com Sat Jun 25 17:06:45 2016 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Sat, 25 Jun 2016 17:06:45 +0200 Subject: [Development] Push to Gerrit Message-ID: Hi, I'm trying to make my first ever contribution to Qt, but I am struggling with the last part of actually pushing to Gerrit. I've followed the guidelines in the Wiki, but I have probably done something wrong. I've added and committed the patch locally, but when I try to run git push gerrit HEAD:refs/for/5.7 I get a popup messagebox: TortoiseGitPlink Fatal Error Disconnected: No supported authentication methods available (server sent: publickey) I'm on Windows. I assume the problem is related to the ssh keys. Any hints on how to continue would be welcome. Thanks, Harald Vistnes -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Sat Jun 25 18:23:19 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Sat, 25 Jun 2016 17:23:19 +0100 Subject: [Development] Push to Gerrit In-Reply-To: References: Message-ID: <0486d8d3-6148-ef04-1981-be66be7a1eea@kdab.com> Hi Harald, often on Windows it's easiest to install PuTTy and it's helper program, pageant. Run pageant and import/convert your ssh key and set this up in your gerrit webui. Cheers, Sean On 25/06/2016 16:06, Harald Vistnes wrote: > Hi, > > I'm trying to make my first ever contribution to Qt, but I am > struggling with the last part of actually pushing to Gerrit. I've > followed the guidelines in the Wiki, but I have probably done > something wrong. > > I've added and committed the patch locally, but when I try to run > > git push gerrit HEAD:refs/for/5.7 > > I get a popup messagebox: > > TortoiseGitPlink Fatal Error > Disconnected: No supported authentication methods available (server > sent: publickey) > > I'm on Windows. I assume the problem is related to the ssh keys. > > Any hints on how to continue would be welcome. > > Thanks, > > Harald Vistnes > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Sat Jun 25 20:59:51 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Sat, 25 Jun 2016 20:59:51 +0200 Subject: [Development] [Qt-creator] [OS X] Dock icon progress widget References: <2448170.ne5phv0VbN@portia.local> <4C34B8D9-6F69-426C-9A95-9ECB251DFEE6@qt.io> <4929178.37KF4n3Wu8@portia.local> <1687137.c0nW9rkVGV@tjmaciei-mobl1> Message-ID: <1550571.eGTEqu1aGG@patux.local> Thiago Macieira wrote: > On sexta-feira, 24 de junho de 2016 18:12:25 PDT René J. V. Bertin wrote: >> The remark above did make me wonder if QtDBus couldn't use a >> platform-native backend transparently. It seems unlikely (just as you >> probably cannot replace dbus itself by something that isn't ... dbus) but >> it cannot hurt to ask :) > What do you mean by that? What is a "platform-native backend"? Something that uses the platform's native desktop bus, as far as something like that exists. > How would it be used transparently? If 2 applications communicate via QtDBus calls it doesn't really matter what QtDBus does, it hides the implementation details. Instead of a daemon there could be an angel that handles the communication ;) > And more importantly, what is any of that different than > what QtDBus does right now? Well, that's the main point, isn't it. Replacing dbus by something that does the same thing almost the same way only in order to avoid using dbus doesn't make a lot of sense. I wasn't wondering aloud how we could do something completely different, but rather what could be improved to make dbus a true cross-platform daemon-based desktop bus service that cannot be accused of being a fish out of the water. R From thiago.macieira at intel.com Sun Jun 26 06:24:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 25 Jun 2016 21:24:12 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <3106066.eL2LTxgl0P@tjmaciei-mobl1> References: <3106066.eL2LTxgl0P@tjmaciei-mobl1> Message-ID: <9173263.7iln094xCU@tjmaciei-mobl1> On sexta-feira, 24 de junho de 2016 08:51:51 PDT Thiago Macieira wrote: > On sexta-feira, 24 de junho de 2016 10:26:37 PDT Tuukka Turunen wrote: > > Hi, > > > > I do not know why 5.6.1 has been deleted, but it is of course a mistake. > > However, we need to make sure no-one accidentally takes it, so maybe > > moving > > to archive is good approach? > > No, keep it in http://download.qt.io/official_releases/qt/5.6/, since it's > an official release. Source code is enough though, we don't need the > binaries. > > The solution for "make sure no one accidentally takes it" is to name the > other release 5.6.2... Files are still not back yet. I've created a P0 task for the release team. Please solve this Monday. https://bugreports.qt.io/browse/QTBUG-54351 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jun 26 06:22:23 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 25 Jun 2016 21:22:23 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <3152647.zdLgNqpmXz@tjmaciei-mobl1> References: <3152647.zdLgNqpmXz@tjmaciei-mobl1> Message-ID: <3214923.QAmtTkyShX@tjmaciei-mobl1> On sexta-feira, 24 de junho de 2016 08:50:01 PDT Thiago Macieira wrote: > I disagree. This problem is going to affect Support a lot more, as it will > be difficult to get the actual version number from people. When customers > come for support and say they have 5.6.1, Support will have to tell the > customer "please re-download and install the new version" because they > won't be sure that the customer didn't download the old version last week. > > As for support on the IRC channel and mailing list,s if we don't change the > .qmake.conf file, I will simply tell people to *downgrade* to 5.6.0 or wait > for 5.6.2. Think of packagers that don't pay that good an attention to this > mailing list. They may not realise that it's a different version and may > simply call it 5.6.1. On IRC just now: 20:59 < nurupo> what does "-1" in "5.6.1-1" mean? 21:00 < nurupo> it always was major.minor.patch, with the API/ABI compatibility relation between them well defined 21:00 < nurupo> but suddenly there is this "-1" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From techabc at gmail.com Sun Jun 26 15:53:47 2016 From: techabc at gmail.com (techabc) Date: Sun, 26 Jun 2016 21:53:47 +0800 Subject: [Development] Are QT winmigrate framework will be back in qt 5.x ? Message-ID: I need to call 300+ MFC extending DLL in a new QT 5.x application, if except winmigrate, whatthing else can do it? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jedrzej.Nowacki at qt.io Sun Jun 26 20:45:44 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Sun, 26 Jun 2016 18:45:44 +0000 Subject: [Development] Interesting CI failure: Fwd: Change in qt/qt3d[5.7]: Entity: add simple method to check for components In-Reply-To: <2591977.DleicqiMy5@tjmaciei-mobl1> References: <20160624160440.274CF50202@mx.qt-project.org> , <2591977.DleicqiMy5@tjmaciei-mobl1> Message-ID: As far I remember it is our QTestlib trying hard to disconnect from attached debugger session on OSX. You got it because something crashed. Not related to CI :-) Cheers, Jędrek ________________________________ From: Development on behalf of Thiago Macieira Sent: Friday, June 24, 2016 8:02:57 PM To: development at qt-project.org Subject: Re: [Development] Interesting CI failure: Fwd: Change in qt/qt3d[5.7]: Entity: add simple method to check for components http://www.gnu.org/fun/jokes/ed-msg.html ==== Let's look at a typical novice's session with the mighty ed: golem$ ed ? help ? ? ? quit ? exit ? bye ? hello? ? eat flaming death ? ^C ? ^C ? ^D ? === Note that I can't reproduce the last one. Ctrl+D quits ed for me. (I'd seen those CI quit errors before) On sexta-feira, 24 de junho de 2016 18:42:12 PDT Sean Harmer wrote: > Well, that's a new one but fits quite well with the news today. > > Sean > > -------- Forwarded Message -------- > Subject: Change in qt/qt3d[5.7]: Entity: add simple method to check for > components > Date: Fri, 24 Jun 2016 16:04:39 +0000 > From: Qt CI Bot (Code Review) > Reply-To: qt_ci_bot at qt-project.org > To: Paul Lemire > CC: Qt Sanity Bot , Sean Harmer > , Robert Brock > > > > Qt CI Bot has posted comments on this change. > > Change subject: Entity: add simple method to check for components > ...................................................................... > > > Continuous Integration: Failed > > Module "qt/qt3d" (3524e549c48edf4f6c90ba1e8f8af24d864b4afb) Failed > test(s): /Users/qt/work/qt/qt3d/tests/auto/core/qaspectengine: quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > ^D > quit > quit > quit > quit > quit > ^D > ^D > ^D > quit > quit > quit > ^D > quit > quit > ^D > ^D > ^D > ^D > quit > quit > ^D > ^D > ^D > quit > quit > quit > ^D > quit > quit > ^D > quit > quit > ^D > ^D > ^D > quit > quit > quit > ^D > ^D > ^D > quit > ^D > ^D > quit > quit > ^D > quit > quit > ^D > quit > quit > ^D > quit > ^D > ^D > ^D > quit > quit > ^D > quit > quit > ^D > quit > ^D > quit > Attaching to process with: > process attach -p 3095 > ^D > ^D > ^D > ^D > ^D > ^D > ^D > ^D > ^D > ^D > ^D > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > ^D > quit > ^D > ^D > ^D > quit > quit > quit > ^D > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > quit > ^D > quit > quit > ^D > quit > ^D > quit > ^D > ^D > ^D > ^D > quit > quit > quit > quit > ^D > ^D > ^D > ^D > quit > quit > quit > ^D > quit > quit > ^D > quit > ^D > quit > ^D > quit > ^D > quit > ^D > ^D > ^D > quit > quit > quit > ^D > quit > ^D > ^D > ^D > quit > quit > quit > ^D > ^D > ^D > ^D > ^D > quit > quit > quit > quit > quit > ^D > ^D > quit > quit > ^D > ^D > ^D > ^D > ^D > ^D > ^D > quit > quit > quit > quit > quit > quit > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > quit > quit > ^D > ^D > quit > ^D > quit > quit > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > quit > quit > quit > ^D > quit > ^D > ^D > quit > quit > ^D > quit > ^D > ^D > ^D > ^D > ^D > ^D > quit > quit > quit > quit > quit > quit > ^D > ^D > quit > ^D > quit > ^D > ^D > ^D > quit > quit > ^D > quit > quit > quit > ^D > ^D > ^D > quit > quit > ^D > quit > ^D > quit > quit > ^D > ^D > ^D > ^D > quit > quit > quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > quit > quit > ^D > quit > quit > ^D > ^D > ^D > quit > quit > ^D > ^D > quit > ^D > ^D > quit > quit > quit > ^D > ^D > ^D > quit > ^D > quit > quit > quit > quit > ^D > quProcess 3095 stopped > Executable module set to > "/Users/qt/work/qt/qt3d/tests/auto/core/qaspectengine/tst_qaspectengine.app > /Contents/MacOS/tst_qaspectengine". Architecture set to: > x86_64-apple-macosx. > (lldb) quit > ^D > (lldb) quitquit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > quit > > agent:2016/06/24 19:04:33 build.go:221: Killed process after timeout > (total time) agent:2016/06/24 19:04:34 agent.go:170: Test failed > agent:2016/06/24 19:04:34 build.go:158: Error reading from stdout/err: > Timeout after 15m0s: Maximum duration reached agent:2016/06/24 19:04:34 > agent.go:127: ERROR building: Timeout after 15m0s: Maximum duration reached > > Build log: > http://testresults.qt.io/logs/qt/qt3d/224055f620a8fc4ed6bcf965832b26d79e39b > 965/OSXOSX_10_08x86_64OSXOSX_10_08x86_64ClangRelease_NoFramework/f5928a8f6f4 > 10b5c920089ab39348d986238c96e/testrun_1466782347/testlog.txt.gz > > Details: > http://testresults.qt.io/coin/integration/qt/qt3d/tasks/1466782347.thrift_b > in > > Tested changes (refs/builds/qtci/5.7/1466782346): > > https://codereview.qt-project.org/#/q/9746c18738d3191120f51ff08d259c05bd5f2 > d83,n,z Entity: add simple method to check for components > https://codereview.qt-project.org/#/q/cb1fdc35938a70acc56054d363476690abac2 > e89,n,z Entity: use QVector for componentsHandle/renderComponents > https://codereview.qt-project.org/#/q/fbc7ea5d2d64ec2fa229a326a5e8ce2caa914 > 5cd,n,z FrameGraphNode: make children() return a QVector -- 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 harald.vistnes at gmail.com Sun Jun 26 22:46:52 2016 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Sun, 26 Jun 2016 22:46:52 +0200 Subject: [Development] Push to Gerrit In-Reply-To: <0486d8d3-6148-ef04-1981-be66be7a1eea@kdab.com> References: <0486d8d3-6148-ef04-1981-be66be7a1eea@kdab.com> Message-ID: Hi Sean, I got it to work. The problem was that I had both TortoiseGit and msysgit installed. I removed TortoiseGit and then it worked. Thanks Harald 2016-06-25 18:23 GMT+02:00 Sean Harmer : > Hi Harald, > > often on Windows it's easiest to install PuTTy and it's helper program, > pageant. Run pageant and import/convert your ssh key and set this up in > your gerrit webui. > Cheers, > > Sean > > > On 25/06/2016 16:06, Harald Vistnes wrote: > > Hi, > > I'm trying to make my first ever contribution to Qt, but I am struggling > with the last part of actually pushing to Gerrit. I've followed the > guidelines in the Wiki, but I have probably done something wrong. > > I've added and committed the patch locally, but when I try to run > > git push gerrit HEAD:refs/for/5.7 > > I get a popup messagebox: > > TortoiseGitPlink Fatal Error > Disconnected: No supported authentication methods available (server sent: > publickey) > > I'm on Windows. I assume the problem is related to the ssh keys. > > Any hints on how to continue would be welcome. > > Thanks, > > Harald Vistnes > > > > _______________________________________________ > Development mailing listDevelopment at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development > > > > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > KDAB (UK) Ltd, a KDAB Group company > Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 > Mobile: +44 (0)7545 140604 > KDAB - Qt Experts > > > _______________________________________________ > 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 suy at badopi.org Sun Jun 26 23:20:41 2016 From: suy at badopi.org (Alejandro Exojo) Date: Sun, 26 Jun 2016 23:20:41 +0200 Subject: [Development] v5.6.1-1 tag should have been v5.6.2 In-Reply-To: References: <1863824.yxbtdSSHUM@tjmaciei-mobl1> Message-ID: <7892484.4m29tbCJB0@walt> On Wednesday 22 June 2016 05:29:35 Simon Hausmann wrote: > Approach 3: Include the one declarative fix in 5.6.1, create a new tag and > rebuild declarative and all the modules that depend on it. That is the > quickest way of getting the release into the hands of the users (qtbase was > not rebuilt nor any other module not depending in declarative). We had > binaries ready for testing in under 24 hours. Note: When I wrote "rebuilt" > I mean re-compile and also re-run the auto-tests. With a big module like > qtbase you this can take a few iterations. And once qtbase changes all > depending modules undergo the same. This just makes me wonder a bunch of things: 1. Why would it take several iterations to get qtbase working if it's the same code already released, and just the version number is bumped? If it's because the auto tests can fail from time to time, then I don't get it. The tests fail surprisingly often in my humble experience. Running them over and over till they succeed will not give you any assurance that the packages are good. 2. Why all this effort in keeping binary compatibility, and splitting sources and binaries if you can't release just qtdeclarative with a different version than the rest? 3. Why would the qtdeclarative-dependent packages even need to be recompiled? Isn't the binary compatibility enough? 4. Why if some of your tools can't cope with 5.6.1.1, assume that 5.6.1-1 will be fine for all the downstreams? The dash is used as the separator for the packager version it at least one important packaging format. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net From suy at badopi.org Sun Jun 26 23:26:57 2016 From: suy at badopi.org (Alejandro Exojo) Date: Sun, 26 Jun 2016 23:26:57 +0200 Subject: [Development] v5.6.1-1 tag should have been v5.6.2 In-Reply-To: <7892484.4m29tbCJB0@walt> References: <1863824.yxbtdSSHUM@tjmaciei-mobl1> <7892484.4m29tbCJB0@walt> Message-ID: <1930682.FZgCrlzGdq@walt> On Sunday 26 June 2016 23:20:41 Alejandro Exojo wrote: > This just makes me wonder a bunch of things: Sorry, I wanted to trash this email that I started to write last Friday, and instead I sent it. This reads harsher that what I wanted to send, and I did not want to add more noise. My point is just that it's probably worth considering reviewing a bit the process to make a release if making a really quick 5.6.2 is not a reasonable path for cases like this. A security-related release would be even more important. I think Lars mentioned discussing it at QtCon, so I'll just leave the topic to then. Greetings, and sorry for the noise. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net From tuukka.turunen at qt.io Mon Jun 27 09:18:02 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 27 Jun 2016 07:18:02 +0000 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <3169505.IQ7K87i83b@cartman> References: <301E19B5-1193-40A4-B58E-654CB8403C30@qt.io> <3250075.1QZH7qfuxE@tjmaciei-mobl1> <3169505.IQ7K87i83b@cartman> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Sean Harmer > Sent: perjantaina 24. kesäkuuta 2016 11.23 > To: development at qt-project.org > Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 > packages > > -- clip --- > This is why we have a process. How is this situation compatible with TQC's ISO > 9001 certification?! > Hi Sean, Making a fix release fits well with the release process of the ISO 9001 certification, no problems there. In general, it is valuable to be able to make releases quickly to fix e.g. a security vulnerability. The fastest way to do it is to push the needed change (or changes) into the release branch, and create new release directly from there. I do not have any strong opinion if the number of the release should be x.y.z.1 , x.y.z-1 or even x.y.(z+1). Earlier the notation has been -1, but if there is desire to change it going forward, I do not think that is a problem. Yours, Tuukka > Sean > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB > (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46- > 563-540090 > Mobile: +44 (0)7545 140604 > KDAB - Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Mon Jun 27 09:45:46 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Jun 2016 00:45:46 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <3169505.IQ7K87i83b@cartman> Message-ID: <3215139.MassiJRip3@tjmaciei-mobl1> On segunda-feira, 27 de junho de 2016 07:18:02 PDT Tuukka Turunen wrote: > In general, it is valuable to be able to make releases quickly to fix e.g. a > security vulnerability. The fastest way to do it is to push the needed > change (or changes) into the release branch, and create new release > directly from there. I do not have any strong opinion if the number of the > release should be x.y.z.1 , x.y.z-1 or even x.y.(z+1). Earlier the notation > has been -1, but if there is desire to change it going forward, I do not > think that is a problem. Correction, no, there was no earlier notation because we've never done this before. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jun 27 09:57:56 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Jun 2016 00:57:56 -0700 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <9173263.7iln094xCU@tjmaciei-mobl1> References: <3106066.eL2LTxgl0P@tjmaciei-mobl1> <9173263.7iln094xCU@tjmaciei-mobl1> Message-ID: <1550896.ho3QIfyQIj@tjmaciei-mobl1> On sábado, 25 de junho de 2016 21:24:12 PDT Thiago Macieira wrote: > On sexta-feira, 24 de junho de 2016 08:51:51 PDT Thiago Macieira wrote: > > On sexta-feira, 24 de junho de 2016 10:26:37 PDT Tuukka Turunen wrote: > > > Hi, > > > > > > I do not know why 5.6.1 has been deleted, but it is of course a mistake. > > > However, we need to make sure no-one accidentally takes it, so maybe > > > moving > > > to archive is good approach? > > > > No, keep it in http://download.qt.io/official_releases/qt/5.6/, since it's > > an official release. Source code is enough though, we don't need the > > binaries. > > > > The solution for "make sure no one accidentally takes it" is to name the > > other release 5.6.2... > > Files are still not back yet. > > I've created a P0 task for the release team. Please solve this Monday. > > https://bugreports.qt.io/browse/QTBUG-54351 This is your daily reminder that the files are not back yet. Please address it by EOB today. I will send a new reminder when I wake up, if they are not there. I will send reminders every couple of hours if I am in front of my computer while the files are not there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at qt.io Mon Jun 27 10:34:57 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 27 Jun 2016 08:34:57 +0000 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <1550896.ho3QIfyQIj@tjmaciei-mobl1> References: <3106066.eL2LTxgl0P@tjmaciei-mobl1> <9173263.7iln094xCU@tjmaciei-mobl1> <1550896.ho3QIfyQIj@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Thiago > Macieira > Sent: maanantaina 27. kesäkuuta 2016 10.58 > To: development at qt-project.org > Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 > packages > > On sábado, 25 de junho de 2016 21:24:12 PDT Thiago Macieira wrote: > > On sexta-feira, 24 de junho de 2016 08:51:51 PDT Thiago Macieira wrote: > > > On sexta-feira, 24 de junho de 2016 10:26:37 PDT Tuukka Turunen wrote: > > > > Hi, > > > > > > > > I do not know why 5.6.1 has been deleted, but it is of course a mistake. > > > > However, we need to make sure no-one accidentally takes it, so > > > > maybe moving to archive is good approach? > > > > > > No, keep it in http://download.qt.io/official_releases/qt/5.6/, > > > since it's an official release. Source code is enough though, we > > > don't need the binaries. > > > > > > The solution for "make sure no one accidentally takes it" is to name > > > the other release 5.6.2... > > > > Files are still not back yet. > > > > I've created a P0 task for the release team. Please solve this Monday. > > > > https://bugreports.qt.io/browse/QTBUG-54351 > > This is your daily reminder that the files are not back yet. Please address it by > EOB today. > > I will send a new reminder when I wake up, if they are not there. > > I will send reminders every couple of hours if I am in front of my computer > while the files are not there. > As said before, removal of the earlier release was an error, which will be fixed as soon as possible. Feel free to send reminders to ML, but it really does not make the repos sync any faster. Yours, Tuukka > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Mon Jun 27 10:39:42 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 27 Jun 2016 08:39:42 +0000 Subject: [Development] Input events handling ideas and feedback In-Reply-To: References: Message-ID: <073A4C5F-6278-4354-8F01-3F5E8C68230E@qt.io> > On 25 Jun 2016, at 15:15, Filippo Cucchetto wrote: > > hi everyone, > this is going to be a lengthy email so i'd like to thank those > who will read it and maybe give me their opinions. > The topic here is throwing some ideas for improving QtQuick event > handling (both for mouse and keyboard). > First let's take a look at some simple/silly keyboard examples that will > make us introduce the main topic and some issue with the current way of handling > events. > First example (here)[http://pastebin.com/jiGJimGS]. Here the user would like to > count how many times the right key has been pressed. Try it and you will see that > the Keys.onPressed handler will be called twice when the caret is at the end > of the TextField but it will work when the caret moves inside the text. I know > that once the final user discover this, he can workaround it and fix the counter but > this is not the point. The reason why the Keys.onPressed is called twice > is caused by the TextField implementation. In fact a TextField is a composed Control > made of a TextInput plus a Text. At the same time, the end user doesn't know this and We have mostly stopped working on QtQuick Controls 1, because the implementation of Controls 2 is much more performant, and we have to focus on that. It was achieved by implementing behavior in C++, so each Control is composed of fewer objects. You should be testing it for some time already. It’s already out of tech preview, fully supported in 5.7. (Unfortunately the tech preview period was pretty short, from 5.6.0 to 5.7.0.) So please see what kinds of issues you still have with that. > he can only interact with the whole TextField (in theory he doesn't have to know that > the TextField contains a inner TextInput). For this reason the developer of the TextField > control added a Keys.forward[root] inside the inner TextInput toward the parent TextField. > This is correct in the current state of things because this allows the end user to override > the key handling of the the TextField. But why we see two events? This comes by the fact that: > 1 The right pressed event is delivered to the inner TextInput (because it has activeFocus) > 2 The event is forward to the TextField before being processed by the TextInput (because of Keys.forward[]) > 3 The TextField calls the Keys.onPressed handler of the user (that simply ignores the event) > 4 The event is processed by the TextInput that ignores it (because the caret is at the end) > 5 The event bubble up to the TextField again and the Keys.onPressed event handler will be called for the second time. > This example shows us that the actual way of handling events doesn't play well with item composition. > Furthermore the event forwarding is very error prone given that without attention is very easy to create > loops or unexpected chain of calls (due to bubbling and forwarding). > Obviously there could be several ways to solve this, for example > 1) Find some way of disabling the call to the event handler (during bubbling) since it has been called once > 2) Find some way for making a complex object (made of sub controls) to be seen as a unique entity for the sake > of event handling > 3) Let the user monitor the events before they reach a child. > 4) <--- your ideas here > Let's take a look to another example (here)[http://pastebin.com/9s36E6bm]. Here the user would like to disable > the ComboBox event handling, for example because the ComboBox is inside a ListView or TableView and he doesn't > want to break the View event handling (up ad down keys). If you try it you will see that it doesn't work. Even if > the events are accepted they're still delivered to the ComboBox. This is due (probably) by the fact the a Keys.forward[] > directive is missing inside the ComboBox implementation. > Another broader example is allowing a ListView to handle mouse clicks and events even if the delegate has a MouseArea on top. > This letter case can be implemented by using the filterChildMouseEvents api. > I've taken a look at what other frameworks do, in particular WPF (this doesn't mean the design of WPF is better or clever). > In WPF it seems there are three mechanism > 1) Event tunneling. The events first make a down path from the UI root node to the target node > 2) Event bubbling. The events are bubbled from the target node up to the UI root node > 3) Event flagged as handled (accepted) still make their way up (bubbling) because some nodes could be interested in a event > even if it has been flagged (rare ma usefull). > Point 1 it's basically a child monitor. Point 2 is what we already do. Point 3 is usefull because at point 1 you know that > an event is being delivered to a child but you don't know if it'll be accepted or not. Point 3 can be used for this purpose. OK, that’s an interesting idea. I was thinking that there must be some good ideas from other frameworks, but am not sure which one has best-in-class handling of events, especially mouse and/or touch (more on that below), and don’t have time to learn them all. > Just for fun i pushed two wip code reviews for event tunneling for keys events: one in QtCore https://codereview.qt-project.org/#/c/163502/ > and one in QtDeclarative https://codereview.qt-project.org/#/c/163502/ > With this patch the example 1 and 2 can be written like this: http://pastebin.com/t0ewNrxC and http://pastebin.com/LqvPZkZN > Further informations about tunneling and wpf event handling can be found here https://msdn.microsoft.com/it-it/library/ms742806(v=vs.110).aspx#how_event_processing_works > My patches are just wips and if there's interest i can work further on them. For example i would like > to have some sort of Mouse attacched object, like Keys and implementing bubbling even for handled events. > Finally maybe we need some sort of QEP for writing long term ideas and discuss them in public. We are working on a new QPointerEvent and a set of pointer handler objects now. My main goal is to unify the handling of mouse, touch and tablet events, and make it possible for a handler either to be device-agnostic (just handle a click or tap, don’t distinguish them) or to filter events based on devices, capabilities etc. (handle a touch-drag differently than a stylus-drag). Those filters are specified declaratively. The design for the handlers is between that of MouseArea and the Keys handler: it’s not an attached object, because I think you need to be able to have multiple handlers per Item; but it’s just an object, not an Item. It is a delegate object for handling a particular kind of event within an Item. And in the context of a single Item, all handlers have equal opportunity to handle every event. This amounts to a loosening of the restriction that an Item must grab an event in order to get the updates: at least it’s only the Item grabbing, but multiple handlers inside can still get the updates. So you can easily use a PinchHandler and a DragHandler and a TapHandler together, as siblings declared within one Item. But I think we might still need to go further than that, because sometimes it’s unavoidable that you need events to bubble up through a stack of Items, and so far to do that you set filtersChildMouseEvents. And child-filtering feels a bit too special, too out-of-band. Or, you can write a QObject event filter, which also seems like dubious design to me, but the jury’s still out on whether we ought to consider that technique a fundamental part of event handling in Qt Quick. We have discussed sometimes whether declared Handlers ought to be augmented with attached objects, so that handling the mouse or touchpoint could be a one-liner in some cases. But attached objects are actually less lightweight in implementation (I wish that wasn’t the case, but it always has been); and if you can only attach one handler of a particular type to an Item, then some advanced cases would require imperative code like what you’d typically write in Keys.onPressed. That kind of code is not declarative enough, IMO. It’s mitigated somewhat by all the key-specific signals like onSpacePressed, onTabPressed etc. But we don’t yet have signals for every possible key; and even if you can avoid writing a big switch in Keys.onPressed, you might still need to check the modifiers inside your onSpacePressed (or whatever) function. We also came up with the idea of handling pointer events in phases: for each Handler which is visited, first ask if it wants the event, then ask it to process the event, then ask it to post-process the event (this last step is an opportunity to emit all signals at the same time and in the right order). But so far we are going through those phases while visiting one handler - not visiting all of them to ask whether it wants it, and then visiting all of them again to process it. I had the idea because I don’t like the ambiguity that QQuickItem::event() returns a bool, and there’s also the opportunity to accept or reject the event: it’s not sufficiently memorable which of those is the right way to prevent or allow propagation in a particular situation, and which takes precedence. Every time I look at the code I have to figure that out again. Whereas if the prefilter returns false, at the very least it means that it’s going to propagate this time, and maybe it should also mean that this handler does not see a need for a grab… or maybe not. We have the opportunity to revisit the grabbing concept now. I agree that we should try to bring key and pointer handling closer. But I’m also less aware of what’s wrong with key handling, compared to pointer handling. So it’s worthwhile to discuss, but my main focus right now is pointer handling, to get it done in time for a tech preview for 5.8 (that means there’s only a few weeks left before feature freeze). Later we could try to apply what we learn to key handling, to the extent that it’s applicable. Everyone is welcome to send me challenges: mouse and touch use cases that are tough to implement with the current Areas. I know we have quite a few bugs about those cases already. I’m not sure if we can come up with declarative syntax that makes every such case easy to express, but it’s a stretch goal. From sean.harmer at kdab.com Mon Jun 27 10:45:59 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 27 Jun 2016 09:45:59 +0100 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: References: <3169505.IQ7K87i83b@cartman> Message-ID: <10730113.zkXKN0fKDo@cartman> On Monday 27 June 2016 07:18:02 Tuukka Turunen wrote: > > -----Original Message----- > > From: Development [mailto:development- > > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Sean Harmer > > Sent: perjantaina 24. kesäkuuta 2016 11.23 > > To: development at qt-project.org > > Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 > > packages > > > > -- clip --- > > This is why we have a process. How is this situation compatible with TQC's > > ISO 9001 certification?! > > > > > Hi Sean, > > Making a fix release fits well with the release process of the ISO 9001 > certification, no problems there. ISO 9001 is about following the processes that you say you follow. This is clearly not the case here as a process was made up on the spot to do it quickly. This is clearly a non-conformance. Removing packages is clearly another. I'm not disputing that a process for quick fix releases should be made, but the time to do this is not when there is a sudden need for it. That's when unforeseen mistakes slip through the cracks. Had the decision to just cherry pick this one fix and apply the usual release process for a 5.6.2 had been made, the level of testing could have been reduced accordingly to speed up the process and a message put out saying to avoid 5.6.1 if you are using QML/Quick. With a 5.6.2 release coming shortly, users could have made the informed decision to stick with 5.6.0 until 5.6.2 was ready. If the installer had the ability to downgrade as well as upgrade, this would be even easier. Cheers, Sean > In general, it is valuable to be able to make releases quickly to fix e.g. a > security vulnerability. The fastest way to do it is to push the needed > change (or changes) into the release branch, and create new release > directly from there. I do not have any strong opinion if the number of the > release should be x.y.z.1 , x.y.z-1 or even x.y.(z+1). Earlier the notation > has been -1, but if there is desire to change it going forward, I do not > think that is a problem. > Yours, > > Tuukka > > > > > > Sean > > -- > > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB > > (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46- > > 563-540090 > > Mobile: +44 (0)7545 140604 > > KDAB - Qt Experts > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From Uwe.Rathmann at tigertal.de Mon Jun 27 11:28:50 2016 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Mon, 27 Jun 2016 09:28:50 +0000 (UTC) Subject: [Development] Input events handling ideas and feedback References: <073A4C5F-6278-4354-8F01-3F5E8C68230E@qt.io> Message-ID: On Mon, 27 Jun 2016 08:39:42 +0000, Shawn Rutledge wrote: > We have mostly stopped working on QtQuick Controls 1, because the > implementation of Controls 2 is much more performant ... Controls 2 are for "embedded" - what at least means to me: not being for desktop applications. > It was achieved by implementing behavior in C++ ... ... and by dropping desktop specific features. But does your statement imply, that Qt development has mostly given up QML as a technology for the desktop ? If true, was it done because of: a) seeing Controls 1 as complete and satisfying b) something is wrong with the implementation of Controls 1 c) the overhead of QML is too big for such large projects d) nobody is interested in the desktop at all And what is recommended for us users: better starting off with widgets for new desktop applications ? Uwe From szehowe.koh at gmail.com Mon Jun 27 11:46:58 2016 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Mon, 27 Jun 2016 17:46:58 +0800 Subject: [Development] Input events handling ideas and feedback In-Reply-To: References: <073A4C5F-6278-4354-8F01-3F5E8C68230E@qt.io> Message-ID: On 27 June 2016 at 17:28, Uwe Rathmann wrote: > > On Mon, 27 Jun 2016 08:39:42 +0000, Shawn Rutledge wrote: > > > We have mostly stopped working on QtQuick Controls 1, because the > > implementation of Controls 2 is much more performant ... > > Controls 2 are for "embedded" - what at least means to me: not being for > desktop applications. > > > It was achieved by implementing behavior in C++ ... > > ... and by dropping desktop specific features. > > But does your statement imply, that Qt development has mostly given up QML > as a technology for the desktop ? > > If true, was it done because of: > > a) seeing Controls 1 as complete and satisfying > b) something is wrong with the implementation of Controls 1 > c) the overhead of QML is too big for such large projects > d) nobody is interested in the desktop at all > > And what is recommended for us users: better starting off with widgets > for new desktop applications ? > > Uwe Hi, I suggest reading the comments section of https://blog.qt.io/blog/2016/06/10/qt-quick-controls-2-0-a-new-beginning/ for detailed comments about Desktop support. Regards, Sze-Howe From tuukka.turunen at qt.io Mon Jun 27 12:08:29 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 27 Jun 2016 10:08:29 +0000 Subject: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 packages In-Reply-To: <10730113.zkXKN0fKDo@cartman> References: <3169505.IQ7K87i83b@cartman> <10730113.zkXKN0fKDo@cartman> Message-ID: > -----Original Message----- > From: sean.harmer On Behalf Of Sean Harmer > Sent: maanantaina 27. kesäkuuta 2016 11.46 > To: development at qt-project.org > Cc: Tuukka Turunen > Subject: Re: [Development] [Releasing] brown paper bag issue in Qt 5.6.1 > packages > > On Monday 27 June 2016 07:18:02 Tuukka Turunen wrote: > > > -----Original Message----- > > > From: Development [mailto:development- > > > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Sean > > > bounces+Harmer > > > Sent: perjantaina 24. kesäkuuta 2016 11.23 > > > To: development at qt-project.org > > > Subject: Re: [Development] [Releasing] brown paper bag issue in Qt > > > 5.6.1 packages > > > > > > -- clip --- > > > This is why we have a process. How is this situation compatible with > > > TQC's ISO > 9001 certification?! > > > > > > > > > Hi Sean, > > > > Making a fix release fits well with the release process of the ISO > > 9001 certification, no problems there. > > ISO 9001 is about following the processes that you say you follow. This is > clearly not the case here as a process was made up on the spot to do it > quickly. This is clearly a non-conformance. Removing packages is clearly > another. > Deleting the package was an error that is fixed as soon as possible. It is not part of the process to do so. > I'm not disputing that a process for quick fix releases should be made, but > the time to do this is not when there is a sudden need for it. That's when > unforeseen mistakes slip through the cracks. > I do agree that the process of making this kind of releases should be better documented and agreed upon by the various stakeholders. Release team has also earlier made similar ones, but mostly related to packaging problems. > Had the decision to just cherry pick this one fix and apply the usual release > process for a 5.6.2 had been made, the level of testing could have been > reduced accordingly to speed up the process and a message put out saying to > avoid 5.6.1 if you are using QML/Quick. With a 5.6.2 release coming shortly, > users could have made the informed decision to stick with 5.6.0 until 5.6.2 > was ready. If the installer had the ability to downgrade as well as upgrade, > this would be even easier. > I think it would be best to have this discussion in the next release team meeting and in addition at QtCon. Changing the version number in Qt modules, re-doing all change files etc, takes time and especially when done so close to release would cause users possibly to miss the other changes in the logs. We need to have a process that is lightweight enough to make "hotfixes" when necessary. If the process of making for example a security fix is too time consuming, it will cause us not to use it as often as we perhaps should. Yours, Tuukka > Cheers, > > Sean > > > In general, it is valuable to be able to make releases quickly to fix > > e.g. a security vulnerability. The fastest way to do it is to push the > > needed change (or changes) into the release branch, and create new > > release directly from there. I do not have any strong opinion if the > > number of the release should be x.y.z.1 , x.y.z-1 or even x.y.(z+1). > > Earlier the notation has been -1, but if there is desire to change it > > going forward, I do not think that is a problem. > > > Yours, > > > > Tuukka > > > > > > > > > > > Sean > > > -- > > > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB > > > (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) > > > +46- > > > 563-540090 > > > Mobile: +44 (0)7545 140604 > > > KDAB - Qt Experts > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB > (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46- > 563-540090 > Mobile: +44 (0)7545 140604 > KDAB - Qt Experts From edward.welbourne at qt.io Mon Jun 27 12:29:34 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 27 Jun 2016 10:29:34 +0000 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: <13210002.JkO6No2ATJ@42> References: , <13210002.JkO6No2ATJ@42> Message-ID: Jędrzej Nowacki said (inter alia): > Technically waiting for merges is not necessary. Coin is able > to test arbitrary refs from gerrit, I encourage you to not wait for > the system, but just make bunch of changes and tests the expected > combination, before it gets merged from stable branches. You can also > request a feature branch for testing if you want to work that way. In > the same time I agree, the merge cycle is too slow, it is just > annoying. In my opinion the system should automatically create merge > patches after each successful integration and warn if it was not > possible because of conflicts. It seems also that I'm extremist in > that area, but one merge per day seems to be a reasonable compromise. +1 for regular automated up-merging as often as possible. We'd still need to manually resolve conflicts, but this would bring them to light early and one at a time, which tends to make them easier to resolve ! Eddy. From Shawn.Rutledge at qt.io Mon Jun 27 13:19:17 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 27 Jun 2016 11:19:17 +0000 Subject: [Development] Input events handling ideas and feedback In-Reply-To: References: <073A4C5F-6278-4354-8F01-3F5E8C68230E@qt.io> Message-ID: <19A3C26B-A504-46A7-A10F-AFD5D99A7222@qt.io> Disclaimer: I'm writing some mix of personal opinion (which is subject to change anyway) and opinions that I’ve heard from others, in reply to this... > On 27 Jun 2016, at 11:28, Uwe Rathmann wrote: > > On Mon, 27 Jun 2016 08:39:42 +0000, Shawn Rutledge wrote: > >> We have mostly stopped working on QtQuick Controls 1, because the >> implementation of Controls 2 is much more performant ... > > Controls 2 are for "embedded" - what at least means to me: not being for > desktop applications. Emulating pixel-perfect native appearance is always tricky at best. But if you avoid doing that, you can still develop some nice desktop applications. And lately, support has been added for the native menubar, and for platform dialogs and tray icons - those aren’t for embedded. The trend is for every app to have its own design nowadays (even though the old guard of usability-oriented designers will naturally think that’s terrible). People got used to diversity, and having to learn the UI of every app separately. They got used to web apps: it’s so easy to make incremental changes there. Visual designers have gotten the upper hand over usability designers. Personally I use all the OSes (except for avoiding Windows a lot of the time), so I just have to adapt. Even the OSes are in flux, so native app designs get updated periodically whether we like it or not. Is there a backlash against all this change (much of which is completely gratuitous)? Will there be? I’m not sure. What people enjoy and what’s optimal for them are seldom the same. And AI is coming, so we can expect that more flux is coming too: AIs could be used to rewrite software faster; they might be able to optimize the human factors better (if people can make the AIs focus on that); and the UI which itself incorporates AI can be expected to be different anyway. How soon will people begin to think about and agree on expectations for conversational interfaces: when and how do we want to talk to the software and when do we not? Personally, I only want to talk to it if its motivations aren’t completely opposite to mine, if it’s not an advertising or surveillance platform first and a UI second, if I can be sure it doesn't record everything I type and all sound within my environment all the time, and send it to the cloud. So with all that coming, is it really so important to accurately emulate the appearance of widgets on your OS-of-the-day? Every year or so, it will change again, so it’s quite some effort for us to keep following along, copycatting their every move. People who are so inclined sometimes work on widget styles, and then Controls 1 was reusing them to draw the native-looking controls. It’s not a pure QtQuick way of rendering: the CPU has to do some of the rendering work. Why couldn’t we keep doing that? Controls 2 has C++ for behavior, and you do the styling in QML, so maybe someone will again write a way of reusing the widget styles to draw the controls. It hasn’t been done yet AFAIK; maybe it will be. And when UI designs (like Android Material) themselves incorporate animation, widget styles can’t express that anyway, so we have to emulate it via animations in QtQuick. >> It was achieved by implementing behavior in C++ ... > > ... and by dropping desktop specific features. > > But does your statement imply, that Qt development has mostly given up QML > as a technology for the desktop ? > > If true, was it done because of: > > a) seeing Controls 1 as complete and satisfying > b) something is wrong with the implementation of Controls 1 > c) the overhead of QML is too big for such large projects > d) nobody is interested in the desktop at all > > And what is recommended for us users: better starting off with widgets > for new desktop applications ? There is probably disagreement on that, but I’d say it depends what kind of application. If you are writing the same kind of application that you’d have written a decade ago, and you want it to look native and stay that way, then you never needed a “fluid” UI anyway (which is what QtQuick is all about). And we keep fixing bugs in widgets, even though we don’t develop many new features, because there continues to be so much demand. But if you want the same application to be portable to mobile devices, then widgets aren’t a great fit, because users don’t get what they expect. So it bothers me that we don’t try to uphold the old write once deploy anywhere strategy anymore, because people think it’s impossible now - mobile and desktop are too different. I don’t think it’s impossible, but we don’t focus on it so far. There are so many app developers, and so much disposable software now. If people don’t value their time so much that they want to write it only once and keep using it for years or decades on multiple platforms without redesigning it, what can we do about that? And if they do, then widgets still work. Maybe it’s worth the time it takes to have a really efficient pure-native application with no interpreters running. And if you have enough experience using Creator and its built-in Designer, you can throw widget apps together almost as fast as QML apps anyway. OTOH there is hope that the 2D Renderer is going to make QtQuick practical on platforms where OpenGL performance isn’t predictable enough. (Although, how many more years are we really going to have trouble with GPU acceleration on any platform? It’s been far too long already.) And there is hope that the compiler replaces the interpreter, at least to an extent. If you need a fluid UI, you’d better have GPU acceleration, IMO. If you want to use the GPU to render the whole UI, you need the scene graph, so that it can batch draw calls. But I suspect we could use some limited GPU acceleration in widgets - if the one thing you want to be “fluid” is flicking and scrolling, why not render the scrollable contents (or tiles from it) to texture(s), and let the GPU move them around during the scrolling? We ought to be able to have that technique in the mainstream eventually. Then widgets would be more tolerable for a while yet, and it might be more efficient when it works. Somebody will probably point out a way that you can already do that, but so far you have to jump through whatever hoops to make it happen. But making that mainstream hasn’t been prioritized. From oswald.buddenhagen at qt.io Mon Jun 27 13:24:18 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 27 Jun 2016 13:24:18 +0200 Subject: [Development] Qt 5.8 branching & Feature Freeze In-Reply-To: References: <13210002.JkO6No2ATJ@42> Message-ID: <20160627112417.GD7359@troll08.intra.qt.io> On Mon, Jun 27, 2016 at 10:29:34AM +0000, Edward Welbourne wrote: > this would bring them to light early and one at a time, which tends to > make them easier to resolve ! > given that mutiple conflicts in the same place are pretty rare, i'll challenge that claim. From frederik.gladhorn at qt.io Mon Jun 27 14:30:48 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 27 Jun 2016 14:30:48 +0200 Subject: [Development] RHEL 7.2 added to Coin Message-ID: <1541912.zGMnCiMMM6@frederik-thinkcentre-m93p> Hi all, good news when it comes to packaging on Linux, we added red hat 7.2 as the new packaging config for the dev branch - Qt 5.8 that is. We'll also run it as developer build with the 5.7 branch. I'll flip the switch to actually run it in a few minutes. I'd not be terribly surprised if some module has issues, even though we did successfully produce complete builds of all modules and run all tests, but there is a chance that something changed or new flaky ness is added. If you see things that look suspicious on the new platform, please let me know. Cheers, Frederik From frederik.gladhorn at qt.io Mon Jun 27 15:26:49 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 27 Jun 2016 15:26:49 +0200 Subject: [Development] RHEL 7.2 added to Coin In-Reply-To: <1541912.zGMnCiMMM6@frederik-thinkcentre-m93p> References: <1541912.zGMnCiMMM6@frederik-thinkcentre-m93p> Message-ID: <8896870.qXkZASZtPy@frederik-thinkcentre-m93p> On mandag 27. juni 2016 14.30.48 CEST Frederik Gladhorn wrote: > Hi all, > > good news when it comes to packaging on Linux, we added red hat 7.2 as the > new packaging config for the dev branch - Qt 5.8 that is. We'll also run it > as developer build with the 5.7 branch. I'll flip the switch to actually > run it in a few minutes. ... and temporarily reverted again, not sure what is wrong with the VM, but it didn't start reliably. I'll try re-enabling this in a bit... Frederik From filippocucchetto at gmail.com Mon Jun 27 22:03:49 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Mon, 27 Jun 2016 22:03:49 +0200 Subject: [Development] Input events handling ideas and feedback In-Reply-To: References: <073A4C5F-6278-4354-8F01-3F5E8C68230E@qt.io> Message-ID: Please let's try not go off topic. This post is for improving and collecting ideas for improving the QtQuick event handling. I would be more interested in knowing the struggle you had dealing with it and discussing the idea i've proposed F. 2016-06-27 11:28 GMT+02:00 Uwe Rathmann : > On Mon, 27 Jun 2016 08:39:42 +0000, Shawn Rutledge wrote: > > > We have mostly stopped working on QtQuick Controls 1, because the > > implementation of Controls 2 is much more performant ... > > Controls 2 are for "embedded" - what at least means to me: not being for > desktop applications. > > > It was achieved by implementing behavior in C++ ... > > ... and by dropping desktop specific features. > > But does your statement imply, that Qt development has mostly given up QML > as a technology for the desktop ? > > If true, was it done because of: > > a) seeing Controls 1 as complete and satisfying > b) something is wrong with the implementation of Controls 1 > c) the overhead of QML is too big for such large projects > d) nobody is interested in the desktop at all > > And what is recommended for us users: better starting off with widgets > for new desktop applications ? > > Uwe > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From filippocucchetto at gmail.com Mon Jun 27 23:12:13 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Mon, 27 Jun 2016 23:12:13 +0200 Subject: [Development] Input events handling ideas and feedback In-Reply-To: <073A4C5F-6278-4354-8F01-3F5E8C68230E@qt.io> References: <073A4C5F-6278-4354-8F01-3F5E8C68230E@qt.io> Message-ID: Thank you Shawn for your reply > Control is composed of fewer objects. You should be testing it for some time already. Well i already used the QtQuickControls 2 and i do understand that their design if superior (like for example the font handling) but i still think that composition of multiple QQuickItems is something we should deal with (independently by the fact that we support Native or not Native styles). > don’t have time to learn them all I'm sorry if i sounded rude, i didn't mean that you (or who worked in the QtQuick event handling implementation) should know all frameworks implementations. I just wanted to give some hints, discuss them together and show some WIP patches for implementing something similar. Obviously i'm totaly open to drop them if not appreciated or against the future visions/plans for QtQuick. The more we discuss these things openly the more we can arrive at a better result. > My main goal is to unify the handling of mouse, touch and tablet events.. > ...even if you can avoid writing a big switch in Keys.onPressed, I agree with that even if IMHO having a javascript switch in the handler it's not so terrible. To me what matter is to make most use cases possible in a "good" way. >The design for the handlers is between that of MouseArea and the Keys handler: it’s not an attached object, because I think you need to be able to have multiple handlers per Item; but it’s just an object, not an Item. > It is a delegate object for handling a particular kind of event within an Item. And in the context of a single Item, all handlers have equal opportunity to handle every event. > This amounts to a loosening of the restriction that an Item must grab an event in order to get the updates: at least it’s only the Item grabbing, but multiple handlers inside can still get the updates. This seems reasonable but still (as you exaplained) we have the problem with bubbling and the need for monitoring mouse/keys event in a parent item. To me it seems that tunneling/bubbling methods are not in contrast with your idea. Tunneling/bubbling handle the recursive phase; instead multiple handlers (as you suggested) handle the item step. > Everyone is welcome to send me challenges: mouse and touch use cases that are tough to implement with the current Areas. The most common hard thing to implement right now is handling ListView/TableView/TreeViews mouse events. The problem is that an item delegate that handles mouse events break the view mouse handling. Obviously rejecting the MouseEvent in the pressEvent is not sufficient: in fact this allows the event to bubble up to the view but prevent the delegate MouseArea to receive composed events like clicks or double clicks. To me a possible solution would be to use point (3) of my previous mail: the View should receive all the mouse events independently by the fact that they have been handled or not. In this way the view can handle selection/dragging correctly. Obviously this behaviour could be unwanted, but this could be disable with something like this ListView { Mouse.onPressed: { if (mouse.handled) { return } } } The idea is to have a possible Mouse attached object that has a higher priority over the normal item event handling (like is done with the Keys attached objects). In this way we can disable the item default event handling with already handled events (that bubbled up from a delegate). Thank you again for the answer F. 2016-06-27 10:39 GMT+02:00 Shawn Rutledge : > > > On 25 Jun 2016, at 15:15, Filippo Cucchetto > wrote: > > > > hi everyone, > > this is going to be a lengthy email so i'd like to thank those > > who will read it and maybe give me their opinions. > > The topic here is throwing some ideas for improving QtQuick event > > handling (both for mouse and keyboard). > > First let's take a look at some simple/silly keyboard examples that will > > make us introduce the main topic and some issue with the current way of > handling > > events. > > First example (here)[http://pastebin.com/jiGJimGS]. Here the user would > like to > > count how many times the right key has been pressed. Try it and you will > see that > > the Keys.onPressed handler will be called twice when the caret is at the > end > > of the TextField but it will work when the caret moves inside the text. > I know > > that once the final user discover this, he can workaround it and fix the > counter but > > this is not the point. The reason why the Keys.onPressed is called twice > > is caused by the TextField implementation. In fact a TextField is a > composed Control > > made of a TextInput plus a Text. At the same time, the end user doesn't > know this and > > We have mostly stopped working on QtQuick Controls 1, because the > implementation of Controls 2 is much more performant, and we have to focus > on that. It was achieved by implementing behavior in C++, so each Control > is composed of fewer objects. You should be testing it for some time > already. It’s already out of tech preview, fully supported in 5.7. > (Unfortunately the tech preview period was pretty short, from 5.6.0 to > 5.7.0.) So please see what kinds of issues you still have with that. > > > he can only interact with the whole TextField (in theory he doesn't have > to know that > > the TextField contains a inner TextInput). For this reason the developer > of the TextField > > control added a Keys.forward[root] inside the inner TextInput toward the > parent TextField. > > This is correct in the current state of things because this allows the > end user to override > > the key handling of the the TextField. But why we see two events? This > comes by the fact that: > > 1 The right pressed event is delivered to the inner TextInput (because > it has activeFocus) > > 2 The event is forward to the TextField before being processed by the > TextInput (because of Keys.forward[]) > > 3 The TextField calls the Keys.onPressed handler of the user (that > simply ignores the event) > > 4 The event is processed by the TextInput that ignores it (because the > caret is at the end) > > 5 The event bubble up to the TextField again and the Keys.onPressed > event handler will be called for the second time. > > This example shows us that the actual way of handling events doesn't > play well with item composition. > > Furthermore the event forwarding is very error prone given that without > attention is very easy to create > > loops or unexpected chain of calls (due to bubbling and forwarding). > > Obviously there could be several ways to solve this, for example > > 1) Find some way of disabling the call to the event handler (during > bubbling) since it has been called once > > 2) Find some way for making a complex object (made of sub controls) to > be seen as a unique entity for the sake > > of event handling > > 3) Let the user monitor the events before they reach a child. > > 4) <--- your ideas here > > Let's take a look to another example (here)[http://pastebin.com/9s36E6bm]. > Here the user would like to disable > > the ComboBox event handling, for example because the ComboBox is inside > a ListView or TableView and he doesn't > > want to break the View event handling (up ad down keys). If you try it > you will see that it doesn't work. Even if > > the events are accepted they're still delivered to the ComboBox. This is > due (probably) by the fact the a Keys.forward[] > > directive is missing inside the ComboBox implementation. > > Another broader example is allowing a ListView to handle mouse clicks > and events even if the delegate has a MouseArea on top. > > This letter case can be implemented by using the filterChildMouseEvents > api. > > I've taken a look at what other frameworks do, in particular WPF (this > doesn't mean the design of WPF is better or clever). > > In WPF it seems there are three mechanism > > 1) Event tunneling. The events first make a down path from the UI root > node to the target node > > 2) Event bubbling. The events are bubbled from the target node up to the > UI root node > > 3) Event flagged as handled (accepted) still make their way up > (bubbling) because some nodes could be interested in a event > > even if it has been flagged (rare ma usefull). > > Point 1 it's basically a child monitor. Point 2 is what we already do. > Point 3 is usefull because at point 1 you know that > > an event is being delivered to a child but you don't know if it'll be > accepted or not. Point 3 can be used for this purpose. > > OK, that’s an interesting idea. I was thinking that there must be some > good ideas from other frameworks, but am not sure which one has > best-in-class handling of events, especially mouse and/or touch (more on > that below), and don’t have time to learn them all. > > > Just for fun i pushed two wip code reviews for event tunneling for keys > events: one in QtCore https://codereview.qt-project.org/#/c/163502/ > > and one in QtDeclarative https://codereview.qt-project.org/#/c/163502/ > > With this patch the example 1 and 2 can be written like this: > http://pastebin.com/t0ewNrxC and http://pastebin.com/LqvPZkZN > > Further informations about tunneling and wpf event handling can be found > here > https://msdn.microsoft.com/it-it/library/ms742806(v=vs.110).aspx#how_event_processing_works > > My patches are just wips and if there's interest i can work further on > them. For example i would like > > to have some sort of Mouse attacched object, like Keys and implementing > bubbling even for handled events. > > Finally maybe we need some sort of QEP for writing long term ideas and > discuss them in public. > > We are working on a new QPointerEvent and a set of pointer handler objects > now. My main goal is to unify the handling of mouse, touch and tablet > events, and make it possible for a handler either to be device-agnostic > (just handle a click or tap, don’t distinguish them) or to filter events > based on devices, capabilities etc. (handle a touch-drag differently than a > stylus-drag). Those filters are specified declaratively. The design for > the handlers is between that of MouseArea and the Keys handler: it’s not an > attached object, because I think you need to be able to have multiple > handlers per Item; but it’s just an object, not an Item. It is a delegate > object for handling a particular kind of event within an Item. And in the > context of a single Item, all handlers have equal opportunity to handle > every event. This amounts to a loosening of the restriction that an Item > must grab an event in order to get the updates: at least it’s only the Item > grabbing, but multiple handlers inside can still get the updates. So you > can easily use a PinchHandler and a DragHandler and a TapHandler together, > as siblings declared within one Item. But I think we might still need to > go further than that, because sometimes it’s unavoidable that you need > events to bubble up through a stack of Items, and so far to do that you set > filtersChildMouseEvents. And child-filtering feels a bit too special, too > out-of-band. Or, you can write a QObject event filter, which also seems > like dubious design to me, but the jury’s still out on whether we ought to > consider that technique a fundamental part of event handling in Qt Quick. > > We have discussed sometimes whether declared Handlers ought to be > augmented with attached objects, so that handling the mouse or touchpoint > could be a one-liner in some cases. But attached objects are actually less > lightweight in implementation (I wish that wasn’t the case, but it always > has been); and if you can only attach one handler of a particular type to > an Item, then some advanced cases would require imperative code like what > you’d typically write in Keys.onPressed. That kind of code is not > declarative enough, IMO. It’s mitigated somewhat by all the key-specific > signals like onSpacePressed, onTabPressed etc. But we don’t yet have > signals for every possible key; and even if you can avoid writing a big > switch in Keys.onPressed, you might still need to check the modifiers > inside your onSpacePressed (or whatever) function. > > We also came up with the idea of handling pointer events in phases: for > each Handler which is visited, first ask if it wants the event, then ask it > to process the event, then ask it to post-process the event (this last step > is an opportunity to emit all signals at the same time and in the right > order). But so far we are going through those phases while visiting one > handler - not visiting all of them to ask whether it wants it, and then > visiting all of them again to process it. I had the idea because I don’t > like the ambiguity that QQuickItem::event() returns a bool, and there’s > also the opportunity to accept or reject the event: it’s not sufficiently > memorable which of those is the right way to prevent or allow propagation > in a particular situation, and which takes precedence. Every time I look > at the code I have to figure that out again. Whereas if the prefilter > returns false, at the very least it means that it’s going to propagate this > time, and maybe it should also mean that this handler does not see a need > for a grab… or maybe not. We have the opportunity to revisit the grabbing > concept now. > > I agree that we should try to bring key and pointer handling closer. But > I’m also less aware of what’s wrong with key handling, compared to pointer > handling. So it’s worthwhile to discuss, but my main focus right now is > pointer handling, to get it done in time for a tech preview for 5.8 (that > means there’s only a few weeks left before feature freeze). Later we could > try to apply what we learn to key handling, to the extent that it’s > applicable. > > Everyone is welcome to send me challenges: mouse and touch use cases that > are tough to implement with the current Areas. I know we have quite a few > bugs about those cases already. I’m not sure if we can come up with > declarative syntax that makes every such case easy to express, but it’s a > stretch goal. > > -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From Liang.Qi at qt.io Tue Jun 28 09:58:29 2016 From: Liang.Qi at qt.io (Liang Qi) Date: Tue, 28 Jun 2016 07:58:29 +0000 Subject: [Development] RHEL 7.2 added to Coin In-Reply-To: <8896870.qXkZASZtPy@frederik-thinkcentre-m93p> References: <1541912.zGMnCiMMM6@frederik-thinkcentre-m93p>, <8896870.qXkZASZtPy@frederik-thinkcentre-m93p> Message-ID: Could we disable RHEL 7.2? at least for QtScript. There is a failure in qt5.git dev integration. It is the only blocker for it now. https://codereview.qt-project.org/162195 Best Regards, Liang ________________________________ From: Development on behalf of Frederik Gladhorn Sent: Monday, June 27, 2016 3:26:49 PM To: development at qt-project.org Subject: Re: [Development] RHEL 7.2 added to Coin On mandag 27. juni 2016 14.30.48 CEST Frederik Gladhorn wrote: > Hi all, > > good news when it comes to packaging on Linux, we added red hat 7.2 as the > new packaging config for the dev branch - Qt 5.8 that is. We'll also run it > as developer build with the 5.7 branch. I'll flip the switch to actually > run it in a few minutes. ... and temporarily reverted again, not sure what is wrong with the VM, but it didn't start reliably. I'll try re-enabling this in a bit... Frederik _______________________________________________ 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 chgans at gna.org Tue Jun 28 10:32:16 2016 From: chgans at gna.org (Ch'Gans) Date: Tue, 28 Jun 2016 20:32:16 +1200 Subject: [Development] RHEL 7.2 added to Coin In-Reply-To: <1541912.zGMnCiMMM6@frederik-thinkcentre-m93p> References: <1541912.zGMnCiMMM6@frederik-thinkcentre-m93p> Message-ID: BTW, is it just me or http://testresults.qt.io/ci/status/ has some problems: error fetching data from http://testresults.qt.io/cgi-bin/ci-api: error; Can't connect to 127.0.0.1:7181 (Connection refused); Can't connect to 127.0.0.1:7181 (Connection refused) LWP::Protocol::http::Socket: connect: Connection refused at /usr/share/perl5/LWP/Protocol/http.pm line 51. () Chris On 28 June 2016 at 00:30, Frederik Gladhorn wrote: > Hi all, > > good news when it comes to packaging on Linux, we added red hat 7.2 as the new > packaging config for the dev branch - Qt 5.8 that is. We'll also run it as > developer build with the 5.7 branch. I'll flip the switch to actually run it in > a few minutes. > > I'd not be terribly surprised if some module has issues, even though we did > successfully produce complete builds of all modules and run all tests, but > there is a chance that something changed or new flaky ness is added. > > If you see things that look suspicious on the new platform, please let me > know. > > Cheers, > Frederik > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From frederik.gladhorn at qt.io Tue Jun 28 13:32:58 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Tue, 28 Jun 2016 13:32:58 +0200 Subject: [Development] RHEL 7.2 added to Coin In-Reply-To: References: <1541912.zGMnCiMMM6@frederik-thinkcentre-m93p> Message-ID: <3694165.E3L68O2FVP@frederik-thinkcentre-m93p> On tirsdag 28. juni 2016 20.32.16 CEST Ch'Gans wrote: > BTW, is it just me or http://testresults.qt.io/ci/status/ has some problems: > > error fetching data from http://testresults.qt.io/cgi-bin/ci-api: > error; Can't connect to 127.0.0.1:7181 (Connection refused); Can't > connect to 127.0.0.1:7181 (Connection refused) > LWP::Protocol::http::Socket: connect: Connection refused at > /usr/share/perl5/LWP/Protocol/http.pm line 51. () I guess this was the old status page from Jenkins? I'm not sure what the path should contain. For Coin, this link should work: http://testresults.qt.io/coin/ Cheers, Frederik > > Chris > > On 28 June 2016 at 00:30, Frederik Gladhorn wrote: > > Hi all, > > > > good news when it comes to packaging on Linux, we added red hat 7.2 as the > > new packaging config for the dev branch - Qt 5.8 that is. We'll also run > > it as developer build with the 5.7 branch. I'll flip the switch to > > actually run it in a few minutes. > > > > I'd not be terribly surprised if some module has issues, even though we > > did > > successfully produce complete builds of all modules and run all tests, but > > there is a chance that something changed or new flaky ness is added. > > > > If you see things that look suspicious on the new platform, please let me > > know. > > > > Cheers, > > Frederik > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at qt.io Tue Jun 28 15:58:46 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 28 Jun 2016 13:58:46 +0000 Subject: [Development] Input events handling ideas and feedback In-Reply-To: References: <073A4C5F-6278-4354-8F01-3F5E8C68230E@qt.io> Message-ID: <22773438-3EA5-4FD4-A8D6-8E788F5FF9E6@qt.io> > On 27 Jun 2016, at 23:12, Filippo Cucchetto wrote: > > Thank you Shawn for your reply > > > Control is composed of fewer objects. You should be testing it for some time already. > Well i already used the QtQuickControls 2 and i do understand that their design if superior (like for example the font handling) but > i still think that composition of multiple QQuickItems is something we should deal with (independently by the fact that we > support Native or not Native styles). Yes that’s true. There are lots of third-party sets of controls, and there’s nothing wrong with creating them by composition - it’s just that QQControls 1 got a bit carried away with creating too many objects. > > don’t have time to learn them all > I'm sorry if i sounded rude, i didn't mean that you (or who worked in the QtQuick event handling implementation) should know > all frameworks implementations. You were not at all rude, and I didn’t mean to be either. When it comes to event propagation/grabbing/stealing/monitoring, our way is just one of many possibilities, but maybe it could be more elegant. So you provided one example (WPF), and I’ll try to think more about the pros and cons of how they did it. If we had time to filter out all the good ideas from all the frameworks, we’d have a better chance of making ours the best. ;-) > I just wanted to give some hints, discuss them together and show some WIP patches for implementing > something similar. Obviously i'm totaly open to drop them if not appreciated or against the future visions/plans for QtQuick. The more > we discuss these things openly the more we can arrive at a better result. Yes. > > My main goal is to unify the handling of mouse, touch and tablet events.. > > ...even if you can avoid writing a big switch in Keys.onPressed, > I agree with that even if IMHO having a javascript switch in the handler it's not so terrible. To me what matter is to make most use cases > possible in a "good" way. Well we advertise that it’s a declarative language. We could make it even more that way, even if it’s not strictly necessary. Would it be more elegant? > >The design for the handlers is between that of MouseArea and the Keys handler: it’s not an attached object, because I think you need to be able to have multiple handlers per Item; but it’s just an object, not an Item. > > It is a delegate object for handling a particular kind of event within an Item. And in the context of a single Item, all handlers have equal opportunity to handle every event. > > This amounts to a loosening of the restriction that an Item must grab an event in order to get the updates: at least it’s only the Item grabbing, but multiple handlers inside can still get the updates. > This seems reasonable but still (as you exaplained) we have the problem with bubbling and the need for monitoring mouse/keys event in a parent item. > To me it seems that tunneling/bubbling methods are not in contrast with your idea. Tunneling/bubbling handle the recursive phase; instead multiple handlers (as you suggested) handle the item step. > > > Everyone is welcome to send me challenges: mouse and touch use cases that are tough to implement with the current Areas. > The most common hard thing to implement right now is handling ListView/TableView/TreeViews mouse events. The problem is that an item delegate that handles mouse events break the view mouse handling. > Obviously rejecting the MouseEvent in the pressEvent is not sufficient: in fact this allows the event to bubble up to the view but prevent the delegate MouseArea to receive composed events like clicks or double clicks. Well in my experience, handling clicks inside delegates works fine, but we have trouble with hover propagation, and we have trouble with draggable items inside the delegate, especially when you try to drag via touch. The ListView/etc. monitors its children’s events. So if you drag beyond the drag threshold in the ListView’s direction of interest, the ListView steals the grab, and for the MouseArea inside the delegate, the grab is canceled. I think we could say that QQuickWindowPrivate::deliverInitialMousePressEvent() does tunnelling: it starts with the root and goes recursively _down_ through the children until the event is accepted (Handled in WPF terminology). But for each child recursively, it calls QQuickWindow::sendEvent(), which in the case of mouse events calls sendFilteredMouseEvent(item->parentItem(), item, e, &hasFiltered). And that goes recursively _up_ the parent hierarchy, calling childMouseEventFilter on any ancestor Item which has the filtersChildMouseEvents flag set. So it’s kindof like bubbling, but it happens before the real event handling in the leaf Item, rather than afterwards. And it happens multiple times per “target", which would be inefficient and redundant, so QSet *hasFiltered is used to keep track of the items that have already had their chance at filtering. (Yeah, a fresh new QSet gets populated for every event. But it’s not the only case of that, either.) So that’s already rather like bubbling, but I'd worry about changing the order: WPF gives the “source” a chance to handle the event first, then the bubbling happens after; whereas QtQuick does sendFilteredMouseEvent first and then lets the Item have the event. That might be a big change to make. But then again, by the time the ListView’s drag threshold is exceeded, the MouseArea inside the delegate has already been the grabber for a while; so the grab must be canceled, and that involves sending another event to tell it that it was canceled. So if we did tunnelling followed by bubbling, we’d need to keep doing that, and maybe it would be OK. https://msdn.microsoft.com/en-us/library/ms742806(v=vs.110).aspx#how_event_processing_works is the English equivalent to the link you posted. So now I have some quotes and comments. They start with an example with 3 buttons inside a couple of nested containers, and say "the source of a Click event is one of the Button elements”. Saying that the event source is the leaf node, or that the leaf node “raised” the event, hides how it figured that out. Didn’t it need to use tunnelling to decide that? At least from Qt’s perspective, the Window “raised” the event, and we need to find the relevant Item inside. But they say tunnelling is one routing strategy alongside “bubbling” and “direct”, and routed events use “one of three routing strategies”. Well, maybe they used tunnelling, or some other means to narrow down the items in the neighborhood where the event occurred, to find the “source”, before this routing even starts. So the “source” is always a leaf? I was thinking of trying some kind of space partitioning; didn’t get around to trying that. Items which have Handlers could be put into a k-d tree, or something. But there would have to be a worthwhile speedup to justify maintaining that structure. And we’d only need it for press events, not for releases and updates, as long as we keep the grabbing the same. Then under WPF Input Events there is a tree of elements. Based on the explanation, I guess it does start with the root element and does tunnelling, but is that the first step or do they already know by magic that leaf #2 “raised” the event? How did they skip the step of tunnelling to leaf #1? "Usually, once the input event is marked Handled, further handlers are not invoked. … The exception to this general statement about Handled state is that input event handlers that are registered to deliberately ignore Handled state of the event data would still be invoked along either route.” Aha… so bubbling doesn’t always occur: the item must register an interest in receiving already-handled events, right? I was thinking of having a list of Items like that in QQuickWindow: those which want to monitor all pointer events regardless of the grabber. Or, maybe making it so that grabbing can be non-exclusive: multiple items can grab at the same time, but it’s prioritized so that the leaf item will get the event first, or the “grabbiest” will get it first, whatever that means. So there is a registry for items which want to monitor all events, but the bubbling should still be done in reverse-z-order? After the tunnelling, the leaf gets the event, then we look at its parent and see if it’s in the monitor-all list, and let it have the bubbled event if so; then go to its parent and do the same; etc. Does that sound about right? Well, instead of a separate list, we have the filtersChildMouseEvents flag, and we are checking each parent. > To me a possible solution would be to use point (3) of my previous mail: the View should receive all the mouse events independently by the fact that they have been handled or not. In this way the view can handle > selection/dragging correctly. Obviously this behaviour could be unwanted, but this could be disable with something like this > ListView { > Mouse.onPressed: { > if (mouse.handled) { > return > } > } > } Returning from a JS function will happen whether you write “return” or not. There’s an escalation/arms-race problem: by default the leaf MouseArea grabs, which should already mean that it’s exclusive, it doesn’t want any ancestor to see the event. (Why should grabbing be default? Only because subsequent events can be delivered quickly, it seems. But grabbing prevents easy monitoring by the ancestors.) But, we violate that by having the ListView monitor its children’s events - not only that, it gets them first, before the children. And it can also steal the grab. Oh, but the child can also have preventStealing: true. We don’t yet have ListView.preventStealingPrevention or stealEvenMoreBrazenly. ;-) So should the leaf item not grab by default? Well then we need to do more work to deliver subsequent events: redo the “tunnelling” step each time, right? Anyway I guess we have bubbling, within the parent hierarchy, in the form of setting filtersChildMouseEvents to true. What we don’t have is event propagation to other Items which occupy the same space but are siblings or cousins of that hierarchy. Whereas with key events, deliverKeyEvent sends to activeFocusItem only. It’s the keyboard grabber, and that had to be determined ahead of time. That’s different than mouse and touch handling. But I guess it’s because only one TextInput is supposed to have an active cursor, so you can see where it’s going to go. The delivery is not based on position and geometry. You just run into trouble when you use key events for other purposes than text input, right? > The idea is to have a possible Mouse attached object that has a higher priority over the normal item event handling (like is done with the Keys attached objects). In this > way we can disable the item default event handling with already handled events (that bubbled up from a delegate). So pre-filtering like we already do when filtersChildMouseEvents is true, but outside the hierarchy, so that siblings can monitor mouse events too? Only via the attached object? For high-priority key handling, we have Shortcut. Those are handled early in QGuiApplicationPrivate::processKeyEvent() before the QKeyEvent is constructed and delivered. And there is the QObject::installEventFilter() technique. We could have a PointerFilter if we like, or certain specialized handlers for specific use cases. It could install itself on whatever object it’s declared inside of, or maybe it has to install itself on the window. But then there wouldn’t necessarily be a way to control the ordering if you declare multiple filters, and they are all on the Window. From thiago.macieira at intel.com Tue Jun 28 16:48:33 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 28 Jun 2016 07:48:33 -0700 Subject: [Development] RHEL 7.2 added to Coin In-Reply-To: References: <1541912.zGMnCiMMM6@frederik-thinkcentre-m93p> <8896870.qXkZASZtPy@frederik-thinkcentre-m93p> Message-ID: <1863573.rPZT5uPsAg@tjmaciei-mobl1> On terça-feira, 28 de junho de 2016 07:58:29 PDT Liang Qi wrote: > Could we disable RHEL 7.2? at least for QtScript. There is a failure in > qt5.git dev integration. It is the only blocker for it now. > > > https://codereview.qt-project.org/162195 Is there any other config running tests with a gtk3 plugin? What desktop environment is that RH 7.2 using? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From heikki.halmet at qt.io Wed Jun 29 08:20:47 2016 From: heikki.halmet at qt.io (Heikki Halmet) Date: Wed, 29 Jun 2016 06:20:47 +0000 Subject: [Development] RHEL 7.2 added to Coin In-Reply-To: <1863573.rPZT5uPsAg@tjmaciei-mobl1> References: <1541912.zGMnCiMMM6@frederik-thinkcentre-m93p> <8896870.qXkZASZtPy@frederik-thinkcentre-m93p> <1863573.rPZT5uPsAg@tjmaciei-mobl1> Message-ID: >>Is there any other config running tests with a gtk3 plugin? I don't think so >>What desktop environment is that RH 7.2 using? gnome-classic - Heikki -----Original Message----- From: Development [mailto:development-bounces+heikki.halmet=qt.io at qt-project.org] On Behalf Of Thiago Macieira Sent: 28. kesäkuuta 2016 17:49 To: development at qt-project.org Subject: Re: [Development] RHEL 7.2 added to Coin On terça-feira, 28 de junho de 2016 07:58:29 PDT Liang Qi wrote: > Could we disable RHEL 7.2? at least for QtScript. There is a failure > in qt5.git dev integration. It is the only blocker for it now. > > > https://codereview.qt-project.org/162195 Is there any other config running tests with a gtk3 plugin? What desktop environment is that RH 7.2 using? -- 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 Jun 29 16:54:34 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 29 Jun 2016 07:54:34 -0700 Subject: [Development] RHEL 7.2 added to Coin In-Reply-To: References: <1541912.zGMnCiMMM6@frederik-thinkcentre-m93p> <1863573.rPZT5uPsAg@tjmaciei-mobl1> Message-ID: <5099622.uPKc1OjPCu@tjmaciei-mobl1> On quarta-feira, 29 de junho de 2016 06:20:47 PDT Heikki Halmet wrote: > >>Is there any other config running tests with a gtk3 plugin? > > I don't think so > > >>What desktop environment is that RH 7.2 using? > > gnome-classic The maintainers of the gtk3 plugin need to take a look. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From konstantin at podsvirov.pro Thu Jun 30 05:38:23 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Thu, 30 Jun 2016 06:38:23 +0300 Subject: [Development] [QtIFW] [Help Request] Relocatable Repository Set In-Reply-To: <1169021466574106@web16o.yandex.ru> References: <1169021466574106@web16o.yandex.ru> Message-ID: <1225011467257903@web5m.yandex.ru> Hello again! 22.06.2016, 08:42, Konstantin Podsvirov" : > Hello QtIFW developers! > > It's my first change. > > Can anybody review and merge It: > > https://codereview.qt-project.org/#/c/163220/ Some time ago I added a small change in QtIFW. https://codereview.qt-project.org/#/c/163220 This change will allow to use relative URLs for the updates repository. This feature is useful for projects with multiple repositories. This feature will allow you to make sets online repository portable. Also, this feature can help to close a task: https://bugreports.qt.io/browse/QTIFW-441 I have updated just 12 lines of code, but need help with adding documentation and examples of this functionality. English is not my native and I don't want to do a lot of silly typos in this work. Asking all stakeholders to help promote this change. -- Regards, Konstantin Podsvirov From olivier at woboq.com Thu Jun 30 12:52:19 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 30 Jun 2016 12:52:19 +0200 Subject: [Development] clang-format config file. Message-ID: <16877743.hqAKVsFRrF@maurice> Hi, I have made a clang-format config file. I believe it should go into the qtrepotools repository, so I made this pull request: https://codereview.qt-project.org/163941 You can download this file from there and put it in the parent directory of your qt repositories. (clang-format search all the parent folders for a .clang-format file) We don't want to reformat existing files, but this help to format only the lines that are touched in a given commit. The git-clang-format tool can be used for that. The git-clang-format tool is part of the clang. So it is probably packaged in your distribution as part of clang. To use it, simply commit as before, but before pushing, run: git-clang-format HEAD^ git diff # look at the changes made by clang-format, possibly retify some of it git commit -a --amend Then you can push. If you want to run git-clang-format on several commit separately, the --exec feature of git rebase comes handy: git rebase -i --exec "git-clang-format HEAD^" The rebase will stop if clang-format does changes so you can apply the changes to that last commit and continue with git rebase --continue ⁂ The conf file is based on the WebKit style which is the closest builtin style to Qt. Then it was adjusted to fit better to the existing Qt style. It follows the style closely, but there are some cases that might not be following existing practices. The question is if we want to try to fix clang- format to be able to cope with them, or simply adapt the coding style to fit clang-format config. Some of the things that are not possible with clang-format if to have all the function in one line like we sometimes have in our headers: inline const QString operator+(const QString &s1, const QString &s2) { QString t(s1); t += s2; return t; } The style disabled any re-wraping of the comments, because the qdoc rules are not encoded in clang-format. So comments will not be touched. But in general, I have been trying it on a few commits and it works quite well. You should try it as well and report the problems so they can be addressed. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From dominik.holland at pelagicore.com Thu Jun 30 13:01:30 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Thu, 30 Jun 2016 13:01:30 +0200 Subject: [Development] clang-format config file. In-Reply-To: <16877743.hqAKVsFRrF@maurice> References: <16877743.hqAKVsFRrF@maurice> Message-ID: Hi Olivier, Am 06/30/2016 um 12:52 PM schrieb Olivier Goffart: > Hi, > > I have made a clang-format config file. I believe it should go into the > qtrepotools repository, so I made this pull request: > https://codereview.qt-project.org/163941 > > You can download this file from there and put it in the parent directory of > your qt repositories. (clang-format search all the parent folders for a > .clang-format file) > > We don't want to reformat existing files, but this help to format only the > lines that are touched in a given commit. The git-clang-format tool can be > used for that. > > The git-clang-format tool is part of the clang. So it is probably packaged in > your distribution as part of clang. > > To use it, simply commit as before, but before pushing, run: > > git-clang-format HEAD^ > git diff > # look at the changes made by clang-format, possibly retify some of it > git commit -a --amend > > Then you can push. > > If you want to run git-clang-format on several commit separately, the --exec > feature of git rebase comes handy: > > git rebase -i --exec "git-clang-format HEAD^" > > The rebase will stop if clang-format does changes so you can apply the changes > to that last commit and continue with git rebase --continue > > ⁂ > > The conf file is based on the WebKit style which is the closest builtin style > to Qt. Then it was adjusted to fit better to the existing Qt style. > > It follows the style closely, but there are some cases that might not be > following existing practices. The question is if we want to try to fix clang- > format to be able to cope with them, or simply adapt the coding style to fit > clang-format config. I think it would be cool to have a built-in Qt config, as it would be very convenient also for other developers which work with Qt. > > Some of the things that are not possible with clang-format if to have all the > function in one line like we sometimes have in our headers: > > inline const QString operator+(const QString &s1, const QString &s2) > { QString t(s1); t += s2; return t; } > > > The style disabled any re-wraping of the comments, because the qdoc rules are > not encoded in clang-format. So comments will not be touched. > > But in general, I have been trying it on a few commits and it works quite > well. You should try it as well and report the problems so they can be > addressed. > thx for uploading this. We used clang-format in one of our projects and what we've seen is that the clang-format version used for the formatting is important and can lead to different results. Which version did you use ? Debian(unstable) is currently offering the following versions for me: clang-format - Tool to format C/C++/Obj-C code clang-format-3.5 - Tool to format C/C++/Obj-C code clang-format-3.6 - Tool to format C/C++/Obj-C code clang-format-3.7 - Tool to format C/C++/Obj-C code clang-format-3.8 - Tool to format C/C++/Obj-C code clang-format-3.9 - Tool to format C/C++/Obj-C code clang-format-3.4 - Tool to format C/C++/Obj-C code If the version is not packaged for your distribution you might be able to download a binary version here: http://llvm.org/releases/download.html Dominik -- 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 olivier at woboq.com Thu Jun 30 13:37:01 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 30 Jun 2016 13:37:01 +0200 Subject: [Development] clang-format config file. In-Reply-To: References: <16877743.hqAKVsFRrF@maurice> Message-ID: <15139077.B7xQ5jcTPt@maurice> On Donnerstag, 30. Juni 2016 13:01:30 CEST Dominik Holland wrote: > Hi Olivier, > > Am 06/30/2016 um 12:52 PM schrieb Olivier Goffart: > > Hi, > > > > I have made a clang-format config file. I believe it should go into the > > qtrepotools repository, so I made this pull request: > > https://codereview.qt-project.org/163941 > > > > You can download this file from there and put it in the parent directory > > of your qt repositories. (clang-format search all the parent folders for > > a .clang-format file) > > > > We don't want to reformat existing files, but this help to format only the > > lines that are touched in a given commit. The git-clang-format tool can > > be used for that. > > > > The git-clang-format tool is part of the clang. So it is probably packaged > > in your distribution as part of clang. > > > > To use it, simply commit as before, but before pushing, run: > > git-clang-format HEAD^ > > git diff > > # look at the changes made by clang-format, possibly retify some of it > > git commit -a --amend > > > > Then you can push. > > > > If you want to run git-clang-format on several commit separately, the > > --exec feature of git rebase comes handy: > > git rebase -i --exec "git-clang-format HEAD^" > > > > The rebase will stop if clang-format does changes so you can apply the > > changes to that last commit and continue with git rebase --continue > > > > ⁂ > > > > The conf file is based on the WebKit style which is the closest builtin > > style to Qt. Then it was adjusted to fit better to the existing Qt style. > > > > It follows the style closely, but there are some cases that might not be > > following existing practices. The question is if we want to try to fix > > clang- format to be able to cope with them, or simply adapt the coding > > style to fit clang-format config. > > I think it would be cool to have a built-in Qt config, as it would be > very convenient also for other developers which work with Qt. > > > Some of the things that are not possible with clang-format if to have all > > the> > > function in one line like we sometimes have in our headers: > > inline const QString operator+(const QString &s1, const QString &s2) > > { QString t(s1); t += s2; return t; } > > > > The style disabled any re-wraping of the comments, because the qdoc rules > > are not encoded in clang-format. So comments will not be touched. > > > > But in general, I have been trying it on a few commits and it works quite > > well. You should try it as well and report the problems so they can be > > addressed. > > thx for uploading this. > > We used clang-format in one of our projects and what we've seen is that > the clang-format version used for the formatting is important and can > lead to different results. > > Which version did you use ? I was using clang 3.8. > Debian(unstable) is currently offering the following versions for me: > > clang-format - Tool to format C/C++/Obj-C code > clang-format-3.5 - Tool to format C/C++/Obj-C code > clang-format-3.6 - Tool to format C/C++/Obj-C code > clang-format-3.7 - Tool to format C/C++/Obj-C code > clang-format-3.8 - Tool to format C/C++/Obj-C code > clang-format-3.9 - Tool to format C/C++/Obj-C code > clang-format-3.4 - Tool to format C/C++/Obj-C code > > If the version is not packaged for your distribution you might be able > to download a binary version here: http://llvm.org/releases/download.html > > Dominik -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From lykurg at gmail.com Thu Jun 30 14:26:34 2016 From: lykurg at gmail.com (Lorenz Haas) Date: Thu, 30 Jun 2016 14:26:34 +0200 Subject: [Development] clang-format config file. In-Reply-To: <16877743.hqAKVsFRrF@maurice> References: <16877743.hqAKVsFRrF@maurice> Message-ID: Hi, > The style disabled any re-wraping of the comments, because the qdoc rules are > not encoded in clang-format. So comments will not be touched. just for the record: clang-format can exclude specific comment types from re-wrapping. Thus if you/we do not mind a "either re-wrap all comments or leave them all as they are" rule, CommentPragmas could be used, e.g.: CommentPragmas: '^!|^:|^=|^~' Cheers From harald.vistnes at gmail.com Thu Jun 30 15:14:10 2016 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Thu, 30 Jun 2016 15:14:10 +0200 Subject: [Development] [Qt3D] Render to FBO Message-ID: Hi, Are there any plans on getting offscreen rendering (render to FBO) into Qt3D for 5.8? This has been requested multiple times before, and Sean suggested to try a solution based on the Scene3DItem implementation. I tried this and made some progress. I just uploaded a small demo example to https://bugreports.qt.io/browse/QTBUG-52136 https://bugreports.qt.io/secure/attachment/57353/offscreenrenderer.zip I think I am quite close to the solution. I get Qt3D to render into the FBO, because the color of the image extracted from the FBO has the same color as the clearcolor set in the framegraph. But there is no geometry rendered. I've not been able to figure out why. The example is set up so that it can render the same scene either to a normal Qt3DWindow or to the FBO, so I see that the scene is set up correctly. If someone with more knowledge of the inner workings of Qt3D could look into this, I would be very grateful. If this problem can be solved, I can contribute some time to get this into 5.8, because this missing feature is the last blocker that prevents me from switching to Qt3D in my application. Best regards, Harald -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Thu Jun 30 15:17:52 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 30 Jun 2016 15:17:52 +0200 Subject: [Development] clang-format config file. In-Reply-To: References: <16877743.hqAKVsFRrF@maurice> Message-ID: <13231263.kMcFY5tscv@maurice> On Donnerstag, 30. Juni 2016 14:26:34 CEST Lorenz Haas wrote: > Hi, > > > The style disabled any re-wraping of the comments, because the qdoc rules > > are not encoded in clang-format. So comments will not be touched. > > just for the record: clang-format can exclude specific comment types > from re-wrapping. Thus if you/we do not mind a "either re-wrap all > comments or leave them all as they are" rule, CommentPragmas could be > used, e.g.: > > CommentPragmas: '^!|^:|^=|^~' Thanks for your suggestion. I updated the file. (I used only ! and :, I don't know what = or ~ was refering to) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From mwoehlke.floss at gmail.com Thu Jun 30 21:00:16 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 30 Jun 2016 15:00:16 -0400 Subject: [Development] clang-format config file. In-Reply-To: <16877743.hqAKVsFRrF@maurice> References: <16877743.hqAKVsFRrF@maurice> Message-ID: On 2016-06-30 06:52, Olivier Goffart wrote: > [clang-format] follows the style closely, but there are some cases > that might not be following existing practices. The question is if we > want to try to fix clang-format to be able to cope with them, or > simply adapt the coding style to fit clang-format config. > > Some of the things that are not possible with clang-format if to have all the > function in one line like we sometimes have in our headers: > > inline const QString operator+(const QString &s1, const QString &s2) > { QString t(s1); t += s2; return t; } FWIW, I vote for fixing clang-format... because Qt is probably not the only project out there that would prefer to use such format :-). -- Matthew