From jani.heikkinen at qt.io Thu Dec 1 09:07:12 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 1 Dec 2016 08:07:12 +0000 Subject: [Development] Qt 5.8.0 change files. MAINTAINERS: your actions needed Message-ID: Hi, We did initial change files for Qt 5.8.0 (for those modules where missing), see https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+5.8.0%22,n,z Maintainers, please take those over & finalize as soon as possible. And of course make sure those will be reviewed soon as well. We need to get all these in now, RC is planned to happen 13th Dec! br, Jani From sierdzio at gmail.com Thu Dec 1 10:00:45 2016 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Thu, 1 Dec 2016 10:00:45 +0100 Subject: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery? In-Reply-To: <1771536.9ryNEon5mP@klux.site> References: <2244793.ZbTD6rx2HE@klux.site> <1771536.9ryNEon5mP@klux.site> Message-ID: On 30 November 2016 at 17:14, Friedrich W. H. Kossebau wrote: > > And seeing that KDE uses /usr/share/doc/HTML for documentation in html/ > docbook(?) format I am for now proposing > /usr/share/doc/QCH Sounds good. And just to add my voice - I think automatic pickup of QCH files is something very worth introducing (and not only on Linux). From Julius.Bullinger at asctec.de Thu Dec 1 14:04:51 2016 From: Julius.Bullinger at asctec.de (Julius Bullinger) Date: Thu, 1 Dec 2016 13:04:51 +0000 Subject: [Development] Qt 5.9 In-Reply-To: References: , <1730010.M5yXzDyc6Q@tjmaciei-mobl1> Message-ID: -----Ursprüngliche Nachricht----- Von: Development [mailto:development-bounces+julius.bullinger=asctec.de at qt-project.org] Im Auftrag von Jani Heikkinen Gesendet: Tuesday, 29 November, 2016 12:08 An: Thiago Macieira ; development at qt-project.org Betreff: Re: [Development] Qt 5.9 > And how to encourage users to use online installers instead of offline ones? One solution could be that we start using online ones at > first & bring offline ones later. Earlier we have released beta with offline only so should we do this differently with Qt 5.9: > > Qt 5.9 alpha: src only > Qt 5.9 beta: online only > Qt 5.9 rc & final: online + offline I hope it's okay to chime in here as a non-developer, but I would actually really be happy about that! I really like to test beta-versions on Windows, but can't justify installing a completely new Qt environment (including another Creator instance with its own kits and settings). If the beta was available in the online installer, I would happily start testing today! From kevin.kofler at chello.at Fri Dec 2 02:04:00 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 02 Dec 2016 02:04 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? References: <3180741.cRJAskENCj@tjmaciei-mobl1> <05EB4094-933F-4B45-AFA2-A389F978E275@qt.io> <201611182037.26392.marc.mutz@kdab.com> <7856b53df583fc7dd2de58906b33c14b@kdab.com> Message-ID: Marc Mutz wrote: > To see how simple gsl::owner markup is to incorporate into Qt, I sat > down, added it to QtGlobal and marked up QScopedPointer (incl. docs) > with gsl::owner. > > https://codereview.qt-project.org/178107 This is just pointless noise making the code more verbose for no practical benefit whatsoever. Kevin Kofler From kevin.kofler at chello.at Fri Dec 2 02:53:11 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 02 Dec 2016 02:53:11 +0100 Subject: [Development] Recommendations for 3rd-party QCH file installation folder for easy discovery? References: <2244793.ZbTD6rx2HE@klux.site> <1771536.9ryNEon5mP@klux.site> Message-ID: Friedrich W. H. Kossebau wrote: > As it seems that Qt Assistant automatically adds (after restart) new QCH > files it discovers in the QT_INSTALL_DOCS folder to the default help file > collection, simply installing any 3rd-party QCH files into that folder > would serve the use-case of automatic addition to Qt Assistant after > install. And thus this is what I propose now as well to do. After all > installing into the Qt system dirs is also done already for 3rd-party > plugins, mkspec files or QML imports. As a distro packager, I think this is definitely the way to go. Tracking what package any individual file comes from is what the package manager is for. This is also how it works for manpages, .desktop files, etc. > And seeing that KDE uses /usr/share/doc/HTML for documentation in html/ > docbook(?) format I am for now proposing > /usr/share/doc/QCH > as folder where packages would drop the QCH/qthelp system specific files, Why would we need to invent yet another directory? QT_INSTALL_DOCS in Fedora is currently /usr/share/doc/qt5, I think that is perfectly fine. It is also versioned, so you do not get, e.g., kdelibs4 apidocs in the Qt 5 Assistant, or the other way round. I think you should just use the existing QT_INSTALL_DOCS directory and stick to it, no need to reinvent the wheel and break compatibility. Kevin Kofler From kevin.kofler at chello.at Fri Dec 2 02:56:52 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 02 Dec 2016 02:56:52 +0100 Subject: [Development] New library in qtbase References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> <2976940.gPpOHW8DdO@tjmaciei-mobl1> <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> <5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io> <938B8FC5-626C-47B1-BB12-6017C475490A@edeltech.ch> Message-ID: Samuel Gaist wrote: > The idea is to implement the notification part which would be then used by > QSystemTrayIcon. Then you want to use the freedesktop.org "Galago" notification spec. Kevin Kofler From tobias.hunger at gmail.com Fri Dec 2 07:45:48 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 2 Dec 2016 07:45:48 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <7856b53df583fc7dd2de58906b33c14b@kdab.com> References: <3180741.cRJAskENCj@tjmaciei-mobl1> <05EB4094-933F-4B45-AFA2-A389F978E275@qt.io> <201611182037.26392.marc.mutz@kdab.com> <7856b53df583fc7dd2de58906b33c14b@kdab.com> Message-ID: Hi Marc, Am 28.11.2016 15:33 schrieb "Marc Mutz" : > To see how simple gsl::owner markup is to incorporate into Qt, I sat down, added it to QtGlobal and marked up QScopedPointer (incl. docs) with gsl::owner. > > https://codereview.qt-project.org/178107 Owner does not work with Qt's object tree, so this seems like a pointless exercise to me. Having some owners but not being able to use them consistently is not a big win and already possible with plain C++ smart pointers. I asked Bjarne Stroustrup at Meeting C++ about Owner and object trees and he said that is a memory model that is not supported and that we are on our own there. Best Regards, Tobias -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri Dec 2 08:22:18 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 2 Dec 2016 08:22:18 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: References: <7856b53df583fc7dd2de58906b33c14b@kdab.com> Message-ID: <201612020822.18522.marc.mutz@kdab.com> On Friday 02 December 2016 07:45:48 Tobias Hunger wrote: > Hi Marc, > > Am 28.11.2016 15:33 schrieb "Marc Mutz" : > > To see how simple gsl::owner markup is to incorporate into Qt, I sat > > down, added it to QtGlobal and marked up QScopedPointer (incl. docs) with > gsl::owner. > > > https://codereview.qt-project.org/178107 > > Owner does not work with Qt's object tree, so this seems like a pointless > exercise to me. Having some owners but not being able to use them > consistently is not a big win and already possible with plain C++ smart > pointers. > > I asked Bjarne Stroustrup at Meeting C++ about Owner and object trees and > he said that is a memory model that is not supported and that we are on our > own there. As you can see, I was not using it on QObject, as, indeed, the ownership there is messed up. But we have tons of take*() and take()-like API, where even in auto-tests, which presumably were written by people that know the API well, the return value was ignored/leaked, making this kind of API a strong case for use of owner<>. If the Qt low-level smart pointer do not support gsl::owner, then we impair users that wish to use the GSL in their own code from using it, because Qt code will throw false positives. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From Shawn.Rutledge at qt.io Fri Dec 2 11:27:16 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Fri, 2 Dec 2016 10:27:16 +0000 Subject: [Development] New library in qtbase In-Reply-To: References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> <2976940.gPpOHW8DdO@tjmaciei-mobl1> <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> <5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io> <938B8FC5-626C-47B1-BB12-6017C475490A@edeltech.ch> Message-ID: <357754E1-D65A-4037-948D-CCDA582D2D97@qt.io> > On 2 Dec 2016, at 02:56, Kevin Kofler wrote: > > Samuel Gaist wrote: >> The idea is to implement the notification part which would be then used by >> QSystemTrayIcon. > > Then you want to use the freedesktop.org "Galago" notification spec. http://www.galago-project.org/about.php sounds like it’s just for “presence” to tell instant-messaging clients whether you are using the computer or not. From bo at vikingsoft.eu Fri Dec 2 12:32:16 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Fri, 2 Dec 2016 12:32:16 +0100 Subject: [Development] two questions about the build system of Qt In-Reply-To: References: Message-ID: Den 29-11-2016 kl. 19:53 skrev Cor-Paul Bezemer: > Hi, I am a researcher in a team that is working on build systems and we > are doing a case study on missing dependencies in the Qt 5.3.0 build > system. I know that Qt 5.3.0 is an old version but the case study is > part of a paper that has been under review for more than a year now. Could you say a bit more about why you are doing this and what you are hoping to achieve? It's not often that I see someone investigating things like the two issues you found. Thanks, Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From tobias.hunger at gmail.com Fri Dec 2 14:28:24 2016 From: tobias.hunger at gmail.com (Tobias Hunger) Date: Fri, 2 Dec 2016 14:28:24 +0100 Subject: [Development] Basing Qt Creator Coding Style on C++ Core Guidelines? In-Reply-To: <201612020822.18522.marc.mutz@kdab.com> References: <7856b53df583fc7dd2de58906b33c14b@kdab.com> <201612020822.18522.marc.mutz@kdab.com> Message-ID: Hi Marc, On Fri, Dec 2, 2016 at 8:22 AM, Marc Mutz wrote: > As you can see, I was not using it on QObject, as, indeed, the ownership there > is messed up. It just does not work with the concepts laid out in the GSL, but that does not make it messed up. > But we have tons of take*() and take()-like API, where even in auto-tests, > which presumably were written by people that know the API well, the return > value was ignored/leaked, making this kind of API a strong case for use of > owner<>. Sprinkling owner<> over our code-base will not magically improve any of this. > If the Qt low-level smart pointer do not support gsl::owner, then we impair > users that wish to use the GSL in their own code from using it, because Qt > code will throw false positives. Everybody is free to use the STL smart pointers and be done with it. GSL users will be comfortable with those classes. Considering that you will get a warning from each and every widget in a dialog you are probably not going to use enforce GSL owner semantics in a Qt application anyway. Best Regards, Tobias From thiago.macieira at intel.com Fri Dec 2 17:55:21 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 02 Dec 2016 08:55:21 -0800 Subject: [Development] Fwd: REMINDER: Call for Proposals - ELC + OpenIoT Summit NA 2017; 1 Week Left to Submit Message-ID: <2833396.eIMjoEtmp3@tjmaciei-mobl1> Quick reminder for Embedded Linux Conference and OpenIoT Summit North America 2017. They'll be here in Portland. Quick link: http://events.linuxfoundation.org/cfp/dashboard -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center -------------- next part -------------- An embedded message was scrubbed... From: Linux Foundation Events Subject: REMINDER: Call for Proposals - ELC + OpenIoT Summit NA 2017; 1 Week Left to Submit Date: Thu, 01 Dec 2016 13:12:00 -0600 Size: 30085 URL: From kevin.kofler at chello.at Sat Dec 3 00:36:48 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 03 Dec 2016 00:36:48 +0100 Subject: [Development] New library in qtbase References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> <2976940.gPpOHW8DdO@tjmaciei-mobl1> <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> <5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io> <938B8FC5-626C-47B1-BB12-6017C475490A@edeltech.ch> <357754E1-D65A-4037-948D-CCDA582D2D97@qt.io> Message-ID: Shawn Rutledge wrote: > http://www.galago-project.org/about.php > > sounds like it’s just for “presence” to tell instant-messaging clients > whether you are using the computer or not. I did not suggest you use the Galago software, just this specification: https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html older versions of which were hosted on: http://www.galago-project.org/specs/notification/ (which is how it came to be known as the "Galago (notification) spec"). If you want to use an existing library, libnotify is what you are looking for: https://developer.gnome.org/libnotify/ All these are GNOME URLs, but the protocol is also supported by KDE Plasma and by other desktop environments: https://wiki.archlinux.org/index.php/Desktop_notifications Kevin Kofler From samuel.gaist at edeltech.ch Sun Dec 4 00:16:20 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Sun, 4 Dec 2016 00:16:20 +0100 Subject: [Development] New library in qtbase In-Reply-To: <3150359.ivMQHeSVmh@tjmaciei-mobl1> References: <2976940.gPpOHW8DdO@tjmaciei-mobl1> <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> <3150359.ivMQHeSVmh@tjmaciei-mobl1> Message-ID: <98329731-3407-4520-BD74-FE5EBEC5AB4E@edeltech.ch> > On 29 Nov 2016, at 09:31, Thiago Macieira wrote: > > On terça-feira, 29 de novembro de 2016 09:07:47 PST Samuel Gaist wrote: >>> On 27 Nov 2016, at 20:44, Thiago Macieira >>> wrote:> >>> On domingo, 27 de novembro de 2016 20:22:25 PST Samuel Gaist wrote: >>>> Currently there’s macOS and iOS already working. >>>> >>>> The plan is to add >>>> - Android >>>> - Linux through DBus >>>> - Win10 (there will be some constraints if I understood their >>>> documentation >>>> correctly) >>> >>> How about the older X11 / XEmbed way? >> >> I was writing the list from memory and I forgot that one. >> >> I haven’t took a deep look yet at it but I don’t see any reason to not have >> it. > > So it really looks like this should be part of QtGui with implementation in > each QPA plugin. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > In the case of Linux, if I understood the situation correctly, there might be several backends possible which is unlikely on other platforms expect for Growl but it’s not “native” and doesn’t look actively maintained currently although it’s still working AFAIK. Thus what would be the recommended architecture ? The first 2 rounds of implementation were run time based while the last, following the comments on gerrit, is build time based. From peter-qt at hartmann.tk Sun Dec 4 22:28:16 2016 From: peter-qt at hartmann.tk (Peter Hartmann) Date: Sun, 4 Dec 2016 22:28:16 +0100 Subject: [Development] Qt in Google's OSS-Fuzz Message-ID: <8aeb89b0-4cac-d205-4b9c-d022d75fc433@hartmann.tk> Hello, after Google announced their continuous fuzzing approach some days ago (see [1]), I tried to make Qt work with it and the fuzzing testcases I have written the last weeks ([2]). If people agree, we could try going forward with putting Qt onto OSS-Fuzz as well. I am almost there with setting it up ([3]), and once this is done I don't expect a lot of maintenance. The fuzzing test cases ([2]) could be hosted as a Qt playground project instead of github if desired. As a side note, this platform already contains libraries that Qt uses, e.g. OpenSSL, zlib, harfbuzz, ICU and others. Regards, Peter [1] https://testing.googleblog.com/2016/12/announcing-oss-fuzz-continuous-fuzzing.html [2] https://github.com/peter-ha/qt-fuzzing [3] https://github.com/peter-ha/oss-fuzz/tree/qt -- Peter Hartmann // Titurelstrasse 2 // 89125 Munich // Germany peter at hartmann.tk www.peter.hartmann.tk From kde at carewolf.com Mon Dec 5 13:23:45 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Mon, 5 Dec 2016 13:23:45 +0100 Subject: [Development] Nominating Konstantin Tokarev for Approver status Message-ID: <201612051323.45933.kde@carewolf.com> Hi all, I just noticed Konstantin Tokarev who has been doing most of the development, and practical maintenance of QtWebKit after it moved into "removed" state is still missing reviewer status. I suggest we correct this. Besides his work in the official qtwebkit branch, he also doing the QtWebKit- NG project trying to make a new updated QtWebKit module with a recent upstream WebKit. Here are his recent merged commits: https://codereview.qt-project.org/#/q/owner:"Konstantin+Tokarev"+status:merged,n,z And reviews: https://codereview.qt-project.org/#/q/reviewer:"Konstantin+Tokarev",n,z Best regards `Allan From Simon.Hausmann at qt.io Mon Dec 5 13:50:56 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 5 Dec 2016 12:50:56 +0000 Subject: [Development] Nominating Konstantin Tokarev for Approver status In-Reply-To: <201612051323.45933.kde@carewolf.com> References: <201612051323.45933.kde@carewolf.com> Message-ID: +1 Simon ________________________________ From: Development on behalf of Allan Sandfeld Jensen Sent: Monday, December 5, 2016 1:23:45 PM To: development at qt-project.org Subject: [Development] Nominating Konstantin Tokarev for Approver status Hi all, I just noticed Konstantin Tokarev who has been doing most of the development, and practical maintenance of QtWebKit after it moved into "removed" state is still missing reviewer status. I suggest we correct this. Besides his work in the official qtwebkit branch, he also doing the QtWebKit- NG project trying to make a new updated QtWebKit module with a recent upstream WebKit. Here are his recent merged commits: https://codereview.qt-project.org/#/q/owner:"Konstantin+Tokarev"+status:merged,n,z And reviews: https://codereview.qt-project.org/#/q/reviewer:"Konstantin+Tokarev",n,z Best regards `Allan _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Mon Dec 5 13:58:32 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 5 Dec 2016 12:58:32 +0000 Subject: [Development] Nominating Konstantin Tokarev for Approver status In-Reply-To: References: <201612051323.45933.kde@carewolf.com> Message-ID: +1 from me as well. Cheers, Lars From: Development on behalf of Simon Hausmann Date: Monday, 5 December 2016 at 13:50 To: Allan Sandfeld Jensen , Qt development mailing list Subject: Re: [Development] Nominating Konstantin Tokarev for Approver status +1 Simon ________________________________ From: Development on behalf of Allan Sandfeld Jensen Sent: Monday, December 5, 2016 1:23:45 PM To: development at qt-project.org Subject: [Development] Nominating Konstantin Tokarev for Approver status Hi all, I just noticed Konstantin Tokarev who has been doing most of the development, and practical maintenance of QtWebKit after it moved into "removed" state is still missing reviewer status. I suggest we correct this. Besides his work in the official qtwebkit branch, he also doing the QtWebKit- NG project trying to make a new updated QtWebKit module with a recent upstream WebKit. Here are his recent merged commits: https://codereview.qt-project.org/#/q/owner:"Konstantin+Tokarev"+status:merged,n,z And reviews: https://codereview.qt-project.org/#/q/reviewer:"Konstantin+Tokarev",n,z Best regards `Allan _______________________________________________ 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 milian.wolff at kdab.com Mon Dec 5 14:07:38 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 05 Dec 2016 14:07:38 +0100 Subject: [Development] Nominating Konstantin Tokarev for Approver status In-Reply-To: <201612051323.45933.kde@carewolf.com> References: <201612051323.45933.kde@carewolf.com> Message-ID: <1748974.2XU6s7y2pJ@milian-kdab2> On Monday, December 5, 2016 1:23:45 PM CET Allan Sandfeld Jensen wrote: > Hi all, > > I just noticed Konstantin Tokarev who has been doing most of the > development, and practical maintenance of QtWebKit after it moved into > "removed" state is still missing reviewer status. I suggest we correct > this. > > Besides his work in the official qtwebkit branch, he also doing the > QtWebKit- NG project trying to make a new updated QtWebKit module with a > recent upstream WebKit. > > Here are his recent merged commits: > https://codereview.qt-project.org/#/q/owner:"Konstantin+Tokarev"+status:merg > ed,n,z > > And reviews: > https://codereview.qt-project.org/#/q/reviewer:"Konstantin+Tokarev",n,z big +1 from my side as well! -- 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 sergio.martins at kdab.com Mon Dec 5 14:09:27 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Mon, 05 Dec 2016 13:09:27 +0000 Subject: [Development] Nominating Konstantin Tokarev for Approver status In-Reply-To: <201612051323.45933.kde@carewolf.com> References: <201612051323.45933.kde@carewolf.com> Message-ID: On 2016-12-05 12:23, Allan Sandfeld Jensen wrote: > Hi all, > > I just noticed Konstantin Tokarev who has been doing most of the > development, > and practical maintenance of QtWebKit after it moved into "removed" > state is > still missing reviewer status. I suggest we correct this. +1 Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From milian.wolff at kdab.com Mon Dec 5 14:11:08 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 05 Dec 2016 14:11:08 +0100 Subject: [Development] Qt in Google's OSS-Fuzz In-Reply-To: <8aeb89b0-4cac-d205-4b9c-d022d75fc433@hartmann.tk> References: <8aeb89b0-4cac-d205-4b9c-d022d75fc433@hartmann.tk> Message-ID: <3094319.Bu8hqUTyNc@milian-kdab2> On Sunday, December 4, 2016 10:28:16 PM CET Peter Hartmann wrote: > Hello, > > after Google announced their continuous fuzzing approach some days ago > (see [1]), I tried to make Qt work with it and the fuzzing testcases I > have written the last weeks ([2]). > > If people agree, we could try going forward with putting Qt onto > OSS-Fuzz as well. I am almost there with setting it up ([3]), and once > this is done I don't expect a lot of maintenance. > > The fuzzing test cases ([2]) could be hosted as a Qt playground project > instead of github if desired. > > As a side note, this platform already contains libraries that Qt uses, > e.g. OpenSSL, zlib, harfbuzz, ICU and others. I'd like to see that happen, more testing is always a win. But we will need to learn from the coverity lessons: - make sure from the start that multiple people in the qt community know how to update the tests (and qt version), and access the results - make sure that qt security list gets notified about potential securitiy issues found therein Peppe (CC'ed) has also just recently looked into fuzzing, he probably has something to add. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From jturcotte at woboq.com Mon Dec 5 14:24:24 2016 From: jturcotte at woboq.com (Jocelyn Turcotte) Date: Mon, 5 Dec 2016 14:24:24 +0100 Subject: [Development] Nominating Konstantin Tokarev for Approver status In-Reply-To: <201612051323.45933.kde@carewolf.com> References: <201612051323.45933.kde@carewolf.com> Message-ID: <18221D96-F6A9-4585-AC58-0D3EB9C9AFF6@woboq.com> > On 5 Dec 2016, at 13:23, Allan Sandfeld Jensen wrote: > > Hi all, > > I just noticed Konstantin Tokarev who has been doing most of the development, > and practical maintenance of QtWebKit after it moved into "removed" state is > still missing reviewer status. I suggest we correct this. +1! From alexander.blasche at qt.io Mon Dec 5 15:05:34 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Mon, 5 Dec 2016 14:05:34 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_Antti_M=E4=E4tt=E4_as_Qt?= =?iso-8859-1?q?3D_approver?= In-Reply-To: References: <3379777.7RlVj0Nj30@454> <4625893.daMKahMxrn@cartman>, Message-ID: Congratulations to Antti Määttä. Approver rights have been set. -- Alex ________________________________________ From: Development on behalf of Pasi Keränen Sent: Tuesday, 15 November 2016 6:16:06 AM To: Sean Harmer; development at qt-project.org Subject: Re: [Development] Nominating Antti Määttä as Qt3D approver +1 from me as well. Regards, Pasi On 14/11/16 17:19, "Development on behalf of Sean Harmer" wrote: On Monday 14 November 2016 15:15:16 Paul Lemire wrote: > Hi > > I would like to propose the nomination of Antti Määttä for approver status. > Antti has been contributing many patches to Qt3D adding new features and > providing bug fixes. In addition, having another approver would be a great > help to reduce the amount of time patches are spent awaiting a review. +1 from me. Cheers, Sean _______________________________________________ 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 gunnar.roth at gmx.de Mon Dec 5 15:42:25 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Mon, 5 Dec 2016 15:42:25 +0100 Subject: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression Message-ID: An HTML attachment was scrubbed... URL: From Friedemann.Kleint at qt.io Mon Dec 5 16:35:36 2016 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Mon, 5 Dec 2016 16:35:36 +0100 Subject: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression In-Reply-To: References: Message-ID: Hi, >My try to build qt 5.8.0 from git using vs2017 rc (CL 19.10.24629) failed already when building configure. (commit 2c27ccd1c9a821edd071cae6336ecb2066ce2ab7) >the qt 5.8 beta did work. Using CL 19.00.24213.1 (vs2015 upd3 + kb) also works. >does anyone have the same problem? Probably constexpr was activated for this compiler but not tested. Please make sure you have "Fixed build using Visual Studio 2017" a103992f49045323a3aaa4970eb1ee5f65a378dd https://codereview.qt-project.org/#/c/177743/ applied. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH From gunnar.roth at gmx.de Mon Dec 5 17:18:29 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Mon, 5 Dec 2016 17:18:29 +0100 Subject: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression In-Reply-To: References: , Message-ID: An HTML attachment was scrubbed... URL: From frederik.gladhorn at qt.io Mon Dec 5 18:16:57 2016 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 05 Dec 2016 18:16:57 +0100 Subject: [Development] Nominating Konstantin Tokarev for Approver status In-Reply-To: <201612051323.45933.kde@carewolf.com> References: <201612051323.45933.kde@carewolf.com> Message-ID: <5004066.iY2pasf3tg@frederik-thinkcentre-m93p> On mandag 5. desember 2016 13.23.45 CET Allan Sandfeld Jensen wrote: > Hi all, > > I just noticed Konstantin Tokarev who has been doing most of the > development, and practical maintenance of QtWebKit after it moved into > "removed" state is still missing reviewer status. I suggest we correct > this. And another +1 from my side, Konstantin is doing great work :) Frederik > > Besides his work in the official qtwebkit branch, he also doing the > QtWebKit- NG project trying to make a new updated QtWebKit module with a > recent upstream WebKit. > > Here are his recent merged commits: > https://codereview.qt-project.org/#/q/owner:"Konstantin+Tokarev"+status:merg > ed,n,z > > And reviews: > https://codereview.qt-project.org/#/q/reviewer:"Konstantin+Tokarev",n,z > > Best regards > `Allan > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From perezmeyer at gmail.com Mon Dec 5 19:46:43 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 05 Dec 2016 15:46:43 -0300 Subject: [Development] Tagging private symbols as such Message-ID: <4328581.XPRJ7y2mly@tonks> Hi! Some time ago Thiago made possible to tag private symbols as such, at least on Linux. We have found some more symbols that need this tag (QTBUG-57060) and I'm tracking a possible new set on fcitx-qt5. I would love to try and patch this but I definitely can't remember what was the tag that one should add to the right .pro file in order to get this achieved. Can anyone help my bad memory here? Thanks in advance, Lisandro. -- No pienses que estoy loco, es sólo una manera de actuar De mí - Charly García Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Mon Dec 5 20:07:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Dec 2016 11:07:41 -0800 Subject: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression In-Reply-To: References: Message-ID: <8417395.CmZkJoKjlO@tjmaciei-mobl1> Em segunda-feira, 5 de dezembro de 2016, às 15:42:25 PST, Gunnar Roth escreveu: > Hello, > My try to build qt 5.8.0 from git using vs2017 rc (CL 19.10.24629) failed > already when building configure. (commit > 2c27ccd1c9a821edd071cae6336ecb2066ce2ab7) the qt 5.8 beta did work. Using > CL 19.00.24213.1 (vs2015 upd3 + kb) also works. does anyone have the same > problem? Probably constexpr was activated for this compiler but not tested. 5.8 beta is too old. Pleaase upgrade to the latest 5.8.0 branch. From the other email: > Ok thank you Friedeman, > so > $ cd qt5 > $ perl init-repository > $ git checkout 5.8.0 > $ git submodule update > is not the correct way to get latest 5.8.0 from git? > > But what is the correct way then? It is, but it's possible that the qt5 link to qtbase is outdated due to having failed to integrate. You need to update qtbase to the 5.8.0 branch, even past what qt5 requires of you. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Dec 5 20:13:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Dec 2016 11:13:59 -0800 Subject: [Development] Tagging private symbols as such In-Reply-To: <4328581.XPRJ7y2mly@tonks> References: <4328581.XPRJ7y2mly@tonks> Message-ID: <2614753.Msd75lRBqX@tjmaciei-mobl1> Em segunda-feira, 5 de dezembro de 2016, às 15:46:43 PST, Lisandro Damián Nicanor Pérez Meyer escreveu: > Hi! Some time ago Thiago made possible to tag private symbols as such, at > least on Linux. We have found some more symbols that need this tag > (QTBUG-57060) and I'm tracking a possible new set on fcitx-qt5. > > I would love to try and patch this but I definitely can't remember what was > the tag that one should add to the right .pro file in order to get this > achieved. Can anyone help my bad memory here? I'm not sure the QPA symbols should be marked as private API. But maybe they should be. Anyway, there's no tag. It really depends on the scanning done by the mkspecs/features/data/unix/findclasslist.pl. It is given the header list by mkspecs/features/qt_module.prf, which in turn uses the list creatd by syncqt.pl and stored in include//headers.pri. The code in qt_module.prf does not take QPA into account. It assumes that a module only has private headers and non-private headers, which doesn't hold true for QtGui. Try adding SYNCQT.QPA_HEADER_FILES to: for(header, SYNCQT.PRIVATE_HEADER_FILES): \ verscript_content += " @FILE:$${_PRO_FILE_PWD_}/$$header@" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From gunnar.roth at gmx.de Tue Dec 6 00:00:20 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 6 Dec 2016 00:00:20 +0100 Subject: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression In-Reply-To: <8417395.CmZkJoKjlO@tjmaciei-mobl1> References: <8417395.CmZkJoKjlO@tjmaciei-mobl1> Message-ID: <1076B34F-162C-4275-A697-931A08D94F18@gmx.de> > Am 05.12.2016 um 20:07 schrieb Thiago Macieira : > > Em segunda-feira, 5 de dezembro de 2016, às 15:42:25 PST, Gunnar Roth > escreveu: >> Hello, >> My try to build qt 5.8.0 from git using vs2017 rc (CL 19.10.24629) failed >> already when building configure. (commit >> 2c27ccd1c9a821edd071cae6336ecb2066ce2ab7) the qt 5.8 beta did work. Using >> CL 19.00.24213.1 (vs2015 upd3 + kb) also works. does anyone have the same >> problem? Probably constexpr was activated for this compiler but not tested. > > 5.8 beta is too old. Pleaase upgrade to the latest 5.8.0 branch. Sure thats why i tried using the version from git. > > From the other email: >> Ok thank you Friedeman, >> so >> $ cd qt5 >> $ perl init-repository >> $ git checkout 5.8.0 >> $ git submodule update >> is not the correct way to get latest 5.8.0 from git? >> >> But what is the correct way then? > > It is, but it's possible that the qt5 link to qtbase is outdated due to having > failed to integrate. You need to update qtbase to the 5.8.0 branch, even past > what qt5 requires of you. i did git checkout 5.8 git submodule update which compiled then. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Dec 6 00:55:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 05 Dec 2016 15:55:55 -0800 Subject: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression In-Reply-To: <1076B34F-162C-4275-A697-931A08D94F18@gmx.de> References: <8417395.CmZkJoKjlO@tjmaciei-mobl1> <1076B34F-162C-4275-A697-931A08D94F18@gmx.de> Message-ID: <1503310.JUlZeBN0je@tjmaciei-mobl1> Em terça-feira, 6 de dezembro de 2016, às 00:00:20 PST, Gunnar Roth escreveu: > > It is, but it's possible that the qt5 link to qtbase is outdated due to > > having failed to integrate. You need to update qtbase to the 5.8.0 > > branch, even past what qt5 requires of you. > > i did git checkout 5.8 git submodule update which compiled then. That's not enough. You need to cd qtbase && git checkout 5.8.0 Possibly pull every now and again in there. If you need to be in the bleeding edge, git submodule update is the wrong tool. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mitya57.ml at gmail.com Tue Dec 6 11:59:58 2016 From: mitya57.ml at gmail.com (Dmitry Shachnev) Date: Tue, 6 Dec 2016 13:59:58 +0300 Subject: [Development] New library in qtbase In-Reply-To: References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> <2976940.gPpOHW8DdO@tjmaciei-mobl1> <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> <5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io> <938B8FC5-626C-47B1-BB12-6017C475490A@edeltech.ch> <357754E1-D65A-4037-948D-CCDA582D2D97@qt.io> Message-ID: <20161206105958.pip2zch37zn3efdw@mitya57.me> On Sat, Dec 03, 2016 at 12:36:48AM +0100, Kevin Kofler wrote: > I did not suggest you use the Galago software, just this specification: > https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html > older versions of which were hosted on: > http://www.galago-project.org/specs/notification/ > (which is how it came to be known as the "Galago (notification) spec"). > > If you want to use an existing library, libnotify is what you are looking > for: > https://developer.gnome.org/libnotify/ It is better to re-use the existing code in qtbase, rather than relying on a 3rdparty library: https://code.qt.io/cgit/qt/qtbase.git/tree/src/platformsupport/themes/genericunix/dbustray/qxdgnotificationproxy_p.h -- Dmitry Shachnev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From giuseppe.dangelo at kdab.com Tue Dec 6 12:45:55 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 6 Dec 2016 11:45:55 +0000 Subject: [Development] Qt in Google's OSS-Fuzz In-Reply-To: <8aeb89b0-4cac-d205-4b9c-d022d75fc433@hartmann.tk> References: <8aeb89b0-4cac-d205-4b9c-d022d75fc433@hartmann.tk> Message-ID: <80e7c616-fa38-8422-cbae-77e7011fd29b@kdab.com> On 04/12/16 21:28, Peter Hartmann wrote: > after Google announced their continuous fuzzing approach some days ago > (see [1]), I tried to make Qt work with it and the fuzzing testcases I > have written the last weeks ([2]). > > If people agree, we could try going forward with putting Qt onto > OSS-Fuzz as well. I am almost there with setting it up ([3]), and once > this is done I don't expect a lot of maintenance. > > The fuzzing test cases ([2]) could be hosted as a Qt playground project > instead of github if desired. I'm all for it, and I think we should fuzz all sorts of "parsers" inside Qt (HTTP, JSON, image formats, CSS, HTML, ...). My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From peter-qt at hartmann.tk Tue Dec 6 13:14:45 2016 From: peter-qt at hartmann.tk (Peter Hartmann) Date: Tue, 6 Dec 2016 13:14:45 +0100 Subject: [Development] Qt in Google's OSS-Fuzz In-Reply-To: <80e7c616-fa38-8422-cbae-77e7011fd29b@kdab.com> References: <8aeb89b0-4cac-d205-4b9c-d022d75fc433@hartmann.tk> <80e7c616-fa38-8422-cbae-77e7011fd29b@kdab.com> Message-ID: On 06.12.2016 12:45, Giuseppe D'Angelo wrote: > I'm all for it, and I think we should fuzz all sorts of "parsers" inside > Qt (HTTP, JSON, image formats, CSS, HTML, ...). good idea, as I said we could host the tests as a playground project or so and let people add more test cases... To address Milian's other comments, building Qt and checking out the right version etc. would be hosted inside Google's repos (see e.g. the build script for curl: https://github.com/google/oss-fuzz/blob/master/projects/curl/build.sh); they also provide tools and documentation on how to run this locally. We could make the security mailing list the direct email contact in case issues are found; I just don't know how much noise this would produce. Anyhow I think we could find a solution that works for everybody... Peter -- Peter Hartmann // Titurelstrasse 2 // 89125 Munich // Germany peter at hartmann.tk www.peter.hartmann.tk From perezmeyer at gmail.com Tue Dec 6 14:50:19 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 06 Dec 2016 10:50:19 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <2614753.Msd75lRBqX@tjmaciei-mobl1> References: <4328581.XPRJ7y2mly@tonks> <2614753.Msd75lRBqX@tjmaciei-mobl1> Message-ID: <2054151.hLXXNGcMKb@tonks> On lunes, 5 de diciembre de 2016 11:13:59 ART Thiago Macieira wrote: > Em segunda-feira, 5 de dezembro de 2016, às 15:46:43 PST, Lisandro Damián > > Nicanor Pérez Meyer escreveu: > > Hi! Some time ago Thiago made possible to tag private symbols as such, at > > least on Linux. We have found some more symbols that need this tag > > (QTBUG-57060) and I'm tracking a possible new set on fcitx-qt5. > > > > I would love to try and patch this but I definitely can't remember what > > was > > the tag that one should add to the right .pro file in order to get this > > achieved. Can anyone help my bad memory here? > > I'm not sure the QPA symbols should be marked as private API. But maybe they > should be. Well, at least from a packager's point of view they are shipped in a versioned path (/usr/include/QtGui/5.x.y/QtGui/qpa/*) and are one of the most used private headers by third parties, which we need to keep track of. > Anyway, there's no tag. It really depends on the scanning done by the > mkspecs/features/data/unix/findclasslist.pl. It is given the header list by > mkspecs/features/qt_module.prf, which in turn uses the list creatd by > syncqt.pl and stored in include//headers.pri. > > The code in qt_module.prf does not take QPA into account. It assumes that a > module only has private headers and non-private headers, which doesn't hold > true for QtGui. > > Try adding SYNCQT.QPA_HEADER_FILES to: > > for(header, SYNCQT.PRIVATE_HEADER_FILES): \ > verscript_content += " @FILE:$${_PRO_FILE_PWD_}/$$header@" Excellent, will give it a try. Thanks a lot! -- Los comentarios o respuestas sobre SL en tono absolutista solo hacen aparecer a la comunidad SL como una sarta de fanáticos que viven dentro de un tupperware. Pablo Di Noto - GrULiC Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From Shawn.Rutledge at qt.io Tue Dec 6 15:44:11 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 6 Dec 2016 14:44:11 +0000 Subject: [Development] New library in qtbase In-Reply-To: References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> <2976940.gPpOHW8DdO@tjmaciei-mobl1> <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> <5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io> <938B8FC5-626C-47B1-BB12-6017C475490A@edeltech.ch> <357754E1-D65A-4037-948D-CCDA582D2D97@qt.io> Message-ID: > On 3 Dec 2016, at 00:36, Kevin Kofler wrote: > > Shawn Rutledge wrote: >> http://www.galago-project.org/about.php >> >> sounds like it’s just for “presence” to tell instant-messaging clients >> whether you are using the computer or not. > > I did not suggest you use the Galago software, just this specification: > https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-latest.html > older versions of which were hosted on: > http://www.galago-project.org/specs/notification/ > (which is how it came to be known as the "Galago (notification) spec”). That page doesn’t mention Galago. Anyway org.freedesktop.Notifications is the specification we are already using in qtbase/src/platformsupport/dbustray. But we know that increasingly notifications are being used independently from tray icons, and that basically every platform has some kind of notifications, so maybe we’ll end up with another Qt API for that eventually. It’s unintuitive that if you only want to show notifications but don’t need a tray icon, you have to use QSystemTrayIcon::showMessage(). > If you want to use an existing library, libnotify is what you are looking > for: > https://developer.gnome.org/libnotify/ Well why should Qt depend on another library which does the D-Bus communication in its own way, when we already have Qt D-Bus? > All these are GNOME URLs, but the protocol is also supported by KDE Plasma > and by other desktop environments: > https://wiki.archlinux.org/index.php/Desktop_notifications Yeah, that was the idea of implementing it that way, to get it working on Gnome and Ubuntu and KDE. From gunnar.roth at gmx.de Tue Dec 6 15:53:37 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 6 Dec 2016 15:53:37 +0100 Subject: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression In-Reply-To: <1503310.JUlZeBN0je@tjmaciei-mobl1> References: <8417395.CmZkJoKjlO@tjmaciei-mobl1> <1076B34F-162C-4275-A697-931A08D94F18@gmx.de>, <1503310.JUlZeBN0je@tjmaciei-mobl1> Message-ID: Hi Thiago, now I get confused. >That's not enough. You need to >cd qtbase && git checkout 5.8.0   When I do this I get the old code which does not compile. Doing cd qtbase && git checkout 5.8 gives me the new code   >Possibly pull every now and again in there. If you need to be in the bleeding >edge, git submodule update is the wrong tool. So what is the right tool? Why is is mentioned in the qt5 wiki Building from git? I also have seen that I didnt get qtvirtualkeyboard just an empty directory. using perl init-repository --module-subset=qtvirtualkeyboard -f i get it it, but also message that the other folder are removed. doing perl init-repository -f again. But how is it supposed to work? How do I get the code which will become the release candidate? Do I need to wait for a label? Regards, Gunnar Roth From hrvoje.senjan at gmail.com Tue Dec 6 16:22:39 2016 From: hrvoje.senjan at gmail.com (=?utf-8?B?xaF1bXNraQ==?=) Date: Tue, 06 Dec 2016 16:22:39 +0100 Subject: [Development] Tagging private symbols as such In-Reply-To: <4328581.XPRJ7y2mly@tonks> References: <4328581.XPRJ7y2mly@tonks> Message-ID: <15932031.fRQlK9K3W8@shumarija> On ponedjeljak, 5. prosinca 2016. 15:46:43 CET Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! Some time ago Thiago made possible to tag private symbols as such, at > least on Linux. We have found some more symbols that need this tag > (QTBUG-57060) and I'm tracking a possible new set on fcitx-qt5. > > I would love to try and patch this but I definitely can't remember what was > the tag that one should add to the right .pro file in order to get this > achieved. Can anyone help my bad memory here? > > Thanks in advance, Lisandro. We're using this[1] in openSUSE. Cheers, Hrvoje -------- [1] https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/libqt5-qtbase/tell-the-truth-about-private-api.patch?expand=1 From thiago.macieira at intel.com Tue Dec 6 17:39:48 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Dec 2016 08:39:48 -0800 Subject: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression In-Reply-To: References: <1503310.JUlZeBN0je@tjmaciei-mobl1> Message-ID: <2951684.4mm0CXZdQE@tjmaciei-mobl1> On terça-feira, 6 de dezembro de 2016 15:53:37 PST Gunnar Roth wrote: > Hi Thiago, > now I get confused. > > >That's not enough. You need to > >cd qtbase && git checkout 5.8.0 > > When I do this I get the old code which does not compile. > Doing cd qtbase && git checkout 5.8 gives me the new code There are two branches: 5.8.0 and 5.8 (which will be 5.8.1). I'm not sure which one contains the fix, as I don't think we're considering MSVC 2017 as a priority platform. I can tell you 5.8 will have the fix, eventually, but it may not have it now. You're telling me that the fixes landed in 5.8 only. That's not unexpected. > >Possibly pull every now and again in there. If you need to be in the > >bleeding edge, git submodule update is the wrong tool. > > So what is the right tool? Why is is mentioned in the qt5 wiki Building from > git? I also have seen that I didnt get qtvirtualkeyboard just an empty > directory. using perl init-repository --module-subset=qtvirtualkeyboard -f > i get it it, but also message that the other folder are removed. > doing I do: git fetch --recurse-submodules=yes git submodule foreach git rebase (this is after setting each submodule on the 5.8 branch, or dev branch, or whichever it may be I am working on) As I said, this is the most bleeding edge (for a given branch). It means you'll be ahead of qt5.git, which is what was last guaranteed to compile and pass all tests. So by choosing to go to the bleeding edge, you may face issues that still need correcting. > But how is it supposed to work? How do I get the code which will become the > release candidate? Do I need to wait for a label? Here's the thing: you are getting it with git submodule update. You'll just get it slightly later than what the command above gives you. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Dec 6 17:41:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Dec 2016 08:41:38 -0800 Subject: [Development] Tagging private symbols as such In-Reply-To: <15932031.fRQlK9K3W8@shumarija> References: <4328581.XPRJ7y2mly@tonks> <15932031.fRQlK9K3W8@shumarija> Message-ID: <1590363.VnRi5a9kGd@tjmaciei-mobl1> On terça-feira, 6 de dezembro de 2016 16:22:39 PST šumski wrote: > On ponedjeljak, 5. prosinca 2016. 15:46:43 CET Lisandro Damián Nicanor Pérez > Meyer wrote: > > Hi! Some time ago Thiago made possible to tag private symbols as such, at > > least on Linux. We have found some more symbols that need this tag > > (QTBUG-57060) and I'm tracking a possible new set on fcitx-qt5. > > > > I would love to try and patch this but I definitely can't remember what > > was > > the tag that one should add to the right .pro file in order to get this > > achieved. Can anyone help my bad memory here? > > > > Thanks in advance, Lisandro. > > We're using this[1] in openSUSE. Contains: - verscript_content = "Qt_$${QT_MAJOR_VERSION}_PRIVATE_API {" \ + verscript_content = "Qt_$${QT_MAJOR_VERSION}.$${QT_MINOR_VERSION}.$$ {QT_PATCH_VERSION}_PRIVATE_API {" \ Do other people think that is useful? If so, I can make that permanent (though disabled for -developer-build). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From holger at freyther.de Tue Dec 6 18:43:05 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 6 Dec 2016 18:43:05 +0100 Subject: [Development] Qt in Google's OSS-Fuzz In-Reply-To: <3094319.Bu8hqUTyNc@milian-kdab2> References: <8aeb89b0-4cac-d205-4b9c-d022d75fc433@hartmann.tk> <3094319.Bu8hqUTyNc@milian-kdab2> Message-ID: <836A3D41-9F57-4535-BAA5-CB1A5725E26C@freyther.de> > On 05 Dec 2016, at 14:11, Milian Wolff wrote: Hi Milian, > I'd like to see that happen, more testing is always a win. But we will need to > learn from the coverity lessons: which lessons? Feel free to reply off-list. regards holger From holger at freyther.de Tue Dec 6 18:43:03 2016 From: holger at freyther.de (Holger Freyther) Date: Tue, 6 Dec 2016 18:43:03 +0100 Subject: [Development] Qt in Google's OSS-Fuzz In-Reply-To: <3094319.Bu8hqUTyNc@milian-kdab2> References: <8aeb89b0-4cac-d205-4b9c-d022d75fc433@hartmann.tk> <3094319.Bu8hqUTyNc@milian-kdab2> Message-ID: <76378706-6C1C-4F11-9B54-E11C6F785411@freyther.de> > On 05 Dec 2016, at 14:11, Milian Wolff wrote: Hi Milian, > I'd like to see that happen, more testing is always a win. But we will need to > learn from the coverity lessons: which lessons? Feel free to reply off-list. regards holger From milian.wolff at kdab.com Tue Dec 6 18:49:58 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Tue, 06 Dec 2016 18:49:58 +0100 Subject: [Development] Qt in Google's OSS-Fuzz In-Reply-To: <76378706-6C1C-4F11-9B54-E11C6F785411@freyther.de> References: <8aeb89b0-4cac-d205-4b9c-d022d75fc433@hartmann.tk> <3094319.Bu8hqUTyNc@milian-kdab2> <76378706-6C1C-4F11-9B54-E11C6F785411@freyther.de> Message-ID: <2291677.LrUx2OHQfU@milian-kdab2> On Tuesday, December 6, 2016 6:43:03 PM CET Holger Freyther wrote: > > On 05 Dec 2016, at 14:11, Milian Wolff wrote: > Hi Milian, > > > I'd like to see that happen, more testing is always a win. But we will > > need to > > learn from the coverity lessons: > > which lessons? Feel free to reply off-list. I have mostly the one in mind: That we need an active _group_ of people maintaining it. Afaik, until recently, the qt coverity reports did not get the love they needed. I.e. updates where infrequent and noone really bothered to look at the results either. This has changed, recently imo. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From perezmeyer at gmail.com Tue Dec 6 20:14:39 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 06 Dec 2016 16:14:39 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <1590363.VnRi5a9kGd@tjmaciei-mobl1> References: <4328581.XPRJ7y2mly@tonks> <15932031.fRQlK9K3W8@shumarija> <1590363.VnRi5a9kGd@tjmaciei-mobl1> Message-ID: <3114260.LjEi0BJEya@tonks> On martes, 6 de diciembre de 2016 08:41:38 ART Thiago Macieira wrote: > On terça-feira, 6 de dezembro de 2016 16:22:39 PST šumski wrote: > > On ponedjeljak, 5. prosinca 2016. 15:46:43 CET Lisandro Damián Nicanor > > Pérez> > > Meyer wrote: > > > Hi! Some time ago Thiago made possible to tag private symbols as such, > > > at > > > least on Linux. We have found some more symbols that need this tag > > > (QTBUG-57060) and I'm tracking a possible new set on fcitx-qt5. > > > > > > I would love to try and patch this but I definitely can't remember what > > > was > > > the tag that one should add to the right .pro file in order to get this > > > achieved. Can anyone help my bad memory here? > > > > > > Thanks in advance, Lisandro. > > > > We're using this[1] in openSUSE. > > Contains: > > - verscript_content = "Qt_$${QT_MAJOR_VERSION}_PRIVATE_API {" \ > + verscript_content = > "Qt_$${QT_MAJOR_VERSION}.$${QT_MINOR_VERSION}.$$ > {QT_PATCH_VERSION}_PRIVATE_API {" \ > > Do other people think that is useful? If so, I can make that permanent > (though disabled for -developer-build). I need to check. It might create lots of fuzz when dealing with symbols with our tools. But of course if other people find it usefull we can back-apply it. -- angasule: tenes el teletransportador encendido? :P si Yo no :-P lo arme con el PIC16F84, una batata y algo que estaba adentro de una zapatilla vieja angasule: yo tenia uno andando pero speedy te bloquea el puerto... Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Wed Dec 7 00:42:34 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 06 Dec 2016 20:42:34 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <15932031.fRQlK9K3W8@shumarija> References: <4328581.XPRJ7y2mly@tonks> <15932031.fRQlK9K3W8@shumarija> Message-ID: <3330618.aRuS2c1WIL@tonks> On martes, 6 de diciembre de 2016 16:22:39 ART šumski wrote: [snip] > [1] > https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/libqt5-qtba > se/tell-the-truth-about-private-api.patch?expand=1 Maybe there's a typo in line 28? I see a double ')' -- No hay preguntas tontas, solo tontos que no preguntan. personaje, en un mail del LugFi. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Wed Dec 7 00:44:06 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 06 Dec 2016 20:44:06 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <3114260.LjEi0BJEya@tonks> References: <4328581.XPRJ7y2mly@tonks> <1590363.VnRi5a9kGd@tjmaciei-mobl1> <3114260.LjEi0BJEya@tonks> Message-ID: <1519863.QrkxghlSRW@tonks> On martes, 6 de diciembre de 2016 16:14:39 ART you wrote: [snip] > > Contains: > > > > - verscript_content = "Qt_$${QT_MAJOR_VERSION}_PRIVATE_API {" \ > > + verscript_content = > > "Qt_$${QT_MAJOR_VERSION}.$${QT_MINOR_VERSION}.$$ > > {QT_PATCH_VERSION}_PRIVATE_API {" \ > > > > Do other people think that is useful? If so, I can make that permanent > > (though disabled for -developer-build). > > I need to check. It might create lots of fuzz when dealing with symbols with > our tools. But of course if other people find it usefull we can back-apply > it. If I understand the patch correctly that would effectively change the symbol version on each new patch release. That's something at least us in Debian would like to avoid, but again, if it's useful for someone else, we can always patch it out. -- If for every rule there is an exception, then we have established that there is an exception to every rule. If we accept "For every rule there is an exception" as a rule, then we must concede that there may not be an exception after all, since the rule states that there is always the possibility of exception, and if we follow it to its logical end we must agree that there can be an exception to the rule that for every rule there is an exception. Bill Boquist Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Wed Dec 7 01:26:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Dec 2016 16:26:41 -0800 Subject: [Development] Tagging private symbols as such In-Reply-To: <1519863.QrkxghlSRW@tonks> References: <4328581.XPRJ7y2mly@tonks> <3114260.LjEi0BJEya@tonks> <1519863.QrkxghlSRW@tonks> Message-ID: <43611360.gUn43JsshR@tjmaciei-mobl1> Em terça-feira, 6 de dezembro de 2016, às 20:44:06 PST, Lisandro Damián Nicanor Pérez Meyer escreveu: > If I understand the patch correctly that would effectively change the symbol > version on each new patch release. That's something at least us in Debian > would like to avoid, but again, if it's useful for someone else, we can > always patch it out. It would change the ELF version for private symbols. The idea, I guess, is that if you forgot to rebuild, then the old .so fails to load. With the same ELF version, it would load and may do bad things. I think I had thought of that when I originally came up with the idea, but discarded it. I know I don't want it in developer builds for the same reason that QObjectPrivate's constructor does not complain about mixing Qt versions in developer builds (see 5bf67f5f41ab110eb41ab74f2a87e649735af435 for the rationale). But unlike the QObjectPrivate check, changing the ELF version according to Qt version would render a -developer-build library binary- incompatible with a non-developer-build user. I may have had other reasons, but I don't remember them now. So I think it's not a good idea to apply the SUSE patch as-is. The QPA part makes sense, though. I wonder: do we want a different ELF version for the QPA bits, other than Qt_5_PRIVATE_API? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Wed Dec 7 01:28:16 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Tue, 06 Dec 2016 21:28:16 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <3330618.aRuS2c1WIL@tonks> References: <4328581.XPRJ7y2mly@tonks> <15932031.fRQlK9K3W8@shumarija> <3330618.aRuS2c1WIL@tonks> Message-ID: <1901184.jQ3BbVs8fK@tonks> On martes, 6 de diciembre de 2016 20:42:34 ART Lisandro Damián Nicanor Pérez Meyer wrote: > On martes, 6 de diciembre de 2016 16:22:39 ART šumski wrote: > [snip] > > > [1] > > https://build.opensuse.org/package/view_file/openSUSE:Leap:42.2/libqt5-qtb > > a > > se/tell-the-truth-about-private-api.patch?expand=1 > > Maybe there's a typo in line 28? I see a double ')' And indeed it does the correct thing. I'll push the QPA stuff to gerrit tomorrow (hopefully). -- The generation of random numbers is too important to be left to chance. http://www.devtopics.com/best-programming-jokes/ Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Wed Dec 7 02:01:06 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 07 Dec 2016 02:01:06 +0100 Subject: [Development] Tagging private symbols as such References: <4328581.XPRJ7y2mly@tonks> <15932031.fRQlK9K3W8@shumarija> <1590363.VnRi5a9kGd@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > Do other people think that is useful? If so, I can make that permanent > (though disabled for -developer-build). >From a Fedora perspective, yes. It will make RPM automatically produce symbol version dependencies that will correctly break when the package needs rebuilding, and thus should allow us to drop any manually added explicit RPM dependencies doing the same thing. Kevin Kofler From kevin.kofler at chello.at Wed Dec 7 02:23:15 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 07 Dec 2016 02:23:15 +0100 Subject: [Development] Tagging private symbols as such References: <4328581.XPRJ7y2mly@tonks> <3114260.LjEi0BJEya@tonks> <1519863.QrkxghlSRW@tonks> <43611360.gUn43JsshR@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > It would change the ELF version for private symbols. The idea, I guess, is > that if you forgot to rebuild, then the old .so fails to load. With the > same ELF version, it would load and may do bad things. Yes, but on RPM-based distributions, it would not even install, and the mismatch would be detected by our automated broken dependency checks. This is because RPM automatically scans ELF files for dependencies on versioned symbols and adds a dependency on the "soname(symbol version)" pair. (The actual symbol names are discarded because there would be just too many to track. And the version numbers are needed anyway because the symbol can also change its ABI without changing its name.) That is why OpenSUSE thinks this is useful, and at least I think it would benefit Fedora too. > I think I had thought of that when I originally came up with the idea, but > discarded it. I know I don't want it in developer builds for the same > reason that QObjectPrivate's constructor does not complain about mixing Qt > versions in developer builds (see 5bf67f5f41ab110eb41ab74f2a87e649735af435 > for the rationale). But unlike the QObjectPrivate check, changing the ELF > version according to Qt version would render a -developer-build library > binary- incompatible with a non-developer-build user. > > I may have had other reasons, but I don't remember them now. > > So I think it's not a good idea to apply the SUSE patch as-is. But applying it downstream in distribution packages should be OK in any case, shouldn't it? I don't think binary compatibility with upstream makes sense for private symbols which are not even guaranteed to be compatible between two upstream version. > I wonder: do we want a different ELF version for the QPA bits, other than > Qt_5_PRIVATE_API? IMHO, we want a versioned one, but in both cases. Distinguishing between QPA and other private bits does not really matter though, if they have the same (lack of) ABI guarantees. Kevin Kofler From thiago.macieira at intel.com Wed Dec 7 03:18:35 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 06 Dec 2016 18:18:35 -0800 Subject: [Development] Tagging private symbols as such In-Reply-To: References: <4328581.XPRJ7y2mly@tonks> <43611360.gUn43JsshR@tjmaciei-mobl1> Message-ID: <4498145.L5tUram0jQ@tjmaciei-mobl1> Em quarta-feira, 7 de dezembro de 2016, às 02:23:15 PST, Kevin Kofler escreveu: > > I think I had thought of that when I originally came up with the idea, but > > discarded it. I know I don't want it in developer builds for the same > > reason that QObjectPrivate's constructor does not complain about mixing Qt > > versions in developer builds (see 5bf67f5f41ab110eb41ab74f2a87e649735af435 > > for the rationale). But unlike the QObjectPrivate check, changing the ELF > > version according to Qt version would render a -developer-build library > > binary- incompatible with a non-developer-build user. > > > > I may have had other reasons, but I don't remember them now. > > > > So I think it's not a good idea to apply the SUSE patch as-is. > > But applying it downstream in distribution packages should be OK in any > case, shouldn't it? I don't think binary compatibility with upstream makes > sense for private symbols which are not even guaranteed to be compatible > between two upstream version. I would rather distros not produce binary-incompatible patches to upstream Qt. This is such a patch. And I was actually affected by it: I wanted to backport an XRandR bugfix to libQt5XcbQpa, so I just built my own check out of qtbase on the tag + cherry- pick. But the lib wouldn't load because the ELF versions were different. I had to install qmake & qtbase development files from the distro so it would build and load. I'd like to come to an agreement. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Wed Dec 7 06:59:32 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 07 Dec 2016 06:59:32 +0100 Subject: [Development] Tagging private symbols as such References: <4328581.XPRJ7y2mly@tonks> <43611360.gUn43JsshR@tjmaciei-mobl1> <4498145.L5tUram0jQ@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > And I was actually affected by it: I wanted to backport an XRandR bugfix > to libQt5XcbQpa, so I just built my own check out of qtbase on the tag + > cherry- pick. But the lib wouldn't load because the ELF versions were > different. I had to install qmake & qtbase development files from the > distro so it would build and load. The right way to test a backport of a patch to a distro package is really to export the patch from git, check out the distro source package (e.g. the SRPM, or its sources: specfile, tarball(s), patches if any), add the patch to the specfile (or equivalent) and rebuild the package (ideally using something like mock or debootstrap so that you build in a clean chroot without any self-built stuff). You would not recommend mixing different versions of Qt to a user either, would you? It is also a bad idea for a developer. So don't mix distro packages and self-built (from git sources) binaries, either use all self- built or all distro packages. Kevin Kofler From oswald.buddenhagen at qt.io Wed Dec 7 11:25:24 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 7 Dec 2016 11:25:24 +0100 Subject: [Development] git 5.8.0 build failure with vs 2017 rc error C3615: constexpr function 'QAlgorithmsPrivate::qt_builtin_ctz' cannot result in a constant exp ression In-Reply-To: References: <8417395.CmZkJoKjlO@tjmaciei-mobl1> <1076B34F-162C-4275-A697-931A08D94F18@gmx.de> <1503310.JUlZeBN0je@tjmaciei-mobl1> Message-ID: <20161207102524.GD11876@troll08> On Tue, Dec 06, 2016 at 03:53:37PM +0100, Gunnar Roth wrote: > >Possibly pull every now and again in there. If you need to be in the bleeding > >edge, git submodule update is the wrong tool. > > So what is the right tool? > init-repository -f --branch From perezmeyer at gmail.com Wed Dec 7 14:23:21 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 07 Dec 2016 10:23:21 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: References: <4328581.XPRJ7y2mly@tonks> <43611360.gUn43JsshR@tjmaciei-mobl1> Message-ID: <7123134.Sl9WmefQQV@tonks> On miércoles, 7 de diciembre de 2016 02:23:15 ART Kevin Kofler wrote: > Thiago Macieira wrote: [snip] > > I wonder: do we want a different ELF version for the QPA bits, other than > > Qt_5_PRIVATE_API? > > IMHO, we want a versioned one, but in both cases. Distinguishing between QPA > and other private bits does not really matter though, if they have the same > (lack of) ABI guarantees. The same could be said from the Debian side. If you find it useful to have a different ELF version we will just need to adjust a couple of scripts, but as long as we can determine that those are private symbols, everything is fine. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Wed Dec 7 14:37:27 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 07 Dec 2016 10:37:27 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <4498145.L5tUram0jQ@tjmaciei-mobl1> References: <4328581.XPRJ7y2mly@tonks> <4498145.L5tUram0jQ@tjmaciei-mobl1> Message-ID: <1519918.zPzpvdQfql@tonks> On martes, 6 de diciembre de 2016 18:18:35 ART Thiago Macieira wrote: > Em quarta-feira, 7 de dezembro de 2016, às 02:23:15 PST, Kevin Kofler escreveu: > > > I think I had thought of that when I originally came up with the idea, > > > but > > > discarded it. I know I don't want it in developer builds for the same > > > reason that QObjectPrivate's constructor does not complain about mixing > > > Qt > > > versions in developer builds (see > > > 5bf67f5f41ab110eb41ab74f2a87e649735af435 > > > for the rationale). But unlike the QObjectPrivate check, changing the > > > ELF > > > version according to Qt version would render a -developer-build library > > > binary- incompatible with a non-developer-build user. > > > > > > I may have had other reasons, but I don't remember them now. > > > > > > So I think it's not a good idea to apply the SUSE patch as-is. > > > > But applying it downstream in distribution packages should be OK in any > > case, shouldn't it? I don't think binary compatibility with upstream makes > > sense for private symbols which are not even guaranteed to be compatible > > between two upstream version. > > I would rather distros not produce binary-incompatible patches to upstream > Qt. This is such a patch. I do really understand both positions. Truth is that the same tools that helps us detect and follow this situation without the need to even recompile are the same tools that would increase our maintainance burden if we used this patch. Let me asset with my team mate how much more work it really means to us and see if we have some way to make everyone's life better. -- Passwords are like underwear. You shouldn’t leave them out where people can see them. You should change them regularly. And you shouldn’t loan them out to strangers. Anonymous Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From mitya57.ml at gmail.com Wed Dec 7 16:12:13 2016 From: mitya57.ml at gmail.com (Dmitry Shachnev) Date: Wed, 7 Dec 2016 18:12:13 +0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <43611360.gUn43JsshR@tjmaciei-mobl1> References: <4328581.XPRJ7y2mly@tonks> <3114260.LjEi0BJEya@tonks> <1519863.QrkxghlSRW@tonks> <43611360.gUn43JsshR@tjmaciei-mobl1> Message-ID: <20161207151213.65jkcclfq3b7bmae@mitya57.me> Hi Thiago, On Tue, Dec 06, 2016 at 04:26:41PM -0800, Thiago Macieira wrote: > So I think it's not a good idea to apply the SUSE patch as-is. The QPA part > makes sense, though. I also dislike this change. As Lisandro says, we do not want it in Debian (because we keep track of versions ourselves in the symbols file, and when the versions are in the symbols themselves they are just useless noise for us). And as you say, you do not want distributions Qt builds to be ABI incompatible with upstream (we also would like to avoid that), so if this patch gets applied upstream, we will be in a bad situation. I wonder what was the reason for OpenSUSE to have this change — I could not find a relevant changelog entry. Why cannot they just rebuild all packages using private headers for every Qt release, like we do? > I wonder: do we want a different ELF version for the QPA bits, other than > Qt_5_PRIVATE_API? I think Qt_5_PRIVATE_API is enough. (But I won't mind if something different is used, provided that it does not change from release to release.) -- Dmitry Shachnev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From thiago.macieira at intel.com Wed Dec 7 17:02:20 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 07 Dec 2016 08:02:20 -0800 Subject: [Development] Tagging private symbols as such In-Reply-To: <20161207151213.65jkcclfq3b7bmae@mitya57.me> References: <4328581.XPRJ7y2mly@tonks> <43611360.gUn43JsshR@tjmaciei-mobl1> <20161207151213.65jkcclfq3b7bmae@mitya57.me> Message-ID: <3976954.qf18LPJo2m@tjmaciei-mobl1> On quarta-feira, 7 de dezembro de 2016 18:12:13 PST Dmitry Shachnev wrote: > I wonder what was the reason for OpenSUSE to have this change — I could not > find a relevant changelog entry. Why cannot they just rebuild all packages > using private headers for every Qt release, like we do? My guess is that they can and they do. But the extra versioning is a further safety check: if something was missed in the update, like for example some code compiled by the user (regardless of use of package management), it will necessarily stop working. And if it used package management, it will not install, or it will prevent upgrade until it is provided in a new version. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Wed Dec 7 18:01:01 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 07 Dec 2016 14:01:01 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <3976954.qf18LPJo2m@tjmaciei-mobl1> References: <4328581.XPRJ7y2mly@tonks> <20161207151213.65jkcclfq3b7bmae@mitya57.me> <3976954.qf18LPJo2m@tjmaciei-mobl1> Message-ID: <1758019.35GhEEstaU@tonks> On miércoles, 7 de diciembre de 2016 08:02:20 ART Thiago Macieira wrote: > On quarta-feira, 7 de dezembro de 2016 18:12:13 PST Dmitry Shachnev wrote: > > I wonder what was the reason for OpenSUSE to have this change — I could > > not > > find a relevant changelog entry. Why cannot they just rebuild all packages > > using private headers for every Qt release, like we do? > > My guess is that they can and they do. > > But the extra versioning is a further safety check: if something was missed > in the update, like for example some code compiled by the user (regardless > of use of package management), it will necessarily stop working. Truth, although we haven't received any complaints about this so far. > And if it > used package management, it will not install, or it will prevent upgrade > until it is provided in a new version. That's already covered at least in our case. So from my side: +1 to making QPA symbols marked as private, 0 (tending to -1 because it will make us work ;-) ) to add minor [.patch] to private symbols versioning. Worst case scenario we will have to patch it out for some time until we find a way to automate the process for our tools. That would leave us with some time of non-compatibility but should get fixed for the next stable release that includes Qt > 5.8. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From kevin.kofler at chello.at Thu Dec 8 02:02:36 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 08 Dec 2016 02:02:36 +0100 Subject: [Development] Tagging private symbols as such References: <4328581.XPRJ7y2mly@tonks> <3114260.LjEi0BJEya@tonks> <1519863.QrkxghlSRW@tonks> <43611360.gUn43JsshR@tjmaciei-mobl1> <20161207151213.65jkcclfq3b7bmae@mitya57.me> Message-ID: Dmitry Shachnev wrote: > I also dislike this change. As Lisandro says, we do not want it in Debian > (because we keep track of versions ourselves in the symbols file, and when > the versions are in the symbols themselves they are just useless noise for > us). And as you say, you do not want distributions Qt builds to be ABI > incompatible with upstream (we also would like to avoid that), so if this > patch gets applied upstream, we will be in a bad situation. > > I wonder what was the reason for OpenSUSE to have this change — I could > not find a relevant changelog entry. Why cannot they just rebuild all > packages using private headers for every Qt release, like we do? See my replies: RPM tracks symbol versions, but not the actual names, e.g., Qt has auto-Provides like: libQt5Core.so.5()(64bit) libQt5Core.so.5(Qt_5)(64bit) libQt5Core.so.5(Qt_5.0)(64bit) libQt5Core.so.5(Qt_5.1)(64bit) libQt5Core.so.5(Qt_5.2)(64bit) libQt5Core.so.5(Qt_5.3)(64bit) libQt5Core.so.5(Qt_5.4)(64bit) libQt5Core.so.5(Qt_5.5)(64bit) libQt5Core.so.5(Qt_5.6)(64bit) libQt5Core.so.5(Qt_5_PRIVATE_API)(64bit) The auto-Requires correspond. As you can see, the non-private symbols are properly versioned, so if something requires an API introduced in 5.6, it will have an auto-Requires on "libQt5Core.so.5(Qt_5.6)(64bit)", and the dependency solver will know to drag in qt5-qtbase-5.6.0 or newer in a selective update scenario (because the older versions will just not have that Provides). Unfortunately, the private symbols just have a generic "libQt5Core.so.5(Qt_5_PRIVATE_API)(64bit)" version, which is completely useless. (It is versioned as if the ABI were completely immutable, thus effectively unversioned.) So we are left to manually query for stuff requiring Qt_5_PRIVATE_API and/or manually add versioned Requires on the package. If the symbols instead had a version number, e.g.: libQt5Core.so.5(Qt_5_6_2_PRIVATE_API)(64bit) that would automatically ensure the packages drag in Qt 5.6.2 and no other version, without having to manually add a: Requires: qt5-qtbase%{?_isa} = %{_qt5_version} The difference in implementation compared to the Qt_5.x symbol versions would be that the private symbols would of course NOT provide the older symbol versions, only the latest one, making it effectively an = dependency rather than a >= one. RPM explicitly does NOT track individual symbols as Debian tooling apparently does. Kevin Kofler From Morten.Sorvig at qt.io Fri Dec 9 10:35:04 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Fri, 9 Dec 2016 09:35:04 +0000 Subject: [Development] A new approach for Qt main() Message-ID: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> Hi, We should consider changing the way Qt initialization and startup works. This is something I’ve personally been wanting to do for some time, and a recent offline discussion pushed it on my stack again. Currently, Qt and application startup looks something like this: int main(int argc, char **argv) { QApplication app(argc, argv); // Create root user objects/windows here return app.exec(); } This is fine for the application but cause problems for the Qt platform implementation, which include: * The main entry point may be named something else than main() * The main entry point may be a callback which must be returned from * The platform/Qt/application initialization order is incorrect These have all been worked around in Qt platform code, for example by running Qt on a separate thread, using setjmp/longjmp to simulate a stack, or by temporarily setting up the native event loop before app.exec() is called. We can continue with the workarounds, but they lead to complications in Qt platform code and are also an extra hurdle for implementing support for new platforms, so from the Qt platform development point of view it is desirable with a cleanup. This would be an “all applications should/must port” event, not to be taken lightly. I think the porting would be trivial in many (if not most) cases, but some apps have special requirements for QApplication object management or main thread ownership. This includes our own QTestLib. As a starting point for a concrete API discussion I’ll briefly describe the solution I implemented for the NaCl port. The user API here is a macro which takes application init and exit callback functions: Q_GUI_MAIN(appInit, appExit); The use of a macro allows Qt to inject a main() call with native platform initialization code into the application, if needed. The init and exit functions are callbacks (which must return) and the root user objects must be created on the heap. The QApplication object is managed by Qt and has been created by the time appInit is called. The type of QApplication is decided by the macro, where there are CORE and WIDGETS variants as well. - Morten From Jake.Petroules at qt.io Fri Dec 9 10:42:37 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 9 Dec 2016 09:42:37 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> Message-ID: <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> Without getting too much into the technical details, I'm all for it in principle. It would certainly help on iOS especially as there's a lot of complexity for the main() situation there, which is made even worse by trying to support dynamic libraries. Can you give an example of what the definition of QT_GUI_MAIN would look like and what are the signatures of appInit and appExit? > On Dec 9, 2016, at 1:35 AM, Morten Sorvig wrote: > > Hi, > > We should consider changing the way Qt initialization and startup works. > This is something I’ve personally been wanting to do for some time, and > a recent offline discussion pushed it on my stack again. > > Currently, Qt and application startup looks something like this: > > int main(int argc, char **argv) > { > QApplication app(argc, argv); > > // Create root user objects/windows here > > return app.exec(); > } > > This is fine for the application but cause problems for the Qt platform > implementation, which include: > > * The main entry point may be named something else than main() > > * The main entry point may be a callback which must be returned from > > * The platform/Qt/application initialization order is incorrect > > These have all been worked around in Qt platform code, for example by running > Qt on a separate thread, using setjmp/longjmp to simulate a stack, or by > temporarily setting up the native event loop before app.exec() is called. > > We can continue with the workarounds, but they lead to complications in Qt > platform code and are also an extra hurdle for implementing support for new > platforms, so from the Qt platform development point of view it is desirable > with a cleanup. > > This would be an “all applications should/must port” event, not to be taken > lightly. I think the porting would be trivial in many (if not most) cases, > but some apps have special requirements for QApplication object management > or main thread ownership. This includes our own QTestLib. > > As a starting point for a concrete API discussion I’ll briefly describe the > solution I implemented for the NaCl port. The user API here is a macro which > takes application init and exit callback functions: > > Q_GUI_MAIN(appInit, appExit); > > The use of a macro allows Qt to inject a main() call with native platform > initialization code into the application, if needed. The init and exit > functions are callbacks (which must return) and the root user objects > must be created on the heap. The QApplication object is managed by Qt > and has been created by the time appInit is called. The type of QApplication > is decided by the macro, where there are CORE and WIDGETS variants as well. > > - Morten > > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From Friedemann.Kleint at qt.io Fri Dec 9 11:00:00 2016 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Fri, 9 Dec 2016 11:00:00 +0100 Subject: [Development] A new approach for Qt main() In-Reply-To: <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> Message-ID: Hi, > Q_GUI_MAIN(appInit, appExit); Magic macros for main should be avoided, IMO. A typical application main() can look like main() { QApplication a(); Initialization code for other libraries parseArguments(), return if failed show some FileDialog prompting for argument if sth was missing try { app.exec() } catch (exception) { } De-Initialize something } There is no way to shoehorn this into some macro; this can already be observed when trying to adding some initialization to a test. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH From Simon.Hausmann at qt.io Fri Dec 9 11:17:27 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 9 Dec 2016 10:17:27 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io>, Message-ID: Yes, and we will forever (?) support that kind of main function and application entry point. I don't think that we can break that. I'm all interested in supporting a second supported way of describing an entry point that more closely matches today's semantics of graphics applications on the underlying operating/windowing systems. Oddly, I do like the way that we're doing this on Windows and have been doing it forever, by shoehorning main() into WinMain() through a static library. I'm not suggesting to replace QtMain, but I wonder if we could offer a cross-platform QtMain (with a different name that doesn't clash with the existing one) that requires the programmer to supply a _two_ (or more?) functions instead of one function. No macros involved then. Simon ________________________________ From: Development on behalf of Friedemann Kleint Sent: Friday, December 9, 2016 11:00:00 AM To: development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, > Q_GUI_MAIN(appInit, appExit); Magic macros for main should be avoided, IMO. A typical application main() can look like main() { QApplication a(); Initialization code for other libraries parseArguments(), return if failed show some FileDialog prompting for argument if sth was missing try { app.exec() } catch (exception) { } De-Initialize something } There is no way to shoehorn this into some macro; this can already be observed when trying to adding some initialization to a test. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH _______________________________________________ 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 laszlo.agocs at qt.io Fri Dec 9 11:41:52 2016 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Fri, 9 Dec 2016 10:41:52 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io>, Message-ID: Special macros for straightforward applications on exotic systems? Sure. Forcing an unnecessary change on existing and future applications on platforms that are doing just fine (i.e. the majority)? No. Building on Friedemann's example the list of potentially problematic cases could go on forever. For example, what if you need to set certain application attributes, default surface formats, etc. before the Q(Gui)Application construction. Or the special cases where app object creation should be carefully placed. In the end those macros would need to get a lot more complicated than they look at first. Based on all the negative experience with testlib's similar and the qtdeclarative examples' main-wrapping macros, I'd rather prefer we think twice before introducing any such macros. Also, if migration for the typical applications is seen that easy, it should be no problem for developers targeting exotic systems to provide a new-style entry point in their apps. Best regards, Laszlo From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Simon Hausmann Sent: Friday, December 9, 2016 11:17 AM To: Friedemann Kleint ; development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Yes, and we will forever (?) support that kind of main function and application entry point. I don't think that we can break that. I'm all interested in supporting a second supported way of describing an entry point that more closely matches today's semantics of graphics applications on the underlying operating/windowing systems. Oddly, I do like the way that we're doing this on Windows and have been doing it forever, by shoehorning main() into WinMain() through a static library. I'm not suggesting to replace QtMain, but I wonder if we could offer a cross-platform QtMain (with a different name that doesn't clash with the existing one) that requires the programmer to supply a _two_ (or more?) functions instead of one function. No macros involved then. Simon ________________________________ From: Development > on behalf of Friedemann Kleint > Sent: Friday, December 9, 2016 11:00:00 AM To: development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, > Q_GUI_MAIN(appInit, appExit); Magic macros for main should be avoided, IMO. A typical application main() can look like main() { QApplication a(); Initialization code for other libraries parseArguments(), return if failed show some FileDialog prompting for argument if sth was missing try { app.exec() } catch (exception) { } De-Initialize something } There is no way to shoehorn this into some macro; this can already be observed when trying to adding some initialization to a test. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Fri Dec 9 11:44:24 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 9 Dec 2016 10:44:24 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> Message-ID: <0011A189-CA27-47A3-B411-804422199864@qt.io> Well, the problem is that the main() entry point is causing huge amounts of issues on at least Android and iOS. We’d help those platforms a lot if we didn’t support this kind of entry point (on those platforms) anymore. But I agree that we can’t break this in Qt 5, but we can prepare for Qt6. I’d propose to define a new entry point that works better on these platforms and offering that as the recommended way for new apps. The best solution is probably a static library that provides callbacks that can be used to initialize things. When we then come to Qt6, we could deprecate using main() as the entry point, and remove support for it at least on the platforms where this is problematic. Cheers, Lars From: Development on behalf of Simon Hausmann Date: Friday, 9 December 2016 at 11:17 To: Friedemann Kleint , Qt development mailing list Subject: Re: [Development] A new approach for Qt main() Yes, and we will forever (?) support that kind of main function and application entry point. I don't think that we can break that. I'm all interested in supporting a second supported way of describing an entry point that more closely matches today's semantics of graphics applications on the underlying operating/windowing systems. Oddly, I do like the way that we're doing this on Windows and have been doing it forever, by shoehorning main() into WinMain() through a static library. I'm not suggesting to replace QtMain, but I wonder if we could offer a cross-platform QtMain (with a different name that doesn't clash with the existing one) that requires the programmer to supply a _two_ (or more?) functions instead of one function. No macros involved then. Simon ________________________________ From: Development on behalf of Friedemann Kleint Sent: Friday, December 9, 2016 11:00:00 AM To: development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, > Q_GUI_MAIN(appInit, appExit); Magic macros for main should be avoided, IMO. A typical application main() can look like main() { QApplication a(); Initialization code for other libraries parseArguments(), return if failed show some FileDialog prompting for argument if sth was missing try { app.exec() } catch (exception) { } De-Initialize something } There is no way to shoehorn this into some macro; this can already be observed when trying to adding some initialization to a test. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH _______________________________________________ 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 Fri Dec 9 12:03:32 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 9 Dec 2016 11:03:32 +0000 Subject: [Development] Qt 5.8.0 change files. MAINTAINERS: your actions needed In-Reply-To: References: Message-ID: Hi all, Most of change files are still ongoing. MAINTAINERS: Please take an action and finalize those now. br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Thursday, December 1, 2016 10:07 AM To: development at qt-project.org Subject: [Development] Qt 5.8.0 change files. MAINTAINERS: your actions needed Hi, We did initial change files for Qt 5.8.0 (for those modules where missing), see https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+5.8.0%22,n,z Maintainers, please take those over & finalize as soon as possible. And of course make sure those will be reviewed soon as well. We need to get all these in now, RC is planned to happen 13th Dec! br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From filippocucchetto at gmail.com Fri Dec 9 12:07:53 2016 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Fri, 9 Dec 2016 12:07:53 +0100 Subject: [Development] A new approach for Qt main() In-Reply-To: <0011A189-CA27-47A3-B411-804422199864@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> Message-ID: Does this relates to moving Qt main loop to a different thread other than the main thread? Cause currently creating the QtApp from a different thread causes problems. In particular the plugins static objects are destroyed at app exit and thus on the main thread (and this causes problems because QObjects should be freed in the same thread where they've created). An example is the QQmlComponentsCache. Il 09 dic 2016 11:44, "Lars Knoll" ha scritto: > Well, the problem is that the main() entry point is causing huge amounts > of issues on at least Android and iOS. We’d help those platforms a lot if > we didn’t support this kind of entry point (on those platforms) anymore. > But I agree that we can’t break this in Qt 5, but we can prepare for Qt6. > > > > I’d propose to define a new entry point that works better on these > platforms and offering that as the recommended way for new apps. The best > solution is probably a static library that provides callbacks that can be > used to initialize things. > > > > When we then come to Qt6, we could deprecate using main() as the entry > point, and remove support for it at least on the platforms where this is > problematic. > > > > Cheers, > > Lars > > > > *From: *Development > on behalf of Simon Hausmann > *Date: *Friday, 9 December 2016 at 11:17 > *To: *Friedemann Kleint , Qt development mailing > list > *Subject: *Re: [Development] A new approach for Qt main() > > > > > > Yes, and we will forever (?) support that kind of main function and > application entry point. I don't think that we can break that. > > > > I'm all interested in supporting a second supported way of describing an > entry point that more closely matches today's semantics > > of graphics applications on the underlying operating/windowing systems. > > > > Oddly, I do like the way that we're doing this on Windows and have been > doing it forever, by shoehorning main() into WinMain() > > through a static library. I'm not suggesting to replace QtMain, but I > wonder if we could offer a cross-platform QtMain (with a different > > name that doesn't clash with the existing one) that requires the > programmer to supply a _two_ (or more?) functions instead of one function. > No > > macros involved then. > > > > > > Simon > ------------------------------ > > *From:* Development qt.io at qt-project.org> on behalf of Friedemann Kleint < > Friedemann.Kleint at qt.io> > *Sent:* Friday, December 9, 2016 11:00:00 AM > *To:* development at qt-project.org > *Subject:* Re: [Development] A new approach for Qt main() > > > > Hi, > > > Q_GUI_MAIN(appInit, appExit); > > Magic macros for main should be avoided, IMO. > > A typical application main() can look like > > main() > { > QApplication a(); > > Initialization code for other libraries > > parseArguments(), return if failed > > show some FileDialog prompting for argument if sth was missing > > try { > app.exec() > } catch (exception) { > } > De-Initialize something > } > > There is no way to shoehorn this into some macro; this can already be > observed when trying to adding some initialization to a test. > > Regards, > Friedemann > > -- > > Friedemann Kleint > The Qt Company GmbH > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From laszlo.agocs at qt.io Fri Dec 9 12:11:15 2016 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Fri, 9 Dec 2016 11:11:15 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> Message-ID: There are two separate things in there, though: the entry point and the construction of the Q(Core|Gui)Application object. The problem is with the latter: is it not clear why Morten’s proposal moves that under the framework’s control. Introducing a new entry point, e.g. qtMain(), for all platforms in Qt 6 is fine. Moving the application object construction into the underlying platform-specific entry point Qt provides is not. Laszlo From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Filippo Cucchetto Sent: Friday, December 9, 2016 12:08 PM To: Lars Knoll Cc: Qt Project Development Mailing-List Subject: Re: [Development] A new approach for Qt main() Does this relates to moving Qt main loop to a different thread other than the main thread? Cause currently creating the QtApp from a different thread causes problems. In particular the plugins static objects are destroyed at app exit and thus on the main thread (and this causes problems because QObjects should be freed in the same thread where they've created). An example is the QQmlComponentsCache. Il 09 dic 2016 11:44, "Lars Knoll" > ha scritto: Well, the problem is that the main() entry point is causing huge amounts of issues on at least Android and iOS. We’d help those platforms a lot if we didn’t support this kind of entry point (on those platforms) anymore. But I agree that we can’t break this in Qt 5, but we can prepare for Qt6. I’d propose to define a new entry point that works better on these platforms and offering that as the recommended way for new apps. The best solution is probably a static library that provides callbacks that can be used to initialize things. When we then come to Qt6, we could deprecate using main() as the entry point, and remove support for it at least on the platforms where this is problematic. Cheers, Lars From: Development > on behalf of Simon Hausmann > Date: Friday, 9 December 2016 at 11:17 To: Friedemann Kleint >, Qt development mailing list > Subject: Re: [Development] A new approach for Qt main() Yes, and we will forever (?) support that kind of main function and application entry point. I don't think that we can break that. I'm all interested in supporting a second supported way of describing an entry point that more closely matches today's semantics of graphics applications on the underlying operating/windowing systems. Oddly, I do like the way that we're doing this on Windows and have been doing it forever, by shoehorning main() into WinMain() through a static library. I'm not suggesting to replace QtMain, but I wonder if we could offer a cross-platform QtMain (with a different name that doesn't clash with the existing one) that requires the programmer to supply a _two_ (or more?) functions instead of one function. No macros involved then. Simon ________________________________ From: Development > on behalf of Friedemann Kleint > Sent: Friday, December 9, 2016 11:00:00 AM To: development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, > Q_GUI_MAIN(appInit, appExit); Magic macros for main should be avoided, IMO. A typical application main() can look like main() { QApplication a(); Initialization code for other libraries parseArguments(), return if failed show some FileDialog prompting for argument if sth was missing try { app.exec() } catch (exception) { } De-Initialize something } There is no way to shoehorn this into some macro; this can already be observed when trying to adding some initialization to a test. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Friedemann.Kleint at qt.io Fri Dec 9 12:31:24 2016 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Fri, 9 Dec 2016 12:31:24 +0100 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> Message-ID: <4a673c84-5da5-df4d-97e5-7c3caad94cb8@qt.io> Hi, from the Windows POV, support for wmain() with wide arguments would be a nice thing to have (see https://bugreports.qt.io/browse/QTBUG-46118 ): int wmain( int argc, wchar_t *argv[ ], wchar_t *envp[ ] ) Maybe that can be implemented by some smart modularization. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH From tor.arne.vestbo at qt.io Fri Dec 9 12:40:17 2016 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 9 Dec 2016 12:40:17 +0100 Subject: [Development] A new approach for Qt main() In-Reply-To: <0011A189-CA27-47A3-B411-804422199864@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> Message-ID: <84635995-0a2f-be18-34f7-7b12a2f1693e@qt.io> On 09/12/2016 11:44, Lars Knoll wrote: > Well, the problem is that the main() entry point is causing huge amounts > of issues on at least Android and iOS. I don't know about Android, but on iOS this is patently false. While the workaround is complex, it has worked very well in the 3 years since its inception. Please don't use iOS as a straw-man in this discussion. Tor Arne From Jake.Petroules at qt.io Fri Dec 9 12:49:51 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 9 Dec 2016 11:49:51 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: <84635995-0a2f-be18-34f7-7b12a2f1693e@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> <84635995-0a2f-be18-34f7-7b12a2f1693e@qt.io> Message-ID: > On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø wrote: > > On 09/12/2016 11:44, Lars Knoll wrote: >> Well, the problem is that the main() entry point is causing huge amounts >> of issues on at least Android and iOS. > > I don't know about Android, but on iOS this is patently false. While the workaround is complex, it has worked very well in the 3 years since its inception. Please don't use iOS as a straw-man in this discussion. The point is that we shouldn't need such a workaround in the first place. That's kind of the point of this discussion. And as I said, the iOS situation is made even worse further by dynamic libraries. > > Tor Arne > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From eskil.abrahamsen-blomfeldt at qt.io Fri Dec 9 12:58:46 2016 From: eskil.abrahamsen-blomfeldt at qt.io (Eskil Abrahamsen Blomfeldt) Date: Fri, 9 Dec 2016 12:58:46 +0100 Subject: [Development] A new approach for Qt main() In-Reply-To: <84635995-0a2f-be18-34f7-7b12a2f1693e@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> <84635995-0a2f-be18-34f7-7b12a2f1693e@qt.io> Message-ID: <335325de-2d16-dd9a-b92e-8e1e84735862@qt.io> Den 09.12.2016 12:40, skrev Tor Arne Vestbø: > On 09/12/2016 11:44, Lars Knoll wrote: >> Well, the problem is that the main() entry point is causing huge amounts >> of issues on at least Android and iOS. > > I don't know about Android, but on iOS this is patently false. While > the workaround is complex, it has worked very well in the 3 years > since its inception. Please don't use iOS as a straw-man in this > discussion. Speaking for Android, there are and have been thread synchronization issues due to Qt running a synchronous event loop in the main function. It is also impossible to make applications with multiple entry points and complex life cycles, which you would expect in an Android application consisting of several activities and services that can be triggered independently and simultaenously. Our work-around for this is to limit support to applications with one activity or one service per process in the application. So while we have been able to find solutions for most our problems, both on Android and iOS, I guess Lars' point is that we are encountering more and more cases where we have to invent hacks and work-arounds and document limitations in order to be functional on modern platforms. It might be a sign that we should adapt. -- Eskil Abrahamsen Blomfeldt Senior Manager, R&D The Qt Company Sandakerveien 116 0484 Oslo, Norway eskil.abrahamsen-blomfeldt at qt.io http://qt.io From tor.arne.vestbo at qt.io Fri Dec 9 14:02:12 2016 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 9 Dec 2016 14:02:12 +0100 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> <84635995-0a2f-be18-34f7-7b12a2f1693e@qt.io> Message-ID: On 09/12/2016 12:49, Jake Petroules wrote: >> On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø >> wrote: >> >> On 09/12/2016 11:44, Lars Knoll wrote: >>> Well, the problem is that the main() entry point is causing huge >>> amounts of issues on at least Android and iOS. >> >> I don't know about Android, but on iOS this is patently false. >> While the workaround is complex, it has worked very well in the 3 >> years since its inception. Please don't use iOS as a straw-man in >> this discussion. > > The point is that we shouldn't need such a workaround in the first > place. That's kind of the point of this discussion. And as I said, > the iOS situation is made even worse further by dynamic libraries. Obviously getting rid of workaround (in all platforms, not just iOS) would be preferable. But describing the current (x years and counting) situation as 'causing huge amount of issues' (on iOS) is just plain wrong, and derails the discussion from pragmatic and constructive solutions to the problem. tor arne From tor.arne.vestbo at qt.io Fri Dec 9 14:10:03 2016 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 9 Dec 2016 14:10:03 +0100 Subject: [Development] A new approach for Qt main() In-Reply-To: <335325de-2d16-dd9a-b92e-8e1e84735862@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> <84635995-0a2f-be18-34f7-7b12a2f1693e@qt.io> <335325de-2d16-dd9a-b92e-8e1e84735862@qt.io> Message-ID: <40fac04b-89f5-8750-d306-3319c70eaf41@qt.io> On 09/12/2016 12:58, Eskil Abrahamsen Blomfeldt wrote: > Den 09.12.2016 12:40, skrev Tor Arne Vestbø: >> On 09/12/2016 11:44, Lars Knoll wrote: >>> Well, the problem is that the main() entry point is causing huge amounts >>> of issues on at least Android and iOS. >> >> I don't know about Android, but on iOS this is patently false. While >> the workaround is complex, it has worked very well in the 3 years >> since its inception. Please don't use iOS as a straw-man in this >> discussion. > > Speaking for Android, there are and have been thread synchronization > issues due to Qt running a synchronous event loop in the main function. > It is also impossible to make applications with multiple entry points > and complex life cycles, which you would expect in an Android > application consisting of several activities and services that can be > triggered independently and simultaenously. Our work-around for this is > to limit support to applications with one activity or one service per > process in the application. > > So while we have been able to find solutions for most our problems, both > on Android and iOS, I guess Lars' point is that we are encountering more > and more cases where we have to invent hacks and work-arounds and > document limitations in order to be functional on modern platforms. It > might be a sign that we should adapt. Yes, I'm not disagreeing that a new model for Qt initialization would be welcome, I was reacting to the swiping generalization Lars was making in trying to make his point :-) tor arne From Jake.Petroules at qt.io Fri Dec 9 14:10:50 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Fri, 9 Dec 2016 13:10:50 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> <84635995-0a2f-be18-34f7-7b12a2f1693e@qt.io> Message-ID: <98357455-9C16-4282-8D98-D3A33DB48314@qt.io> > On Dec 9, 2016, at 5:02 AM, Tor Arne Vestbø wrote: > > On 09/12/2016 12:49, Jake Petroules wrote: >>> On Dec 9, 2016, at 3:40 AM, Tor Arne Vestbø >>> wrote: >>> >>> On 09/12/2016 11:44, Lars Knoll wrote: >>>> Well, the problem is that the main() entry point is causing huge >>>> amounts of issues on at least Android and iOS. >>> >>> I don't know about Android, but on iOS this is patently false. >>> While the workaround is complex, it has worked very well in the 3 >>> years since its inception. Please don't use iOS as a straw-man in >>> this discussion. >> >> The point is that we shouldn't need such a workaround in the first >> place. That's kind of the point of this discussion. And as I said, >> the iOS situation is made even worse further by dynamic libraries. > > Obviously getting rid of workaround (in all platforms, not just iOS) would be preferable. But describing the current (x years and counting) situation as 'causing huge amount of issues' (on iOS) is just plain wrong, and derails the discussion from pragmatic and constructive solutions to the problem. Again, I think you're missing Lars' point - "causing huge amount of issues" doesn't necessarily mean that we are constantly finding and fixing issues every week - in this context it means "the fact that we have a workaround at all", i.e. a suboptimal solution to an architectural problem that we wish wasn't there. Even ONE issue (the one that was "fixed" years ago) can still qualify as "huge amount of issues" simply because the solution in place is complicated and we don't like it. I think at this point we're nitpicking linguistics. We both understood what Lars meant and obviously both agree with him. > tor arne -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From bogdan.vatra at kdab.com Fri Dec 9 14:19:27 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Fri, 09 Dec 2016 15:19:27 +0200 Subject: [Development] A new approach for Qt main() In-Reply-To: <335325de-2d16-dd9a-b92e-8e1e84735862@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <84635995-0a2f-be18-34f7-7b12a2f1693e@qt.io> <335325de-2d16-dd9a-b92e-8e1e84735862@qt.io> Message-ID: <1797487.tCrkIipktl@zmeu> On vineri, 9 decembrie 2016 12:58:46 EET Eskil Abrahamsen Blomfeldt wrote: > Den 09.12.2016 12:40, skrev Tor Arne Vestbø: > > On 09/12/2016 11:44, Lars Knoll wrote: > >> Well, the problem is that the main() entry point is causing huge amounts > >> of issues on at least Android and iOS. > > > > I don't know about Android, but on iOS this is patently false. While > > the workaround is complex, it has worked very well in the 3 years > > since its inception. Please don't use iOS as a straw-man in this > > discussion. > > Speaking for Android, there are and have been thread synchronization > issues due to Qt running a synchronous event loop in the main function. > It is also impossible to make applications with multiple entry points > and complex life cycles, which you would expect in an Android > application consisting of several activities and services that can be > triggered independently and simultaenously. Our work-around for this is > to limit support to applications with one activity or one service per > process in the application. > > So while we have been able to find solutions for most our problems, both > on Android and iOS, I guess Lars' point is that we are encountering more > and more cases where we have to invent hacks and work-arounds and > document limitations in order to be functional on modern platforms. It > might be a sign that we should adapt. IMHO (at least) for Android the biggest problem is the QPA architecture which is not designed for multiple Activities/Services. On Android we'll need a QPA instance for every Activities/Services :). This also means we'll need to redesign QtAndroidExtras as well. Even if having multiple Activities in the same process will be a nice thing, is not a very demanding feature. The most demanding feature will be to support multiple Services alongside an Activity in the same process. Cheers, BogDan. From tor.arne.vestbo at qt.io Fri Dec 9 14:22:17 2016 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 9 Dec 2016 14:22:17 +0100 Subject: [Development] A new approach for Qt main() In-Reply-To: <98357455-9C16-4282-8D98-D3A33DB48314@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> <84635995-0a2f-be18-34f7-7b12a2f1693e@qt.io> <98357455-9C16-4282-8D98-D3A33DB48314@qt.io> Message-ID: On 09/12/2016 14:10, Jake Petroules wrote: > Again, I think you're missing Lars' point - "causing huge amount of > issues" doesn't necessarily mean that we are constantly finding and > fixing issues every week - in this context it means "the fact that we > have a workaround at all", i.e. a suboptimal solution to an > architectural problem that we wish wasn't there. Even ONE issue (the > one that was "fixed" years ago) can still qualify as "huge amount of > issues" simply because the solution in place is complicated and we > don't like it. Yes, linguistics is quite important when trying to make a point over the internet. For example using the present tense "causing" instead of past tense. The fact that you personally have some sort of allergic reaction to the current situation, based on the strong argument of "not liking it", is not of much concern to me in shaping the future solution in this area. tor arne From Andre.Poenitz at qt.io Fri Dec 9 14:51:19 2016 From: Andre.Poenitz at qt.io (Andre Poenitz) Date: Fri, 9 Dec 2016 13:51:19 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: <0011A189-CA27-47A3-B411-804422199864@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> , <0011A189-CA27-47A3-B411-804422199864@qt.io> Message-ID: Whatever the problem is, I think we should try hard to have a solution that 1. does not use macros and 2. that does not optically change the int main(int argc, char *argv[]) { QApplication app(argc, argv)... } stanza. Macros look and feel ugly and outdated in contemporary C++, are harder to debug, etc etc. Changing away from a normal main will make look Qt code alien, not to mention the necessary adaptation in documentation and each and every "getting started with Qt" tutorial out there. This would be a high price to pay. I have to admit that I don't really understand the scope of the problem yet. If this is about having customization points in the QApplication object's life cycle, or supporting multiple entry points or similar one could have e.g. a number of QApplication::setFooCustomization(std::function<...>) static functions that can be used to register callbacks by the platform specific Qt and/or user code. Also, the actual "application object" lifecycle does not have to be match the user's QApplication object in main(). The real thing can be created whenever it make sense, and what the user sees will only forward calls, or hold back calls, or possible finalize initialization or whatever using the registered callbacks. For me it would be helpful to have a list of problems that need to be solved before discussing one specific potential solution. Andre' ________________________________________ From: Development on behalf of Lars Knoll Sent: Friday, December 9, 2016 11:44 AM To: Simon Hausmann; Friedemann Kleint; development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Well, the problem is that the main() entry point is causing huge amounts of issues on at least Android and iOS. We’d help those platforms a lot if we didn’t support this kind of entry point (on those platforms) anymore. But I agree that we can’t break this in Qt 5, but we can prepare for Qt6. I’d propose to define a new entry point that works better on these platforms and offering that as the recommended way for new apps. The best solution is probably a static library that provides callbacks that can be used to initialize things. When we then come to Qt6, we could deprecate using main() as the entry point, and remove support for it at least on the platforms where this is problematic. Cheers, Lars From: Development on behalf of Simon Hausmann Date: Friday, 9 December 2016 at 11:17 To: Friedemann Kleint , Qt development mailing list Subject: Re: [Development] A new approach for Qt main() Yes, and we will forever (?) support that kind of main function and application entry point. I don't think that we can break that. I'm all interested in supporting a second supported way of describing an entry point that more closely matches today's semantics of graphics applications on the underlying operating/windowing systems. Oddly, I do like the way that we're doing this on Windows and have been doing it forever, by shoehorning main() into WinMain() through a static library. I'm not suggesting to replace QtMain, but I wonder if we could offer a cross-platform QtMain (with a different name that doesn't clash with the existing one) that requires the programmer to supply a _two_ (or more?) functions instead of one function. No macros involved then. Simon ________________________________ From: Development on behalf of Friedemann Kleint Sent: Friday, December 9, 2016 11:00:00 AM To: development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, > Q_GUI_MAIN(appInit, appExit); Magic macros for main should be avoided, IMO. A typical application main() can look like main() { QApplication a(); Initialization code for other libraries parseArguments(), return if failed show some FileDialog prompting for argument if sth was missing try { app.exec() } catch (exception) { } De-Initialize something } There is no way to shoehorn this into some macro; this can already be observed when trying to adding some initialization to a test. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Morten.Sorvig at qt.io Fri Dec 9 15:34:45 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Fri, 9 Dec 2016 14:34:45 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> Message-ID: > On 9 Dec 2016, at 12:11, Laszlo Agocs wrote: > > There are two separate things in there, though: the entry point and the construction of the Q(Core|Gui)Application object. The problem is with the latter: is it not clear why Morten’s proposal moves that under the framework’s control. Introducing a new entry point, e.g. qtMain(), for all platforms in Qt 6 is fine. Moving the application object construction into the underlying platform-specific entry point Qt provides is not. The reasoning was that QApplication management ended up as boilerplate code, so let’s simplify. This is especially true if the application type has already been selected via a macro. Keeping support for setting options before creating the application object is a very good argument for letting user code control it though. Morten From Morten.Sorvig at qt.io Fri Dec 9 15:34:47 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Fri, 9 Dec 2016 14:34:47 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> Message-ID: > On 9 Dec 2016, at 11:41, Laszlo Agocs wrote: > > > Special macros for straightforward applications on exotic systems? Sure. Forcing an unnecessary change on existing and future applications on platforms that are doing just fine (i.e. the majority)? No. > > > Also, if migration for the typical applications is seen that easy, it should be no problem for developers targeting exotic systems to provide a new-style entry point in their apps. I think we should have one primary way to handle app init though, which would be mentioned first in the documentation and which most of the examples use. So I would prefer to keep the current API if we can’t find a new primary API. Morten From Morten.Sorvig at qt.io Fri Dec 9 16:29:51 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Fri, 9 Dec 2016 15:29:51 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <82BF30BB-834C-427B-AA8B-5006F18CB68E@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> Message-ID: <5357572B-05CC-4F5D-A342-F3B259DEFA2D@qt.io> > On 9 Dec 2016, at 14:51, Andre Poenitz wrote: > > > Whatever the problem is, I think we should try hard to have a solution > that 1. does not use macros and 2. that does not optically change the > int main(int argc, char *argv[]) { QApplication app(argc, argv)... } stanza. This sounds like the current approach, where we solve the startup issue by adding complexity to the Qt platform implementation that allows us to keep main(). The suggested approach would solve the issue by changing the API, and the motivation is a simplification of the Qt platform implementation. So the benefit is perhaps not immediately clear to those not directly involved with Qt platform development, except for the potential for faster developed, more stable Qt. > > Macros look and feel ugly and outdated in contemporary C++, are harder > to debug, etc etc. Changing away from a normal main will make look Qt > code alien, not to mention the necessary adaptation in documentation > and each and every "getting started with Qt" tutorial out there. This would > be a high price to pay. Indeed if keeping the normal main (and docs etc) is very important then that could tip the scales over to not making API changes. Morten From mwoehlke.floss at gmail.com Fri Dec 9 17:10:15 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 9 Dec 2016 11:10:15 -0500 Subject: [Development] A new approach for Qt main() In-Reply-To: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> Message-ID: <584AD767.8070308@gmail.com> On 2016-12-09 04:35, Morten Sorvig wrote: > We should consider changing the way Qt initialization and startup works. > This is something I’ve personally been wanting to do for some time, and > a recent offline discussion pushed it on my stack again. > > Currently, Qt and application startup looks something like this: > > int main(int argc, char **argv) > { > QApplication app(argc, argv); > > // Create root user objects/windows here > > return app.exec(); > } > > We can continue with the workarounds, but they lead to complications in Qt > platform code and are also an extra hurdle for implementing support for new > platforms, so from the Qt platform development point of view it is desirable > with a cleanup. > > This would be an “all applications should/must port” event, not to be taken > lightly. I think the porting would be trivial in many (if not most) cases, > but some apps have special requirements for QApplication object management > or main thread ownership. This includes our own QTestLib. One concern I have is if users are monkeying with argc/argv prior to constructing a QApplication instance. IIRC, KDE used to do this (not sure if they still do), and qtCliArgs¹ does this also. This allows, for instance, enforcing a consistent argument naming policy that differs from Qt's own policy, while still being able to pass Qt CLI arguments. Also, how does this work if someone wants to subclass Q*Application? (Again, I have projects that do that...) (¹ https://github.com/Kitware/qtextensions/blob/master/core/qtCliArgs.h) -- Matthew From thiago.macieira at intel.com Fri Dec 9 18:05:46 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Dec 2016 09:05:46 -0800 Subject: [Development] A new approach for Qt main() In-Reply-To: <0011A189-CA27-47A3-B411-804422199864@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> Message-ID: <2324419.ev00mqjj6g@tjmaciei-mobl1> Em sexta-feira, 9 de dezembro de 2016, às 10:44:24 PST, Lars Knoll escreveu: > Well, the problem is that the main() entry point is causing huge amounts of > issues on at least Android and iOS. We’d help those platforms a lot if we > didn’t support this kind of entry point (on those platforms) anymore. But I > agree that we can’t break this in Qt 5, but we can prepare for Qt6. > > I’d propose to define a new entry point that works better on these platforms > and offering that as the recommended way for new apps. The best solution is > probably a static library that provides callbacks that can be used to > initialize things. Can we get a description of what those problems are, for those of us who have never developed anything for those OSes, so we're not discussing things in the abstract? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Dec 9 18:10:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Dec 2016 09:10:47 -0800 Subject: [Development] A new approach for Qt main() In-Reply-To: <584AD767.8070308@gmail.com> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <584AD767.8070308@gmail.com> Message-ID: <1483931.M9FFs49qIn@tjmaciei-mobl1> Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke escreveu: > Also, how does this work if someone wants to subclass Q*Application? > (Again, I have projects that do that...) But why do they do that? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Fri Dec 9 18:13:57 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 09 Dec 2016 20:13:57 +0300 Subject: [Development] A new approach for Qt main() In-Reply-To: <1483931.M9FFs49qIn@tjmaciei-mobl1> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <584AD767.8070308@gmail.com> <1483931.M9FFs49qIn@tjmaciei-mobl1> Message-ID: <14822721481303637@web1g.yandex.ru> 09.12.2016, 20:11, "Thiago Macieira" : >  Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke >  escreveu: >>   Also, how does this work if someone wants to subclass Q*Application? >>   (Again, I have projects that do that...) > >  But why do they do that? To override virtual methods, like notify() >  -- >  Thiago Macieira - thiago.macieira (AT) intel.com >    Software Architect - Intel Open Source Technology Center > >  _______________________________________________ >  Development mailing list >  Development at qt-project.org >  http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Fri Dec 9 18:29:56 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Dec 2016 09:29:56 -0800 Subject: [Development] A new approach for Qt main() In-Reply-To: <14822721481303637@web1g.yandex.ru> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <1483931.M9FFs49qIn@tjmaciei-mobl1> <14822721481303637@web1g.yandex.ru> Message-ID: <13228561.0VH2P8f482@tjmaciei-mobl1> Em sexta-feira, 9 de dezembro de 2016, às 20:13:57 PST, Konstantin Tokarev escreveu: > 09.12.2016, 20:11, "Thiago Macieira" : > > Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke > > > > escreveu: > >> Also, how does this work if someone wants to subclass Q*Application? > >> (Again, I have projects that do that...) > > > > But why do they do that? > > To override virtual methods, like notify() Ok, that's no longer a valid reason because we'll deprecate that practice in Qt 6. Any other reasons? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Fri Dec 9 21:28:13 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 9 Dec 2016 15:28:13 -0500 Subject: [Development] A new approach for Qt main() In-Reply-To: <1483931.M9FFs49qIn@tjmaciei-mobl1> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <584AD767.8070308@gmail.com> <1483931.M9FFs49qIn@tjmaciei-mobl1> Message-ID: <584B13DD.7030601@gmail.com> On 2016-12-09 12:10, Thiago Macieira wrote: > Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke > escreveu: >> Also, how does this work if someone wants to subclass Q*Application? >> (Again, I have projects that do that...) > > But why do they do that? ...because I have a number of executables which share logic, and it seemed like the obvious thing to do. (It saves having to create an entirely separate singleton that interacts closely with QApplication.) I can work around that, though it's obnoxious. I'm more concerned about not being able to tinker with the CLI arguments before Qt gets them. -- Matthew From mwoehlke.floss at gmail.com Fri Dec 9 21:28:13 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 9 Dec 2016 15:28:13 -0500 Subject: [Development] A new approach for Qt main() In-Reply-To: <1483931.M9FFs49qIn@tjmaciei-mobl1> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <584AD767.8070308@gmail.com> <1483931.M9FFs49qIn@tjmaciei-mobl1> Message-ID: <584B13DD.7030601@gmail.com> On 2016-12-09 12:10, Thiago Macieira wrote: > Em sexta-feira, 9 de dezembro de 2016, às 11:10:15 PST, Matthew Woehlke > escreveu: >> Also, how does this work if someone wants to subclass Q*Application? >> (Again, I have projects that do that...) > > But why do they do that? ...because I have a number of executables which share logic, and it seemed like the obvious thing to do. (It saves having to create an entirely separate singleton that interacts closely with QApplication.) I can work around that, though it's obnoxious. I'm more concerned about not being able to tinker with the CLI arguments before Qt gets them. -- Matthew From thiago.macieira at intel.com Fri Dec 9 22:23:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Dec 2016 13:23:01 -0800 Subject: [Development] A new approach for Qt main() In-Reply-To: <584B13DD.7030601@gmail.com> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <1483931.M9FFs49qIn@tjmaciei-mobl1> <584B13DD.7030601@gmail.com> Message-ID: <2730654.ajvTuP4Uuq@tjmaciei-mobl1> Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke escreveu: > I can work around that, though it's obnoxious. I'm more concerned about > not being able to tinker with the CLI arguments before Qt gets them. That's a valid concern, but not one that warrants a QApplication subclass. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Fri Dec 9 22:50:29 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 9 Dec 2016 16:50:29 -0500 Subject: [Development] A new approach for Qt main() In-Reply-To: <2730654.ajvTuP4Uuq@tjmaciei-mobl1> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <1483931.M9FFs49qIn@tjmaciei-mobl1> <584B13DD.7030601@gmail.com> <2730654.ajvTuP4Uuq@tjmaciei-mobl1> Message-ID: <584B2725.2020700@gmail.com> On 2016-12-09 16:23, Thiago Macieira wrote: > Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke > escreveu: >> I can work around that, though it's obnoxious. I'm more concerned about >> not being able to tinker with the CLI arguments before Qt gets them. > > That's a valid concern, but not one that warrants a QApplication subclass. Right; that one is an issue if the user is no longer in control of instantiating the Q*Application instance. -- Matthew From thiago.macieira at intel.com Sat Dec 10 01:43:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Dec 2016 16:43:00 -0800 Subject: [Development] A new approach for Qt main() In-Reply-To: <584B2725.2020700@gmail.com> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <2730654.ajvTuP4Uuq@tjmaciei-mobl1> <584B2725.2020700@gmail.com> Message-ID: <2624452.zT3LX7U3yD@tjmaciei-mobl1> Em sexta-feira, 9 de dezembro de 2016, às 16:50:29 PST, Matthew Woehlke escreveu: > On 2016-12-09 16:23, Thiago Macieira wrote: > > Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke > > > > escreveu: > >> I can work around that, though it's obnoxious. I'm more concerned about > >> not being able to tinker with the CLI arguments before Qt gets them. > > > > That's a valid concern, but not one that warrants a QApplication subclass. > > Right; that one is an issue if the user is no longer in control of > instantiating the Q*Application instance. Ah, that's a good point. Though quite frankly I don't see that as an issue. Applications can only have access to argc and argv if they write the main() function, which means they can continue to use the current functionality. I'm imaginiing that this new way is needed for platforms where a main() function makes no sense, in which case there's no command-line to begin with. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Sat Dec 10 03:23:50 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 09 Dec 2016 23:23:50 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: References: <4328581.XPRJ7y2mly@tonks> <20161207151213.65jkcclfq3b7bmae@mitya57.me> Message-ID: <1514152.RHHB768Ehq@tonks> On jueves, 8 de diciembre de 2016 02:02:36 ART Kevin Kofler wrote: > Dmitry Shachnev wrote: > > I also dislike this change. As Lisandro says, we do not want it in Debian > > (because we keep track of versions ourselves in the symbols file, and when > > the versions are in the symbols themselves they are just useless noise for > > us). And as you say, you do not want distributions Qt builds to be ABI > > incompatible with upstream (we also would like to avoid that), so if this > > patch gets applied upstream, we will be in a bad situation. > > > > I wonder what was the reason for OpenSUSE to have this change — I could > > not find a relevant changelog entry. Why cannot they just rebuild all > > packages using private headers for every Qt release, like we do? > > See my replies: RPM tracks symbol versions, but not the actual names, e.g., [snip] Thanks for clarifying the issue, this was neither inmediately clear to me. > The difference in implementation compared to the Qt_5.x symbol versions > would be that the private symbols would of course NOT provide the older > symbol versions, only the latest one, making it effectively an = dependency > rather than a >= one. Right. > RPM explicitly does NOT track individual symbols as Debian tooling > apparently does. And once again, right (although we can later force the last version to be the final one). And this is exactly where our tooling would make our lives not easy if the above gets implemented. So, as I've said before, there is a valid use case for this, although if implemented we might need to avoid it for some time, hopefully not too long. Thiago: should I push to gerrit the complete patch as it is or just the QPA stuff on one patch and the private symbols versioning on another? And to what branch exactly? -- 2: Windows con las funciones que realiza se clasifica como: * Un bug 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: 833 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Sat Dec 10 03:54:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 09 Dec 2016 18:54:11 -0800 Subject: [Development] Tagging private symbols as such In-Reply-To: <1514152.RHHB768Ehq@tonks> References: <4328581.XPRJ7y2mly@tonks> <1514152.RHHB768Ehq@tonks> Message-ID: <3101662.UH55Bh2aQB@tjmaciei-mobl1> Em sexta-feira, 9 de dezembro de 2016, às 23:23:50 PST, Lisandro Damián Nicanor Pérez Meyer escreveu: > Thiago: should I push to gerrit the complete patch as it is or just the QPA > stuff on one patch and the private symbols versioning on another? And to > what branch exactly? Please split. They do completely different things. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oleg.shalnev at gmail.com Sun Dec 11 13:16:11 2016 From: oleg.shalnev at gmail.com (Oleg Shalnev) Date: Sun, 11 Dec 2016 15:16:11 +0300 Subject: [Development] QTcpSocket disconnect signal surprise Message-ID: Good day, all in the list! Some problems during detection "connection lost" via KeepAlive and disconnect signal. After enabling KeepAlive, if there is some data in the socket buffer, disconnect signal is not working. So there is no way to detect cable lost. After disconnecting, socket don't send disconnect signal, don't send stateChanged signal, don't send error code. bytesToWrite() returns 0 bytes. If there is no data in the socket disconnected signal is working normal. Here is the test code. SocketTransport::SocketTransport(QObject *parent) : QObject(parent) { QObject::connect(&mSocket, &QTcpSocket::disconnected, this, &SocketTransport::onDisconnect); QObject::connect(&mSocket, &QTcpSocket::readyRead, this, &SocketTransport::readData); QObject::connect(&mSocket, &QTcpSocket::connected, this, &SocketTransport::onConnected); QObject::connect(&mTimer, &QTimer::timeout, this, &SocketTransport::writeData, Qt::QueuedConnection); } void SocketTransport::establishConnection() { mSocket.connectToHost("192.168.1.2", 3333); } void SocketTransport::onDisconnect() { qDebug()<<"On disconnect"; } void SocketTransport::readData() { } void SocketTransport::onConnected() { qDebug()<<"OnConnected"; mSocket.setSocketOption(QAbstractSocket::KeepAliveOption, 1); int Idle=1; int Count=2; int Interval=1; if(setsockopt(static_cast(mSocket.socketDescriptor()), IPPROTO_TCP, TCP_KEEPIDLE, &Idle, sizeof(Idle))<0) qDebug()<<"Error setsockopt IPPROTO_TCP, TCP_KEEPIDLE"; if(setsockopt(static_cast(mSocket.socketDescriptor()),IPPROTO_TCP, TCP_KEEPCNT, &Count, sizeof(Count))<0) qDebug()<<"Error setsockopt IPPROTO_TCP, TCP_KEEPCNT"; if(setsockopt(static_cast(mSocket.socketDescriptor()), IPPROTO_TCP, TCP_KEEPINTVL, &Interval, sizeof(Interval))<0) qDebug()<<"Error setsockopt IPPROTO_TCP, TCP_KEEPINTVL"; mTimer.start(1000); } void SocketTransport::writeData() { qDebug()<<"BYTES to write"< -------------- next part -------------- A non-text attachment was scrubbed... Name: Socket.tar.bz2 Type: application/x-bzip2 Size: 6641 bytes Desc: not available URL: From thiago.macieira at intel.com Sun Dec 11 19:36:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 11 Dec 2016 10:36:40 -0800 Subject: [Development] QTcpSocket disconnect signal surprise In-Reply-To: References: Message-ID: <6166153.GG6WPrlWZY@tjmaciei-mobl1> On domingo, 11 de dezembro de 2016 15:16:11 PST Oleg Shalnev wrote: > Good day, all in the list! > > Some problems during detection "connection lost" via KeepAlive and > disconnect signal. > > After enabling KeepAlive, if there is some data in the socket buffer, > disconnect signal is not working. So there is no way to detect cable lost. > > After disconnecting, socket don't send disconnect signal, don't send > stateChanged signal, don't send error code. > bytesToWrite() returns 0 bytes. > > If there is no data in the socket disconnected signal is working normal. [cut] > Can enybody help me with this problem? [This is the list for development of Qt, so I am assuming we're trying to figure out if this is a bug in Qt] Can you check with a tool like strace (on Linux) if the socket disconnects? What's the difference in OS behaviour between the case when it works and when it doesn't? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Sebastian.Loesch at governikus.de Mon Dec 12 10:36:55 2016 From: Sebastian.Loesch at governikus.de (=?utf-8?B?TMO2c2NoLCBTZWJhc3RpYW4=?=) Date: Mon, 12 Dec 2016 09:36:55 +0000 Subject: [Development] Review needed on new TLS feature "server side signature algorithms" Message-ID: <1481535385.1000.3.camel@governikus.de> Hello, I would like to contribute a patch to qt's network module to make the signature algorithms on the server side configurable for TLS connections. I am looking for someone with knowledge in TLS to review my patch on gerrit: https://codereview.qt-project.org/#/c/173427/ Thanks in advance for any feedback. Best regards Sebastian From timur.pocheptsov at qt.io Mon Dec 12 10:44:07 2016 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Mon, 12 Dec 2016 09:44:07 +0000 Subject: [Development] Review needed on new TLS feature "server side signature algorithms" In-Reply-To: <1481535385.1000.3.camel@governikus.de> References: <1481535385.1000.3.camel@governikus.de> Message-ID: Hi, I'll review the patch this week (well, somebody will probably do it faster). Best regards, Timur. ________________________________ From: Development on behalf of Lösch, Sebastian Sent: Monday, December 12, 2016 10:36:55 AM To: development at qt-project.org Subject: [Development] Review needed on new TLS feature "server side signature algorithms" Hello, I would like to contribute a patch to qt's network module to make the signature algorithms on the server side configurable for TLS connections. I am looking for someone with knowledge in TLS to review my patch on gerrit: https://codereview.qt-project.org/#/c/173427/ Thanks in advance for any feedback. Best regards Sebastian _______________________________________________ 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 mark.dewit at iesve.com Mon Dec 12 10:56:35 2016 From: mark.dewit at iesve.com (Mark De Wit) Date: Mon, 12 Dec 2016 09:56:35 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: <2624452.zT3LX7U3yD@tjmaciei-mobl1> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <2730654.ajvTuP4Uuq@tjmaciei-mobl1> <584B2725.2020700@gmail.com> <2624452.zT3LX7U3yD@tjmaciei-mobl1> Message-ID: <3709A7D425EE8C45991DB29EC2FACA8827578CA2@GL-EXC-01.iesve.com> I have an application based on qt-solutions qtwinmigrate sample. Because we're integrating Qt into an existing MFC application, we're not even running QApplication exec. The application uses MFC's entry point for startup and drives the Qt event loop manually as part of the MFC event loop. Mark -----Original Message----- From: Development [mailto:development-bounces+mark.dewit=iesve.com at qt-project.org] On Behalf Of Thiago Macieira Sent: 10 December 2016 00:43 To: development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Em sexta-feira, 9 de dezembro de 2016, às 16:50:29 PST, Matthew Woehlke escreveu: > On 2016-12-09 16:23, Thiago Macieira wrote: > > Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke > > > > escreveu: > >> I can work around that, though it's obnoxious. I'm more concerned about > >> not being able to tinker with the CLI arguments before Qt gets them. > > > > That's a valid concern, but not one that warrants a QApplication subclass. > > Right; that one is an issue if the user is no longer in control of > instantiating the Q*Application instance. Ah, that's a good point. Though quite frankly I don't see that as an issue. Applications can only have access to argc and argv if they write the main() function, which means they can continue to use the current functionality. I'm imaginiing that this new way is needed for platforms where a main() function makes no sense, in which case there's no command-line to begin with. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From b.terrier at gmail.com Mon Dec 12 11:07:56 2016 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Mon, 12 Dec 2016 11:07:56 +0100 Subject: [Development] A new approach for Qt main() In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA8827578CA2@GL-EXC-01.iesve.com> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <2730654.ajvTuP4Uuq@tjmaciei-mobl1> <584B2725.2020700@gmail.com> <2624452.zT3LX7U3yD@tjmaciei-mobl1> <3709A7D425EE8C45991DB29EC2FACA8827578CA2@GL-EXC-01.iesve.com> Message-ID: 2016-12-12 10:56 GMT+01:00 Mark De Wit : > I have an application based on qt-solutions qtwinmigrate sample. > > Because we're integrating Qt into an existing MFC application, we're not even running QApplication exec. The application uses MFC's entry point for startup and drives the Qt event loop manually as part of the MFC event loop. > > Mark I also did something like that on Linux with a software written with another graphical framework. We made it work by calling QApplication::processEvents() in the other framework event loop. Benjamin From annulen at yandex.ru Mon Dec 12 15:49:13 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 12 Dec 2016 17:49:13 +0300 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <2730654.ajvTuP4Uuq@tjmaciei-mobl1> <584B2725.2020700@gmail.com> <2624452.zT3LX7U3yD@tjmaciei-mobl1> <3709A7D425EE8C45991DB29EC2FACA8827578CA2@GL-EXC-01.iesve.com> Message-ID: <282721481554153@web2g.yandex.ru> 12.12.2016, 13:08, "Benjamin TERRIER" : > 2016-12-12 10:56 GMT+01:00 Mark De Wit : >>  I have an application based on qt-solutions qtwinmigrate sample. >> >>  Because we're integrating Qt into an existing MFC application, we're not even running QApplication exec. The application uses MFC's entry point for startup and drives the Qt event loop manually as part of the MFC event loop. >> >>  Mark > > I also did something like that on Linux with a software written with > another graphical framework. > We made it work by calling QApplication::processEvents() in the other > framework event loop. Same is true for QtWebKit in WebKit2 mode - in background processes we don't run exec() directly, it is invoked inside WTF::RunLoop. -- Regards, Konstantin From edward.welbourne at qt.io Mon Dec 12 17:11:07 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 12 Dec 2016 16:11:07 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: <282721481554153@web2g.yandex.ru> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <2730654.ajvTuP4Uuq@tjmaciei-mobl1> <584B2725.2020700@gmail.com> <2624452.zT3LX7U3yD@tjmaciei-mobl1> <3709A7D425EE8C45991DB29EC2FACA8827578CA2@GL-EXC-01.iesve.com> , <282721481554153@web2g.yandex.ru> Message-ID: Em sexta-feira, 9 de dezembro de 2016, às 10:44:24 PST, Lars Knoll escreveu: >>>>> Well, the problem is that the main() entry point is causing huge >>>>> amounts of issues on at least Android and iOS. We’d help those >>>>> platforms a lot if we didn’t support this kind of entry point (on >>>>> those platforms) anymore. But I agree that we can’t break this in >>>>> Qt 5, but we can prepare for Qt6. >>>>> >>>>> I’d propose to define a new entry point that works better on these >>>>> platforms and offering that as the recommended way for new >>>>> apps. The best solution is probably a static library that provides >>>>> callbacks that can be used to initialize things. On 9 December 2016 18:05, Thiago Macieira replied: >>>> Can we get a description of what those problems are, for those of >>>> us who have never developed anything for those OSes, so we're not >>>> discussing things in the abstract? I haven't seen an actual reply to that, but these fragments at least point towards a sketch of the reply: 2016-12-12 10:56 GMT+01:00 Mark De Wit : >>> I have an application based on qt-solutions qtwinmigrate sample. >>> >>> Because we're integrating Qt into an existing MFC application, >>> we're not even running QApplication exec. The application uses >>> MFC's entry point for startup and drives the Qt event loop >>> manually as part of the MFC event loop. 12.12.2016, 13:08, "Benjamin TERRIER" : >> I also did something like that on Linux with a software written with >> another graphical framework. >> We made it work by calling QApplication::processEvents() in the other >> framework event loop. 12 December 2016 15:49 Konstantin Tokarev > Same is true for QtWebKit in WebKit2 mode - in background processes we > don't run exec() directly, it is invoked inside WTF::RunLoop. and I've heard some conversations over meals, so let's sketch what I think is the main pattern for which the present architecture is a problem: * In some systems, the event loop isn't ours to control. What that means in practice is that all we can do is register call-backs to respond to events. Details remain a mystery, but presumably we get some way to register a "getting started" call-back, which can presumably register a "shutting down" call-back and assorted call-backs for other events. I'd like to see detailed descriptions of what the actual details are, for this, on each of the platforms for which traditional C main() isn't a good model. To have one architecture that works for such environments and also works for the traditional main() context, we need Qt's event loop to be optional. Something we may as well call QApplication might provide a default event loop implementation (for main() use), but none of the rest of our code should presume this is the event loop in use. We need all our "register handler" APIs to be designed to be agnostic about whose event loop those handlers get registered to. This shall mean even Qt-internal events (e.g. those implementing signal/slot interactions) can be packaged as platform-native events (that Qt shall unpack and enact when they're delivered). We should, none the less, be able to package that architecture with Q*Application objects that *do* provide an event loop so that existing main() users and tutorials don't need to change what main() looks like; there might be some changes to how they register handlers and there shall surely be some changes "under the bonnet" to how moc implements signals and slots (so that their handling is message-loop-agnostic). ... and that's about as much as I think anyone can say about the future architecture until someone familiar with the main()-incompatible world can explain to us all what the contexts are in which the old way fails. Perhaps we need a Wiki page, detailing the different ways platforms support start-up and shut-down. So let's have a wiki page for that: * https://wiki.qt.io/Application_Start-up_Patterns While I'm at it, I've put that into * https://wiki.qt.io/Category:Developing_Qt::Architecture and invite anyone who knows about wiki pages that talk about Qt's architecture to add them to [[Category:Developing_Qt::Architecture]]. They might be more discoverable that way. Eddy. From thiago.macieira at intel.com Mon Dec 12 17:28:54 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 12 Dec 2016 08:28:54 -0800 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <3709A7D425EE8C45991DB29EC2FACA8827578CA2@GL-EXC-01.iesve.com> Message-ID: <2530585.VD2ummT5Gf@tjmaciei-mobl1> On segunda-feira, 12 de dezembro de 2016 11:07:56 PST Benjamin TERRIER wrote: > 2016-12-12 10:56 GMT+01:00 Mark De Wit : > > I have an application based on qt-solutions qtwinmigrate sample. > > > > Because we're integrating Qt into an existing MFC application, we're not > > even running QApplication exec. The application uses MFC's entry point > > for startup and drives the Qt event loop manually as part of the MFC > > event loop. > > > > Mark > > I also did something like that on Linux with a software written with > another graphical framework. > We made it work by calling QApplication::processEvents() in the other > framework event loop. Both cases are served by integrating the event loop of the foreign framework with Qt's. Doesn't matter how you start it (though I certainly prefer Qt's app.exec()), but you need to integrate. processEvents() is not a solution. It's, at best, a crude hack. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Dec 12 17:31:57 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 12 Dec 2016 08:31:57 -0800 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <282721481554153@web2g.yandex.ru> Message-ID: <4927096.DTFPD67lI3@tjmaciei-mobl1> On segunda-feira, 12 de dezembro de 2016 16:11:07 PST Edward Welbourne wrote: > I haven't seen an actual reply to that, but these fragments at least > point towards a sketch of the reply: We already have a solution for those cases and that's QAbstractEventDispatcher. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mathias at taschenorakel.de Mon Dec 12 19:53:50 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Mon, 12 Dec 2016 19:53:50 +0100 Subject: [Development] A new approach for Qt main() In-Reply-To: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> Message-ID: Hi, Seems this turned into a nice bike shed discussion quickly, so let me use the chance to present my preferred Qt main(). I am totally convinced that this one should rule the Qt world: class BlueBikeShedApplication : public QApplication { Q_OBJECT public: using QApplication::QApplication; int run() { if (!parseCommandLine()) return EXIT_FAILURE; if (!initializeColorBucket()) return EXIT_FAILURE; setupBrush(); return exec(); } }; int main(int argc, char *argv[]) { return BlueBikeShedApplication{argc, argv}.run(); } The big advantage I see in this approach is, that you work within a proper QObject context with fully setup QApplication early. Also this main() is sufficiently generic to be hidden in a platform specific macro, or static library. Thank you for reading, Mathias From Morten.Sorvig at qt.io Mon Dec 12 22:12:31 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Mon, 12 Dec 2016 21:12:31 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: <2324419.ev00mqjj6g@tjmaciei-mobl1> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> <2324419.ev00mqjj6g@tjmaciei-mobl1> Message-ID: <82BEDDDF-F134-4A5F-9D81-FC323750FAAF@qt.io> > On 9 Dec 2016, at 18:05, Thiago Macieira wrote: > > Em sexta-feira, 9 de dezembro de 2016, às 10:44:24 PST, Lars Knoll escreveu: >> Well, the problem is that the main() entry point is causing huge amounts of >> issues on at least Android and iOS. We’d help those platforms a lot if we >> didn’t support this kind of entry point (on those platforms) anymore. But I >> agree that we can’t break this in Qt 5, but we can prepare for Qt6. >> >> I’d propose to define a new entry point that works better on these platforms >> and offering that as the recommended way for new apps. The best solution is >> probably a static library that provides callbacks that can be used to >> initialize things. > > Can we get a description of what those problems are, for those of us who have > never developed anything for those OSes, so we're not discussing things in the > abstract? For some background, here’s what typical application startup looks like on macOS, NaCl, and Emscripten: macOS: Define the application delegate, create instance of it in main() // Define application delegate with app lifecycle callbacks @interface AppDelegate () @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { // Init application here } - (void)applicationWillTerminate:(NSNotification *)aNotification { // Tear down here } @end // In main, install application delegate and start the app int main(int argc, const char *argv[]) { NSApplication *app = [NSApplication sharedApplication]; app.delegate = [[AppDelegate alloc] initWithArgc:argc argv:argv]; return NSApplicationMain(argc, argv); } Native Client: Define pp::CreateModule() and return the application module (which is a subclass of pp::Module) namespace pp { Module* CreateModule() { return new ApplicationModule(); } } Emscripten: implement main() int main(int argc, const char *argv[) { // Init application here return 0; } main() should/must return to keep the web page responsive. There is API for simulating a main that does not return and preserve the stack, see emscripten_set_main_loop() in the emscripten documentation. Morten From Morten.Sorvig at qt.io Mon Dec 12 22:14:52 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Mon, 12 Dec 2016 21:14:52 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: <2624452.zT3LX7U3yD@tjmaciei-mobl1> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <2730654.ajvTuP4Uuq@tjmaciei-mobl1> <584B2725.2020700@gmail.com> <2624452.zT3LX7U3yD@tjmaciei-mobl1> Message-ID: <56924756-77B6-48FA-B25D-2AB8720A29AA@qt.io> > On 10 Dec 2016, at 01:43, Thiago Macieira wrote: > > Em sexta-feira, 9 de dezembro de 2016, às 16:50:29 PST, Matthew Woehlke > escreveu: >> On 2016-12-09 16:23, Thiago Macieira wrote: >>> Em sexta-feira, 9 de dezembro de 2016, às 15:28:13 PST, Matthew Woehlke >>> >>> escreveu: >>>> I can work around that, though it's obnoxious. I'm more concerned about >>>> not being able to tinker with the CLI arguments before Qt gets them. >>> >>> That's a valid concern, but not one that warrants a QApplication subclass. >> >> Right; that one is an issue if the user is no longer in control of >> instantiating the Q*Application instance. > > Ah, that's a good point. > > Though quite frankly I don't see that as an issue. Applications can only have > access to argc and argv if they write the main() function, which means they > can continue to use the current functionality. > > I'm imaginiing that this new way is needed for platforms where a main() > function makes no sense, in which case there's no command-line to begin with. That is one use case, another is where the standard way to start the native platform and event loop is not compatible with the Q*Application on stack and app.exec() pattern. (See macOS example in the other mail) Morten From thiago.macieira at intel.com Mon Dec 12 22:32:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 12 Dec 2016 13:32:01 -0800 Subject: [Development] A new approach for Qt main() In-Reply-To: <82BEDDDF-F134-4A5F-9D81-FC323750FAAF@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <2324419.ev00mqjj6g@tjmaciei-mobl1> <82BEDDDF-F134-4A5F-9D81-FC323750FAAF@qt.io> Message-ID: <4991693.fqRYWQJZ0N@tjmaciei-mobl1> Em segunda-feira, 12 de dezembro de 2016, às 21:12:31 PST, Morten Sorvig escreveu: > > Can we get a description of what those problems are, for those of us who > > have never developed anything for those OSes, so we're not discussing > > things in the abstract? > > For some background, here’s what typical application startup looks like on > macOS, NaCl, and Emscripten: > macOS: Define the application delegate, create instance of it in main() > > > // Define application delegate with app lifecycle callbacks > @interface AppDelegate () > @end > > @implementation AppDelegate > - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { > // Init application here > } > > - (void)applicationWillTerminate:(NSNotification *)aNotification { > // Tear down here > } > @end > > // In main, install application delegate and start the app > int main(int argc, const char *argv[]) > { > NSApplication *app = [NSApplication sharedApplication]; > app.delegate = [[AppDelegate alloc] initWithArgc:argc argv:argv]; > return NSApplicationMain(argc, argv); > } Thanks, but the above makes no sense to me. There are a couple of identifiers in your code that I've never seen before and aren't defined in the application (NSApplication, NSApplicationMain), plus there's no Qt code anywhere. I don't know what the code is doing. I was hoping you'd give some material on how one currently has to integrate Qt with their platform. > Native Client: Define pp::CreateModule() and return the application module > (which is a subclass of pp::Module) > > namespace pp { > Module* CreateModule() { > return new ApplicationModule(); > } > } Ok, this is a factory. That's a very important difference. There's also no command-line. Still, I need the example of how one has to integrate with Qt. I have no idea what the application module is supposed to do, what it can do, when it can do that, etc. > Emscripten: implement main() > > int main(int argc, const char *argv[) { > // Init application here > return 0; > } > > main() should/must return to keep the web page responsive. There is API for > simulating a main that does not return and preserve the stack, see > emscripten_set_main_loop() in the emscripten documentation. And obviously there's something else going on, otherwise the code above does nothing. In fact, I'm surprised it needs a main function at all... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Tue Dec 13 10:36:54 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 13 Dec 2016 09:36:54 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io>, Message-ID: Hi, The joke of the bikeshedding aside I for one do like the idea of exporting a QObject sub-class instead of a function. That makes it easier to extend in the future with more entry-points as slots for example. Simon ________________________________ From: Development on behalf of Mathias Hasselmann Sent: Monday, December 12, 2016 7:53:50 PM To: development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, Seems this turned into a nice bike shed discussion quickly, so let me use the chance to present my preferred Qt main(). I am totally convinced that this one should rule the Qt world: class BlueBikeShedApplication : public QApplication { Q_OBJECT public: using QApplication::QApplication; int run() { if (!parseCommandLine()) return EXIT_FAILURE; if (!initializeColorBucket()) return EXIT_FAILURE; setupBrush(); return exec(); } }; int main(int argc, char *argv[]) { return BlueBikeShedApplication{argc, argv}.run(); } The big advantage I see in this approach is, that you work within a proper QObject context with fully setup QApplication early. Also this main() is sufficiently generic to be hidden in a platform specific macro, or static library. Thank you for reading, Mathias _______________________________________________ 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 laszlo.agocs at qt.io Tue Dec 13 10:42:05 2016 From: laszlo.agocs at qt.io (Laszlo Agocs) Date: Tue, 13 Dec 2016 09:42:05 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io>, Message-ID: Hi, How does this handle the cases that need code before the QGuiApplication construction? AFAICS it does not. Laszlo From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Simon Hausmann Sent: Tuesday, December 13, 2016 10:37 AM To: Mathias Hasselmann ; development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, The joke of the bikeshedding aside I for one do like the idea of exporting a QObject sub-class instead of a function. That makes it easier to extend in the future with more entry-points as slots for example. Simon ________________________________ From: Development > on behalf of Mathias Hasselmann > Sent: Monday, December 12, 2016 7:53:50 PM To: development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, Seems this turned into a nice bike shed discussion quickly, so let me use the chance to present my preferred Qt main(). I am totally convinced that this one should rule the Qt world: class BlueBikeShedApplication : public QApplication { Q_OBJECT public: using QApplication::QApplication; int run() { if (!parseCommandLine()) return EXIT_FAILURE; if (!initializeColorBucket()) return EXIT_FAILURE; setupBrush(); return exec(); } }; int main(int argc, char *argv[]) { return BlueBikeShedApplication{argc, argv}.run(); } The big advantage I see in this approach is, that you work within a proper QObject context with fully setup QApplication early. Also this main() is sufficiently generic to be hidden in a platform specific macro, or static library. Thank you for reading, Mathias _______________________________________________ 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 Simon.Hausmann at qt.io Tue Dec 13 11:24:48 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 13 Dec 2016 10:24:48 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io>, , Message-ID: Hi, I don't think it does handle those cases. But we're not talking about eliminating main(), we're talking about a second supported "launch" method. That said, it's still possible to run code before the constructor, although it's not pretty. Simon ________________________________ From: Laszlo Agocs Sent: Tuesday, December 13, 2016 10:42:05 AM To: Simon Hausmann; Mathias Hasselmann; development at qt-project.org Subject: RE: [Development] A new approach for Qt main() Hi, How does this handle the cases that need code before the QGuiApplication construction? AFAICS it does not. Laszlo From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Simon Hausmann Sent: Tuesday, December 13, 2016 10:37 AM To: Mathias Hasselmann ; development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, The joke of the bikeshedding aside I for one do like the idea of exporting a QObject sub-class instead of a function. That makes it easier to extend in the future with more entry-points as slots for example. Simon ________________________________ From: Development > on behalf of Mathias Hasselmann > Sent: Monday, December 12, 2016 7:53:50 PM To: development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, Seems this turned into a nice bike shed discussion quickly, so let me use the chance to present my preferred Qt main(). I am totally convinced that this one should rule the Qt world: class BlueBikeShedApplication : public QApplication { Q_OBJECT public: using QApplication::QApplication; int run() { if (!parseCommandLine()) return EXIT_FAILURE; if (!initializeColorBucket()) return EXIT_FAILURE; setupBrush(); return exec(); } }; int main(int argc, char *argv[]) { return BlueBikeShedApplication{argc, argv}.run(); } The big advantage I see in this approach is, that you work within a proper QObject context with fully setup QApplication early. Also this main() is sufficiently generic to be hidden in a platform specific macro, or static library. Thank you for reading, Mathias _______________________________________________ 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 Simon.Hausmann at qt.io Tue Dec 13 11:25:58 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 13 Dec 2016 10:25:58 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io>, , , Message-ID: Apologies, I should've expanded a little more on what I said. For example if we expose a QObject class to Qt instead of a function, then we could dispatch a static meta-call to a static initialization function that is called before the constructor, if present. Introspection makes that quite easy I think. Simon ________________________________ From: Simon Hausmann Sent: Tuesday, December 13, 2016 11:24:48 AM To: Laszlo Agocs; Mathias Hasselmann; development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, I don't think it does handle those cases. But we're not talking about eliminating main(), we're talking about a second supported "launch" method. That said, it's still possible to run code before the constructor, although it's not pretty. Simon ________________________________ From: Laszlo Agocs Sent: Tuesday, December 13, 2016 10:42:05 AM To: Simon Hausmann; Mathias Hasselmann; development at qt-project.org Subject: RE: [Development] A new approach for Qt main() Hi, How does this handle the cases that need code before the QGuiApplication construction? AFAICS it does not. Laszlo From: Development [mailto:development-bounces+laszlo.agocs=qt.io at qt-project.org] On Behalf Of Simon Hausmann Sent: Tuesday, December 13, 2016 10:37 AM To: Mathias Hasselmann ; development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, The joke of the bikeshedding aside I for one do like the idea of exporting a QObject sub-class instead of a function. That makes it easier to extend in the future with more entry-points as slots for example. Simon ________________________________ From: Development > on behalf of Mathias Hasselmann > Sent: Monday, December 12, 2016 7:53:50 PM To: development at qt-project.org Subject: Re: [Development] A new approach for Qt main() Hi, Seems this turned into a nice bike shed discussion quickly, so let me use the chance to present my preferred Qt main(). I am totally convinced that this one should rule the Qt world: class BlueBikeShedApplication : public QApplication { Q_OBJECT public: using QApplication::QApplication; int run() { if (!parseCommandLine()) return EXIT_FAILURE; if (!initializeColorBucket()) return EXIT_FAILURE; setupBrush(); return exec(); } }; int main(int argc, char *argv[]) { return BlueBikeShedApplication{argc, argv}.run(); } The big advantage I see in this approach is, that you work within a proper QObject context with fully setup QApplication early. Also this main() is sufficiently generic to be hidden in a platform specific macro, or static library. Thank you for reading, Mathias _______________________________________________ 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 Kai.Koehne at qt.io Tue Dec 13 13:13:12 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 13 Dec 2016 12:13:12 +0000 Subject: [Development] Rules for Third-Party components in Qt 4.8 onwards Message-ID: Hi, I'd like to put down the rules on how we handle code in Qt that we as Qt contributors do not have copyright over ourselves in a QUIP: https://codereview.qt-project.org/#/c/177201/6/quip-0004.txt I suggest that - Every third party component must be documented by a qt_attribution.json file - Adding a third-party component that will become part of a Qt library, plugin or tool needs approval by the Chief Maintainer - Third-party components that become part of a Qt library, plugin, or tool need to be mentioned in the change log of the release in a [Third-Party Code] area. Regards Kai -- Kai Köhne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From edward.welbourne at qt.io Tue Dec 13 14:51:24 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 13 Dec 2016 13:51:24 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: <82BEDDDF-F134-4A5F-9D81-FC323750FAAF@qt.io> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> <2324419.ev00mqjj6g@tjmaciei-mobl1>, <82BEDDDF-F134-4A5F-9D81-FC323750FAAF@qt.io> Message-ID: Morten Sorvig supplied: > For some background, here’s what typical application startup looks > like on macOS, NaCl, and Emscripten: I've updated [0] to illustrate these. [0] https://wiki.qt.io/Application_Start-up_Patterns > macOS: Define the application delegate, create instance of it in main() > > // Define application delegate with app lifecycle callbacks > @interface AppDelegate () > @end > > @implementation AppDelegate > - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { > // Init application here > } > > - (void)applicationWillTerminate:(NSNotification *)aNotification { > // Tear down here > } > @end Please say more about what has to happen in these, especially init; presumably, we need to add some handlers to something like an event queue, to ensure our application gets told what's happening and when to respond to it. > // In main, install application delegate and start the app > int main(int argc, const char *argv[]) > { > NSApplication *app = [NSApplication sharedApplication]; > app.delegate = [[AppDelegate alloc] initWithArgc:argc argv:argv]; > return NSApplicationMain(argc, argv); > } I take it NSApplicationMain(argc, argv) contains a system standard event loop that looks to the shared NSApplication for its control. > Native Client: Define pp::CreateModule() and return the application > module (which is a subclass of pp::Module) > > namespace pp { > Module* CreateModule() { > return new ApplicationModule(); > } > } I need some clue what methods pp::Module allows us to override and how we can, by doing so, control what the resulting app does. > Emscripten: implement main() > > int main(int argc, const char *argv[) { > // Init application here > return 0; > } > > main() should/must return to keep the web page responsive. I take it, then, that "main()" isn't the whole program, in the classic C way, just an insertion into an existing running something - into which we presumably inject some application-specific objects that connect themselves into the event stream and provide ways to respond. > There is API for simulating a main that does not return and preserve > the stack, see emscripten_set_main_loop() in the emscripten > documentation. Sounds complicated. Better to fit in naturally with the native system's preferred modus operandi. Illustrations (maybe provided by link to existing examples) of how we presently shoe-horn our existing architecture into the various cases would be a passable first attempt at answering the open questions ... Eddy. From Kai.Koehne at qt.io Tue Dec 13 17:20:35 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Tue, 13 Dec 2016 16:20:35 +0000 Subject: [Development] Rules for Third-Party components in Qt 5.8 onwards Message-ID: Hi, (I'll try to answer some comments made in the gerrit review here. IMO gerrit works great for editorial stuff, but not for more substantial things). > [Tobias Hunger] > I would make the homepage mandatory in the attribution file. That information is critical IMHO when you want to find out more about that piece of code. If there's a homepage, by all means, specify the "Homepage" property. I didn't make it mandatory though because we have code where there's just no legitimate upstream homepage, most often because Qt itself is the 'upstream'. Putting "www.qt.io" here would be possible, but also confusing ;) That's e.g. the case for some of the text codes, like http://doc-snapshots.qt.io/qt5-5.8/qtcore-attribution-qtsciicodec.html. > I would also suggest to add something about giving the exact revision of the code (full download link, repo where the code came from and exact version specification in that repo) in the commit message when initially > importing the code or when updating it. For my taste it is currently too hard to find out which exact versions of stuff we use. It is very important to track the upstream version used, so that we can easily see when something is outdated and track custom changes done before it's imported. You should not only put that in the commit message though. In qt_attribution.json file you should set a 'Version' field that you should set to the official property. This could also be e.g. an SHA if there's no marked upstream version. In addition, you should set the 'DownloadLocation' field that should link to the upstream package / installer / ... When creating the initial qt_attribution.json files, I was adding this information when it was obvious, but I didn't do much due diligence. I'd appreciate it if contributors/maintainers would complete the information wherever possible. > [Robin Burchell on Copyright field being mandatory] > Having the license for instance as mandatory seems quite reasonable, but I'm less certain about this. Keeping it maintained could be quite a burden, and for complex software I can imagine it ending up quite long. Does > it have significant value? What's the purpose of it? > > For example, I looked at another project I've been a significant part of, started around 2002, with a fairly constant stream of random contributors. There are 135 unique "Copyright" lines throughout the source, > although a number of these are duplicated authors with different year information. The most frequently repeated lines are repeated >100 times. I'm a bit unsure about the extra 'Copyright' field myself, especially if it duplicates the Copyright in the license file (like it is for the BSD licenses). I added it because it's sometimes requested by customers, and is also part of e.g. the SPDX and debian/copyright specifications [1,2]. In general, the copyright field shows the user a) when the copyright protection might run out and b) whom to contact in case one has questions. Also, even if not strictly required by some licenses, it is also acknowledging the original authors. So, I do think it adds value, also to the documentation. In practical terms, often bigger projects tend to have generic acknowledgements like Copyright XXXX the authors or Copyright XXXX the
and contributors If that is done upstream, it obviously is the right thing to keep it like that in the qt_attribution.json file, too. I can try to find out whether it's also ok to consolidate on our own. So, in summary, I'd keep the field mandatory, potentially consolidating it to one name. If the Copyright is also part of the License text itself (like for the typical BSD license), I've duplicated the lines in the past. If we decide to keep it this way, I can try to clarify it in the QUIP. [1]: https://spdx.org/spdx-specification-21-web-version#h.2grqrue [2]: https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/#copyright-field From konstantin at podsvirov.pro Tue Dec 13 20:11:53 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 13 Dec 2016 22:11:53 +0300 Subject: [Development] Fwd: [Interest] QtIFW 2.0.4 Release? Message-ID: <624041481656313@web12m.yandex.ru> An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Wed Dec 14 04:49:41 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 14 Dec 2016 00:49:41 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <3976954.qf18LPJo2m@tjmaciei-mobl1> References: <4328581.XPRJ7y2mly@tonks> <20161207151213.65jkcclfq3b7bmae@mitya57.me> <3976954.qf18LPJo2m@tjmaciei-mobl1> Message-ID: <12668037.T3J5yuIKVz@tonks> On miércoles, 7 de diciembre de 2016 08:02:20 ART Thiago Macieira wrote: [snip] > But the extra versioning is a further safety check: if something was missed > in the update, like for example some code compiled by the user (regardless > of use of package management), it will necessarily stop working. I not sure of the usefullnes in this case. If I remember correctly the linker will try first to locate the symbol with the right version and if it fails the first symbol that matches no matter it's version. I remember that when the symbols' version was added to Qt we did not have to rebuild anything: things just worked out without issues. And we where dealing with public symbols here. I never the less give it a try and compiled Qt 5.7.1 (latest snapshot) with the patch that changes QPA symbols' version to private ones. I've got segfaults while running Plasma, but no linking problems that I could see. Granted, I don't know why the crashes happened but I didn't directly see any effect of changing QPA's symbols's versions, so I don't know if code compiled by the user will necesarily stop working. Am I missing something here? -- If little green men land in your back yard, hide any little green women you've got in the house. Mike Harding, "The Armchair Anarchist's Almanac" Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From jani.heikkinen at qt.io Wed Dec 14 11:56:27 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 14 Dec 2016 10:56:27 +0000 Subject: [Development] new Qt 5.8.0 rc snapshot available Message-ID: Hi all, We have new snapshot for testing Linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/596/ Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/664/ Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/689/ src: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/latest_src/ Packages are based on https://codereview.qt-project.org/#/c/179514/ . Packages are RTA smoke tested and everything seems to be mostly OK so please test the packages to see if we are ready for RC or not. Please make sure all open blockers are visible in https://bugreports.qt.io/issues/?filter=18053. We are trying to get rc out still before Christmas so please fix all found blockers immediately! And remember, no any nice-to-have's in '5.8.0' anymore! br, Jani Heikkinen Release Manager From announce at qt-project.org Wed Dec 14 13:55:58 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 14 Dec 2016 12:55:58 +0000 Subject: [Development] [Announce] Qt 5.7.1 and Qt Creator 4.2 released In-Reply-To: References: Message-ID: Hi, I am happy to inform that Qt 5.7.1 and Qt Creator 4.2 are released today, see more info from http://blog.qt.io/blog/2016/12/14/qt-5-7-1-released/ and http://blog.qt.io/blog/2016/12/14/qt-creator-4-2-released/ Big thanks to everyone involved! br, Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From dominik.holland at pelagicore.com Wed Dec 14 16:54:03 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Wed, 14 Dec 2016 16:54:03 +0100 Subject: [Development] new Qt 5.8.0 rc snapshot available In-Reply-To: References: Message-ID: Hi, any plans on adding qtwayland to these packages as well ? Dominik Am 12/14/2016 um 11:56 AM schrieb Jani Heikkinen: > Hi all, > > We have new snapshot for testing > > Linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/596/ > Mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/664/ > Windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/689/ > src: http://download.qt.io/snapshots/qt/5.8/5.8.0-rc/latest_src/ > > Packages are based on https://codereview.qt-project.org/#/c/179514/ . Packages are RTA smoke tested and everything seems to be mostly OK so please test the packages to see if we are ready for RC or not. Please make sure all open blockers are visible in https://bugreports.qt.io/issues/?filter=18053. > > We are trying to get rc out still before Christmas so please fix all found blockers immediately! And remember, no any nice-to-have's in '5.8.0' anymore! > > br, > Jani Heikkinen > Release Manager > > > > _______________________________________________ > 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 mwoehlke.floss at gmail.com Wed Dec 14 21:35:20 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 14 Dec 2016 15:35:20 -0500 Subject: [Development] A new approach for Qt main() In-Reply-To: <2624452.zT3LX7U3yD@tjmaciei-mobl1> References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <2730654.ajvTuP4Uuq@tjmaciei-mobl1> <584B2725.2020700@gmail.com> <2624452.zT3LX7U3yD@tjmaciei-mobl1> Message-ID: <5851AD08.2030901@gmail.com> On 2016-12-09 19:43, Thiago Macieira wrote: > Em sexta-feira, 9 de dezembro de 2016, às 16:50:29 PST, Matthew Woehlke escreveu: >> On 2016-12-09 16:23, Thiago Macieira wrote: >>> That's a valid concern, but not one that warrants a QApplication subclass. >> >> Right; that one is an issue if the user is no longer in control of >> instantiating the Q*Application instance. > > Ah, that's a good point. > > Though quite frankly I don't see that as an issue. Applications can only have > access to argc and argv if they write the main() function, which means they > can continue to use the current functionality. > > I'm imaginiing that this new way is needed for platforms where a main() > function makes no sense, in which case there's no command-line to begin with. If we're not deprecating the traditional main(), that WFM. (That's not how I read the initial post, however...) -- Matthew From Morten.Sorvig at qt.io Wed Dec 14 22:52:43 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Wed, 14 Dec 2016 21:52:43 +0000 Subject: [Development] A new approach for Qt main() In-Reply-To: References: <80015823-FCF5-4FD2-AFF4-9BDA5FD6884D@qt.io> <0011A189-CA27-47A3-B411-804422199864@qt.io> <2324419.ev00mqjj6g@tjmaciei-mobl1> <82BEDDDF-F134-4A5F-9D81-FC323750FAAF@qt.io> Message-ID: <85B4EE6C-E7AC-41F9-86CF-1693D1EC48F2@qt.io> > On 13 Dec 2016, at 14:51, Edward Welbourne wrote: > > Morten Sorvig supplied: > >> For some background, here’s what typical application startup looks >> like on macOS, NaCl, and Emscripten: > > I've updated [0] to illustrate these. > [0] https://wiki.qt.io/Application_Start-up_Patterns Thanks! > >> macOS: Define the application delegate, create instance of it in main() >> >> // Define application delegate with app lifecycle callbacks >> @interface AppDelegate () >> @end >> >> @implementation AppDelegate >> - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { >> // Init application here >> } >> >> - (void)applicationWillTerminate:(NSNotification *)aNotification { >> // Tear down here >> } >> @end > > Please say more about what has to happen in these, especially init; > presumably, we need to add some handlers to something like an event > queue, to ensure our application gets told what's happening and when to > respond to it. You are correct. On the highest level, the “Init” code would be: g_application = new QGuiApplicaiton() // Init application (create app windows etc) This gives us a nice ordered startup: The native platform has been initialized, we initialize Qt, and then call application initialization code. Digging into QGuiApplicaiton construction, it will among other things select and load a platform plugin, and then ask that platform plugin to create an event dispatcher, which hooks into the native event queue. The Qt event dispatcher implementation on macOS supports integrating with an already running event loop, which is the case here. Calling app.exec() is not required (and would not work in the callback). Morten From alexander.blasche at qt.io Thu Dec 15 10:04:10 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Thu, 15 Dec 2016 09:04:10 +0000 Subject: [Development] Nominating Teemu Holappa for Approver and Maintainer status. In-Reply-To: References: Message-ID: Congratulations to Teemu. His rights have been adjusted. -- Alex ________________________________________ From: Development on behalf of Gatis Paeglis Sent: Thursday, 24 November 2016 2:00:32 PM To: development at qt-project.org Subject: [Development] Nominating Teemu Holappa for Approver and Maintainer status. Hi, I'd like to nominate Teemu Holappa for the Approver status. He joined Digia (now The Qt Company) 3+ years ago as a Qt consultant. Teemu has contributed to meta-boot2qt and anything else that needs fixing to get Qt for Device Creation releases out the door. Here is his gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z Teemu also has done a good job at reviewing changes for meta-{boot2qt, qt5, mingw} among other projects: https://codereview.qt-project.org/#/q/reviewer:%22Teemu+Holappa+%253Cteemu.holappa%2540qt.io%253E%22+status:merged,n,z I'd also like to nominate him as the Maintainer of the qtdeviceutilities module (http://code.qt.io/cgit/qt/qtdeviceutilities.git/). Teemu has heavily refactored this module and added significant amount of new features. He is the go-to guy in the team when qtdeviceutilities is the topic. Gatis Paeglis. From soroush.rabiei at gmail.com Thu Dec 15 11:30:33 2016 From: soroush.rabiei at gmail.com (Soroush Rabiei) Date: Thu, 15 Dec 2016 14:00:33 +0330 Subject: [Development] Calendar Systems proposal Message-ID: 1. Purpose Nowadays, almost all major programming frameworks support calendar globalization. We are a small group of developers working with non-Gregorian calendars and we believe Qt must support this too. This proposal discusses details of our plan (and early implementation) to add support for multiple calendar systems in Qt library. 2.History Originally there was four plans described in [1] based on ideas discussed in [2]. These talks (dated back to 2011) were never implemented and eventually abandoned. 3. Current Status Currently there is no support of any calendar system other than Gregorian. Gregorian calendar is widely used in western countries. However most countries in Middle-east, Asia and Africa use other calendar systems. Unfortunately there is no support for them. 4. Requirements Users of calendar systems expect same functionality provided by default calendar for their local calendar (at least we do so). Following list describes requirements of date/time API. 4.1. Such a feature must provide an API same as QDate, and all related classes. Adding convenient classed for each calendar type (QJalaliDate, QHebrewDate, QIslamicDate, etc.) will be discussed, Tough we believe any API without QDate integration will not satisfy our needs. 4.2. Backward compatibility must be kept in both public API and semantics of QDate, QDateTime and related classes. Such a feature must not affect any program that uses date, but has nothing to do with the calendar systems. A program compiled with Qt 5.9 must behave the way it do with 5.8, whether it utilizes calendar systems or not. There will be no assumption on user locale, nor the host system’s default calendar (as there is not any now). 4.3. The Public API and semantics of other parts of Qt that work with QDate, should not be changed. For instance, regardless of the calendar system that a QDate object uses, a QSqlQuery must be able to use it. And QVarient must be able to store/read it the way it did before. We prefer not to change private API and implementation as well, but if we had have to, (and it’s an affordable change) we will do it. For example we may need to change QtSql and QtCore classes to overwrite calendar system of QDate object to work properly. We hope we will find a way to avoid this. These examples are based on the assumption that QDate API will change, and calendar system support will be added directly to QDate (See S5 below) 4.4. Calendar systems and Locales, are irrelevant except month naming. There is nothing to do with the locales while implementing calendar system: Adding a new calendar is not about naming months for some locale. Some calendars are different in the math behind. For example, the year in Jalali calendar starts in 21st March. First 6 months are 31 days and next 6 months are 30 except 12th. Changing locale should not change calendar system. And there will be no information on calendar system in supported locales. (There is no default calendar in locale definition). It’s necessary to have multiple calendars at the same time in an application, and it’s necessary to have calendar system in all locales. Also calendar System and Time Zones are irrelevant. There were assumptions on previous plans (described in [1]) that are totally misunderstanding of the calendar systems. A particular plan was about adding calendar integration to QLocale, which we do believe is wrong in all aspects. Because calendar system has nothing to do with culture. A calendar is an abstract astronomical concept. 5. API Candidates The plan is to implement support for at least five most-used calendar systems. Each calendar’s implementation will be added into a new class named `QCalendarSystem`. This class will provide information on calendar system details, like how many days are in each month and if a year is leap year or normal. This class will also contain the calculation code needed for QDate. Most importantly, how to convert between julian day and calendar date. Currently these calculations are implemented in QDate class (qtbase/src/corelib/tools/qdatetime.cpp). There are several candidates for date object APIs. Following list discusses these APIs. 5.1. Integrate calendar system semantics into QDate This is what we plan to do. There are several ways to do this. All of course will preserve backward compatibility. First three options are based on John Layt’s ideas described at [3] 5.1.1. Add a calculator class, add convenience methods to QDate QDate myDate = QDate::gregorianDate(2000, 1, 1); QDateCalculator myCalc; int localYear = myCalc.year(myDate); QString localString = QLocale::system().toString(myDate); QDateTimeEdit myEdit(myDate); myCalc.setCalendar(QLocale::HebrewCalendar); int hebrewYear = myCalc.year(); There are several issues with this API. Most importantly it does not preserve backward-compatibility of QDate API. This also does not meet the requirement of having QDate-like API. 5.1.2. Add new methods to QDate QDate myDate = QDate::gregorianDate(2000,1,1); int localYear = myDate.localYear(); QString localString = QLocale::system().toString(myDate); QDateTimeEdit myEdit(myDate); int hebrewYear = myDate.localYear(QLocale::HebrewCalendar); This option has previous one’s problems. And there is something not clear with this option: How QLocale knows about calendar system of a given date object? Is there a member added to QDate? 5.1.3. Add `calendar()` method to QDate, and return a QLocalDate QDate myDate = QDate::gregorianDate(2000,1,1); int localYear = myDate.calendar().year(); QString localString = myDate.calendar().toString(); QDateTimeEdit myEdit(myDate); int hebrewYear = myDate.calendar(QLocale::HebrewCalendar).year(); This is the best of above three, yet does not meet the requirements: myDate.calendar(someCalendar).year() is not a good way to obtain year number of a date object. We prefer QDate::year(). 5.1.4. Using an enumeration to perform the math This option is complicated, and backward-compatible. We plan to implement this one if there is no problem. Needed API changes are: * Adding an enum to the QLocale class: enum Calendar{Default, Gregorian=Default, Hebrew, Jalali, Islamic,...} * Adding arguments of this enum with default values to `Gregorian` to these member functions: QString monthName(int, FormatType format = LongFormat, Calendar calendar = Default) const; QString standaloneMonthName(int, FormatType format = LongFormat, Calendar calendar = Default) const; * Adding `QCalendarSystem` class * Adding three member functions to the QDate: setCalendarSystem, calendarSyste and a constructor The QCalendarSystem will contain information on calendar systems and the math. This will help us to move calculations out of QDate, by providing a handle (a private member) to a calendar system object. This object will have the dirty code of calendar system, and will keep QDate implementation cleaner. So we will have something like: // qdatetime.cpp: void QDate::setCalendarSystem(QCalendarSystem::Type t){ // This is the new API d_calendar.setType(t); } int QDate::year() const { #ifndef QT_NOCALENDARSYSTEM // Previous implementation #else return d_calendar.year(); #endif } // qcalendar_system.cpp: QCalendarSystem::year(quint64 jd){ switch(m_type){ case CalendarSyste::Gregorian: return q_gregorianYearFromJulianDay(jd); case CalendarSyste::Jalali: return q_jalaliYearFromJulianDay(jd); } } // the calendar math (not optimized): QCalendarSystemPrivate::ParsedDate jalaliDateFromJulianDay(quint64 julianDay) { quint64 depoch = julianDay - PERSIAN_EPOCH; quint64 cycle = depoch / 1029983; quint64 cyear = depoch % 1029983; quint64 ycycle ; quint64 aux1,aux2; if(cyear==1029982){ ycycle=2820; } else{ aux1 = cyear / 366; aux2 = cyear % 366; ycycle = (((2134 * aux1) + (2816 * aux2) + 2815) / 1028522) + aux1 + 1; } int year = ycycle + (2820 * cycle) + 474; int month; if(year <= 0){ --year; } quint64 yday = (julianDay - persian_jdn(year, 1, 1)) + 1; if(yday <= 186){ month = ::ceil(static_cast(yday)/31.0); } else { month = ::ceil(static_cast(yday-6.0)/30.0); } int day = julianDay-persian_jdn(year, 1, 1)+1; const QCalendarSystemPrivate::ParsedDate result = {year,month,day}; return result; } 5.2. Provide separated date classes for each calendar system So there will be QGregorianDate, QJalaliDate, QIslamicDate, QHebrewDate... Possibly all inherited a common base. This solution is not reasonable. This will not meet any of our requirements. And will not satisfy the need to have calendar system integrated into QDate (So that we can change the calnedar easily). We prefer transparent API which is integrated to Qt itself, not many irrelevant classes. We already have them in several libraries, and our own hand-made APIs that we currently use. However this API is open for discussion. If you think we must go with this option, feel free to discuss about your reasons. 6. Known Problems There are several issues with option 5.1.4 that are discussed here. I will not discuss other options (5.1.1 to 5.1.3) as I don't want to implement them. If you think they may fit the requirements, please let me know about the reason and issues. And also if you see any other issues not mentioned here, please let me know about. 6.1. Missing calendar localization in CLDR Currently, month names are provided by QLocale and being read from the CLDR embedded in Qt source code. Unfortunately there is no data in CLDR for non-Gregorian calendars. This problem is submited as a proposal in 2012 [4] which is not added to CLDR yet. So how do we provide data for month names? I have implemented a workaround for this: QString QLocale::monthName(int month, FormatType type, Calendar calendar) const { if (month < 1 || month > 12) return QString(); switch (calendar) { case Gregorian: { #ifndef QT_NO_SYSTEMLOCALE if (d->m_data == systemData()) { QVariant res = systemLocale()->query(type == LongFormat ? QSystemLocale::MonthNameLong: QSystemLocale::MonthNameShort, month); if (!res.isNull()) return res.toString(); } #endif quint32 idx, size; switch (type) { case QLocale::LongFormat: idx = d->m_data->m_long_month_names_idx; size = d->m_data->m_long_month_names_size; break; case QLocale::ShortFormat: idx = d->m_data->m_short_month_names_idx; size = d->m_data->m_short_month_names_size; break; case QLocale::NarrowFormat: idx = d->m_data->m_narrow_month_names_idx; size = d->m_data->m_narrow_month_names_size; break; default: return QString(); } return getLocaleListData(months_data + idx, size, month - 1); } case Jalali: switch (type) { case QLocale::LongFormat: // TODO: Add local month names at least for // Persian, Afghani, Pashtoo, English and Arabic return jalaliLongMonthNames[month]; break; case QLocale::ShortFormat: case QLocale::NarrowFormat: // TODO: Add local month names at least for // Persian, Afghani, Pashtoo, English and Arabic return jalaliShortMonthNames[month]; break; default: return QString(); } default: return QString(); } } It works, but it's not good enough. Can we add month names to the CLDR and pass the calnedar type to query? 6.2. Calendar system support must be optional. Adding calendars following option 5.1.4, will add a dependency to QDate. And qmake will also need to compile that. I'm thinking of adding options to configure script to enable calendar support. And let qmake be compiled without calendar object in it. This requires a lot of #ifdef preprocessors in QDate class, to keep previous implementation. That will cause a dirty code in QDate... 6.3. ICU support must be in place when ICU is available. We can do calendar math, conversions using ICU. Though not having ICU, we must have calendars available. That also requires a lot of math in QCalendarSystem messed up with loads of #ifdefs. 7. References [1] https://wiki.qt.io/Locale_Support_in_Qt_5 [2] https://wiki.qt.io/Qt_5_ICU#QCalendarSystem_Design [3] http://lists.qt-project.org/pipermail/qt5-feedback/2011-September/001126.html [4] http://cldr.unicode.org/development/development-process/design-proposals/generic -calendar-data Cheers, soroush -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Thu Dec 15 13:23:20 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 15 Dec 2016 12:23:20 +0000 Subject: [Development] Calendar Systems proposal In-Reply-To: References: Message-ID: Soroush Rabiei wrote: > Nowadays, almost all major programming frameworks support calendar > globalization. We are a small group of developers working with > non-Gregorian calendars and we believe Qt must support this too. This > proposal discusses details of our plan (and early implementation) to > add support for multiple calendar systems in Qt library. Excellent initiative. I've only had time for a cursory review (I'm running away for mid-winter after today, not back until January, and have a few other irons in the fire to get into a sensible state before I go) so shall have to read in greater depth next year. However, one thing did cross my mind in reading: How about having the QCalendarSystem object be an optional parameter to various methods of QDate, that configures how it behaves, with the default behaviour being that of the Gregorian system ? This has the advantage that client code might be able to supply a custom QCalendarSystem object, where an enum-based solution can only know about the ones that the Qt project has chosen to support. Presumably every calendar system can be referred back to the Julian date [0], so most of the QCalendarSystem API would just implement methods mapping Julian date to the chosen calendar's year, month, day &c. [0] which, lest anyone be confused, has nothing to do with the Julian calendar - which *is* still in use ... For the sake of anyone who hasn't understood why calendar system isn't related to locale (or time-zone, or anything else particularly), note that members of a culture that traditionally uses another calendar may want to deal with a government-imposed (probably Gregorian) calendar for all their work planning while using their culture's traditional calendar when organising family and community events. A conference centre organiser, furthermore, may want to be able to switch freely between calendars to get a view of their diverse guests' perspectives in order to avoid cultural gaffes and be ready to accommodate complications. Even if there's nothing religious about the conference, knowing that it happens to fall in Ramadan will prime the conference centre staff to be ready to accommodate any attendees who won't be eating during the hours of daylight, Eddy. From nospam at vuorela.dk Thu Dec 15 22:10:19 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Thu, 15 Dec 2016 21:10:19 +0000 (UTC) Subject: [Development] Calendar Systems proposal References: Message-ID: On 2016-12-15, Soroush Rabiei wrote: > 2.History > Hi I would welcome more calendar systems. Personally I hope for french revolutionary calendar. Because it is funny. I think you need to touch quite some of the 'inner bits' of date / time, and while you are there, I'd love if the design could make it easier to implement my two missing pet features: - Partial dates - Date/time intervals/delta's. You might need the latter part for the implementation. (By partial dates, I mean e.g. my friend has birthday on november 1st. every year. or unknown year.) (by date/time deltas, I e.g. I started working somewhere on november 1st 2014. and stopped january 3rd 2015. How long did I work there) /Sune From andre at familiesomers.nl Thu Dec 15 22:33:11 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 15 Dec 2016 22:33:11 +0100 Subject: [Development] Calendar Systems proposal In-Reply-To: References: Message-ID: Op 15/12/2016 om 22:10 schreef Sune Vuorela: > On 2016-12-15, Soroush Rabiei wrote: >> 2.History >> > Hi > > I would welcome more calendar systems. Personally I hope for french > revolutionary calendar. Because it is funny. > > I think you need to touch quite some of the 'inner bits' of date / time, > and while you are there, I'd love if the design could make it easier to > implement my two missing pet features: > - Partial dates > - Date/time intervals/delta's. > > You might need the latter part for the implementation. > > (By partial dates, I mean e.g. my friend has birthday on november 1st. > every year. or unknown year.) > > (by date/time deltas, I e.g. I started working somewhere on november 1st > 2014. and stopped january 3rd 2015. How long did I work there) If memory serves me right: When, years ago, I tried to get the latter in, the work was a bit blocked because somebody else what working on... calendar support. :-) André From soroush.rabiei at gmail.com Fri Dec 16 00:24:39 2016 From: soroush.rabiei at gmail.com (Soroush Rabiei) Date: Fri, 16 Dec 2016 02:54:39 +0330 Subject: [Development] Calendar Systems proposal In-Reply-To: References: Message-ID: On Thu, Dec 15, 2016 at 3:53 PM, Edward Welbourne wrote: > Soroush Rabiei wrote: > > Nowadays, almost all major programming frameworks support calendar > > globalization. We are a small group of developers working with > > non-Gregorian calendars and we believe Qt must support this too. This > > proposal discusses details of our plan (and early implementation) to > > add support for multiple calendar systems in Qt library. > > Excellent initiative. I've only had time for a cursory review (I'm > running away for mid-winter after today, not back until January, and > have a few other irons in the fire to get into a sensible state before I > go) so shall have to read in greater depth next year. However, one > thing did cross my mind in reading: > > How about having the QCalendarSystem object be an optional parameter to > various methods of QDate, that configures how it behaves, with the > default behaviour being that of the Gregorian system ? This has the > advantage that client code might be able to supply a custom > QCalendarSystem object, where an enum-based solution can only know about > the ones that the Qt project has chosen to support. > That's interesting. Please tell me more about your idea when you're back. I suppose adding new calendars by users, requires subclassing QDate? Or maybe somehow extend the enum that contains calendar systems[?]. I think adding the information on which calendar system is current date is on, can be added as a member (handlre/enum) to QDate. > > Presumably every calendar system can be referred back to the Julian date > [0], so most of the QCalendarSystem API would just implement methods > mapping Julian date to the chosen calendar's year, month, day &c. > > [0] which, lest anyone be confused, has nothing to do with the Julian > calendar - which *is* still in use ... > > That's correct for Persian, Islamic and Hebrew calendar AFAIK. There math behind is a more complex compared to Gregorian, but it will do it. I'm learning about other calendar systems, and it seems there will be no problem with having ant reference day as a date start point, for any calendar. > For the sake of anyone who hasn't understood why calendar system isn't > related to locale (or time-zone, or anything else particularly), note > that members of a culture that traditionally uses another calendar may > want to deal with a government-imposed (probably Gregorian) calendar > for all their work planning while using their culture's traditional > calendar when organising family and community events. A conference > centre organiser, furthermore, may want to be able to switch freely > between calendars to get a view of their diverse guests' perspectives in > order to avoid cultural gaffes and be ready to accommodate > complications. Even if there's nothing religious about the conference, > knowing that it happens to fall in Ramadan will prime the conference > centre staff to be ready to accommodate any attendees who won't be > eating during the hours of daylight, > > Eddy. > Exactly! Locale, Time Zone and Calendars can be used in any combination. We may want to have date and time in Persian calendar, written in German, on on CET +01:00 to celebrate Nowrooz in Berlin. And we must be able to have multiple calendars in one application. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gna.org Fri Dec 16 03:44:00 2016 From: chgans at gna.org (Ch'Gans) Date: Fri, 16 Dec 2016 15:44:00 +1300 Subject: [Development] Calendar Systems proposal In-Reply-To: References: Message-ID: On 16 December 2016 at 10:10, Sune Vuorela wrote: > On 2016-12-15, Soroush Rabiei wrote: >> 2.History >> > > Hi > > I would welcome more calendar systems. Personally I hope for french > revolutionary calendar. Because it is funny. > > I think you need to touch quite some of the 'inner bits' of date / time, > and while you are there, I'd love if the design could make it easier to > implement my two missing pet features: > - Partial dates > - Date/time intervals/delta's. > > You might need the latter part for the implementation. > > (By partial dates, I mean e.g. my friend has birthday on november 1st. > every year. or unknown year.) > > (by date/time deltas, I e.g. I started working somewhere on november 1st > 2014. and stopped january 3rd 2015. How long did I work there) Boost have them all: date/time, calendar, time zone, time period and time duration Date/Time is a very tricky subject, why not rely on boost implementation? http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/group__date__time.html Chris > > /Sune > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From harald.vistnes at gmail.com Fri Dec 16 09:55:06 2016 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Fri, 16 Dec 2016 09:55:06 +0100 Subject: [Development] qtwebkit Message-ID: Hi, is it still possible to build the qtwebkit module manually in 5.8.0? I've tried fetching the sources from git, but qtwebkit is not built. I guess I have to change some build scripts since it is obsolete, but I am not sure what needs to be done. Here is what I did git clone git://code.qt.io/qt/qt5.git cd qt5 perl init-repository --module-subset=all,-ignore,-qtwebkit-examples,-qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-qtdatavis3d,-qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,-qtdoc git checkout 5.8.0 configure -prefix %CD%\qtbase -opensource -shared -confirm-license -debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-angle -qt-libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip qtwayland -skip qtserialbus -skip qtserialport -skip qtvirtualkeyboard -skip qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech -skip qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -nomake tests I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro (line 29), but that did not help. I'm on Windows 10 with VS2015. I've built qtwebkit before, so I think I have all dependencies installed. What am I missing? Thanks, Harald -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Fri Dec 16 09:59:58 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 16 Dec 2016 08:59:58 +0000 Subject: [Development] qtwebkit In-Reply-To: References: Message-ID: Have you tried running qmake && jom (or nmake) manually inside the qtwebkit source directory? Kai > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Harald Vistnes > Sent: Friday, December 16, 2016 9:55 AM > To: development at qt-project.org > Subject: [Development] qtwebkit > > Hi, > > is it still possible to build the qtwebkit module manually in 5.8.0? I've tried > fetching the sources from git, but qtwebkit is not built. I guess I have to > change some build scripts since it is obsolete, but I am not sure what needs > to be done. > > Here is what I did > > git clone git://code.qt.io/qt/qt5.git cd qt5 perl > init-repository --module-subset=all,-ignore,-qtwebkit-examples,- > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-qtdatavis3d,- > qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,-qtdoc > git checkout 5.8.0 > > configure -prefix %CD%\qtbase -opensource -shared -confirm-license - > debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-angle -qt- > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip > qtwayland -skip qtserialbus -skip qtserialport -skip qtvirtualkeyboard -skip > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech -skip > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -nomake tests > > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro > (line 29), but that did not help. > > I'm on Windows 10 with VS2015. I've built qtwebkit before, so I think I have > all dependencies installed. > > What am I missing? > > Thanks, > Harald From harald.vistnes at gmail.com Fri Dec 16 10:00:43 2016 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Fri, 16 Dec 2016 10:00:43 +0100 Subject: [Development] qtwebkit In-Reply-To: References: Message-ID: Yes, nothing happens. Harald 2016-12-16 9:59 GMT+01:00 Kai Koehne : > Have you tried running qmake && jom (or nmake) manually inside the > qtwebkit source directory? > > Kai > > > -----Original Message----- > > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > > project.org] On Behalf Of Harald Vistnes > > Sent: Friday, December 16, 2016 9:55 AM > > To: development at qt-project.org > > Subject: [Development] qtwebkit > > > > Hi, > > > > is it still possible to build the qtwebkit module manually in 5.8.0? > I've tried > > fetching the sources from git, but qtwebkit is not built. I guess I have > to > > change some build scripts since it is obsolete, but I am not sure what > needs > > to be done. > > > > Here is what I did > > > > git clone git://code.qt.io/qt/qt5.git cd > qt5 perl > > init-repository --module-subset=all,-ignore,-qtwebkit-examples,- > > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,-qtdatavis3d,- > > qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,-qtdoc > > git checkout 5.8.0 > > > > configure -prefix %CD%\qtbase -opensource -shared -confirm-license - > > debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no-angle > -qt- > > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip > > qtwayland -skip qtserialbus -skip qtserialport -skip qtvirtualkeyboard > -skip > > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech -skip > > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 -nomake tests > > > > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro > > (line 29), but that did not help. > > > > I'm on Windows 10 with VS2015. I've built qtwebkit before, so I think I > have > > all dependencies installed. > > > > What am I missing? > > > > Thanks, > > Harald > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at qt.io Fri Dec 16 10:14:22 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 16 Dec 2016 09:14:22 +0000 Subject: [Development] qtwebkit In-Reply-To: References: Message-ID: > -----Original Message----- > From: Harald Vistnes [mailto:harald.vistnes at gmail.com] > Sent: Friday, December 16, 2016 10:01 AM > To: Kai Koehne > Cc: development at qt-project.org > Subject: Re: [Development] qtwebkit > > Yes, nothing happens. So there's no output from qmake? Have you checked that the webkit sources are actually there? Either qmake should end with an error indicating unmet dependencies. Or jom/nmake with a compile error ... Kai > Harald > > 2016-12-16 9:59 GMT+01:00 Kai Koehne >: > > > Have you tried running qmake && jom (or nmake) manually inside > the qtwebkit source directory? > > Kai > > > -----Original Message----- > > From: Development [mailto:development-bounces+kai.koehne > =qt.io at qt- > > project.org ] On Behalf Of Harald Vistnes > > Sent: Friday, December 16, 2016 9:55 AM > > To: development at qt-project.org project.org> > > Subject: [Development] qtwebkit > > > > Hi, > > > > is it still possible to build the qtwebkit module manually in 5.8.0? > I've tried > > fetching the sources from git, but qtwebkit is not built. I guess I > have to > > change some build scripts since it is obsolete, but I am not sure > what needs > > to be done. > > > > Here is what I did > > > > git clone git://code.qt.io/qt/qt5.git > cd qt5 perl > > init-repository --module-subset=all,-ignore,-qtwebkit-examples,- > > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,- > qtdatavis3d,- > > qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,- > qtdoc > > git checkout 5.8.0 > > > > configure -prefix %CD%\qtbase -opensource -shared -confirm- > license - > > debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no- > angle -qt- > > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip > > qtwayland -skip qtserialbus -skip qtserialport -skip > qtvirtualkeyboard -skip > > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech -skip > > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 - > nomake tests > > > > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro > > > > (line 29), but that did not help. > > > > I'm on Windows 10 with VS2015. I've built qtwebkit before, so I > think I have > > all dependencies installed. > > > > What am I missing? > > > > Thanks, > > Harald > > From harald.vistnes at gmail.com Fri Dec 16 11:25:09 2016 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Fri, 16 Dec 2016 11:25:09 +0100 Subject: [Development] qtwebkit In-Reply-To: References: Message-ID: Silly me, I forgot to run qmake, just tried to run nmake/jom. It's compiling now, hopefully without problems. Thanks for your help! Harald 2016-12-16 10:14 GMT+01:00 Kai Koehne : > > -----Original Message----- > > From: Harald Vistnes [mailto:harald.vistnes at gmail.com] > > Sent: Friday, December 16, 2016 10:01 AM > > To: Kai Koehne > > Cc: development at qt-project.org > > Subject: Re: [Development] qtwebkit > > > > Yes, nothing happens. > > So there's no output from qmake? Have you checked that the webkit sources > are actually there? > > Either qmake should end with an error indicating unmet dependencies. Or > jom/nmake with a compile error ... > > Kai > > > Harald > > > > 2016-12-16 9:59 GMT+01:00 Kai Koehne > >: > > > > > > Have you tried running qmake && jom (or nmake) manually inside > > the qtwebkit source directory? > > > > Kai > > > > > -----Original Message----- > > > From: Development [mailto:development-bounces+kai.koehne > > =qt.io at qt- > > > project.org ] On Behalf Of Harald Vistnes > > > Sent: Friday, December 16, 2016 9:55 AM > > > To: development at qt-project.org > project.org> > > > Subject: [Development] qtwebkit > > > > > > Hi, > > > > > > is it still possible to build the qtwebkit module manually in > 5.8.0? > > I've tried > > > fetching the sources from git, but qtwebkit is not built. I > guess I > > have to > > > change some build scripts since it is obsolete, but I am not sure > > what needs > > > to be done. > > > > > > Here is what I did > > > > > > git clone git://code.qt.io/qt/qt5.git < > http://code.qt.io/qt/qt5.git> > > cd qt5 perl > > > init-repository --module-subset=all,-ignore,-qtwebkit-examples,- > > > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,- > > qtdatavis3d,- > > > qtcharts,-qtpurchasing,-qtquickcontrols2,- > qtserialport,-qtwayland,- > > qtdoc > > > git checkout 5.8.0 > > > > > > configure -prefix %CD%\qtbase -opensource -shared -confirm- > > license - > > > debug-and-release -release -opengl desktop -qt-zlib -qt-libpng > -no- > > angle -qt- > > > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip > qtsensors -skip > > > qtwayland -skip qtserialbus -skip qtserialport -skip > > qtvirtualkeyboard -skip > > > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech > -skip > > > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 - > > nomake tests > > > > > > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro > > > > > > > (line 29), but that did not help. > > > > > > I'm on Windows 10 with VS2015. I've built qtwebkit before, so I > > think I have > > > all dependencies installed. > > > > > > What am I missing? > > > > > > Thanks, > > > Harald > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Dec 16 11:51:52 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 16 Dec 2016 13:51:52 +0300 Subject: [Development] qtwebkit In-Reply-To: References: Message-ID: <2663021481885512@web17g.yandex.ru> 16.12.2016, 13:25, "Harald Vistnes" : >     Silly me, I forgot to run qmake, just tried to run nmake/jom. It's compiling now, hopefully without problems. > >     Thanks for your help! I you are using widgets API, consider trying QtWebKit TP4 from [1]. There are precompiled binaries for VS2015 and Qt 5.7, if you are interested I can prepare 5.8 binaries for you. See [2] for additional background. [1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp4 [2] http://qtwebkit.blogspot.com/2016/08/qtwebkit-im-back.html >     Harald > >     2016-12-16 10:14 GMT+01:00 Kai Koehne : >>>     -----Original Message----- >>>     From: Harald Vistnes [mailto:harald.vistnes at gmail.com] >>>     Sent: Friday, December 16, 2016 10:01 AM >>>     To: Kai Koehne >>>     Cc: development at qt-project.org >>>     Subject: Re: [Development] qtwebkit >>> >>>     Yes, nothing happens. >> >>     So there's no output from qmake? Have you checked that the webkit sources are actually there? >> >>     Either qmake should end with an error indicating unmet dependencies. Or jom/nmake with a compile error ... >> >>     Kai >> >>>     Harald >>> >>>     2016-12-16 9:59 GMT+01:00 Kai Koehne >>      >: >>> >>>           Have you tried running qmake && jom (or nmake) manually inside >>>     the qtwebkit source directory? >>> >>>           Kai >>> >>>           > -----Original Message----- >>>           > From: Development [mailto:development-bounces+kai.koehne >>>      =qt.io at qt- >>>           > project.org ] On Behalf Of Harald Vistnes >>>           > Sent: Friday, December 16, 2016 9:55 AM >> >>>           > To: development at qt-project.org >>     project.org> >>>           > Subject: [Development] qtwebkit >>>           > >>>           > Hi, >>>           > >>>           > is it still possible to build the qtwebkit module manually in 5.8.0? >>>     I've tried >>>           > fetching the sources from git, but qtwebkit is not built. I guess I >>>     have to >>>           > change some build scripts since it is obsolete, but I am not sure >>>     what needs >>>           > to be done. >>>           > >>>           > Here is what I did >>>           > >>>           > git clone git://code.qt.io/qt/qt5.git >>>      cd qt5 perl >>>           > init-repository --module-subset=all,-ignore,-qtwebkit-examples,- >>>           > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,- >>>     qtdatavis3d,- >>>           > qtcharts,-qtpurchasing,-qtquickcontrols2,-qtserialport,-qtwayland,- >>>     qtdoc >>>           > git checkout 5.8.0 >>>           > >>>           > configure -prefix %CD%\qtbase -opensource -shared -confirm- >>>     license - >>>           > debug-and-release -release -opengl desktop -qt-zlib -qt-libpng -no- >>>     angle -qt- >>>           > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip qtsensors -skip >>>           > qtwayland -skip qtserialbus -skip qtserialport -skip >>>     qtvirtualkeyboard -skip >>>           > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip qtspeech -skip >>>           > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 - >>>     nomake tests >>>           > >>>           > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro >>>       >>> >>>           > (line 29), but that did not help. >>>           > >>>           > I'm on Windows 10 with VS2015. I've built qtwebkit before, so I >>>     think I have >>>           > all dependencies installed. >>>           > >>>           > What am I missing? >>>           > >>>           > Thanks, >>>           > Harald >     , > >     _______________________________________________ >     Development mailing list >     Development at qt-project.org >     http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From announce at qt-project.org Thu Dec 15 14:39:57 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 15 Dec 2016 14:39:57 +0100 Subject: [Development] [Announce] Qbs 1.7.0 released Message-ID: Hi, I'd like to announce the release of Qbs 1.7.0. Source and binary packages as well as a change log can be found at https://download.qt.io/official_releases/qbs/1.7.0/. This release of Qbs is also shipped as part of Qt Creator 4.2.0. Best regards, -- Christian Kandeler Senior Software Engineer 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 _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From harald.vistnes at gmail.com Fri Dec 16 15:05:57 2016 From: harald.vistnes at gmail.com (Harald Vistnes) Date: Fri, 16 Dec 2016 15:05:57 +0100 Subject: [Development] qtwebkit In-Reply-To: <2663021481885512@web17g.yandex.ru> References: <2663021481885512@web17g.yandex.ru> Message-ID: Hi Konstantin, precompiled binaries for VS2015 and Qt 5.8 would be perfect! That would save me a lot of time. Compiling qtwebkit failed, I haven't had the time to dig into it yet. I'll try your binaries instead. Thanks, Harald 2016-12-16 11:51 GMT+01:00 Konstantin Tokarev : > > > 16.12.2016, 13:25, "Harald Vistnes" : > > Silly me, I forgot to run qmake, just tried to run nmake/jom. It's > compiling now, hopefully without problems. > > > > Thanks for your help! > > > I you are using widgets API, consider trying QtWebKit TP4 from [1]. There > are precompiled binaries for VS2015 and Qt 5.7, if you are interested I can > prepare 5.8 binaries for you. See [2] for additional background. > > [1] https://github.com/annulen/webkit/releases/tag/qtwebkit-tp4 > [2] http://qtwebkit.blogspot.com/2016/08/qtwebkit-im-back.html > > > > Harald > > > > 2016-12-16 10:14 GMT+01:00 Kai Koehne : > >>> -----Original Message----- > >>> From: Harald Vistnes [mailto:harald.vistnes at gmail.com] > >>> Sent: Friday, December 16, 2016 10:01 AM > >>> To: Kai Koehne > >>> Cc: development at qt-project.org > >>> Subject: Re: [Development] qtwebkit > >>> > >>> Yes, nothing happens. > >> > >> So there's no output from qmake? Have you checked that the webkit > sources are actually there? > >> > >> Either qmake should end with an error indicating unmet > dependencies. Or jom/nmake with a compile error ... > >> > >> Kai > >> > >>> Harald > >>> > >>> 2016-12-16 9:59 GMT+01:00 Kai Koehne >>> >: > >>> > >>> Have you tried running qmake && jom (or nmake) manually > inside > >>> the qtwebkit source directory? > >>> > >>> Kai > >>> > >>> > -----Original Message----- > >>> > From: Development [mailto:development-bounces+kai.koehne > >>> =qt.io at qt- > >>> > project.org ] On Behalf Of Harald > Vistnes > >>> > Sent: Friday, December 16, 2016 9:55 AM > >> > >>> > To: development at qt-project.org >>> project.org> > >>> > Subject: [Development] qtwebkit > >>> > > >>> > Hi, > >>> > > >>> > is it still possible to build the qtwebkit module manually > in 5.8.0? > >>> I've tried > >>> > fetching the sources from git, but qtwebkit is not built. > I guess I > >>> have to > >>> > change some build scripts since it is obsolete, but I am > not sure > >>> what needs > >>> > to be done. > >>> > > >>> > Here is what I did > >>> > > >>> > git clone git://code.qt.io/qt/qt5.git < > http://code.qt.io/qt/qt5.git> > >>> cd qt5 perl > >>> > init-repository --module-subset=all,-ignore,- > qtwebkit-examples,- > >>> > qtwebengine,-qtnetworkauth,-qtspeech,-qtvirtualkeyboard,- > >>> qtdatavis3d,- > >>> > qtcharts,-qtpurchasing,-qtquickcontrols2,- > qtserialport,-qtwayland,- > >>> qtdoc > >>> > git checkout 5.8.0 > >>> > > >>> > configure -prefix %CD%\qtbase -opensource -shared -confirm- > >>> license - > >>> > debug-and-release -release -opengl desktop -qt-zlib > -qt-libpng -no- > >>> angle -qt- > >>> > libjpeg -icu -skip qtconnectivity -skip qtlocation -skip > qtsensors -skip > >>> > qtwayland -skip qtserialbus -skip qtserialport -skip > >>> qtvirtualkeyboard -skip > >>> > qtdatavis3d -skip qtcharts -skip qtpurchasing -skip > qtspeech -skip > >>> > qtnetworkauth -skip qtwebengine -platform win32-msvc2015 - > >>> nomake tests > >>> > > >>> > I tried removing qtwebkit from QT_SKIP_MODULES in qt.pro > >>> > >>> > >>> > (line 29), but that did not help. > >>> > > >>> > I'm on Windows 10 with VS2015. I've built qtwebkit before, > so I > >>> think I have > >>> > all dependencies installed. > >>> > > >>> > What am I missing? > >>> > > >>> > Thanks, > >>> > Harald > > , > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > > -- > Regards, > Konstantin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Fri Dec 16 16:33:40 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 16 Dec 2016 16:33:40 +0100 Subject: [Development] Calendar Systems proposal References: Message-ID: Ch'Gans wrote: > Boost have them all: date/time, calendar, time zone, time period and > time duration > Date/Time is a very tricky subject, why not rely on boost implementation? > > http://www.boost.org/doc/libs/1_51_0/libs/locale/doc/html/group__date__time.html Because it would suck for Qt to depend on Boost. And because just using Boost directly in the applications (without a Qt wrapper) would mean dealing with a horrible API. Kevin Kofler From thiago.macieira at intel.com Fri Dec 16 17:45:49 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 16 Dec 2016 08:45:49 -0800 Subject: [Development] Calendar Systems proposal In-Reply-To: References: Message-ID: <6308711.nl2lZLevpo@tjmaciei-mobl1> Em quinta-feira, 15 de dezembro de 2016, às 21:10:19 PST, Sune Vuorela escreveu: > I think you need to touch quite some of the 'inner bits' of date / time, > and while you are there, I'd love if the design could make it easier to > implement my two missing pet features: > - Partial dates > - Date/time intervals/delta's. I don't expect the calendaring system to require any changes to QDate internals. It stores a Julian day, that's all. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Dec 16 17:47:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 16 Dec 2016 08:47:41 -0800 Subject: [Development] qtwebkit In-Reply-To: References: <2663021481885512@web17g.yandex.ru> Message-ID: <1927279.FOuhvVoX9M@tjmaciei-mobl1> Em sexta-feira, 16 de dezembro de 2016, às 15:05:57 PST, Harald Vistnes escreveu: > Hi Konstantin, > > precompiled binaries for VS2015 and Qt 5.8 would be perfect! That would > save me a lot of time. Compiling qtwebkit failed, I haven't had the time to > dig into it yet. I'll try your binaries instead. There have been a couple of fixes to make it work, due to minor changes to the buildsystem that didn't get tested in qtwebkit. I'm hoping they'll be there in time for the 5.8.0 release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Fri Dec 16 20:37:32 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 16 Dec 2016 16:37:32 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <3101662.UH55Bh2aQB@tjmaciei-mobl1> References: <4328581.XPRJ7y2mly@tonks> <1514152.RHHB768Ehq@tonks> <3101662.UH55Bh2aQB@tjmaciei-mobl1> Message-ID: <4877283.bKKHHfvdRC@tonks> On viernes, 9 de diciembre de 2016 18:54:11 ART Thiago Macieira wrote: > Em sexta-feira, 9 de dezembro de 2016, às 23:23:50 PST, Lisandro Damián > > Nicanor Pérez Meyer escreveu: > > Thiago: should I push to gerrit the complete patch as it is or just the > > QPA > > stuff on one patch and the private symbols versioning on another? And to > > what branch exactly? > > Please split. They do completely different things. Done so in https://codereview.qt-project.org/#/c/180224/ -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From perezmeyer at gmail.com Fri Dec 16 20:45:45 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 16 Dec 2016 16:45:45 -0300 Subject: [Development] Tagging private symbols as such In-Reply-To: <12668037.T3J5yuIKVz@tonks> References: <4328581.XPRJ7y2mly@tonks> <3976954.qf18LPJo2m@tjmaciei-mobl1> <12668037.T3J5yuIKVz@tonks> Message-ID: <2620784.ptr76UjQBf@tonks> On miércoles, 14 de diciembre de 2016 00:49:41 ART you wrote: > On miércoles, 7 de diciembre de 2016 08:02:20 ART Thiago Macieira wrote: > [snip] > > > But the extra versioning is a further safety check: if something was > > missed > > in the update, like for example some code compiled by the user (regardless > > of use of package management), it will necessarily stop working. > > I not sure of the usefullnes in this case. If I remember correctly the > linker will try first to locate the symbol with the right version and if it > fails the first symbol that matches no matter it's version. Not exactly. According to [doc]: "When the linker finds a symbol defined in a library which is not specifically bound to a version node, it will effectively bind it to an unspecified base version of the library." [doc] This explains the case when the symbols where added, but doesn't says what happens if a symbol can't be matched with a specific version. I've got crashes, but not problems at link time that I could see. -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From soroush.rabiei at gmail.com Sat Dec 17 14:43:38 2016 From: soroush.rabiei at gmail.com (Soroush Rabiei) Date: Sat, 17 Dec 2016 17:13:38 +0330 Subject: [Development] Calendar Systems proposal In-Reply-To: <6308711.nl2lZLevpo@tjmaciei-mobl1> References: <6308711.nl2lZLevpo@tjmaciei-mobl1> Message-ID: > > I don't expect the calendaring system to require any changes to QDate > internals. It stores a Julian day, that's all. > That's why we need to change QDate. The idea is to remove all calendar calculation code out of the QDate (into QCalendarSystem possibly). I think QDate already has been bloated and knows more that it needs. Consequently, there is no chance to add other calendaring API into QDate, and I think it's wrong to add such implementation to QDate. My view of QDate is this: QDate represents a day in time. So it only needs to know what day it is (how many days are to the day 0). For example, QDate knows how many days are in a month, what are month names (in case locale is not present), how to find leap years, and how to convert a JulianDay to year, month and day in Gregorian calendar. Well, I think it should only keep a Julian day, and (possibly) a handle to some external resource (may be QCalendarSystem) that knows about calendar math. This external resource will tell the QDate how to convert its Julian day to current calendar. Please let me know if there is anything wrong with this. Some of my current changes to QDate are: int QDate::year() const { if (isNull()) return 0; int year = 0; // Ask from QCalendarSystem what year we are in year = this->cs.yearFromJulianDay(jd); return year; } And also added two methods. This way I'm getting something like: int main(int argc, char *argv[]) { QCoreApplication a(argc, argv); QDate date; date = QDate::currentDate(); date.setCalendar(QCalendarSystem::Jalali); qDebug() << date.toString("yyyy/MM/dd"); qDebug() << date.toString("dd MMMM yyyy"); qDebug() << date.toString(); return 0; } That prints this for me: Starting /home/soroush/workspace/build-test-jalali-date-Qt_5_8_0_qt5-Debug/test-jalali-date... "1395/09/26" "26 Azar 1395" "Sat Aza 26 1395" -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Dec 17 20:16:24 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 17 Dec 2016 11:16:24 -0800 Subject: [Development] Calendar Systems proposal In-Reply-To: References: <6308711.nl2lZLevpo@tjmaciei-mobl1> Message-ID: <2346670.jH9ROVz64T@tjmaciei-mobl1> On sábado, 17 de dezembro de 2016 17:13:38 PST Soroush Rabiei wrote: > > I don't expect the calendaring system to require any changes to QDate > > internals. It stores a Julian day, that's all. > > That's why we need to change QDate. If you change QDate's internals, you have to wait for Qt 6. You can add to its API before then, though. > The idea is to remove all calendar > calculation code out of the QDate (into QCalendarSystem possibly). I think > QDate already has been bloated and knows more that it needs. Consequently, > there is no chance to add other calendaring API into QDate, and I think > it's wrong to add such implementation to QDate. My view of QDate is this: > QDate represents a day in time. So it only needs to know what day it is > (how many days are to the day 0). No chance of that ever happening. QDate will continue to support Gregorian day, month, year, as well as ISO weeks. Support for other calendaring systems (or maybe even other week systems) can be provided by a different class, accessible from QDate and QLocale. > Some of my current changes to QDate are: > > int QDate::year() const > { > if (isNull()) > return 0; > int year = 0; > // Ask from QCalendarSystem what year we are in > year = this->cs.yearFromJulianDay(jd); > return year; > } There's no "cs" member and you cannot add one, so the above would be: return QCalendarSystem::gregorian(*this).year(); > And also added two methods. This way I'm getting something like: > > int main(int argc, char *argv[]) > { > QCoreApplication a(argc, argv); > QDate date; > date = QDate::currentDate(); > date.setCalendar(QCalendarSystem::Jalali); You can't add this method. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From xbenlau at gmail.com Mon Dec 19 04:10:34 2016 From: xbenlau at gmail.com (Ben Lau) Date: Mon, 19 Dec 2016 11:10:34 +0800 Subject: [Development] Load debug symbol from Qt library in lldb Message-ID: Hi, I am tracking a crash problem in Qt library on Mac. First of all, I build a Qt 5.7.1 library from git with : $ ./configure -confirm-license -developer-build -opensource -nomake examples -nomake tests Then build an example program via the the qmake built $ qmake CONFIG+=debug Run it via lldb $ lldb ./lodashdemo.app/Contents/MacOS/lodashdemo $ run (then crash)$ image list ... [ 7] D6239705-2373-32D9-A1E9-E290DBA7CBAD 0x0000000101081000 /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml .... The QtQml is a shared library without debug symbol. The library that hold debug symbol should be QtQml_debug located in the same folder $ file /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml* /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml: Mach-O 64-bit dynamically linked shared library x86_64 /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml_debug: Mach-O 64-bit dynamically linked shared library x86_64 My questions are : 1) can I turn qmake to link the QtQml_debug ? or 2) can I build a QtQml library with debug symbol? Thanks for any advise -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at podsvirov.pro Mon Dec 19 06:30:11 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 19 Dec 2016 08:30:11 +0300 Subject: [Development] Fwd: [Interest] QtIFW 2.0.4 Release? In-Reply-To: <624041481656313@web12m.yandex.ru> References: <624041481656313@web12m.yandex.ru> Message-ID: <5688831482125411@web23j.yandex.ru> An HTML attachment was scrubbed... URL: From Eike.Ziller at qt.io Mon Dec 19 09:07:54 2016 From: Eike.Ziller at qt.io (Eike Ziller) Date: Mon, 19 Dec 2016 08:07:54 +0000 Subject: [Development] Load debug symbol from Qt library in lldb In-Reply-To: References: Message-ID: <76391B57-819C-49FB-8DE9-CF11C282AC40@qt.io> > On Dec 19, 2016, at 4:10 AM, Ben Lau wrote: > > Hi, > > I am tracking a crash problem in Qt library on Mac. First of all, I build a Qt 5.7.1 library from git with : > > $ ./configure -confirm-license -developer-build -opensource -nomake examples -nomake tests > > Then build an example program via the the qmake built > > $ qmake CONFIG+=debug > > Run it via lldb > > $ lldb ./lodashdemo.app/Contents/MacOS/lodashdemo > > $ run > > (then crash)$ image list > > ... > > [ 7] D6239705-2373-32D9-A1E9-E290DBA7CBAD 0x0000000101081000 /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml > > .... > > The QtQml is a shared library without debug symbol. The library that hold debug symbol should be QtQml_debug located in the same folder > > $ file /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml* > > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml: Mach-O 64-bit dynamically linked shared library x86_64 > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml_debug: Mach-O 64-bit dynamically linked shared library x86_64 > > My questions are : > > 1) can I turn qmake to link the QtQml_debug ? > or > > 2) can I build a QtQml library with debug symbol? The “macOS” way to handle frameworks and debug builds, is that the application links against the non-_debug libraries, and if you want to make it load the debug symbols you set DYLD_IMAGE_SUFFIX=_debug before running the application. http://doc.qt.io/qt-5/debug.html#debugging-in-macos-and-xcode Note that applications in /usr/bin (like /usr/bin/lldb) have an additional safe-guard that they reset the DYLD_* variables, so you need to set it in lldb for the application process: $ lldb $ settings set target.env-vars DYLD_IMAGE_SUFFIX=_debug $ run Br, -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From soroush.rabiei at gmail.com Mon Dec 19 09:20:47 2016 From: soroush.rabiei at gmail.com (Soroush Rabiei) Date: Mon, 19 Dec 2016 11:50:47 +0330 Subject: [Development] Calendar Systems proposal In-Reply-To: <2346670.jH9ROVz64T@tjmaciei-mobl1> References: <6308711.nl2lZLevpo@tjmaciei-mobl1> <2346670.jH9ROVz64T@tjmaciei-mobl1> Message-ID: > > If you change QDate's internals, you have to wait for Qt 6. > > You can add to its API before then, though. > Hmm... I'll think of something else then. I thought these changes are backward compatible (API only), though it seems I'm mistaken. Maybe missing something about ABI compatibility: Adding a member will change memory layout and eventually client apps will be forced to recompile I suppose... > No chance of that ever happening. QDate will continue to support Gregorian > day, month, year, as well as ISO weeks. Support for other calendaring > systems > (or maybe even other week systems) can be provided by a different class, > accessible from QDate and QLocale. > > It will support Gregorian day, month, year of course, adding calendaring system will not change default behavior. But it will change if calendar is set to something else. Nevertheless, it seems not possible for QDate to change in semantics in anyway, not for Qt6 nor any release. Following these rules, we need a new design, without changing QDate interface nor its internals. I'm thinking of some changes in viewer widgets and view classes to change their current calendar (utilizing calendar classes and QLocale) without breaking compatibility. Cheers, Soroush -------------- next part -------------- An HTML attachment was scrubbed... URL: From xbenlau at gmail.com Mon Dec 19 09:49:47 2016 From: xbenlau at gmail.com (Ben Lau) Date: Mon, 19 Dec 2016 16:49:47 +0800 Subject: [Development] Load debug symbol from Qt library in lldb In-Reply-To: <76391B57-819C-49FB-8DE9-CF11C282AC40@qt.io> References: <76391B57-819C-49FB-8DE9-CF11C282AC40@qt.io> Message-ID: On 19 December 2016 at 16:07, Eike Ziller wrote: > > > On Dec 19, 2016, at 4:10 AM, Ben Lau wrote: > > > > Hi, > > > > I am tracking a crash problem in Qt library on Mac. First of all, I > build a Qt 5.7.1 library from git with : > > > > $ ./configure -confirm-license -developer-build -opensource -nomake > examples -nomake tests > > > > Then build an example program via the the qmake built > > > > $ qmake CONFIG+=debug > > > > Run it via lldb > > > > $ lldb ./lodashdemo.app/Contents/MacOS/lodashdemo > > > > $ run > > > > (then crash)$ image list > > > > ... > > > > [ 7] D6239705-2373-32D9-A1E9-E290DBA7CBAD 0x0000000101081000 > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml > > > > .... > > > > The QtQml is a shared library without debug symbol. The library that > hold debug symbol should be QtQml_debug located in the same folder > > > > $ file /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/ > Versions/5/QtQml* > > > > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml: > Mach-O 64-bit dynamically linked shared library x86_64 > > /Users/benlau/tmp/qt5/qt5/qtbase/lib/QtQml.framework/Versions/5/QtQml_debug: > Mach-O 64-bit dynamically linked shared library x86_64 > > > > My questions are : > > > > 1) can I turn qmake to link the QtQml_debug ? > > or > > > > 2) can I build a QtQml library with debug symbol? > > The “macOS” way to handle frameworks and debug builds, is that the > application links against the non-_debug libraries, and if you want to make > it load the debug symbols you set DYLD_IMAGE_SUFFIX=_debug before running > the application. > > http://doc.qt.io/qt-5/debug.html#debugging-in-macos-and-xcode > > Note that applications in /usr/bin (like /usr/bin/lldb) have an additional > safe-guard that they reset the DYLD_* variables, so you need to set it in > lldb for the application process: > $ lldb > $ settings set target.env-vars DYLD_IMAGE_SUFFIX=_debug > $ run > > Br, > Hi Eike, It works. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic.marchal at wowtechnology.com Mon Dec 19 12:13:59 2016 From: frederic.marchal at wowtechnology.com (=?ISO-8859-1?Q?Fr=E9d=E9ric?= Marchal) Date: Mon, 19 Dec 2016 12:13:59 +0100 Subject: [Development] Calendar Systems proposal In-Reply-To: <2346670.jH9ROVz64T@tjmaciei-mobl1> References: <2346670.jH9ROVz64T@tjmaciei-mobl1> Message-ID: <1763102.EpZHfqpFKn@port-fma> On Saturday 17 December 2016 11:16:24 Thiago Macieira wrote: > On sábado, 17 de dezembro de 2016 17:13:38 PST Soroush Rabiei wrote: > > The idea is to remove all calendar > > calculation code out of the QDate (into QCalendarSystem possibly). I think > > QDate already has been bloated and knows more that it needs. Consequently, > > there is no chance to add other calendaring API into QDate, and I think > > it's wrong to add such implementation to QDate. My view of QDate is this: > > QDate represents a day in time. So it only needs to know what day it is > > (how many days are to the day 0). > > No chance of that ever happening. QDate will continue to support Gregorian > day, month, year, as well as ISO weeks. Support for other calendaring > systems (or maybe even other week systems) can be provided by a different > class, accessible from QDate and QLocale. Can you elaborate on the reasons that prevent any change of that kind in QDate? Maybe they can be worked around? Soroush's purpose is to allow the use of other calendar systems with minimum application changes (i.e. simply telling QDate to use a different date computation algorithm). I find his idea very attractive and not at odds with some other Qt classes. Your solution implies developers have to know about those calendars and are willing to support them in their applications. That's very unlikely to happen if they have to change lot of code and replace QDate with another class. As a developer, I don't want to know about the gory details of date computation with calendars I have never heard of. Adding "one month" to a date should use the same code whatever the underlying calendar is. The correct calendar to use should be a simple configuration parameter to make it as universally available as retrieving the local time irrespective of the user's location or generating the plural of a message in any language my application could be translated to even without my knowledge. Frederic From katja.marttila at qt.io Mon Dec 19 13:17:29 2016 From: katja.marttila at qt.io (Katja Marttila) Date: Mon, 19 Dec 2016 12:17:29 +0000 Subject: [Development] Fwd: [Interest] QtIFW 2.0.4 Release? In-Reply-To: <5688831482125411@web23j.yandex.ru> References: <624041481656313@web12m.yandex.ru> <5688831482125411@web23j.yandex.ru> Message-ID: Hi Konstantin, It will happen earliest in the beginning of next year. Sorry but I don’t have exact time or week to give you. --Katja Hello again! 22:12, 13 december 2016 г., Konstantin Podsvirov >: Hello guys! QtSDK maintenance now based on 2.0.4 framework, but what about 2.0.4 tag and binaries for QtIFW? Ping. -------------- next part -------------- An HTML attachment was scrubbed... URL: From konstantin at podsvirov.pro Mon Dec 19 13:40:18 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Mon, 19 Dec 2016 15:40:18 +0300 Subject: [Development] Fwd: [Interest] QtIFW 2.0.4 Release? In-Reply-To: References: <624041481656313@web12m.yandex.ru> <5688831482125411@web23j.yandex.ru> Message-ID: <11799541482151218@web27h.yandex.ru> An HTML attachment was scrubbed... URL: From soroush.rabiei at gmail.com Mon Dec 19 14:18:27 2016 From: soroush.rabiei at gmail.com (Soroush Rabiei) Date: Mon, 19 Dec 2016 16:48:27 +0330 Subject: [Development] Calendar Systems proposal In-Reply-To: <1763102.EpZHfqpFKn@port-fma> References: <2346670.jH9ROVz64T@tjmaciei-mobl1> <1763102.EpZHfqpFKn@port-fma> Message-ID: > > Can you elaborate on the reasons that prevent any change of that kind in > QDate? Maybe they can be worked around? > > According to https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B#The_Do.27s_and_Don.27ts Adding a member to struct or class is not possible without breaking ABI. On the other hand https://wiki.qt.io/Qt-Version-Compatibility suggests that Qt minor releases are backwards binary and source compatible. So there is no chance of touching QDate in Qt5 series. I'm working on a solution to provide calendar functionality without breaking ABI, while considering possibilities for Qt6 (keep minimum effort for converting current, temporary solution to futures Qt6 one). This may fail of course, There are too many details that need to be discussed. How we are supposed to change underlying calendar without adding information to QDate? Can we add arguments to all methods with a default value? Something like: QDate d; qDebug() << d.year(); // prints 2016 qDebug() << d.year(QCalendar::Jalali); // prints 1395 And then force relevant widgets/views to show/edit date and time on a specific calendar system: QDateEdit de; de.setDate(d); de.setCalendarSystem(QCalendar::Hebrew); // Is this possible? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Tue Dec 20 14:34:39 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 20 Dec 2016 13:34:39 +0000 Subject: [Development] Proposal to adjust release candidate process Message-ID: Hi, I think we have three major problems with our current release process regarding the release candidate phase: 1. Process to make a RC that is as flawless as final causes inefficiency as we only get full test coverage with the RC itself 2. We get full attention for testing a bit too late, many fixes are still coming in close to the planned RC time causing instability 3. Current time between RC and final is planned to be 2 weeks, which is very little in order to take in the feedback and fix things Therefore, I would like to propose the following: a. Consider "Release Candidate" to be a phase rather than an individual delivery b. Create the first "RC1" almost immediately after release branch (e.g. 5.9.0) is operational c. Criteria for the "RC1" is that no known P0 bugs exist (i.e. there can be other issues that would not be acceptable in a final release) d. During the "RC" phase P1 (and possible P0 of course) bugs and documentation are fixed e. Public "RC" release is similar development release as Alpha and Beta in that it starts a phase of work f. Multiple snapshots / new candidates are created during the "RC" phase until one of them is considered the final release If desired, we could use some other name than "Release Candidate 1" for the release that begins the last phase of the release. It could be called "Beta 2" or "Technology preview", if so desired. Personally, I would call it "Release Candidate 1". The difference to our current process is quite small. In essence it would be about considering the "RC1" the beginning of the final releasing phase (.0 branch), not something we do almost at the end of it. I believe that lowering the quality criterial for "RC1" helps us in being more efficient as it has been in practice impossible to really fulfill the current process goal and have already the first RC as good as the final. In case of Qt 5.9 it would mean that we have the first "RC" out around end of April, soon after the branching to 5.9.0 has been completed. We then have 4 or so weeks to make all the needed amount of candidates / snapshots until one of them will be released as Qt 5.9.0 final. If it happens earlier than in 4 weeks, great. If it takes more time, then so be it (although in such case we have probably missed something in the earlier steps of the release creation). Yours, --- Tuukka Turunen Director, R&D The Qt Company Lutakonaukio 1 40100 Jyväskylä, Finland tuukka.turunen at qt.io +358 40 7655 800 http://qt.io --- -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at qt.io Tue Dec 20 16:10:48 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Tue, 20 Dec 2016 15:10:48 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: Message-ID: <262D86AE-CB73-436F-A3FE-C4D420AC8EEC@qt.io> > On 20 Dec 2016, at 14:34, Tuukka Turunen wrote: > > > Hi, > > I think we have three major problems with our current release process regarding the release candidate phase: > 1. Process to make a RC that is as flawless as final causes inefficiency as we only get full test coverage with the RC itself > 2. We get full attention for testing a bit too late, many fixes are still coming in close to the planned RC time causing instability > 3. Current time between RC and final is planned to be 2 weeks, which is very little in order to take in the feedback and fix things > > Therefore, I would like to propose the following: > a. Consider “Release Candidate” to be a phase rather than an individual delivery > b. Create the first “RC1” almost immediately after release branch (e.g. 5.9.0) is operational > c. Criteria for the “RC1” is that no known P0 bugs exist (i.e. there can be other issues that would not be acceptable in a final release) > d. During the “RC” phase P1 (and possible P0 of course) bugs and documentation are fixed > e. Public “RC” release is similar development release as Alpha and Beta in that it starts a phase of work > f. Multiple snapshots / new candidates are created during the “RC” phase until one of them is considered the final release > > If desired, we could use some other name than “Release Candidate 1” for the release that begins the last phase of the release. It could be called “Beta 2” or “Technology preview”, if so desired. Personally, I would call it “Release Candidate 1”. > > The difference to our current process is quite small. In essence it would be about considering the “RC1” the beginning of the final releasing phase (.0 branch), not something we do almost at the end of it. I believe that lowering the quality criterial for “RC1” helps us in being more efficient as it has been in practice impossible to really fulfill the current process goal and have already the first RC as good as the final. > > In case of Qt 5.9 it would mean that we have the first “RC” out around end of April, soon after the branching to 5.9.0 has been completed. We then have 4 or so weeks to make all the needed amount of candidates / snapshots until one of them will be released as Qt 5.9.0 final. If it happens earlier than in 4 weeks, great. If it takes more time, then so be it (although in such case we have probably missed something in the earlier steps of the release creation). +1, sounds good to me. From sean.harmer at kdab.com Tue Dec 20 16:14:17 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 20 Dec 2016 15:14:17 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: Message-ID: <2254680.W3ZZFgYWVg@cartman> Hi Tuukka, I agree with your proposal, however I think there is also another issue or two that we should address. At present we have ~ 4 releases per year 2 minor versions and 2 further patch releases. One issue is that it looks like 5.8.0 will soon render the very new 5.7.1 release redundant. With that in mind was it worth splitting the effort and having the 5.7.1 release at all? Don't get me wrong I'm all for additional patch releases just that I'd hope they wouldn't coincide so closely with a minor version release. This brings me onto another issue which perhaps we feel more strongly than average in Qt 3D as a new module that is undergoing rapid bug-fixing, improvements and with lots of new feature development starting to open up. For example, although Qt 3D in Qt 5.7.0 was a nice release after lots of effort, we still fixed a huge number of issues for 5.7.1, which took 181 days to release from 5.7.0. Would it be possible for us to release more frequent patch releases? If not for the whole of Qt, then at least for addon modules such as Qt 3D? The latter would require splitting the packaging of such modules but would reduce the amount of overall testing required for a new patch release. If we'd collectively rather not go down that street I still think more frequent patch releases would be nice. Users have the option of upgrading or not if they want to reduce their own internal regression testing burden and freeze on a specific version. But it would have the benefit that other users don't need to wait 6 months for a set of bug fixes - roughly the same time to wait as for new features. I wonder how much of the current pressure on releases is driven by the time- based release policy. We aim for a new minor release every 6 months which is admirable. But I wonder about the consequences of trying to stick to that at the expense of quality of the 5.x.0 releases, especially given the long turn around for subsequent patch releases. With the above in mind, how about this proposal in addition to yours regarding the RC phase? * Branch off new feature branch every 6 months as at present. * Do not rush the release at the expense of quality or when it's convenient due to packagers going on vacation etc. We release only when the release is deemed to meet quality standards. * Aim for a patch release every alternate month if there are fixes on the minor version branch and packaging/release staff are available. i.e. don't try to force one out before the summer/Xmas vacations. * Consider releasing at least one patch release of the previous minor series after the release of the next minor series' .0 release. For example, in the current situation, potentially release a 5.7.2 after 5.8.0. (We already have fixes on 5.8.0 and 5.8 that could have been submitted to the 5.7 branch if there were to be a 5.7.2 release). Additionally, is there any way that contributors outside of The Qt Company can assist with the practicalities of packaging? Just some food for thought. Cheers, Sean On Tuesday 20 December 2016 13:34:39 Tuukka Turunen wrote: > Hi, > > I think we have three major problems with our current release process > regarding the release candidate phase: > > 1. Process to make a RC that is as flawless as final causes > inefficiency as we only get full test coverage with the RC itself > > 2. We get full attention for testing a bit too late, many fixes are > still coming in close to the planned RC time causing instability > > 3. Current time between RC and final is planned to be 2 weeks, which > is very little in order to take in the feedback and fix things > > Therefore, I would like to propose the following: > > a. Consider "Release Candidate" to be a phase rather than an > individual delivery > > b. Create the first "RC1" almost immediately after release branch > (e.g. 5.9.0) is operational > > c. Criteria for the "RC1" is that no known P0 bugs exist (i.e. there > can be other issues that would not be acceptable in a final release) > > d. During the "RC" phase P1 (and possible P0 of course) bugs and > documentation are fixed > > e. Public "RC" release is similar development release as Alpha and > Beta in that it starts a phase of work > > f. Multiple snapshots / new candidates are created during the "RC" > phase until one of them is considered the final release > > If desired, we could use some other name than "Release Candidate 1" for the > release that begins the last phase of the release. It could be called "Beta > 2" or "Technology preview", if so desired. Personally, I would call it > "Release Candidate 1". > > The difference to our current process is quite small. In essence it would be > about considering the "RC1" the beginning of the final releasing phase (.0 > branch), not something we do almost at the end of it. I believe that > lowering the quality criterial for "RC1" helps us in being more efficient > as it has been in practice impossible to really fulfill the current process > goal and have already the first RC as good as the final. > > In case of Qt 5.9 it would mean that we have the first "RC" out around end > of April, soon after the branching to 5.9.0 has been completed. We then > have 4 or so weeks to make all the needed amount of candidates / snapshots > until one of them will be released as Qt 5.9.0 final. If it happens earlier > than in 4 weeks, great. If it takes more time, then so be it (although in > such case we have probably missed something in the earlier steps of the > release creation). > > Yours, > > --- > Tuukka Turunen > Director, R&D > > The Qt Company > Lutakonaukio 1 > 40100 Jyväskylä, Finland > tuukka.turunen at qt.io > +358 40 7655 800 > http://qt.io > --- -- 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 sean.harmer at kdab.com Tue Dec 20 16:31:44 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 20 Dec 2016 15:31:44 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <2254680.W3ZZFgYWVg@cartman> References: <2254680.W3ZZFgYWVg@cartman> Message-ID: <2607031.P9e58b0odW@cartman> On Tuesday 20 December 2016 15:14:17 Sean Harmer wrote: > Hi Tuukka, > > I agree with your proposal, however I think there is also another issue or > two that we should address. Except that instead of calling it RC1 why not call it another beta? The RC should be something that *may* be suitable for release. But at present we get the RC too late so it gets difficult to get fixes for issues accepted. Sure we might need a new RC after that but calling the initial packages after the release branch is branched an RC seems like a misnomer. Cheers, Sean > > At present we have ~ 4 releases per year 2 minor versions and 2 further > patch releases. One issue is that it looks like 5.8.0 will soon render the > very new 5.7.1 release redundant. With that in mind was it worth splitting > the effort and having the 5.7.1 release at all? Don't get me wrong I'm all > for additional patch releases just that I'd hope they wouldn't coincide so > closely with a minor version release. > > This brings me onto another issue which perhaps we feel more strongly than > average in Qt 3D as a new module that is undergoing rapid bug-fixing, > improvements and with lots of new feature development starting to open up. > For example, although Qt 3D in Qt 5.7.0 was a nice release after lots of > effort, we still fixed a huge number of issues for 5.7.1, which took 181 > days to release from 5.7.0. > > Would it be possible for us to release more frequent patch releases? If not > for the whole of Qt, then at least for addon modules such as Qt 3D? The > latter would require splitting the packaging of such modules but would > reduce the amount of overall testing required for a new patch release. If > we'd collectively rather not go down that street I still think more > frequent patch releases would be nice. Users have the option of upgrading > or not if they want to reduce their own internal regression testing burden > and freeze on a specific version. But it would have the benefit that other > users don't need to wait 6 months for a set of bug fixes - roughly the same > time to wait as for new features. > > I wonder how much of the current pressure on releases is driven by the time- > based release policy. We aim for a new minor release every 6 months which > is admirable. But I wonder about the consequences of trying to stick to > that at the expense of quality of the 5.x.0 releases, especially given the > long turn around for subsequent patch releases. > > With the above in mind, how about this proposal in addition to yours > regarding the RC phase? > > * Branch off new feature branch every 6 months as at present. > > * Do not rush the release at the expense of quality or when it's convenient > due to packagers going on vacation etc. We release only when the release is > deemed to meet quality standards. > > * Aim for a patch release every alternate month if there are fixes on the > minor version branch and packaging/release staff are available. i.e. don't > try to force one out before the summer/Xmas vacations. > > * Consider releasing at least one patch release of the previous minor series > after the release of the next minor series' .0 release. For example, in the > current situation, potentially release a 5.7.2 after 5.8.0. (We already > have fixes on 5.8.0 and 5.8 that could have been submitted to the 5.7 > branch if there were to be a 5.7.2 release). > > Additionally, is there any way that contributors outside of The Qt Company > can assist with the practicalities of packaging? > > Just some food for thought. > > Cheers, > > Sean > > On Tuesday 20 December 2016 13:34:39 Tuukka Turunen wrote: > > Hi, > > > > I think we have three major problems with our current release process > > regarding the release candidate phase: > > > > 1. Process to make a RC that is as flawless as final causes > > inefficiency as we only get full test coverage with the RC itself > > > > 2. We get full attention for testing a bit too late, many fixes are > > still coming in close to the planned RC time causing instability > > > > 3. Current time between RC and final is planned to be 2 weeks, which > > is very little in order to take in the feedback and fix things > > > > Therefore, I would like to propose the following: > > > > a. Consider "Release Candidate" to be a phase rather than an > > individual delivery > > > > b. Create the first "RC1" almost immediately after release branch > > (e.g. 5.9.0) is operational > > > > c. Criteria for the "RC1" is that no known P0 bugs exist (i.e. there > > can be other issues that would not be acceptable in a final release) > > > > d. During the "RC" phase P1 (and possible P0 of course) bugs and > > documentation are fixed > > > > e. Public "RC" release is similar development release as Alpha and > > Beta in that it starts a phase of work > > > > f. Multiple snapshots / new candidates are created during the "RC" > > phase until one of them is considered the final release > > > > If desired, we could use some other name than "Release Candidate 1" for > > the > > release that begins the last phase of the release. It could be called > > "Beta > > 2" or "Technology preview", if so desired. Personally, I would call it > > "Release Candidate 1". > > > > The difference to our current process is quite small. In essence it would > > be about considering the "RC1" the beginning of the final releasing phase > > (.0 branch), not something we do almost at the end of it. I believe that > > lowering the quality criterial for "RC1" helps us in being more efficient > > as it has been in practice impossible to really fulfill the current > > process goal and have already the first RC as good as the final. > > > > In case of Qt 5.9 it would mean that we have the first "RC" out around end > > of April, soon after the branching to 5.9.0 has been completed. We then > > have 4 or so weeks to make all the needed amount of candidates / snapshots > > until one of them will be released as Qt 5.9.0 final. If it happens > > earlier > > than in 4 weeks, great. If it takes more time, then so be it (although in > > such case we have probably missed something in the earlier steps of the > > release creation). > > > > Yours, > > > > --- > > Tuukka Turunen > > Director, R&D > > > > The Qt Company > > Lutakonaukio 1 > > 40100 Jyväskylä, Finland > > tuukka.turunen at qt.io > > +358 40 7655 800 > > http://qt.io > > --- -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From jani.heikkinen at qt.io Wed Dec 21 06:28:03 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 21 Dec 2016 05:28:03 +0000 Subject: [Development] Qt 5.9 prebuild binary packages( was: Re: Qt 5.9) In-Reply-To: <5895604.KNhrVNCRLl@tjmaciei-mobl1> References: <76A7D197-150E-485A-AC7F-69BAE5DDD479@qt.io>, <5895604.KNhrVNCRLl@tjmaciei-mobl1> Message-ID: Hi all, I finally managed to do testing how big combined windows installer would be. I was a bit surprised that it is only ~3.3 GB, which is still smaller than combined mac-android-ios installer ;) Ok, this is done from 5.8 packages & binaries so situation might be a bit different in 5.9 where we will have some new binaries to be done. But in the other hand we will/should drop some so I think the size of combined one should be still manageable. So I propose we will offer following set of offline installers from Qt 5.9 -> - For linux we will have 3 installers (instead of existing 5): * qt-enterprise-linux-x64-android (already delivering this) * qt-opensource-linux-x64-android (already delivering this) ** Desktop gcc 64-bit ** Android x86 ** Android armv7 * qt-enterprise-linux-x64-qnx (already delivering this) ** Desktop gcc 64-bit ** Qnx x86 ** Qnx armv7 ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries will be offered like 5.8.0 - For mac we will have 2 installers (instead of existing 6): * qt-enterprise-mac-x64-android-ios (already delivering this) * qt-opensource-mac-x64-android-ios (already delivering this) ** Desktop clang 64-bit ** Android x86 ** Android armv7 ** iOS - For windows we will have 3 installers (instead of existing 17): * qt-enterprise-windows-x86 (new) * qt-opensource-windows-x86 (new) ** Desktop MSVC 2013 x64 ** Desktop MSVC 2015 x86 ** Desktop MSVC 2015 x64 ** Desktop MSVC 2017 x64 ** Desktop MinGW 5.3 x86 ** UWP MSVC 2015 x86 ** UWP MSVC 2015 x64 ** UWP MSVC 2015 armv7 ** UWP MSVC 2017 x86 ** UWP MSVC 2017 x64 ** UWP MSVC 2017 armv7 ** Android x86 ** Android armv7 * qt-enterprise-linux-x64-qnx (already delivering this) ** Desktop MinGW 5.3 x86 ** Qnx x86 ** Qnx armv7 ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries will be offered like 5.8.0 br, Jani ________________________________________ From: Development on behalf of Thiago Macieira Sent: Wednesday, November 30, 2016 5:05 PM To: development at qt-project.org Subject: Re: [Development] Qt 5.9 On quarta-feira, 30 de novembro de 2016 07:53:40 PST Jake Petroules wrote: > How about we have one package per host platform which includes all possible > hosts and targets compatible with it? Then we have 3 packages, ever. Or, at least, one binary per platform + compiler combination. So that's 1 Linux package, 1 macOS package, 3 Windows packages today, with a 4th Windows (MSVC 2017) coming for 5.9. -- 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 tuukka.turunen at qt.io Wed Dec 21 09:17:58 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 21 Dec 2016 08:17:58 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <2254680.W3ZZFgYWVg@cartman> References: <2254680.W3ZZFgYWVg@cartman> Message-ID: > -----Original Message----- > From: sean.harmer On Behalf Of Sean Harmer > Sent: tiistaina 20. joulukuuta 2016 17.14 > To: development at qt-project.org > Cc: Tuukka Turunen ; releasing at qt-project.org > Subject: Re: [Development] Proposal to adjust release candidate process > > Hi Tuukka, > > I agree with your proposal, however I think there is also another issue or two > that we should address. > > At present we have ~ 4 releases per year 2 minor versions and 2 further > patch releases. One issue is that it looks like 5.8.0 will soon render the very > new > 5.7.1 release redundant. With that in mind was it worth splitting the effort > and having the 5.7.1 release at all? Don't get me wrong I'm all for additional > patch releases just that I'd hope they wouldn't coincide so closely with a > minor version release. > Did we need Qt 5.7.1 in my opinion, yes we did. Was it too late, yes it was. We can not change the past, but for Qt 5.8, I would like to branch 5.8.1 quite soon after the 5.8.0 is released. This way there will be more time between 5.8.1 and 5.9.0 releases. There are already quite many changes in 5.8 branch that are not in 5.8.0 branch. > This brings me onto another issue which perhaps we feel more strongly than > average in Qt 3D as a new module that is undergoing rapid bug-fixing, > improvements and with lots of new feature development starting to open > up. For example, although Qt 3D in Qt 5.7.0 was a nice release after lots of > effort, we still fixed a huge number of issues for 5.7.1, which took 181 days to > release from 5.7.0. > > Would it be possible for us to release more frequent patch releases? If not > for the whole of Qt, then at least for addon modules such as Qt 3D? I would like to have more patch level releases. Perhaps not between the feature releases, but to continue patch releases of Qt 5.x also after 5.x+1 is released. Currently this has not been feasible, but it is something I am interested in for 5.9 (after we have completed the big CI HW and virtualization infrastructure change and relocated the machine room). >The > latter would require splitting the packaging of such modules but would > reduce the amount of overall testing required for a new patch release. If > we'd collectively rather not go down that street I still think more frequent > patch releases would be nice. Users have the option of upgrading or not if > they want to reduce their own internal regression testing burden and freeze > on a specific version. But it would have the benefit that other users don't > need to wait 6 months for a set of bug fixes - roughly the same time to wait > as for new features. > > I wonder how much of the current pressure on releases is driven by the > time- based release policy. We aim for a new minor release every 6 months > which is admirable. But I wonder about the consequences of trying to stick to > that at the expense of quality of the 5.x.0 releases, especially given the long > turn around for subsequent patch releases. > I think the two biggest reasons to the pressure are: 1. We end of having too big amount of changes in a patch release and 2. Test automation does not yet catch enough issues on embedded and mobile, and we need to use slow manual testing a lot. Number #1 is something we can fix by our processes and behavior. It is also a "self filling prophecy" as we try to push a lot of things in to current release because it may take long time before next patch release is coming - thus making it more difficult to make patch releases. Number #2 is a continuous effort by our release and QA team and we are already quite good on desktop for automated package testing. > With the above in mind, how about this proposal in addition to yours > regarding the RC phase? > > * Branch off new feature branch every 6 months as at present. > > * Do not rush the release at the expense of quality or when it's convenient > due to packagers going on vacation etc. We release only when the release is > deemed to meet quality standards. > We already try not to rush on expense of quality. I do think the current ~17 weeks is too long time. It may be so long already that some lose focus. I would like to get it shorter, 10 or 12 weeks would be good in my opinion. The first step to reach this is to keep the feature freeze (no exceptions to complete some feature weeks after the FF). > * Aim for a patch release every alternate month if there are fixes on the > minor version branch and packaging/release staff are available. i.e. don't try > to force one out before the summer/Xmas vacations. > > * Consider releasing at least one patch release of the previous minor series > after the release of the next minor series' .0 release. For example, in the > current situation, potentially release a 5.7.2 after 5.8.0. (We already have > fixes on 5.8.0 and 5.8 that could have been submitted to the 5.7 branch if > there were to be a 5.7.2 release). > I think this would be very good for our users and something I would like to reach for 5.9 some way (see above for the reason why not yet) > Additionally, is there any way that contributors outside of The Qt Company > can assist with the practicalities of packaging? > Most important thing from wider community is testing, reporting and fixing the found issues. From maintainers getting the changes files in early and being active to freeze the modules early etc is extremely valuable. The sooner we identify and fix issues, the better it is. Yours, Tuukka > Just some food for thought. > > Cheers, > > Sean > > On Tuesday 20 December 2016 13:34:39 Tuukka Turunen wrote: > > Hi, > > > > I think we have three major problems with our current release process > > regarding the release candidate phase: > > > > 1. Process to make a RC that is as flawless as final causes > > inefficiency as we only get full test coverage with the RC itself > > > > 2. We get full attention for testing a bit too late, many fixes are > > still coming in close to the planned RC time causing instability > > > > 3. Current time between RC and final is planned to be 2 weeks, which > > is very little in order to take in the feedback and fix things > > > > Therefore, I would like to propose the following: > > > > a. Consider "Release Candidate" to be a phase rather than an > > individual delivery > > > > b. Create the first "RC1" almost immediately after release branch > > (e.g. 5.9.0) is operational > > > > c. Criteria for the "RC1" is that no known P0 bugs exist (i.e. there > > can be other issues that would not be acceptable in a final release) > > > > d. During the "RC" phase P1 (and possible P0 of course) bugs and > > documentation are fixed > > > > e. Public "RC" release is similar development release as Alpha and > > Beta in that it starts a phase of work > > > > f. Multiple snapshots / new candidates are created during the "RC" > > phase until one of them is considered the final release > > > > If desired, we could use some other name than "Release Candidate 1" > > for the release that begins the last phase of the release. It could be > > called "Beta 2" or "Technology preview", if so desired. Personally, I > > would call it "Release Candidate 1". > > > > The difference to our current process is quite small. In essence it > > would be about considering the "RC1" the beginning of the final > > releasing phase (.0 branch), not something we do almost at the end of > > it. I believe that lowering the quality criterial for "RC1" helps us > > in being more efficient as it has been in practice impossible to > > really fulfill the current process goal and have already the first RC as good as > the final. > > > > In case of Qt 5.9 it would mean that we have the first "RC" out around > > end of April, soon after the branching to 5.9.0 has been completed. We > > then have 4 or so weeks to make all the needed amount of candidates / > > snapshots until one of them will be released as Qt 5.9.0 final. If it > > happens earlier than in 4 weeks, great. If it takes more time, then so > > be it (although in such case we have probably missed something in the > > earlier steps of the release creation). > > > > Yours, > > > > --- > > Tuukka Turunen > > Director, R&D > > > > The Qt Company > > Lutakonaukio 1 > > 40100 Jyväskylä, Finland > > tuukka.turunen at qt.io > > +358 40 7655 800 > > http://qt.io > > --- > > -- > 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 alexander.blasche at qt.io Wed Dec 21 09:38:44 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Wed, 21 Dec 2016 08:38:44 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <2254680.W3ZZFgYWVg@cartman> References: <2254680.W3ZZFgYWVg@cartman> Message-ID: Hi, > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Sean Harmer > Sent: Tuesday, 20 December 2016 16:14 > I wonder how much of the current pressure on releases is driven by the time- > based release policy. We aim for a new minor release every 6 months which is > admirable. But I wonder about the consequences of trying to stick to that at the > expense of quality of the 5.x.0 releases, especially given the long turn around for > subsequent patch releases. ... > * Do not rush the release at the expense of quality or when it's convenient due > to packagers going on vacation etc. We release only when the release is > deemed to meet quality standards. Tuukka kind of made this point already but I'd like to make it more succinct. We do not want to change the time or the quality constraint. We want to adjust the feature constraint. This means that you and I as maintainers very much have it in our hands to manage the release pressure. You have to fight your own weaker self and accept that you may not keep the quality up with your feature plans for the module you maintain. -- Alex From thiago.macieira at intel.com Wed Dec 21 15:45:37 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 21 Dec 2016 12:45:37 -0200 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: Message-ID: <2557995.lvaW6oQBlV@tjmaciei-mobl1> Em terça-feira, 20 de dezembro de 2016, às 13:34:39 BRST, Tuukka Turunen escreveu: > If desired, we could use some other name than "Release Candidate 1" for the > release that begins the last phase of the release. It could be called "Beta > 2" or "Technology preview", if so desired. Personally, I would call it > "Release Candidate 1". > > The difference to our current process is quite small. In essence it would be > about considering the "RC1" the beginning of the final releasing phase (.0 > branch), not something we do almost at the end of it. I believe that > lowering the quality criterial for "RC1" helps us in being more efficient > as it has been in practice impossible to really fulfill the current process > goal and have already the first RC as good as the final. I like the process, but I would also rename the release like you proposed. We can't have something called "release candidate" when we *know* it's not a candidate. Let's call it beta 2, beta 3, etc. until we can make it a release. Release candidates are really the snapshots that the release team creates when we're testing for sanity right before the actual release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Marco.Bubke at qt.io Wed Dec 21 16:20:50 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Wed, 21 Dec 2016 15:20:50 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <2557995.lvaW6oQBlV@tjmaciei-mobl1> References: , <2557995.lvaW6oQBlV@tjmaciei-mobl1> Message-ID: I think many users see a beta as something you better not touch, but a release candidates can be trusted much more. I know it's not intended that way but people learned by experiences. [?] Maybe "pre release" or "preview" could be a name to show the final status? ________________________________ From: Development on behalf of Thiago Macieira Sent: Wednesday, December 21, 2016 3:45:37 PM To: development at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Em ter?a-feira, 20 de dezembro de 2016, ?s 13:34:39 BRST, Tuukka Turunen escreveu: > If desired, we could use some other name than "Release Candidate 1" for the > release that begins the last phase of the release. It could be called "Beta > 2" or "Technology preview", if so desired. Personally, I would call it > "Release Candidate 1". > > The difference to our current process is quite small. In essence it would be > about considering the "RC1" the beginning of the final releasing phase (.0 > branch), not something we do almost at the end of it. I believe that > lowering the quality criterial for "RC1" helps us in being more efficient > as it has been in practice impossible to really fulfill the current process > goal and have already the first RC as good as the final. I like the process, but I would also rename the release like you proposed. We can't have something called "release candidate" when we *know* it's not a candidate. Let's call it beta 2, beta 3, etc. until we can make it a release. Release candidates are really the snapshots that the release team creates when we're testing for sanity right before the actual release. -- 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 Jake.Petroules at qt.io Wed Dec 21 19:37:47 2016 From: Jake.Petroules at qt.io (Jake Petroules) Date: Wed, 21 Dec 2016 18:37:47 +0000 Subject: [Development] Qt 5.9 prebuild binary packages( was: Re: Qt 5.9) In-Reply-To: References: <76A7D197-150E-485A-AC7F-69BAE5DDD479@qt.io> <5895604.KNhrVNCRLl@tjmaciei-mobl1> Message-ID: LET'S DO IT! And thank you for following through on this idea. This will reduce our package testing burden significantly which is very important because it lowers the barrier to entry for us to actually add new platforms/installers. For example, adding tvOS to the combined macOS/iOS/Android package would be valuable. I would omit the host architectures (it provides no useful value since there are multiple host architectures in some cases) and target platforms from the filenames, though (like -android, -qnx, -android-ios), because they aren't there for the Windows package so it would be more consistent. The download descriptions should detail what each package contains. Also, can we simply subsume the QNX packages into the base enterprise packages? i.e. combine qt-enterprise-linux-x64-android and qt-enterprise-linux-x64-qnx? Or is there a licensing-related issue around that? And why do we need different packages based on the license, anyways? > On Dec 20, 2016, at 9:28 PM, Jani Heikkinen wrote: > > Hi all, > > I finally managed to do testing how big combined windows installer would be. I was a bit surprised that it is only ~3.3 GB, which is still smaller than combined mac-android-ios installer ;) Ok, this is done from 5.8 packages & binaries so situation might be a bit different in 5.9 where we will have some new binaries to be done. But in the other hand we will/should drop some so I think the size of combined one should be still manageable. > > So I propose we will offer following set of offline installers from Qt 5.9 -> > > - For linux we will have 3 installers (instead of existing 5): > * qt-enterprise-linux-x64-android (already delivering this) > * qt-opensource-linux-x64-android (already delivering this) > ** Desktop gcc 64-bit > ** Android x86 > ** Android armv7 > * qt-enterprise-linux-x64-qnx (already delivering this) > ** Desktop gcc 64-bit > ** Qnx x86 > ** Qnx armv7 > ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries will be offered like 5.8.0 > > - For mac we will have 2 installers (instead of existing 6): > * qt-enterprise-mac-x64-android-ios (already delivering this) > * qt-opensource-mac-x64-android-ios (already delivering this) > ** Desktop clang 64-bit > ** Android x86 > ** Android armv7 > ** iOS > > - For windows we will have 3 installers (instead of existing 17): > * qt-enterprise-windows-x86 (new) > * qt-opensource-windows-x86 (new) > ** Desktop MSVC 2013 x64 > ** Desktop MSVC 2015 x86 > ** Desktop MSVC 2015 x64 > ** Desktop MSVC 2017 x64 > ** Desktop MinGW 5.3 x86 > ** UWP MSVC 2015 x86 > ** UWP MSVC 2015 x64 > ** UWP MSVC 2015 armv7 > ** UWP MSVC 2017 x86 > ** UWP MSVC 2017 x64 > ** UWP MSVC 2017 armv7 > ** Android x86 > ** Android armv7 > * qt-enterprise-linux-x64-qnx (already delivering this) > ** Desktop MinGW 5.3 x86 > ** Qnx x86 > ** Qnx armv7 > ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries will be offered like 5.8.0 > br, > Jani > > ________________________________________ > From: Development on behalf of Thiago Macieira > Sent: Wednesday, November 30, 2016 5:05 PM > To: development at qt-project.org > Subject: Re: [Development] Qt 5.9 > > On quarta-feira, 30 de novembro de 2016 07:53:40 PST Jake Petroules wrote: >> How about we have one package per host platform which includes all possible >> hosts and targets compatible with it? Then we have 3 packages, ever. > > Or, at least, one binary per platform + compiler combination. So that's 1 > Linux package, 1 macOS package, 3 Windows packages today, with a 4th Windows > (MSVC 2017) coming for 5.9. > > -- > 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 -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From nospam at vuorela.dk Wed Dec 21 22:05:20 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Wed, 21 Dec 2016 21:05:20 +0000 (UTC) Subject: [Development] Calendar Systems proposal References: <6308711.nl2lZLevpo@tjmaciei-mobl1> Message-ID: On 2016-12-17, Soroush Rabiei wrote: > it's wrong to add such implementation to QDate. My view of QDate is this: > QDate represents a day in time. So it only needs to know what day it is > (how many days are to the day 0). And it is exactly things like that that would prevent partial date support in QDate (which is why I brought it up) /Sune From Maurice.Kalinowski at qt.io Thu Dec 22 08:09:51 2016 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Thu, 22 Dec 2016 07:09:51 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: , <2557995.lvaW6oQBlV@tjmaciei-mobl1> Message-ID: Hence, Technology Preview Preview Release Preview Release Candidate Release \o/ Maurice Von: Development [mailto:development-bounces+maurice.kalinowski=qt.io at qt-project.org] Im Auftrag von Marco Bubke Gesendet: Wednesday, December 21, 2016 4:21 PM An: Thiago Macieira ; development at qt-project.org Betreff: Re: [Development] Proposal to adjust release candidate process I think many users see a beta as something you better not touch, but a release candidates can be trusted much more. I know it's not intended that way but people learned by experiences. [??] Maybe "pre release" or "preview" could be a name to show the final status? ________________________________ From: Development > on behalf of Thiago Macieira > Sent: Wednesday, December 21, 2016 3:45:37 PM To: development at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Em terça-feira, 20 de dezembro de 2016, às 13:34:39 BRST, Tuukka Turunen escreveu: > If desired, we could use some other name than "Release Candidate 1" for the > release that begins the last phase of the release. It could be called "Beta > 2" or "Technology preview", if so desired. Personally, I would call it > "Release Candidate 1". > > The difference to our current process is quite small. In essence it would be > about considering the "RC1" the beginning of the final releasing phase (.0 > branch), not something we do almost at the end of it. I believe that > lowering the quality criterial for "RC1" helps us in being more efficient > as it has been in practice impossible to really fulfill the current process > goal and have already the first RC as good as the final. I like the process, but I would also rename the release like you proposed. We can't have something called "release candidate" when we *know* it's not a candidate. Let's call it beta 2, beta 3, etc. until we can make it a release. Release candidates are really the snapshots that the release team creates when we're testing for sanity right before the actual release. -- 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 Oliver.Wolff at qt.io Thu Dec 22 08:18:27 2016 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Thu, 22 Dec 2016 08:18:27 +0100 Subject: [Development] Qt 5.9 prebuild binary packages( was: Re: Qt 5.9) In-Reply-To: References: <76A7D197-150E-485A-AC7F-69BAE5DDD479@qt.io> <5895604.KNhrVNCRLl@tjmaciei-mobl1> Message-ID: <57b3b8f5-1aa8-831b-62f8-56b28a9ff000@qt.io> Can someone elaborate on how "one package per OS" reduces the testing burden significantly? We still have to check every platform/configuration that is inside the package. All that changes is that the testers install from one big package instead of smaller packages. I doubt that one person will check the whole windows package (for example). At least I will not volunteer to do that :X On 21/12/2016 19:37, Jake Petroules wrote: > LET'S DO IT! And thank you for following through on this idea. > > This will reduce our package testing burden significantly which is very important because it lowers the barrier to entry for us to actually add new platforms/installers. For example, adding tvOS to the combined macOS/iOS/Android package would be valuable. > > I would omit the host architectures (it provides no useful value since there are multiple host architectures in some cases) and target platforms from the filenames, though (like -android, -qnx, -android-ios), because they aren't there for the Windows package so it would be more consistent. The download descriptions should detail what each package contains. > > Also, can we simply subsume the QNX packages into the base enterprise packages? i.e. combine qt-enterprise-linux-x64-android and qt-enterprise-linux-x64-qnx? Or is there a licensing-related issue around that? And why do we need different packages based on the license, anyways? > >> On Dec 20, 2016, at 9:28 PM, Jani Heikkinen wrote: >> >> Hi all, >> >> I finally managed to do testing how big combined windows installer would be. I was a bit surprised that it is only ~3.3 GB, which is still smaller than combined mac-android-ios installer ;) Ok, this is done from 5.8 packages & binaries so situation might be a bit different in 5.9 where we will have some new binaries to be done. But in the other hand we will/should drop some so I think the size of combined one should be still manageable. >> >> So I propose we will offer following set of offline installers from Qt 5.9 -> >> >> - For linux we will have 3 installers (instead of existing 5): >> * qt-enterprise-linux-x64-android (already delivering this) >> * qt-opensource-linux-x64-android (already delivering this) >> ** Desktop gcc 64-bit >> ** Android x86 >> ** Android armv7 >> * qt-enterprise-linux-x64-qnx (already delivering this) >> ** Desktop gcc 64-bit >> ** Qnx x86 >> ** Qnx armv7 >> ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries will be offered like 5.8.0 >> >> - For mac we will have 2 installers (instead of existing 6): >> * qt-enterprise-mac-x64-android-ios (already delivering this) >> * qt-opensource-mac-x64-android-ios (already delivering this) >> ** Desktop clang 64-bit >> ** Android x86 >> ** Android armv7 >> ** iOS >> >> - For windows we will have 3 installers (instead of existing 17): >> * qt-enterprise-windows-x86 (new) >> * qt-opensource-windows-x86 (new) >> ** Desktop MSVC 2013 x64 >> ** Desktop MSVC 2015 x86 >> ** Desktop MSVC 2015 x64 >> ** Desktop MSVC 2017 x64 >> ** Desktop MinGW 5.3 x86 >> ** UWP MSVC 2015 x86 >> ** UWP MSVC 2015 x64 >> ** UWP MSVC 2015 armv7 >> ** UWP MSVC 2017 x86 >> ** UWP MSVC 2017 x64 >> ** UWP MSVC 2017 armv7 >> ** Android x86 >> ** Android armv7 >> * qt-enterprise-linux-x64-qnx (already delivering this) >> ** Desktop MinGW 5.3 x86 >> ** Qnx x86 >> ** Qnx armv7 >> ** NOTE: I don't think we can offer QNX 7 binaries yet so QNX 6 binaries will be offered like 5.8.0 >> br, >> Jani >> >> ________________________________________ >> From: Development on behalf of Thiago Macieira >> Sent: Wednesday, November 30, 2016 5:05 PM >> To: development at qt-project.org >> Subject: Re: [Development] Qt 5.9 >> >> On quarta-feira, 30 de novembro de 2016 07:53:40 PST Jake Petroules wrote: >>> How about we have one package per host platform which includes all possible >>> hosts and targets compatible with it? Then we have 3 packages, ever. >> Or, at least, one binary per platform + compiler combination. So that's 1 >> Linux package, 1 macOS package, 3 Windows packages today, with a 4th Windows >> (MSVC 2017) coming for 5.9. >> >> -- >> 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 Shawn.Rutledge at qt.io Thu Dec 22 08:25:23 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Thu, 22 Dec 2016 07:25:23 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <2557995.lvaW6oQBlV@tjmaciei-mobl1> Message-ID: <6EEA7C45-DB62-4E2D-ABC6-DC1C530D0830@qt.io> > On 22 Dec 2016, at 08:09, Maurice Kalinowski wrote: > > Hence, > > Technology Preview > Preview > Release Preview > Release Candidate > Release Tech Preview is so far the term for a module which is released but we reserve the right to continue making API changes anyway, right? So changing that might be confusing. And besides, alpha and beta are traditional and well understood. (Following that pattern though, I guess we ought to call the RC a “gamma”, but that’s not traditional for some reason.) From andrew.knight at intopalo.com Thu Dec 22 09:13:49 2016 From: andrew.knight at intopalo.com (Andrew Knight) Date: Thu, 22 Dec 2016 10:13:49 +0200 Subject: [Development] Qt 5.9 prebuild binary packages( was: Re: Qt 5.9) In-Reply-To: <57b3b8f5-1aa8-831b-62f8-56b28a9ff000@qt.io> References: <76A7D197-150E-485A-AC7F-69BAE5DDD479@qt.io> <5895604.KNhrVNCRLl@tjmaciei-mobl1> <57b3b8f5-1aa8-831b-62f8-56b28a9ff000@qt.io> Message-ID: <402045d1-2085-6588-6afa-24b99453484b@intopalo.com> Hi, On 12/22/16 09:18, Oliver Wolff wrote: > Can someone elaborate on how "one package per OS" reduces the testing > burden significantly? We still have to check every > platform/configuration that is inside the package. All that changes is > that the testers install from one big package instead of smaller > packages. I doubt that one person will check the whole windows package > (for example). At least I will not volunteer to do that :X I agree. If your goal is to have fewer people testing, combine the installers. Then, people who don't have the time/bandwidth/disk space for several 3.3GB snapshots will simply not test the packages. As as a *former* Windows user, I may be out of sync with developer expectations. Even so, I imagine you would be hard-pressed to find many developers who use all of the ABIs listed in that hypothetical Windows installer. I guess this will push those users to use the online installer, which is probably what is desired... I still have to deal with CI systems which download and install Qt automatically, and they are especially sensitive to the download/installation size issue. Until either installer provides a supported way to script the installation (I've been using [0]), then bloating the offline installer gets a -1 from me. > > > On 21/12/2016 19:37, Jake Petroules wrote: >> LET'S DO IT! And thank you for following through on this idea. >> >> This will reduce our package testing burden significantly which is >> very important because it lowers the barrier to entry for us to >> actually add new platforms/installers. For example, adding tvOS to >> the combined macOS/iOS/Android package would be valuable. This one sounds reasonable. >> >> I would omit the host architectures (it provides no useful value >> since there are multiple host architectures in some cases) and target >> platforms from the filenames, though (like -android, -qnx, >> -android-ios), because they aren't there for the Windows package so >> it would be more consistent. The download descriptions should detail >> what each package contains. Agreed. >> >> Also, can we simply subsume the QNX packages into the base enterprise >> packages? i.e. combine qt-enterprise-linux-x64-android and >> qt-enterprise-linux-x64-qnx? Or is there a licensing-related issue >> around that? And why do we need different packages based on the >> license, anyways? I assume the enterprise components haven't been properly "sanitized" so that they can be disabled for the open-source distribution. Combining the installers certainly makes the most sense, and was something promised already at last year's QtWS IIRC. [0] https://github.com/benlau/qtci/blob/master/bin/extract-qt-installer -- Andrew From a.volkov at rusbitech.ru Thu Dec 22 11:06:58 2016 From: a.volkov at rusbitech.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCS0L7Qu9C60L7Qsg==?=) Date: Thu, 22 Dec 2016 13:06:58 +0300 Subject: [Development] Q_COMPILER_VARIADIC_TEMPLATES since Qt 5.7 Message-ID: Hi, It is stated in https://codereview.qt-project.org/#/c/168057/ that Q_COMPILER_VARIADIC_TEMPLATES is required since Qt 5.7. It is true? Can I use QOverload which depends on it ( https://codereview.qt-project.org/#/c/180525/ ) ? BR, Alexander. From announce at qt-project.org Thu Dec 22 12:08:09 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 22 Dec 2016 11:08:09 +0000 Subject: [Development] [Announce] Qt 5.8.0 RC released In-Reply-To: References: Message-ID: Hi all, We have released Qt 5.8.0 RC today, see http://blog.qt.io/blog/2016/12/22/qt-5-8-0-release-candidate-available/ Thanks to everyone involved. Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io http://qt.io _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From thiago.macieira at intel.com Thu Dec 22 12:10:05 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 22 Dec 2016 09:10:05 -0200 Subject: [Development] Q_COMPILER_VARIADIC_TEMPLATES since Qt 5.7 In-Reply-To: References: Message-ID: <1873974.FQHLTlA0E7@tjmaciei-mobl1> Em quinta-feira, 22 de dezembro de 2016, às 13:06:58 BRST, Александр Волков escreveu: > Hi, > > It is stated in https://codereview.qt-project.org/#/c/168057/ that > Q_COMPILER_VARIADIC_TEMPLATES is required since Qt 5.7. > It is true? Can I use QOverload which depends on it ( > https://codereview.qt-project.org/#/c/180525/ ) ? qOverload requires C++14 variable templates. QOverload could be used, but I'd rather you didn't use it in the Qt sources. It's a bit ugly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexander.blasche at qt.io Thu Dec 22 12:25:12 2016 From: alexander.blasche at qt.io (Alexander Blasche) Date: Thu, 22 Dec 2016 11:25:12 +0000 Subject: [Development] Q_COMPILER_VARIADIC_TEMPLATES since Qt 5.7 In-Reply-To: <1873974.FQHLTlA0E7@tjmaciei-mobl1> References: , <1873974.FQHLTlA0E7@tjmaciei-mobl1> Message-ID: ________________________________________ From: Development on behalf of Thiago Macieira >QOverload could be used, but I'd rather you didn't use it in the Qt sources. >It's a bit ugly. Currently not all Qt compilers work with it which makes it a no go for Qt itself. I had to remove it again: https://bugreports.qt.io/browse/QTBUG-55747 -- Alex From a.volkov at rusbitech.ru Thu Dec 22 12:29:11 2016 From: a.volkov at rusbitech.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCS0L7Qu9C60L7Qsg==?=) Date: Thu, 22 Dec 2016 14:29:11 +0300 Subject: [Development] Q_COMPILER_VARIADIC_TEMPLATES since Qt 5.7 In-Reply-To: <1873974.FQHLTlA0E7@tjmaciei-mobl1> References: <1873974.FQHLTlA0E7@tjmaciei-mobl1> Message-ID: 22.12.2016 14:10, Thiago Macieira пишет: > qOverload requires C++14 variable templates. > > QOverload could be used, but I'd rather you didn't use it in the Qt sources. > It's a bit ugly. It's not uglier than static_cast. Compare: connect(offsetSpinBox, static_cast(&QSpinBox::valueChanged), vs connect(offsetSpinBox, QOverload::of(&QSpinBox::valueChanged), At least it should be used in the examples, so Qt users could search the documentation and find out that there is qOverload. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Thu Dec 22 13:54:08 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 22 Dec 2016 12:54:08 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <6EEA7C45-DB62-4E2D-ABC6-DC1C530D0830@qt.io> References: <2557995.lvaW6oQBlV@tjmaciei-mobl1> <6EEA7C45-DB62-4E2D-ABC6-DC1C530D0830@qt.io> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Shawn > Rutledge > Sent: torstaina 22. joulukuuta 2016 9.25 > To: development at qt-project.org; releasing at qt-project.org > Subject: Re: [Development] Proposal to adjust release candidate process > > > > On 22 Dec 2016, at 08:09, Maurice Kalinowski > wrote: > > > > Hence, > > > > Technology Preview > > Preview > > Release Preview > > Release Candidate > > Release > > Tech Preview is so far the term for a module which is released but we > reserve the right to continue making API changes anyway, right? So changing > that might be confusing. > > And besides, alpha and beta are traditional and well understood. (Following > that pattern though, I guess we ought to call the RC a “gamma”, but that’s > not traditional for some reason.) > :) If we do not want to call the first development release from the release branch "Release Candidate 1", then I think calling it "Release Preview" is a good approach. Yours, Tuukka > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From andre at familiesomers.nl Thu Dec 22 14:08:30 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 22 Dec 2016 14:08:30 +0100 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <2557995.lvaW6oQBlV@tjmaciei-mobl1> <6EEA7C45-DB62-4E2D-ABC6-DC1C530D0830@qt.io> Message-ID: <02c56635-7016-fbbc-7aa0-e147f85243a6@familiesomers.nl> Hi, Op 22/12/2016 om 13:54 schreef Tuukka Turunen: > >> -----Original Message----- >> From: Development [mailto:development- >> bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Shawn >> Rutledge >> Sent: torstaina 22. joulukuuta 2016 9.25 >> To: development at qt-project.org; releasing at qt-project.org >> Subject: Re: [Development] Proposal to adjust release candidate process >> >> >>> On 22 Dec 2016, at 08:09, Maurice Kalinowski >> wrote: >>> Hence, >>> >>> Technology Preview >>> Preview >>> Release Preview >>> Release Candidate >>> Release >> Tech Preview is so far the term for a module which is released but we >> reserve the right to continue making API changes anyway, right? So changing >> that might be confusing. >> >> And besides, alpha and beta are traditional and well understood. (Following >> that pattern though, I guess we ought to call the RC a “gamma”, but that’s >> not traditional for some reason.) >> > :) > > If we do not want to call the first development release from the release branch "Release Candidate 1", then I think calling it "Release Preview" is a good approach. > > At least _somebody_ at the Qt Project still has the normal order of release names clear: https://twitter.com/qtproject/status/811905487600046081 ;-) André From marc.mutz at kdab.com Thu Dec 22 15:24:07 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 22 Dec 2016 15:24:07 +0100 Subject: [Development] Q_COMPILER_VARIADIC_TEMPLATES since Qt 5.7 In-Reply-To: References: <1873974.FQHLTlA0E7@tjmaciei-mobl1> Message-ID: <201612221524.07613.marc.mutz@kdab.com> On Thursday 22 December 2016 12:25:12 Alexander Blasche wrote: > ________________________________________ > From: Development > on behalf of > Thiago Macieira > > >QOverload could be used, but I'd rather you didn't use it in the Qt > >sources. It's a bit ugly. > > Currently not all Qt compilers work with it which makes it a no go for Qt > itself. I had to remove it again: > > https://bugreports.qt.io/browse/QTBUG-55747 I'm not sure that it can be fixed at all (the BR is about overloaded function / function template). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Thu Dec 22 21:09:28 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 22 Dec 2016 18:09:28 -0200 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <6EEA7C45-DB62-4E2D-ABC6-DC1C530D0830@qt.io> Message-ID: <1514942.HKomPSatJR@tjmaciei-mobl1> Em quinta-feira, 22 de dezembro de 2016, às 12:54:08 BRST, Tuukka Turunen escreveu: > > And besides, alpha and beta are traditional and well understood. > > (Following that pattern though, I guess we ought to call the RC a > > “gamma”, but that’s not traditional for some reason.) > > > > If we do not want to call the first development release from the release > branch "Release Candidate 1", then I think calling it "Release Preview" is > a good approach. Call it beta 2 (or gamma 1) right after branch and one we've iterated and we could have released, we call it release candidate. We release them more often, with more iterations, so that we get more feedback. I think that's the most important part. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Dec 22 21:11:29 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 22 Dec 2016 18:11:29 -0200 Subject: [Development] Q_COMPILER_VARIADIC_TEMPLATES since Qt 5.7 In-Reply-To: <201612221524.07613.marc.mutz@kdab.com> References: <201612221524.07613.marc.mutz@kdab.com> Message-ID: <1734070.TZKgayiPvZ@tjmaciei-mobl1> Em quinta-feira, 22 de dezembro de 2016, às 15:24:07 BRST, Marc Mutz escreveu: > On Thursday 22 December 2016 12:25:12 Alexander Blasche wrote: > > ________________________________________ > > From: Development > > on behalf of > > Thiago Macieira > > > > >QOverload could be used, but I'd rather you didn't use it in the Qt > > >sources. It's a bit ugly. > > > > Currently not all Qt compilers work with it which makes it a no go for Qt > > itself. I had to remove it again: > > > > https://bugreports.qt.io/browse/QTBUG-55747 > > I'm not sure that it can be fixed at all (the BR is about overloaded > function / function template). Do we know if Clang is right or if it is a compiler bug? Since it went into the codebase, I assume that the other compilers and other versions of Clang accepted it. I'm guessing it's a Clang update by Apple that caused it. Considering Clang 4.0 is currently unusable due to regressions, I'm not inclined to accept the failure as our fault. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tim at klingt.org Thu Dec 22 23:01:49 2016 From: tim at klingt.org (Tim Blechmann) Date: Thu, 22 Dec 2016 23:01:49 +0100 Subject: [Development] [Announce] Qt 5.8.0 RC released In-Reply-To: References: Message-ID: > We have released Qt 5.8.0 RC today, see http://blog.qt.io/blog/2016/12/22/qt-5-8-0-release-candidate-available/ > Thanks to everyone involved. hi all, like with 5.8-beta, i'm still having issues when linking statically against a prebuilt static library of libpng (because libpng depends on zlib). compare: https://bugreports.qt.io/browse/QTBUG-56163 in short, it gives me: > ERROR: Feature 'system-png' was enabled, but the pre-condition 'features.png && libs.libpng' failed. i had been able to work around this issue via: > diff --git a/qtbase/src/gui/configure.json b/qtbase/src/gui/configure.json > index 1f5011617c..54ea749dfd 100644 > --- a/qtbase/src/gui/configure.json > +++ b/qtbase/src/gui/configure.json > @@ -672,7 +672,6 @@ > "label": " Using system libpng", > "disable": "input.libpng == 'qt'", > "enable": "input.libpng == 'system'", > - "condition": "features.png && libs.libpng", > "output": [ "privateFeature" ] > }, > "qpa_default_platform": { in 5.8.0-RC, this broke in another way, though: > cd gui/ && ( test -e Makefile || /Users/tim/dev/qt3rd/build-Qt-5.x-dev-macx-clang-static/qtbase/bin/qmake -o Makefile /Users/tim/dev/qt3rd/qtbase/src/gui/gui.pro -qtconf /Users/tim/dev/qt3rd/build-Qt-5.x-dev-macx-clang-static/qtbase/bin/qt.conf -- -qt-zlib -qt-harfbuzz -no-glib -confirm-license -nomake tests -nomake examples -skip qtwebchannel -skip qtscript -system-libpng -I /Users/tim/dev/qt3rd/3rdparty-builds/libpng/ -L /Users/tim/dev/qt3rd/3rdparty-builds/libpng/lib/osx -system-libjpeg -I /Users/tim/dev/qt3rd/3rdparty-builds/libjpeg/ -L /Users/tim/dev/qt3rd/3rdparty-builds/libjpeg/lib/osx -system-zlib -I /Users/tim/dev/qt3rd/3rdparty-builds/zlib/ -L /Users/tim/dev/qt3rd/3rdparty-builds/zlib/lib/osx -commercial -debug-and-release -static -prefix /Users/tim/dev/qt3rd/Qt-5.x-dev-macx-clang-static -platform macx-clang ) && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile > Project ERROR: Library 'libpng' is not defined. > make: *** [sub-gui-make_first] Error 3 any idea how i can get qt-5.8 to compile again? thanks a lot, tim From thiago.macieira at intel.com Fri Dec 23 01:10:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 22 Dec 2016 22:10:55 -0200 Subject: [Development] [Announce] Qt 5.8.0 RC released In-Reply-To: References: Message-ID: <2489586.XLrVdKsgBl@tjmaciei-mobl1> Em quinta-feira, 22 de dezembro de 2016, às 23:01:49 BRST, Tim Blechmann escreveu: > like with 5.8-beta, i'm still having issues when linking statically > against a prebuilt static library of libpng (because libpng depends on > zlib). compare: https://bugreports.qt.io/browse/QTBUG-56163 > > in short, it gives me: > > ERROR: Feature 'system-png' was enabled, but the pre-condition > > 'features.png && libs.libpng' failed. What is the actual error, listed in config.log? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Dec 23 01:13:44 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 22 Dec 2016 22:13:44 -0200 Subject: [Development] [Announce] Qt 5.8.0 RC released In-Reply-To: References: Message-ID: <5277880.e8O7FcfNNd@tjmaciei-mobl1> Em quinta-feira, 22 de dezembro de 2016, às 23:01:49 BRST, Tim Blechmann escreveu: > > cd gui/ && ( test -e Makefile || > > /Users/tim/dev/qt3rd/build-Qt-5.x-dev-macx-clang-static/qtbase/bin/qmake > > -o Makefile /Users/tim/dev/qt3rd/qtbase/src/gui/gui.pro -qtconf > > /Users/tim/dev/qt3rd/build-Qt-5.x-dev-macx-clang-static/qtbase/bin/qt.con > > f -- -qt-zlib -qt-harfbuzz -no-glib -confirm-license -nomake tests -nomake > > examples -skip qtwebchannel -skip qtscript -system-libpng -I > > /Users/tim/dev/qt3rd/3rdparty-builds/libpng/ -L > > /Users/tim/dev/qt3rd/3rdparty-builds/libpng/lib/osx -system-libjpeg -I > > /Users/tim/dev/qt3rd/3rdparty-builds/libjpeg/ -L > > /Users/tim/dev/qt3rd/3rdparty-builds/libjpeg/lib/osx -system-zlib -I > > /Users/tim/dev/qt3rd/3rdparty-builds/zlib/ -L > > /Users/tim/dev/qt3rd/3rdparty-builds/zlib/lib/osx -commercial > > -debug-and-release -static -prefix > > /Users/tim/dev/qt3rd/Qt-5.x-dev-macx-clang-static -platform macx-clang ) > > && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile > > Project ERROR: Library 'libpng' is not defined. > > make: *** [sub-gui-make_first] Error 3 > > any idea how i can get qt-5.8 to compile again? Nuke your build dir completely, including and especially hidden files and config.cache. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tim at klingt.org Fri Dec 23 01:26:38 2016 From: tim at klingt.org (Tim Blechmann) Date: Fri, 23 Dec 2016 01:26:38 +0100 Subject: [Development] [Announce] Qt 5.8.0 RC released In-Reply-To: <2489586.XLrVdKsgBl@tjmaciei-mobl1> References: <2489586.XLrVdKsgBl@tjmaciei-mobl1> Message-ID: >> like with 5.8-beta, i'm still having issues when linking statically >> against a prebuilt static library of libpng (because libpng depends on >> zlib). compare: https://bugreports.qt.io/browse/QTBUG-56163 >> >> in short, it gives me: >>> ERROR: Feature 'system-png' was enabled, but the pre-condition >>> 'features.png && libs.libpng' failed. > > What is the actual error, listed in config.log? it is attached to the bug report. (undefined symbols in from zlib) > in 5.8.0-RC, this broke in another way, though: > >> cd gui/ && ( test -e Makefile || /Users/tim/dev/qt3rd/build-Qt-5.x-dev-macx-clang-static/qtbase/bin/qmake -o Makefile /Users/tim/dev/qt3rd/qtbase/src/gui/gui.pro -qtconf /Users/tim/dev/qt3rd/build-Qt-5.x-dev-macx-clang-static/qtbase/bin/qt.conf -- -qt-zlib -qt-harfbuzz -no-glib -confirm-license -nomake tests -nomake examples -skip qtwebchannel -skip qtscript -system-libpng -I /Users/tim/dev/qt3rd/3rdparty-builds/libpng/ -L /Users/tim/dev/qt3rd/3rdparty-builds/libpng/lib/osx -system-libjpeg -I /Users/tim/dev/qt3rd/3rdparty-builds/libjpeg/ -L /Users/tim/dev/qt3rd/3rdparty-builds/libjpeg/lib/osx -system-zlib -I /Users/tim/dev/qt3rd/3rdparty-builds/zlib/ -L /Users/tim/dev/qt3rd/3rdparty-builds/zlib/lib/osx -commercial -debug-and-release -static -prefix /Users/tim/dev/qt3rd/Qt-5.x-dev-macx-cl > ang-static -platform macx-clang ) && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile >> Project ERROR: Library 'libpng' is not defined. >> make: *** [sub-gui-make_first] Error 3 > > any idea how i can get qt-5.8 to compile again? this actually seems to be unrelated to my custom static libraries. running a plain ./configure seems to detect (dynamically linked) libpng installed by homebrew. the error is the same, though ... -qt-libpng compiles (though it is not an option for me atm) From thiago.macieira at intel.com Fri Dec 23 02:35:42 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 22 Dec 2016 23:35:42 -0200 Subject: [Development] [Announce] Qt 5.8.0 RC released In-Reply-To: References: <2489586.XLrVdKsgBl@tjmaciei-mobl1> Message-ID: <2033013.tgnGvbtKKK@tjmaciei-mobl1> Em sexta-feira, 23 de dezembro de 2016, às 01:26:38 BRST, Tim Blechmann escreveu: > it is attached to the bug report. (undefined symbols in from zlib) That means that linking to -lpng requires -lz to show up. configure will try to get the library flags for libpng from pkg-config, but it's not passing the --static option. That is simply not a case we've taken into account. It shouldn't be too hard to make the pkgConfig-type tests in configure retry with the --static option if the build failed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From robin+qt at viroteck.net Fri Dec 23 02:40:26 2016 From: robin+qt at viroteck.net (Robin Burchell) Date: Fri, 23 Dec 2016 02:40:26 +0100 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: Message-ID: <1482457226.2797217.827604001.65A0D3E0@webmail.messagingengine.com> My (slightly delayed) $0.02: On releasing in general: I would agree that releases take too long, often, but I am of the belief that a good part of this is a mess of our own making. For instance, due to an end-user or project requiring a specific version or purely out of fear that the next release may be a long time away, I think we (collectively) often end up pushing changes to branches that might be less than ideally suited for the change in question. I think we should recognise that these pressures do exist, and consider ways we can work to mitigate them (things like: nightly or at least semi-"nightly" builds? working on pushing out patch releases more often? encouraging more of our consumers to apply patches that we already took in upstream and do their own builds? anything else?) It goes without saying that these are hard problems, but I think that working at the root causes is the only way to ultimately fix this. Moving away from a time-based schedule is just going to encourage the schedule to slip further, because now you have to wait [potentially forever] to get a change released rather than roughly [x months], which leads to even more pressure to get changes in an earlier version. Ultimately, I think we need to be better at saying "no" to changes that aren't explicitly necessary, especially on version branches (5.x.y) and in general taking care to evaluate how "done" something is before taking it in too. This is not an exact science, though, which makes it difficult to balance. Even if we truly are on the side of being too aggressive now - it may be perfectly possible that we could end up too conservative (and delaying fixes that our end users would like to see sooner), e.g. by implementing some kind of "blanket" restriction like "only P0 bugs get fixed in this branch" (not a suggestion I am making I will emphasise, just a note that we need to approach this carefully). To the proposal at hand: I think that we should not be afraid of releasing more release candidates. Some of them may well be broken, and while that's unfortunate, it's still certainly better that we release broken release candidates than a broken final release in the end. It may be the case that releasing more betas or using a different name may help get feedback earlier, but IMHO we have to accept to some extent that our end users are not us: they have limited time to build & test Qt in addition to their normal product/application work, and thus, overall, we should not expect too much of them. If we want more feedback, we need to work on making that testing process easier for them, rather than playing naming tricks, I think. On Tue, Dec 20, 2016, at 02:34 PM, Tuukka Turunen wrote: > > Hi, > > I think we have three major problems with our current release process > regarding the release candidate phase: > > 1. Process to make a RC that is as flawless as final causes > inefficiency as we only get full test coverage with the RC itself > > 2. We get full attention for testing a bit too late, many fixes are > still coming in close to the planned RC time causing instability > > 3. Current time between RC and final is planned to be 2 weeks, > which is very little in order to take in the feedback and fix things > > Therefore, I would like to propose the following: > > a. Consider "Release Candidate" to be a phase rather than an > individual delivery > > b. Create the first "RC1" almost immediately after release branch > (e.g. 5.9.0) is operational > > c. Criteria for the "RC1" is that no known P0 bugs exist (i.e. > there can be other issues that would not be acceptable in a final > release) > > d. During the "RC" phase P1 (and possible P0 of course) bugs and > documentation are fixed > > e. Public "RC" release is similar development release as Alpha and > Beta in that it starts a phase of work > > f. Multiple snapshots / new candidates are created during the "RC" > phase until one of them is considered the final release > > If desired, we could use some other name than "Release Candidate 1" for > the release that begins the last phase of the release. It could be called > "Beta 2" or "Technology preview", if so desired. Personally, I would call > it "Release Candidate 1". > > The difference to our current process is quite small. In essence it would > be about considering the "RC1" the beginning of the final releasing phase > (.0 branch), not something we do almost at the end of it. I believe that > lowering the quality criterial for "RC1" helps us in being more efficient > as it has been in practice impossible to really fulfill the current > process goal and have already the first RC as good as the final. > > In case of Qt 5.9 it would mean that we have the first "RC" out around > end of April, soon after the branching to 5.9.0 has been completed. We > then have 4 or so weeks to make all the needed amount of candidates / > snapshots until one of them will be released as Qt 5.9.0 final. If it > happens earlier than in 4 weeks, great. If it takes more time, then so be > it (although in such case we have probably missed something in the > earlier steps of the release creation). > > Yours, > > --- > Tuukka Turunen > Director, R&D > > The Qt Company > Lutakonaukio 1 > 40100 Jyväskylä, Finland > tuukka.turunen at qt.io > +358 40 7655 800 > http://qt.io > --- > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at qt.io Fri Dec 23 08:17:01 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 23 Dec 2016 07:17:01 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <1514942.HKomPSatJR@tjmaciei-mobl1> References: <6EEA7C45-DB62-4E2D-ABC6-DC1C530D0830@qt.io> <1514942.HKomPSatJR@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: torstaina 22. joulukuuta 2016 22.09 > To: development at qt-project.org > Subject: Re: [Development] Proposal to adjust release candidate process > > Em quinta-feira, 22 de dezembro de 2016, às 12:54:08 BRST, Tuukka Turunen > escreveu: > > > And besides, alpha and beta are traditional and well understood. > > > (Following that pattern though, I guess we ought to call the RC a > > > “gamma”, but that’s not traditional for some reason.) > > > > > > > > If we do not want to call the first development release from the > > release branch "Release Candidate 1", then I think calling it "Release > > Preview" is a good approach. > > Call it beta 2 (or gamma 1) right after branch and one we've iterated and we > could have released, we call it release candidate. We release them more > often, with more iterations, so that we get more feedback. I think that's the > most important part. > Beta 2 is still a bit misleading in my opinion. It is coming from release branch, so we are beyond the Beta phase. Let's think about the name later, after the holidays. It anyway seems that the basic approach is seen viable. I would like to try this with Qt 5.9. The current scheduling lists the RC for 17th of May. What would then be the anticipated time to release the gamma/beta2/preview release as soon as we are in the 5.9.0 branch? Perhaps around 3rd of May? 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 tuukka.turunen at qt.io Fri Dec 23 08:33:24 2016 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 23 Dec 2016 07:33:24 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <1482457226.2797217.827604001.65A0D3E0@webmail.messagingengine.com> References: <1482457226.2797217.827604001.65A0D3E0@webmail.messagingengine.com> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Robin Burchell > Sent: perjantaina 23. joulukuuta 2016 3.40 > To: development at qt-project.org > Subject: Re: [Development] Proposal to adjust release candidate process > > My (slightly delayed) $0.02: > > On releasing in general: I would agree that releases take too long, often, but I > am of the belief that a good part of this is a mess of our own making. For > instance, due to an end-user or project requiring a specific version or purely > out of fear that the next release may be a long time away, I think we > (collectively) often end up pushing changes to branches that might be less > than ideally suited for the change in question. > I think this is true and something we need to address. Another symptom of this is the time we reserve between feature freeze and Alpha. Why does it always take many weeks (4 is reserved in the current release process http://wiki.qt.io/Qt5Releasing). There is still a lot of commits coming during this phase, perhaps some of them are such that actually should have been in before the FF. I would like us to reach a state where Alpha is released almost immediately (within 1 week) of the Feature freeze. I know that we are not yet there, but in order to reduce the overall release time that is necessary. > I think we should recognise that these pressures do exist, and consider ways > we can work to mitigate them (things like: nightly or at least semi-"nightly" > builds? working on pushing out patch releases more often? > encouraging more of our consumers to apply patches that we already took in > upstream and do their own builds? anything else?) > > It goes without saying that these are hard problems, but I think that working > at the root causes is the only way to ultimately fix this. > Moving away from a time-based schedule is just going to encourage the > schedule to slip further, because now you have to wait [potentially forever] > to get a change released rather than roughly [x months], which leads to even > more pressure to get changes in an earlier version. > We do not want to move away from the time based releasing, just trying to become better in 1. keeping the schedule and after that 2. reducing the time it takes to make a feature release of Qt. > Ultimately, I think we need to be better at saying "no" to changes that aren't > explicitly necessary, especially on version branches (5.x.y) and in general > taking care to evaluate how "done" something is before taking it in too. This > is not an exact science, though, which makes it difficult to balance. Even if we > truly are on the side of being too aggressive now - it may be perfectly > possible that we could end up too conservative (and delaying fixes that our > end users would like to see sooner), e.g. by implementing some kind of > "blanket" restriction like "only P0 bugs get fixed in this branch" (not a > suggestion I am making I will emphasise, just a note that we need to > approach this carefully). > This, I think, especially has been an issue with some of our patch level releases lately. While it sounds good to have fixes, too big amount of fixes is prone to cause instability - and certainly it increases the effort of making the patch releases. > To the proposal at hand: I think that we should not be afraid of releasing > more release candidates. Some of them may well be broken, and while that's > unfortunate, it's still certainly better that we release broken release > candidates than a broken final release in the end. > Thanks, fully agree. Our users are intelligent people. I do not think anyone thinks such an early preview releases can be used in production (or if they would, then there is a good reason). > It may be the case that releasing more betas or using a different name may > help get feedback earlier, but IMHO we have to accept to some extent that > our end users are not us: they have limited time to build & test Qt in addition > to their normal product/application work, and thus, overall, we should not > expect too much of them. If we want more feedback, we need to work on > making that testing process easier for them, rather than playing naming > tricks, I think. > Actually the problem currently has not so much been lack of feedback, but the fact that feedback comes so late in the release phase that it is hard to react to it properly. I hope we could slightly ease this by having the first release from release branch earlier than we now do. Yours, Tuukka > On Tue, Dec 20, 2016, at 02:34 PM, Tuukka Turunen wrote: > > > > Hi, > > > > I think we have three major problems with our current release process > > regarding the release candidate phase: > > > > 1. Process to make a RC that is as flawless as final causes > > inefficiency as we only get full test coverage with the RC itself > > > > 2. We get full attention for testing a bit too late, many fixes are > > still coming in close to the planned RC time causing instability > > > > 3. Current time between RC and final is planned to be 2 weeks, > > which is very little in order to take in the feedback and fix things > > > > Therefore, I would like to propose the following: > > > > a. Consider "Release Candidate" to be a phase rather than an > > individual delivery > > > > b. Create the first "RC1" almost immediately after release branch > > (e.g. 5.9.0) is operational > > > > c. Criteria for the "RC1" is that no known P0 bugs exist (i.e. > > there can be other issues that would not be acceptable in a final > > release) > > > > d. During the "RC" phase P1 (and possible P0 of course) bugs and > > documentation are fixed > > > > e. Public "RC" release is similar development release as Alpha and > > Beta in that it starts a phase of work > > > > f. Multiple snapshots / new candidates are created during the "RC" > > phase until one of them is considered the final release > > > > If desired, we could use some other name than "Release Candidate 1" > > for the release that begins the last phase of the release. It could be > > called "Beta 2" or "Technology preview", if so desired. Personally, I > > would call it "Release Candidate 1". > > > > The difference to our current process is quite small. In essence it > > would be about considering the "RC1" the beginning of the final > > releasing phase > > (.0 branch), not something we do almost at the end of it. I believe > > that lowering the quality criterial for "RC1" helps us in being more > > efficient as it has been in practice impossible to really fulfill the > > current process goal and have already the first RC as good as the final. > > > > In case of Qt 5.9 it would mean that we have the first "RC" out around > > end of April, soon after the branching to 5.9.0 has been completed. We > > then have 4 or so weeks to make all the needed amount of candidates / > > snapshots until one of them will be released as Qt 5.9.0 final. If it > > happens earlier than in 4 weeks, great. If it takes more time, then so > > be it (although in such case we have probably missed something in the > > earlier steps of the release creation). > > > > Yours, > > > > --- > > Tuukka Turunen > > Director, R&D > > > > The Qt Company > > Lutakonaukio 1 > > 40100 Jyväskylä, Finland > > tuukka.turunen at qt.io > > +358 40 7655 800 > > http://qt.io > > --- > > > > _______________________________________________ > > 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 tim at klingt.org Fri Dec 23 13:34:57 2016 From: tim at klingt.org (Tim Blechmann) Date: Fri, 23 Dec 2016 13:34:57 +0100 Subject: [Development] [Announce] Qt 5.8.0 RC released In-Reply-To: <5277880.e8O7FcfNNd@tjmaciei-mobl1> References: <5277880.e8O7FcfNNd@tjmaciei-mobl1> Message-ID: >>> cd gui/ && ( test -e Makefile || >>> /Users/tim/dev/qt3rd/build-Qt-5.x-dev-macx-clang-static/qtbase/bin/qmake >>> -o Makefile /Users/tim/dev/qt3rd/qtbase/src/gui/gui.pro -qtconf >>> /Users/tim/dev/qt3rd/build-Qt-5.x-dev-macx-clang-static/qtbase/bin/qt.con >>> f -- -qt-zlib -qt-harfbuzz -no-glib -confirm-license -nomake tests -nomake >>> examples -skip qtwebchannel -skip qtscript -system-libpng -I >>> /Users/tim/dev/qt3rd/3rdparty-builds/libpng/ -L >>> /Users/tim/dev/qt3rd/3rdparty-builds/libpng/lib/osx -system-libjpeg -I >>> /Users/tim/dev/qt3rd/3rdparty-builds/libjpeg/ -L >>> /Users/tim/dev/qt3rd/3rdparty-builds/libjpeg/lib/osx -system-zlib -I >>> /Users/tim/dev/qt3rd/3rdparty-builds/zlib/ -L >>> /Users/tim/dev/qt3rd/3rdparty-builds/zlib/lib/osx -commercial >>> -debug-and-release -static -prefix >>> /Users/tim/dev/qt3rd/Qt-5.x-dev-macx-clang-static -platform macx-clang ) >>> && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile >>> Project ERROR: Library 'libpng' is not defined. >>> make: *** [sub-gui-make_first] Error 3 >> >> any idea how i can get qt-5.8 to compile again? > > Nuke your build dir completely, including and especially hidden files and > config.cache. first thing that i had tried ;) -- seems the be related to -system-zlib when -system-libpng is used. steps to reproduce: * install libpng via homebrew * configure qt via: ../configure -system-zlib -system-libpng -platform macx-clang using's qt-zlib seems to work: ../configure -qt-zlib -system-libpng -platform macx-clang From thiago.macieira at intel.com Fri Dec 23 14:18:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 23 Dec 2016 11:18:07 -0200 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <1514942.HKomPSatJR@tjmaciei-mobl1> Message-ID: <9505450.rLpQF0vOJZ@tjmaciei-mobl1> Em sexta-feira, 23 de dezembro de 2016, às 07:17:01 BRST, Tuukka Turunen escreveu: > > Call it beta 2 (or gamma 1) right after branch and one we've iterated and > > we could have released, we call it release candidate. We release them > > more often, with more iterations, so that we get more feedback. I think > > that's the most important part. > > > > > Beta 2 is still a bit misleading in my opinion. It is coming from release > branch, so we are beyond the Beta phase. Let's think about the name later, > after the holidays. It anyway seems that the basic approach is seen viable. The branch it comes from is irrelevant. If it's after Beta 1 and is not RC quaity, then it's still a Beta and the next number available is 2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Fri Dec 23 14:27:30 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 23 Dec 2016 13:27:30 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <9505450.rLpQF0vOJZ@tjmaciei-mobl1> References: <1514942.HKomPSatJR@tjmaciei-mobl1> , <9505450.rLpQF0vOJZ@tjmaciei-mobl1> Message-ID: Hi, I find that the branch is relevant in this context, as it relates to the amount of patches going in. The amount of patches going in is IMO related to the probably of introducing regressions. The process around the release branch, as opposed to the "minor branch", as proven to be a useful mechanism for reducing the churn and making people ask themselves: Do I really want this change in this release or can it wait? So from what I think is one metric of quality (not the only one of course), the naming of release candidate is more meaningful. Simon From: thiago.macieira at intel.com Sent: December 23, 2016 14:20 To: development at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Em sexta-feira, 23 de dezembro de 2016, às 07:17:01 BRST, Tuukka Turunen escreveu: > > Call it beta 2 (or gamma 1) right after branch and one we've iterated and > > we could have released, we call it release candidate. We release them > > more often, with more iterations, so that we get more feedback. I think > > that's the most important part. > > > > > Beta 2 is still a bit misleading in my opinion. It is coming from release > branch, so we are beyond the Beta phase. Let's think about the name later, > after the holidays. It anyway seems that the basic approach is seen viable. The branch it comes from is irrelevant. If it's after Beta 1 and is not RC quaity, then it's still a Beta and the next number available is 2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Dec 23 16:42:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 23 Dec 2016 13:42:12 -0200 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: References: <9505450.rLpQF0vOJZ@tjmaciei-mobl1> Message-ID: <2265621.Hc078j5Qty@tjmaciei-mobl1> Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann escreveu: > I find that the branch is relevant in this context, as it relates to the > amount of patches going in. The amount of patches going in is IMO related > to the probably of introducing regressions. The process around the release > branch, as opposed to the "minor branch", as proven to be a useful > mechanism for reducing the churn and making people ask themselves: Do I > really want this change in this release or can it wait? > > So from what I think is one metric of quality (not the only one of course), > the naming of release candidate is more meaningful. How about this, then? We release beta2 from the 5.n branch right before the 5.n.0 branch is created (or finally branches off). It accomplishes the same thing that Tuukka wanted: a release containing the code that is in the 5.n.0 branch at the moment it is created, not a few weeks after with some round of work. And I really mean "the code that is in the 5.n.0 branch". Since the two branches at the same at that point, it's only a semantic difference which one we created the beta2 release from. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at qt.io Fri Dec 23 18:01:30 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 23 Dec 2016 17:01:30 +0000 Subject: [Development] Proposal to adjust release candidate process In-Reply-To: <2265621.Hc078j5Qty@tjmaciei-mobl1> References: <9505450.rLpQF0vOJZ@tjmaciei-mobl1> , <2265621.Hc078j5Qty@tjmaciei-mobl1> Message-ID: Ahhh, I'm sorry, I misunderstood your email. Yes, you're right, in that case the branch makes no difference and beta is a better name. Simon ________________________________ From: Development on behalf of Thiago Macieira Sent: Friday, December 23, 2016 4:42:12 PM To: development at qt-project.org Subject: Re: [Development] Proposal to adjust release candidate process Em sexta-feira, 23 de dezembro de 2016, às 13:27:30 BRST, Simon Hausmann escreveu: > I find that the branch is relevant in this context, as it relates to the > amount of patches going in. The amount of patches going in is IMO related > to the probably of introducing regressions. The process around the release > branch, as opposed to the "minor branch", as proven to be a useful > mechanism for reducing the churn and making people ask themselves: Do I > really want this change in this release or can it wait? > > So from what I think is one metric of quality (not the only one of course), > the naming of release candidate is more meaningful. How about this, then? We release beta2 from the 5.n branch right before the 5.n.0 branch is created (or finally branches off). It accomplishes the same thing that Tuukka wanted: a release containing the code that is in the 5.n.0 branch at the moment it is created, not a few weeks after with some round of work. And I really mean "the code that is in the 5.n.0 branch". Since the two branches at the same at that point, it's only a semantic difference which one we created the beta2 release from. -- 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 philippeb8 at gmail.com Sun Dec 25 04:39:19 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sat, 24 Dec 2016 22:39:19 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" Message-ID: Greetings, I am a QML developer and it came to my attention that the animation is sluggish because of the internal garbage collector. I know about the QtQuickCompiler that could speed up the rendering but it still uses a garbage collector. I wrote myself a "container-oriented deterministic memory manager" called "root_ptr" that could definitely speed up animation of QML objects: https://github.com/philippeb8/root_ptr Is that something that could be easily integrated into the QtQuickCompiler? If so would there be any interests to integrate root_ptr? Sincerely, -Phil From annulen at yandex.ru Sun Dec 25 06:25:59 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 25 Dec 2016 08:25:59 +0300 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: Message-ID: <292131482643559@web17g.yandex.ru> > Greetings, > > I am a QML developer and it came to my attention that the animation is > sluggish because of the internal garbage collector. Do you have any proofs that GC is to blame here? > I know about the > QtQuickCompiler that could speed up the rendering but it still uses a > garbage collector. > > I wrote myself a "container-oriented deterministic memory manager" > called "root_ptr" that could definitely speed up animation of QML objects: > https://github.com/philippeb8/root_ptr Any numbers for "definitely speed up"? > > Is that something that could be easily integrated into the > QtQuickCompiler? If so would there be any interests to integrate root_ptr? > > Sincerely, > -Phil > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From philippeb8 at gmail.com Sun Dec 25 06:49:48 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 25 Dec 2016 00:49:48 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <292131482643559@web17g.yandex.ru> References: <292131482643559@web17g.yandex.ru> Message-ID: On 12/25/2016 12:25 AM, Konstantin Tokarev wrote: > > >> Greetings, >> >> I am a QML developer and it came to my attention that the animation is >> sluggish because of the internal garbage collector. > > Do you have any proofs that GC is to blame here? My app works fine below a certain threshold but as soon as I reach a certain level of complexity, the animation of the app randomly starts skipping frames. I know the GC randomly kicks in so it fits the same pattern. >> I know about the >> QtQuickCompiler that could speed up the rendering but it still uses a >> garbage collector. >> >> I wrote myself a "container-oriented deterministic memory manager" >> called "root_ptr" that could definitely speed up animation of QML objects: >> https://github.com/philippeb8/root_ptr > > Any numbers for "definitely speed up"? Well as you can see on the aforementioned link, root_ptr is as fast as the best usage of shared_ptr but detects cycles and uses the same amount of memory per pointer. Furthermore it is "deterministic" so it's not going to randomly slow down the animation of your app. Also it is "container-oriented" meaning once the "root_ptr" of a container is deleted, all of its child ptrs gets instantly deleted, bringing down all potential cycles. So the deletion of a Javascript page will not leave any dangling memory block behind. I have talked previously to the WebKit group but their implementation is too complex to simply "swap" the memory manager. So I was hoping the QtQuickCompiler generates a cleaner memory manager that could be swapped relatively easily. >> Is that something that could be easily integrated into the >> QtQuickCompiler? If so would there be any interests to integrate root_ptr? >> >> Sincerely, >> -Phil >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Sun Dec 25 20:15:48 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 25 Dec 2016 22:15:48 +0300 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <292131482643559@web17g.yandex.ru> Message-ID: <1055161482693348@web3m.yandex.ru> 25.12.2016, 08:50, "Phil Bouchard" : > On 12/25/2016 12:25 AM, Konstantin Tokarev wrote: >>>  Greetings, >>> >>>  I am a QML developer and it came to my attention that the animation is >>>  sluggish because of the internal garbage collector. >> >>  Do you have any proofs that GC is to blame here? > > My app works fine below a certain threshold but as soon as I reach a > certain level of complexity, the animation of the app randomly starts > skipping frames. Could you please provide self-contained example of application that invokes pathological GC behavior? >I know the GC randomly kicks in so it fits the same pattern. Having 2 randomly repeating events in the system does not necessary mean these events are correlated. You should provide profiling results or at least logs that show GC kicking in during animation. > >>>  I know about the >>>  QtQuickCompiler that could speed up the rendering but it still uses a >>>  garbage collector. >>> >>>  I wrote myself a "container-oriented deterministic memory manager" >>>  called "root_ptr" that could definitely speed up animation of QML objects: >>>  https://github.com/philippeb8/root_ptr >> >>  Any numbers for "definitely speed up"? > > Well as you can see on the aforementioned link, root_ptr is as fast as > the best usage of shared_ptr but detects cycles and uses the same amount > of memory per pointer. Decently implemented GC can be faster than shared_ptr, because reference counting churn is avoided BTW, FAQ says that VS2015 is required to build your code, so it cannot be integrated into V4 until VS2013 support is dropped. > > Furthermore it is "deterministic" so it's not going to randomly slow > down the animation of your app. Also it is "container-oriented" meaning > once the "root_ptr" of a container is deleted, all of its child ptrs > gets instantly deleted, bringing down all potential cycles. So the > deletion of a Javascript page will not leave any dangling memory block > behind. > > I have talked previously to the WebKit group but their implementation is > too complex to simply "swap" the memory manager. So I was hoping the > QtQuickCompiler generates a cleaner memory manager that could be swapped > relatively easily. > >>>  Is that something that could be easily integrated into the >>>  QtQuickCompiler? If so would there be any interests to integrate root_ptr? >>> >>>  Sincerely, >>>  -Phil >>> >>>  _______________________________________________ >>>  Development mailing list >>>  Development at qt-project.org >>>  http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From philippeb8 at gmail.com Sun Dec 25 20:34:51 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 25 Dec 2016 14:34:51 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <1055161482693348@web3m.yandex.ru> References: <292131482643559@web17g.yandex.ru> <1055161482693348@web3m.yandex.ru> Message-ID: On 12/25/2016 02:15 PM, Konstantin Tokarev wrote: > > > 25.12.2016, 08:50, "Phil Bouchard" : >> On 12/25/2016 12:25 AM, Konstantin Tokarev wrote: >>>> Greetings, >>>> >>>> I am a QML developer and it came to my attention that the animation is >>>> sluggish because of the internal garbage collector. >>> >>> Do you have any proofs that GC is to blame here? >> >> My app works fine below a certain threshold but as soon as I reach a >> certain level of complexity, the animation of the app randomly starts >> skipping frames. > > Could you please provide self-contained example of application that invokes pathological GC behavior? I cannot share my proprietary code but I'll work on some simple example this week. Basically it consists of having a "Flipable" object inside a complex Delegate object of a ListView. The Flipable animation skips frames and the animation is not smooth. >> I know the GC randomly kicks in so it fits the same pattern. > > Having 2 randomly repeating events in the system does not necessary mean these events are correlated. You should provide profiling results or at least logs that show GC kicking in during animation. I'll try to find out how to turn on GC logging. >>>> I know about the >>>> QtQuickCompiler that could speed up the rendering but it still uses a >>>> garbage collector. >>>> >>>> I wrote myself a "container-oriented deterministic memory manager" >>>> called "root_ptr" that could definitely speed up animation of QML objects: >>>> https://github.com/philippeb8/root_ptr >>> >>> Any numbers for "definitely speed up"? >> >> Well as you can see on the aforementioned link, root_ptr is as fast as >> the best usage of shared_ptr but detects cycles and uses the same amount >> of memory per pointer. > > Decently implemented GC can be faster than shared_ptr, because reference counting churn is avoided A GC might be faster at some point but you're just postponing the workload to some other point in time. So benchmarks need to be objective. Also a GC needs not use a dedicated thread (which most of them use) just to be fair in the benchmark. > BTW, FAQ says that VS2015 is required to build your code, so it cannot be integrated into V4 until VS2013 support is dropped. I am sorry for this but this FAQ was copied from a template and this statement is false. It was tested using GCC and portable code is one of the mantra of the Boost library. From annulen at yandex.ru Sun Dec 25 21:01:25 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sun, 25 Dec 2016 23:01:25 +0300 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <292131482643559@web17g.yandex.ru> <1055161482693348@web3m.yandex.ru> Message-ID: <942751482696085@web5j.yandex.ru> 25.12.2016, 22:35, "Phil Bouchard" : > On 12/25/2016 02:15 PM, Konstantin Tokarev wrote: >>  25.12.2016, 08:50, "Phil Bouchard" : >>>  On 12/25/2016 12:25 AM, Konstantin Tokarev wrote: >>>>>   Greetings, >>>>> >>>>>   I am a QML developer and it came to my attention that the animation is >>>>>   sluggish because of the internal garbage collector. >>>> >>>>   Do you have any proofs that GC is to blame here? >>> >>>  My app works fine below a certain threshold but as soon as I reach a >>>  certain level of complexity, the animation of the app randomly starts >>>  skipping frames. >> >>  Could you please provide self-contained example of application that invokes pathological GC behavior? > > I cannot share my proprietary code but I'll work on some simple example > this week. Basically it consists of having a "Flipable" object inside a > complex Delegate object of a ListView. The Flipable animation skips > frames and the animation is not smooth. > >>>  I know the GC randomly kicks in so it fits the same pattern. >> >>  Having 2 randomly repeating events in the system does not necessary mean these events are correlated. You should provide profiling results or at least logs that show GC kicking in during animation. > > I'll try to find out how to turn on GC logging. > >>>>>   I know about the >>>>>   QtQuickCompiler that could speed up the rendering but it still uses a >>>>>   garbage collector. >>>>> >>>>>   I wrote myself a "container-oriented deterministic memory manager" >>>>>   called "root_ptr" that could definitely speed up animation of QML objects: >>>>>   https://github.com/philippeb8/root_ptr >>>> >>>>   Any numbers for "definitely speed up"? >>> >>>  Well as you can see on the aforementioned link, root_ptr is as fast as >>>  the best usage of shared_ptr but detects cycles and uses the same amount >>>  of memory per pointer. >> >>  Decently implemented GC can be faster than shared_ptr, because reference counting churn is avoided > > A GC might be faster at some point but you're just postponing the > workload to some other point in time. So benchmarks need to be > objective. Also a GC needs not use a dedicated thread (which most of > them use) just to be fair in the benchmark. > >>  BTW, FAQ says that VS2015 is required to build your code, so it cannot be integrated into V4 until VS2013 support is dropped. > > I am sorry for this but this FAQ was copied from a template and this > statement is false. It was tested using GCC and portable code is one of > the mantra of the Boost library. But does it work with VS2013? > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From philippeb8 at gmail.com Sun Dec 25 21:04:38 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 25 Dec 2016 15:04:38 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <942751482696085@web5j.yandex.ru> References: <292131482643559@web17g.yandex.ru> <1055161482693348@web3m.yandex.ru> <942751482696085@web5j.yandex.ru> Message-ID: On 12/25/2016 03:01 PM, Konstantin Tokarev wrote: > >>> BTW, FAQ says that VS2015 is required to build your code, so it cannot be integrated into V4 until VS2013 support is dropped. >> >> I am sorry for this but this FAQ was copied from a template and this >> statement is false. It was tested using GCC and portable code is one of >> the mantra of the Boost library. > > But does it work with VS2013? Yes of course, it was tested with Visual Studio Express as well. From thiago.macieira at intel.com Sun Dec 25 22:05:52 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 25 Dec 2016 19:05:52 -0200 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <1055161482693348@web3m.yandex.ru> References: <1055161482693348@web3m.yandex.ru> Message-ID: <2300940.GTYqkcybDp@tjmaciei-mobl1> Em domingo, 25 de dezembro de 2016, às 22:15:48 BRST, Konstantin Tokarev escreveu: > >I know the GC randomly kicks in so it fits the same pattern. > > Having 2 randomly repeating events in the system does not necessary mean > these events are correlated. You should provide profiling results or at > least logs that show GC kicking in during animation. Right, it could just as easily be the size of the L1 cache in your computer. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Sun Dec 25 22:13:37 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 25 Dec 2016 16:13:37 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <2300940.GTYqkcybDp@tjmaciei-mobl1> References: <1055161482693348@web3m.yandex.ru> <2300940.GTYqkcybDp@tjmaciei-mobl1> Message-ID: On 12/25/2016 04:05 PM, Thiago Macieira wrote: > Em domingo, 25 de dezembro de 2016, às 22:15:48 BRST, Konstantin Tokarev > escreveu: >>> I know the GC randomly kicks in so it fits the same pattern. >> >> Having 2 randomly repeating events in the system does not necessary mean >> these events are correlated. You should provide profiling results or at >> least logs that show GC kicking in during animation. > > Right, it could just as easily be the size of the L1 cache in your computer. I hope not because I will port the app on the iPhone and Android which has much less powerful cores. My current system has: *-firmware description: BIOS vendor: American Megatrends Inc. physical id: 0 version: G750JW.210 date: 12/11/2013 size: 64KiB capacity: 6080KiB capabilities: pci upgrade shadowing cdboot bootselect socketedrom edd int13floppy1200 int13floppy720 int13floppy2880 int5printscreen int9keyboard int14serial int17printer acpi usb smartbattery biosbootspecification uefi *-cache:0 description: L2 cache physical id: 9 slot: CPU Internal L2 size: 1MiB capacity: 1MiB capabilities: internal write-back unified *-cache:1 description: L1 cache physical id: a slot: CPU Internal L1 size: 256KiB capacity: 256KiB capabilities: internal write-back *-cache:2 description: L3 cache physical id: b slot: CPU Internal L3 size: 6MiB capacity: 6MiB capabilities: internal write-back unified *-memory description: System Memory physical id: c slot: System board or motherboard size: 16GiB *-bank:0 description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns) product: HMT451S6AFR8A-PB vendor: Hynix/Hyundai physical id: 0 serial: 065058046038 slot: ChannelA-DIMM0 size: 4GiB width: 8 bits clock: 1600MHz (0.6ns) *-bank:1 description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns) product: HMT451S6AFR8A-PB vendor: Hynix/Hyundai physical id: 1 serial: 065026046175 slot: ChannelA-DIMM1 size: 4GiB width: 8 bits clock: 1600MHz (0.6ns) *-bank:2 description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns) product: HMT451S6AFR8A-PB vendor: Hynix/Hyundai physical id: 2 serial: 065074046080 slot: ChannelB-DIMM0 size: 4GiB width: 8 bits clock: 1600MHz (0.6ns) *-bank:3 description: DIMM DDR3 Synchronous 1600 MHz (0.6 ns) product: HMT451S6AFR8A-PB vendor: Hynix/Hyundai physical id: 3 serial: 065058046071 slot: ChannelB-DIMM1 size: 4GiB width: 8 bits clock: 1600MHz (0.6ns) From philippeb8 at gmail.com Mon Dec 26 05:01:49 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Sun, 25 Dec 2016 23:01:49 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <2300940.GTYqkcybDp@tjmaciei-mobl1> References: <1055161482693348@web3m.yandex.ru> <2300940.GTYqkcybDp@tjmaciei-mobl1> Message-ID: On 12/25/2016 04:05 PM, Thiago Macieira wrote: > Em domingo, 25 de dezembro de 2016, às 22:15:48 BRST, Konstantin Tokarev > escreveu: >>> I know the GC randomly kicks in so it fits the same pattern. >> >> Having 2 randomly repeating events in the system does not necessary mean >> these events are correlated. You should provide profiling results or at >> least logs that show GC kicking in during animation. > > Right, it could just as easily be the size of the L1 cache in your computer. Anyways I know for sure that heavy loads of Javascript in WebKit is pretty sluggish for embedded devices, even with multiple processors, so it is obvious the GC is responsible for this effect. And WebKit apparently uses the latest and greatest source code available... From annulen at yandex.ru Mon Dec 26 07:40:12 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 26 Dec 2016 09:40:12 +0300 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <1055161482693348@web3m.yandex.ru> <2300940.GTYqkcybDp@tjmaciei-mobl1> Message-ID: <1414011482734412@web33j.yandex.ru> 26.12.2016, 07:02, "Phil Bouchard" : > On 12/25/2016 04:05 PM, Thiago Macieira wrote: >>  Em domingo, 25 de dezembro de 2016, às 22:15:48 BRST, Konstantin Tokarev >>  escreveu: >>>>  I know the GC randomly kicks in so it fits the same pattern. >>> >>>  Having 2 randomly repeating events in the system does not necessary mean >>>  these events are correlated. You should provide profiling results or at >>>  least logs that show GC kicking in during animation. >> >>  Right, it could just as easily be the size of the L1 cache in your computer. > > Anyways I know for sure that heavy loads of Javascript in WebKit is > pretty sluggish for embedded devices, even with multiple processors, so > it is obvious the GC is responsible for this effect. And WebKit > apparently uses the latest and greatest source code available... You haven't provided any proof for this claim as well, have you? -- Regards, Konstantin From philippeb8 at gmail.com Mon Dec 26 10:09:00 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 26 Dec 2016 04:09:00 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <1414011482734412@web33j.yandex.ru> References: <1055161482693348@web3m.yandex.ru> <2300940.GTYqkcybDp@tjmaciei-mobl1> <1414011482734412@web33j.yandex.ru> Message-ID: On 12/26/2016 01:40 AM, Konstantin Tokarev wrote: > > > 26.12.2016, 07:02, "Phil Bouchard" : >> >> Anyways I know for sure that heavy loads of Javascript in WebKit is >> pretty sluggish for embedded devices, even with multiple processors, so >> it is obvious the GC is responsible for this effect. And WebKit >> apparently uses the latest and greatest source code available... > > You haven't provided any proof for this claim as well, have you? I can't say which version of WebKit is faster because this is confidential but Blink uses a mark and sweep type of GC, which is pretty much the cutting edge technology: https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/Source/platform/heap/BlinkGCAPIReference.md My point is Qt could do better because the QtQuickCompiler is already a good start and I'm sure the containers of the internal Javascript engine could make use of the root_ptr memory manager. From thiago.macieira at intel.com Mon Dec 26 12:40:48 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Dec 2016 09:40:48 -0200 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <2300940.GTYqkcybDp@tjmaciei-mobl1> Message-ID: <30262435.1QxfBYGVNB@tjmaciei-mobl1> Em domingo, 25 de dezembro de 2016, às 23:01:49 BRST, Phil Bouchard escreveu: > Anyways I know for sure that heavy loads of Javascript in WebKit is > pretty sluggish for embedded devices, even with multiple processors, so > it is obvious the GC is responsible for this effect. And WebKit > apparently uses the latest and greatest source code available... No, it's sluggish on those processors because they are underpowered for the task of running an interpreted language. "Underpowered" includes all of: CPU clock, CPU pipelining, branch prediction, L1 caches, latencies, etc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Dec 26 12:43:33 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Dec 2016 09:43:33 -0200 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <1414011482734412@web33j.yandex.ru> Message-ID: <2678629.LgvALkErnG@tjmaciei-mobl1> Em segunda-feira, 26 de dezembro de 2016, às 04:09:00 BRST, Phil Bouchard escreveu: > I can't say which version of WebKit is faster because this is > confidential but Blink uses a mark and sweep type of GC, which is pretty > much the cutting edge technology: > https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/S > ource/platform/heap/BlinkGCAPIReference.md So you cannot tell us if Blink is faster on the same CPU as you tested WebKit? So how can we know that this cutting-edge GC will make things better? Note: I am not saying that we shouldn't adopt better technologies that improve performance, even if just a little. I am simply debating your claim that the GC is the whole reason behind the slowness. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Mon Dec 26 16:52:41 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 26 Dec 2016 10:52:41 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <2678629.LgvALkErnG@tjmaciei-mobl1> References: <1414011482734412@web33j.yandex.ru> <2678629.LgvALkErnG@tjmaciei-mobl1> Message-ID: On 12/26/2016 06:43 AM, Thiago Macieira wrote: > Em segunda-feira, 26 de dezembro de 2016, às 04:09:00 BRST, Phil Bouchard > escreveu: >> I can't say which version of WebKit is faster because this is >> confidential but Blink uses a mark and sweep type of GC, which is pretty >> much the cutting edge technology: >> https://chromium.googlesource.com/chromium/src/+/master/third_party/WebKit/S >> ource/platform/heap/BlinkGCAPIReference.md > > So you cannot tell us if Blink is faster on the same CPU as you tested WebKit? Well there's WebKit, WebKit2, Blink, WebKit for Wayland but I can't share the results of the benchmarks. The renderer differs so some are faster but the bottom line is they all use a mark and sweep GC running in a different thread. > So how can we know that this cutting-edge GC will make things better? I am not saying Blink GC will make things better. > Note: I am not saying that we shouldn't adopt better technologies that improve > performance, even if just a little. I am simply debating your claim that the > GC is the whole reason behind the slowness. Personally I just want the Javascript / QML to be blinking fast and a mixture of one of the aforementioned renderer, QtQuickCompiler on-demand, a decent CPU architecture and root_ptr could definitely get the job done once and for all. From philippeb8 at gmail.com Mon Dec 26 17:13:59 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 26 Dec 2016 11:13:59 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <1414011482734412@web33j.yandex.ru> <2678629.LgvALkErnG@tjmaciei-mobl1> Message-ID: On 12/26/2016 10:52 AM, Phil Bouchard wrote: > On 12/26/2016 06:43 AM, Thiago Macieira wrote: >> >> So you cannot tell us if Blink is faster on the same CPU as you tested >> WebKit? > > Well there's WebKit, WebKit2, Blink, WebKit for Wayland but I can't > share the results of the benchmarks. The renderer differs so some are > faster but the bottom line is they all use a mark and sweep GC running > in a different thread. The point of this thread is not to promote renderers but if you are interested to know more then one of you will have to contact my superior by sending me a private message. From thiago.macieira at intel.com Mon Dec 26 22:45:15 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Dec 2016 19:45:15 -0200 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: Message-ID: <3197846.rWV0bLfoj0@tjmaciei-mobl1> Em segunda-feira, 26 de dezembro de 2016, às 11:13:59 BRST, Phil Bouchard escreveu: > On 12/26/2016 10:52 AM, Phil Bouchard wrote: > > On 12/26/2016 06:43 AM, Thiago Macieira wrote: > >> So you cannot tell us if Blink is faster on the same CPU as you tested > >> WebKit? > > > > Well there's WebKit, WebKit2, Blink, WebKit for Wayland but I can't > > share the results of the benchmarks. The renderer differs so some are > > faster but the bottom line is they all use a mark and sweep GC running > > in a different thread. > > The point of this thread is not to promote renderers but if you are > interested to know more then one of you will have to contact my superior > by sending me a private message. I don't think that's necessary and it's also out of scope. We were talking about QML (non-graphical) performance, so renderers do not come into account. We want a faster memory manager. Do you have any papers that show the advantage of the different possibilities? On modern CPU architectures. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Tue Dec 27 00:04:45 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 26 Dec 2016 18:04:45 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <3197846.rWV0bLfoj0@tjmaciei-mobl1> References: <3197846.rWV0bLfoj0@tjmaciei-mobl1> Message-ID: On 12/26/2016 04:45 PM, Thiago Macieira wrote: > Em segunda-feira, 26 de dezembro de 2016, às 11:13:59 BRST, Phil Bouchard > escreveu: >> >> The point of this thread is not to promote renderers but if you are >> interested to know more then one of you will have to contact my superior >> by sending me a private message. > > I don't think that's necessary and it's also out of scope. We were talking > about QML (non-graphical) performance, so renderers do not come into account. > We want a faster memory manager. > > Do you have any papers that show the advantage of the different possibilities? > On modern CPU architectures. No I didn't write any paper on the subject yet (I already have n side projects to finish). All I have for now is this comparison with shared_ptr: https://github.com/philippeb8/root_ptr But the complexity is constant (O(1)) so the time taken shown will always be the same and it will not clog your memory bus. From philippeb8 at gmail.com Tue Dec 27 01:07:49 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 26 Dec 2016 19:07:49 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <3197846.rWV0bLfoj0@tjmaciei-mobl1> References: <3197846.rWV0bLfoj0@tjmaciei-mobl1> Message-ID: On 12/26/2016 04:45 PM, Thiago Macieira wrote: > > Do you have any papers that show the advantage of the different possibilities? > On modern CPU architectures. There is an objective comparison here: http://stackoverflow.com/questions/2598089/alternative-for-garbage-collector But the most popular answer is not true regarding reference counters because shared_ptr uses atomic reference increment / decrement for most processors. Here's an interesting benchmark comparing shared_ptr with raw pointers: http://blog.davidecoppola.com/2016/10/performance-of-raw-pointers-vs-smart-pointers-in-cpp/ Keep in mind that "shared_ptr's allocate_shared" is faster than "make_shared" and root_ptr is as fast as "shared_ptr's allocate_shared". Also for the C++ programmers out there: root_ptr abstracts more elegantly inheritances than shared_ptr, intrusive_ptr, etc. From thiago.macieira at intel.com Tue Dec 27 01:37:24 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 26 Dec 2016 22:37:24 -0200 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <3197846.rWV0bLfoj0@tjmaciei-mobl1> Message-ID: <1981885.SNB0aErBVp@tjmaciei-mobl1> Em segunda-feira, 26 de dezembro de 2016, às 18:04:45 BRST, Phil Bouchard escreveu: > No I didn't write any paper on the subject yet (I already have n side > projects to finish). All I have for now is this comparison with shared_ptr: > https://github.com/philippeb8/root_ptr So an option we're not using is faster than an option we're also not using. How does this help us? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Tue Dec 27 03:50:45 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 26 Dec 2016 21:50:45 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <1981885.SNB0aErBVp@tjmaciei-mobl1> References: <3197846.rWV0bLfoj0@tjmaciei-mobl1> <1981885.SNB0aErBVp@tjmaciei-mobl1> Message-ID: On 12/26/2016 07:37 PM, Thiago Macieira wrote: > Em segunda-feira, 26 de dezembro de 2016, às 18:04:45 BRST, Phil Bouchard > escreveu: >> No I didn't write any paper on the subject yet (I already have n side >> projects to finish). All I have for now is this comparison with shared_ptr: >> https://github.com/philippeb8/root_ptr > > So an option we're not using is faster than an option we're also not using. > How does this help us? Well I do not know the internals of the GC used by QML but if you want smooth animations in QML / Javascript and to speed things up then I think it's worth trying it out. It's very easy to understand: - You have a root_ptr per container - All the child ptrs are called "note_ptr" and are referencing the root_ptr - When the root_ptr is destroyed then all associated node_ptrs vanish. Also: - A container can link to another one and have multiple root_ptrs. When that happens then the last root_ptr to get destroyed will define when the whole set of containers will get destroyed as well. Thus: - If you use a browser and leave from a Javascript page then all the memory is guaranteed to be released. - It is deterministic therefore the behavior is a 100% predictable and measurable. From annulen at yandex.ru Tue Dec 27 08:04:11 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 27 Dec 2016 10:04:11 +0300 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <3197846.rWV0bLfoj0@tjmaciei-mobl1> <1981885.SNB0aErBVp@tjmaciei-mobl1> Message-ID: <2337481482822251@web1g.yandex.ru> 27.12.2016, 05:51, "Phil Bouchard" : > On 12/26/2016 07:37 PM, Thiago Macieira wrote: >>  Em segunda-feira, 26 de dezembro de 2016, às 18:04:45 BRST, Phil Bouchard >>  escreveu: >>>  No I didn't write any paper on the subject yet (I already have n side >>>  projects to finish). All I have for now is this comparison with shared_ptr: >>>  https://github.com/philippeb8/root_ptr >> >>  So an option we're not using is faster than an option we're also not using. >>  How does this help us? > > Well I do not know the internals of the GC used by QML but if you want > smooth animations in QML / Javascript and to speed things up then I > think it's worth trying it out. IMO obvious option is to postpone GC while animation is running. I would consider such behavior a bug. > > It's very easy to understand: > - You have a root_ptr per container > - All the child ptrs are called "note_ptr" and are referencing the root_ptr > - When the root_ptr is destroyed then all associated node_ptrs vanish. > > Also: > - A container can link to another one and have multiple root_ptrs. When > that happens then the last root_ptr to get destroyed will define when > the whole set of containers will get destroyed as well. > > Thus: > - If you use a browser and leave from a Javascript page then all the > memory is guaranteed to be released. > - It is deterministic therefore the behavior is a 100% predictable and > measurable. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From philippeb8 at gmail.com Tue Dec 27 10:36:10 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 27 Dec 2016 04:36:10 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <2337481482822251@web1g.yandex.ru> References: <3197846.rWV0bLfoj0@tjmaciei-mobl1> <1981885.SNB0aErBVp@tjmaciei-mobl1> <2337481482822251@web1g.yandex.ru> Message-ID: On 12/27/2016 02:04 AM, Konstantin Tokarev wrote: > > > 27.12.2016, 05:51, "Phil Bouchard" : >> On 12/26/2016 07:37 PM, Thiago Macieira wrote: >>> Em segunda-feira, 26 de dezembro de 2016, às 18:04:45 BRST, Phil Bouchard >>> escreveu: >>>> No I didn't write any paper on the subject yet (I already have n side >>>> projects to finish). All I have for now is this comparison with shared_ptr: >>>> https://github.com/philippeb8/root_ptr >>> >>> So an option we're not using is faster than an option we're also not using. >>> How does this help us? >> >> Well I do not know the internals of the GC used by QML but if you want >> smooth animations in QML / Javascript and to speed things up then I >> think it's worth trying it out. > > IMO obvious option is to postpone GC while animation is running. > I would consider such behavior a bug. That could work for most apps and certainly mine but some Javascript webpages / QML games have continuous animations. From philippeb8 at gmail.com Wed Dec 28 01:22:27 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 27 Dec 2016 19:22:27 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <3197846.rWV0bLfoj0@tjmaciei-mobl1> <1981885.SNB0aErBVp@tjmaciei-mobl1> <2337481482822251@web1g.yandex.ru> Message-ID: On 12/27/2016 04:36 AM, Phil Bouchard wrote: > On 12/27/2016 02:04 AM, Konstantin Tokarev wrote: >> >> IMO obvious option is to postpone GC while animation is running. >> I would consider such behavior a bug. > > That could work for most apps and certainly mine but some Javascript > webpages / QML games have continuous animations. Qt developed a QtQuickCompiler which is great but the end result is still not a 100% perfect and software engineering needs to be nothing less than that otherwise you won't sell anything. From thiago.macieira at intel.com Wed Dec 28 01:50:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 27 Dec 2016 22:50:11 -0200 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: Message-ID: <4202991.ueo5ozzvxf@tjmaciei-mobl1> Em terça-feira, 27 de dezembro de 2016, às 19:22:27 BRST, Phil Bouchard escreveu: > On 12/27/2016 04:36 AM, Phil Bouchard wrote: > > On 12/27/2016 02:04 AM, Konstantin Tokarev wrote: > >> IMO obvious option is to postpone GC while animation is running. > >> I would consider such behavior a bug. > > > > That could work for most apps and certainly mine but some Javascript > > webpages / QML games have continuous animations. > > Qt developed a QtQuickCompiler which is great but the end result is > still not a 100% perfect and software engineering needs to be nothing > less than that otherwise you won't sell anything. Considering it has sold something, your assertion is proven false. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Wed Dec 28 02:30:14 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 27 Dec 2016 20:30:14 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <4202991.ueo5ozzvxf@tjmaciei-mobl1> References: <4202991.ueo5ozzvxf@tjmaciei-mobl1> Message-ID: On 12/27/2016 07:50 PM, Thiago Macieira wrote: > Em terça-feira, 27 de dezembro de 2016, às 19:22:27 BRST, Phil Bouchard > escreveu: >> On 12/27/2016 04:36 AM, Phil Bouchard wrote: >>> On 12/27/2016 02:04 AM, Konstantin Tokarev wrote: >>>> IMO obvious option is to postpone GC while animation is running. >>>> I would consider such behavior a bug. >>> >>> That could work for most apps and certainly mine but some Javascript >>> webpages / QML games have continuous animations. >> >> Qt developed a QtQuickCompiler which is great but the end result is >> still not a 100% perfect and software engineering needs to be nothing >> less than that otherwise you won't sell anything. > > Considering it has sold something, your assertion is proven false. Not for the common mortal: - True SmartTV just barely broke the ice in Europe but wait until it will be ported to giant screens in Las Vegas and your website lags; it will look unprofessional. - Popular cell phones apps also do not use extensive animations. I believe they intentionally avoid the problem by not using it. From philippeb8 at gmail.com Wed Dec 28 03:58:57 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 27 Dec 2016 21:58:57 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <4202991.ueo5ozzvxf@tjmaciei-mobl1> Message-ID: On 12/27/2016 08:30 PM, Phil Bouchard wrote: > > Not for the common mortal: > > - True SmartTV just barely broke the ice in Europe but wait until it > will be ported to giant screens in Las Vegas and your website lags; it > will look unprofessional. > > - Popular cell phones apps also do not use extensive animations. I > believe they intentionally avoid the problem by not using it. The only reason I'm so slow in promoting root_ptr is because I have multiple side projects including one in astrophysics which will be tested by NASA next year. It's another "against-the-mainstream" idea which resembles to root_ptr vs GCs. But my point is the mainstream sometimes can be completely wrong. From nassian at bitshift-dynamics.com Wed Dec 28 10:53:32 2016 From: nassian at bitshift-dynamics.com (Alexander Nassian) Date: Wed, 28 Dec 2016 09:53:32 +0000 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <4202991.ueo5ozzvxf@tjmaciei-mobl1> References: <4202991.ueo5ozzvxf@tjmaciei-mobl1> Message-ID: If Qt Quick Compiler doesn't sell anything, why is it then only GPL and commercial? It is obvious that it is just for pushing people to the commercial model. Thiago Macieira schrieb am Mi. 28. Dez. 2016 um 01:50: Em terça-feira, 27 de dezembro de 2016, às 19:22:27 BRST, Phil Bouchard escreveu: > On 12/27/2016 04:36 AM, Phil Bouchard wrote: > > On 12/27/2016 02:04 AM, Konstantin Tokarev wrote: > >> IMO obvious option is to postpone GC while animation is running. > >> I would consider such behavior a bug. > > > > That could work for most apps and certainly mine but some Javascript > > webpages / QML games have continuous animations. > > Qt developed a QtQuickCompiler which is great but the end result is > still not a 100% perfect and software engineering needs to be nothing > less than that otherwise you won't sell anything. Considering it has sold something, your assertion is proven false. -- 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 -- — bitshift dynamics GmbH Neudorfer Str. 1, 79541 Lörrach Registergericht: Amtsgericht Freiburg i. Breisgau, HRB 713747 Geschäftsführer: Alexander Nassian, Markus Pfaffinger http://www.bitshift-dynamics.de Zentrale: +49 762158673 - 0 Fax: +49 7621 58673 - 90 Allgemeine Anfragen: info at bitshift-dynamics.com Technischer Support: support at bitshift-dynamics.com Buchhaltung: invoice at bitshift-dynamics.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Wed Dec 28 13:37:00 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 28 Dec 2016 07:37:00 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <4202991.ueo5ozzvxf@tjmaciei-mobl1> Message-ID: On 12/28/2016 04:53 AM, Alexander Nassian wrote: > If Qt Quick Compiler doesn't sell anything, why is it then only GPL and > commercial? It is obvious that it is just for pushing people to the > commercial model. That's not what I wanted to mean. The end product using QML / Javascript in any form cannot use extensive usage of animations if you're planning to present your project to an investor for example. Everybody knows there is no solution to that "lagging" involved so what do you tell them then? From thiago.macieira at intel.com Wed Dec 28 13:52:20 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 28 Dec 2016 10:52:20 -0200 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: Message-ID: <2457362.z1HspnihMx@tjmaciei-mobl1> Em quarta-feira, 28 de dezembro de 2016, às 07:37:00 BRST, Phil Bouchard escreveu: > On 12/28/2016 04:53 AM, Alexander Nassian wrote: > > If Qt Quick Compiler doesn't sell anything, why is it then only GPL and > > commercial? It is obvious that it is just for pushing people to the > > commercial model. > > That's not what I wanted to mean. The end product using QML / > Javascript in any form cannot use extensive usage of animations if > you're planning to present your project to an investor for example. And yet reality proves you false again. There have been a lot of examples using QML that not only were presented to investors and C-level executives, but have also made it into production. > Everybody knows there is no solution to that "lagging" involved so what > do you tell them then? Obviously they've found solutions. Again, I'm not saying we shouldn't improve. We should make QML much better than any competition, especially HTML. But your arguments aren't flying and you can't point to a paper that objectively proves your claims. Until then, we'll take your suggestion into consideration, but it's going to be low priority. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From berkayelbir at gmail.com Wed Dec 28 14:18:45 2016 From: berkayelbir at gmail.com (Berkay Elbir) Date: Wed, 28 Dec 2016 16:18:45 +0300 Subject: [Development] QProgressDialog when setValue(0) is called Message-ID: Hello All, I have a class that is inherited from QProgressDialog. It sometimes crashes and its inside QProgressDialog class code. I detected that when the setValue(0); is called in its constructor, crash happens. When I commented out this function, It does not crash. Even if setValue(0) is called after constructing of object crash still occurs. This crash occurs when signals are emitted faster. Code piece shows how the function is called: ProgressDialog progress(nullptr); progress.setLabelText("Loading Result Files"); QFutureWatcher watcher; QFuture future = QtConcurrent::run(myClassPtr,&myClass::myFunc); QEventLoop loop; QObject::connect(&watcher, SIGNAL(started()), &progress, SLOT(show())); QObject::connect(&watcher, SIGNAL(finished()), &progress, SLOT(hide())); QObject::connect(&watcher, SIGNAL(finished()), &loop, SLOT(quit())); QObject::connect(transientAnimation, SIGNAL(progress(int)), &progress, SLOT(setValue(int))); watcher.setFuture(future); loop.exec(); progress signal is emitted inside myFunc() in another thread. In this function, multiple files are read in a folder and progress signal is emitted. Why does this crash occur? Thanks in advance. Berkay From philippeb8 at gmail.com Wed Dec 28 14:22:55 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 28 Dec 2016 08:22:55 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: <2457362.z1HspnihMx@tjmaciei-mobl1> References: <2457362.z1HspnihMx@tjmaciei-mobl1> Message-ID: On 12/28/2016 07:52 AM, Thiago Macieira wrote: > > Again, I'm not saying we shouldn't improve. We should make QML much better > than any competition, especially HTML. But your arguments aren't flying and you > can't point to a paper that objectively proves your claims. Until then, we'll > take your suggestion into consideration, but it's going to be low priority. Ok thank you very much. I'm just trying to help because I think the QtQuickCompiler is a nice piece of product. From Simon.Hausmann at qt.io Wed Dec 28 14:36:55 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 28 Dec 2016 13:36:55 +0000 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <2457362.z1HspnihMx@tjmaciei-mobl1>, Message-ID: Hi, building on the suggestion: do you have any thoughts about how your allocator could be used instead of a garbage collector in an ecmascript implementation? Simon From: philippeb8 at gmail.com Sent: December 28, 2016 14:23 To: development at qt-project.org Subject: Re: [Development] Proposal for "container-oriented deterministic memory manager" On 12/28/2016 07:52 AM, Thiago Macieira wrote: > > Again, I'm not saying we shouldn't improve. We should make QML much better > than any competition, especially HTML. But your arguments aren't flying and you > can't point to a paper that objectively proves your claims. Until then, we'll > take your suggestion into consideration, but it's going to be low priority. Ok thank you very much. I'm just trying to help because I think the QtQuickCompiler is a nice piece of product. _______________________________________________ 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 philippeb8 at gmail.com Wed Dec 28 14:44:24 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 28 Dec 2016 08:44:24 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <2457362.z1HspnihMx@tjmaciei-mobl1> Message-ID: On 12/28/2016 08:36 AM, Simon Hausmann wrote: > Hi, > > building on the suggestion: do you have any thoughts about how your > allocator could be used instead of a garbage collector in an ecmascript > implementation? I'll have to look into the details of the ECMAScript but root_ptr can handle neural networks so I'm not sure why it should fail with ECMAScripts. I won't be able to reply during the day today but I can study specific cases this week. From thiago.macieira at intel.com Wed Dec 28 15:40:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 28 Dec 2016 12:40:08 -0200 Subject: [Development] QProgressDialog when setValue(0) is called In-Reply-To: References: Message-ID: <20888603.BkSBIVYhxy@tjmaciei-mobl1> Em quarta-feira, 28 de dezembro de 2016, às 16:18:45 BRST, Berkay Elbir escreveu: > Hello All, > > I have a class that is inherited from QProgressDialog. It sometimes > crashes and its inside QProgressDialog class code. > > I detected that when the setValue(0); is called in its constructor, > crash happens. When I commented out this function, It does not crash. > Even if setValue(0) is called after constructing of object crash still > occurs. > > This crash occurs when signals are emitted faster. Code piece shows > how the function is called: > > ProgressDialog progress(nullptr); > progress.setLabelText("Loading Result Files"); > QFutureWatcher watcher; > QFuture future = QtConcurrent::run(myClassPtr,&myClass::myFunc); > > QEventLoop loop; > QObject::connect(&watcher, SIGNAL(started()), &progress, SLOT(show())); > QObject::connect(&watcher, SIGNAL(finished()), &progress, SLOT(hide())); > QObject::connect(&watcher, SIGNAL(finished()), &loop, SLOT(quit())); > QObject::connect(transientAnimation, SIGNAL(progress(int)), &progress, > SLOT(setValue(int))); > > watcher.setFuture(future); > > loop.exec(); > > progress signal is emitted inside myFunc() in another thread. In this > function, multiple files are read in a folder and progress signal is > emitted. > > Why does this crash occur? Please attach or paste the backtrace, with line numbers from a debug build of Qt. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From berkayelbir at gmail.com Thu Dec 29 08:32:29 2016 From: berkayelbir at gmail.com (Berkay Elbir) Date: Thu, 29 Dec 2016 10:32:29 +0300 Subject: [Development] Fwd: Compiling QtWebEngine In-Reply-To: References: Message-ID: ---------- Forwarded message ---------- From: Berkay Elbir Date: Tue, Dec 13, 2016 at 2:02 PM Subject: Compiling QtWebEngine To: "interest at qt-project.org Interest" Hi everyone, I tried to compile Qt 5.7.0 source code with web engine module on Windows 7 with Visual Studio 2013 Update 5. If I compile the source code without web engine, everything works fine. However, I am in trouble with compiling web engine module and getting following linker error for all qtwebengine objects. '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in qtwebenginecoreglobal.obj Because of some special reason, we have to use qt debug dll's like release. For this, we made following changes : Go to Qt directory and open msvc-desktop.conf file (D:\Qt\Qt5.7.0\qtbase\mkspecs\common\msvc-desktop.conf) Change -MDd params to -MD for debug flags QMAKE_CFLAGS_DEBUG = -Zi -MD And we run the following commands : configure -opensource -confirm-license -mp -no-compile-examples -nomake examples -nomake tests -make tools -opengl desktop -no-angle -no-icu -skip qtmultimedia -skip location -skip sensors -debug-and-release -no-warnings-are-errors -platform win32-msvc2013 -prefix D:\Qt\Qt5.7.0_x64 -openssl -I D:\3rdParty\OpenSSL\OpenSSL-Win64\include -L D:\3rdParty\OpenSSL\OpenSSL-Win64 D:\3rdParty\jom_1_1_0\jom.exe module-qtwebengine Thanks for your help. Berkay From Simon.Hausmann at qt.io Thu Dec 29 10:14:09 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 29 Dec 2016 09:14:09 +0000 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <2457362.z1HspnihMx@tjmaciei-mobl1> , Message-ID: Hi, I don't doubt that root_ptr can be used at all. What I'm curious about is what your thoughts are on how it could perform, how you would map its strengths to the allocation patterns of QML binding evaluations and general ECMAScript code. For the record: Any animation code that _doesn't_ use QML Animators does indeed run in the same thread as the STW garbage collector and is therefore subject to its non-deterministic behavior (from the animation PoV). QML Animators on the other hand are run entirely in the render thread and are not affected by any pauses in the gui thread, whether it is caused by long running scripts, the garbage collector or blocking disk I/O. If with today's release you want to have guaranteed lag-free animations, then the use of animators over NumberAnimation, etc. is required. That is why it _is_ possible to run smooth animations with the scene graph and QML on crazy high resolution displays at minimal CPU usage. That said, it is our expressed goal to improve the garbage collector to interrupt the GUI thread as little as possible, because not everything can (and should) be solved with animators. Scrolling in a listview, delegate re-use, property re-bindings, etc. are things that still have to run in under 16 ms. So without any doubt there is work to do [?] Simon ________________________________ From: Development on behalf of Phil Bouchard Sent: Wednesday, December 28, 2016 2:44:24 PM To: development at qt-project.org Subject: Re: [Development] Proposal for "container-oriented deterministic memory manager" On 12/28/2016 08:36 AM, Simon Hausmann wrote: > Hi, > > building on the suggestion: do you have any thoughts about how your > allocator could be used instead of a garbage collector in an ecmascript > implementation? I'll have to look into the details of the ECMAScript but root_ptr can handle neural networks so I'm not sure why it should fail with ECMAScripts. I won't be able to reply during the day today but I can study specific cases this week. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Dec 29 12:55:46 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 29 Dec 2016 09:55:46 -0200 Subject: [Development] Fwd: Compiling QtWebEngine In-Reply-To: References: Message-ID: <2789798.etnz9Bc8bi@tjmaciei-mobl1> Em quinta-feira, 29 de dezembro de 2016, às 10:32:29 BRST, Berkay Elbir escreveu: > I tried to compile Qt 5.7.0 source code with web engine module on > Windows 7 with Visual Studio 2013 Update 5. If I compile the source > code without web engine, everything works fine. However, I am in > trouble with compiling web engine module and getting following linker > error for all qtwebengine objects. > '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in > qtwebenginecoreglobal.obj That means you're mixing debug and release. You can't do that with MSVC. > Because of some special reason, we have to use qt debug dll's like > release. For this, we made following changes : > > Go to Qt directory and open msvc-desktop.conf file > (D:\Qt\Qt5.7.0\qtbase\mkspecs\common\msvc-desktop.conf) > Change -MDd params to -MD for debug flags > QMAKE_CFLAGS_DEBUG = -Zi -MD Correct. > And we run the following commands : > > configure -opensource -confirm-license -mp -no-compile-examples > -nomake examples -nomake tests -make tools -opengl desktop -no-angle > -no-icu -skip qtmultimedia -skip location -skip sensors > -debug-and-release -no-warnings-are-errors -platform win32-msvc2013 > -prefix D:\Qt\Qt5.7.0_x64 -openssl -I > D:\3rdParty\OpenSSL\OpenSSL-Win64\include -L > D:\3rdParty\OpenSSL\OpenSSL-Win64 > D:\3rdParty\jom_1_1_0\jom.exe module-qtwebengine > > Thanks for your help. You're welcome. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Thu Dec 29 14:49:24 2016 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 29 Dec 2016 08:49:24 -0500 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: <2457362.z1HspnihMx@tjmaciei-mobl1> Message-ID: On 12/29/2016 04:14 AM, Simon Hausmann wrote: > Hi, > > > I don't doubt that root_ptr can be used at all. What I'm curious about > is what your thoughts are on how it could perform, how you would map its > strengths to the allocation patterns of QML binding evaluations and > general ECMAScript code. I'll need to have a general overview of the ECMAScript and study it further before speculating. My knowledge of Javascript is not at the expert level yet so any pointers are appreciated. > For the record: Any animation code that _doesn't_ use QML Animators does > indeed run in the same thread as the STW garbage collector and is > therefore subject to its non-deterministic behavior (from the animation > PoV). QML Animators on the other hand are run entirely in the render > thread and are not affected by any pauses in the gui thread, whether it > is caused by long running scripts, the garbage collector or > blocking disk I/O. If with today's release you want to have guaranteed > lag-free animations, then the use of animators over NumberAnimation, > etc. is required. That is why it _is_ possible to run smooth animations > with the scene graph and QML on crazy high resolution displays at > minimal CPU usage. > > > That said, it is our expressed goal to improve the garbage collector to > interrupt the GUI thread as little as possible, because not everything > can (and should) be solved with animators. Scrolling in a listview, > delegate re-use, property re-bindings, etc. are things that still have > to run in under 16 ms. So without any doubt there is work to do �� I'll do my best to help but one again am I not yet an advanced Javascript programmer but I'm sure architects understand this stuff like the back of their hand. So please give me some time to study this as this week I have skiing training sessions to give to kids. From thiago.macieira at intel.com Thu Dec 29 15:30:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 29 Dec 2016 12:30:38 -0200 Subject: [Development] Proposal for "container-oriented deterministic memory manager" In-Reply-To: References: Message-ID: <1628301.ahCn88OmZl@tjmaciei-mobl1> Em quinta-feira, 29 de dezembro de 2016, às 08:49:24 BRST, Phil Bouchard escreveu: > I'll need to have a general overview of the ECMAScript and study it > further before speculating. My knowledge of Javascript is not at the > expert level yet so any pointers are appreciated. [cut] > I'll do my best to help but one again am I not yet an advanced > Javascript programmer but I'm sure architects understand this stuff like > the back of their hand. Note that you don't need to be a JavaScript expert programmer. You need to know a JavaScript engine and VM only. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center