From edward.welbourne at qt.io Fri Jun 1 08:28:58 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 1 Jun 2018 06:28:58 +0000 Subject: [Development] State of LGPL exception after migration to LGPLv3 In-Reply-To: References: <9256451492428265@web20m.yandex.ru> <3651384.33rW8ZPOfs@tjmaciei-mobl1>, Message-ID: Em segunda-feira, 17 de abril de 2017, às 04:24:25 PDT, Konstantin Tokarev escreveu: >>> 1. Is it still legal to incorporate "inline functions and templates" >>> into code not covered by LGPLv3? In particular, I'm interested in >>> qAsConst On 17 Apr 2017, at 18:07, Thiago Macieira wrote: >> The LGPLv3 text contains the equivalent exception. See LICENSE.LGPLv3 >> section 3 "Object Code Incorporating Material from Library Header >> Files." Lars Knoll (18 April 2017 10:38) > The LGPL_EXCEPTION.txt files should get removed from our > sources. LGPLv3 covers this case directly. Trippng over this in the tail of my in-box the other day, I checked and found it hadn't happened so, after checking with Lars, got on with it. The LGPL_EXCEPTION files are now gone (last integrated this morning). Eddy. From lars.knoll at qt.io Fri Jun 1 08:39:17 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 1 Jun 2018 06:39:17 +0000 Subject: [Development] State of LGPL exception after migration to LGPLv3 In-Reply-To: References: <9256451492428265@web20m.yandex.ru> <3651384.33rW8ZPOfs@tjmaciei-mobl1> Message-ID: <4A077052-98C3-414E-BCE7-89ED3FFEEA60@qt.io> > On 1 Jun 2018, at 08:28, Edward Welbourne wrote: > > Em segunda-feira, 17 de abril de 2017, às 04:24:25 PDT, Konstantin Tokarev escreveu: >>>> 1. Is it still legal to incorporate "inline functions and templates" >>>> into code not covered by LGPLv3? In particular, I'm interested in >>>> qAsConst > > On 17 Apr 2017, at 18:07, Thiago Macieira wrote: >>> The LGPLv3 text contains the equivalent exception. See LICENSE.LGPLv3 >>> section 3 "Object Code Incorporating Material from Library Header >>> Files." > > Lars Knoll (18 April 2017 10:38) >> The LGPL_EXCEPTION.txt files should get removed from our >> sources. LGPLv3 covers this case directly. > > Trippng over this in the tail of my in-box the other day, I checked and > found it hadn't happened so, after checking with Lars, got on with it. > The LGPL_EXCEPTION files are now gone (last integrated this morning). Thanks Eddy! Lars From jani.heikkinen at qt.io Fri Jun 1 13:38:42 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 1 Jun 2018 11:38:42 +0000 Subject: [Development] HEADS-UP: Branching from '5.11' -> '5.11.1' started Message-ID: Hi, We have soft branched 5.11.1 from 5.11 today. Target is to finalize branching & have final downmerge from '5.11' -> '5.11.1' Thu 7.6.2018. Please start using '5.11.1' for new changes targeted to Qt 5.11.1 release. br, Jani Heikkinen Release Manager From jhihn at gmx.com Sat Jun 2 19:27:28 2018 From: jhihn at gmx.com (Jason H) Date: Sat, 2 Jun 2018 19:27:28 +0200 Subject: [Development] qqc2-desktop-style for qt6? Message-ID: I heard that after 5.11 the focus will start on Qt6? On the interest list a while back there was talk about this gem, https://github.com/KDE/qqc2-desktop-style Which seems like a much needed bridge in terms of style, but it requires QPainter from widgets. For Qt6 is there anything planned for styles and style-aware QML components? It seems like to me that QStyle* should be moved to QtGUI or some replacement that allows style information? From thiago.macieira at intel.com Sat Jun 2 19:33:15 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 02 Jun 2018 10:33:15 -0700 Subject: [Development] qqc2-desktop-style for qt6? In-Reply-To: References: Message-ID: <5791344.H3UWvsaWWc@tjmaciei-mobl1> On Saturday, 2 June 2018 10:27:28 PDT Jason H wrote: > I heard that after 5.11 the focus will start on Qt6? That information is outdated. There are no plans for Qt 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Sat Jun 2 21:23:53 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Sat, 2 Jun 2018 19:23:53 +0000 Subject: [Development] qqc2-desktop-style for qt6? In-Reply-To: <5791344.H3UWvsaWWc@tjmaciei-mobl1> References: <5791344.H3UWvsaWWc@tjmaciei-mobl1> Message-ID: <064B8343-8D14-4B9C-B309-E4232EE051E4@qt.io> > On 2 Jun 2018, at 19:33, Thiago Macieira wrote: > > On Saturday, 2 June 2018 10:27:28 PDT Jason H wrote: >> I heard that after 5.11 the focus will start on Qt6? > > That information is outdated. There are no plans for Qt 6. Not yet, but let's see if we can start making some during the contributor summit. But after 5.11 is a bit too early :) Cheers, Lars From ville.voutilainen at gmail.com Sun Jun 3 01:31:15 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Sun, 3 Jun 2018 02:31:15 +0300 Subject: [Development] qqc2-desktop-style for qt6? In-Reply-To: <064B8343-8D14-4B9C-B309-E4232EE051E4@qt.io> References: <5791344.H3UWvsaWWc@tjmaciei-mobl1> <064B8343-8D14-4B9C-B309-E4232EE051E4@qt.io> Message-ID: On 2 June 2018 at 22:23, Lars Knoll wrote: >> On 2 Jun 2018, at 19:33, Thiago Macieira wrote: >> >> On Saturday, 2 June 2018 10:27:28 PDT Jason H wrote: >>> I heard that after 5.11 the focus will start on Qt6? >> >> That information is outdated. There are no plans for Qt 6. > > Not yet, but let's see if we can start making some during the contributor summit. > > But after 5.11 is a bit too early :) Concurred; there are some ruminations about starting to really discuss how to get to Qt 6, and when. What we can say is that it will not just happen unannounced and without discussion after a release like 5.11; we want to actually plan it, and as far as we can help it, it shouldn't come as a surprise to anyone in the community. From olszak.tomasz at gmail.com Mon Jun 4 10:58:25 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Mon, 4 Jun 2018 10:58:25 +0200 Subject: [Development] QTBUG-43096 - QML instantiation performance decadence In-Reply-To: References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Message-ID: Hi Uwe, I quickly reviewed QSkinny and it really nicely exposes C++ to Qml. I can't see however, how you made e.g. QskVariant::stops readable from Qml. Writing stops is possible due to QMetaType::registerConvertes, but how you can iterate overs stop from Qml? Thanks in advance for clarification, Tomek PS: I also tried to have the same implementation for C++ and Qt Qml and now some classes contains duplicated getters/setters (QVariantList instead of QVector). 2018-05-31 9:48 GMT+02:00 Chris Adams : > On Thu, May 31, 2018 at 5:21 PM, Uwe Rathmann > wrote: > > Hi Simon, > > > >> I ran benchmarks comparing a release build of 5.12 against 5.1.1 and ran > >> the benchmark mentioned in the task, where Qt 5.12 came out in average > >> faster by a factor of 4. > > > > Christophers comment in the JIRA ticket raises some questions concerning > > the correctness of those benchmarks. > > > > Would you be so kind to clarify how far we can trust in these numbers ? > > I did have a couple of questions about that particular benchmark > result, but that doesn't mean that the conclusion is incorrect. > > It's important to note that the issue may lie in the original numbers, > as the library metrics test previously used some hand-rolled methods > to discard outliers and perform an average, and worked on wall time > rather than cpu ticks - a method which may very well have been wrong > (and that would be entirely my fault). > > Also, it is worth pointing out that recently a considerable effort has > been made to improve the benchmarking of all stages of QtQuick > applications (from the JS side of things, to the QML compiler side of > things, to the scene graph side of things), as the grafana and > qmlbench etc tracking proves. Performance regressions are now being > caught, and performance metrics are easily visible, thanks to those > efforts, and that is definitely have a very positive effect on > performance outcomes for everyone. > > FWIW I am certain that the QML engine in Qt 5.12 will indeed perform > better than it did in Qt 5.1 days (or any other version of Qt) because > the people working most closely with the engine and the people working > most closely with QtQuick both believe it to be so, and I trust their > judgement. > > Best regards, > Chris. > _______________________________________________ > 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 Uwe.Rathmann at tigertal.de Mon Jun 4 19:43:44 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Mon, 4 Jun 2018 17:43:44 +0000 (UTC) Subject: [Development] QTBUG-43096 - QML instantiation performance decadence References: <1527251405.2829505.1385058224.053D963E@webmail.messagingengine.com> Message-ID: Hi Tomek, > I quickly reviewed QSkinny and it really nicely exposes C++ to Qml. I > can't see however, how you made e.g. QskVariant::stops readable from > Qml. Writing stops is possible due to QMetaType::registerConvertes, but > how you can iterate overs stop from Qml? Don't know either, but I'm not the right person to ask when it comes to JavaScript related issues. > PS: I also tried to have the same implementation for C++ and Qt Qml and > now some classes contains duplicated getters/setters (QVariantList > instead of QVector). Hope it is o.k. to throw in some ideas/experiences, but as my work is not part of the qt-project I don't want to to misuse this mailing list. But if you ( or anyone else ) likes to discuss in more depth what I'm doing you can always contact me of the list. ciao, Uwe From wpurvis at gmail.com Mon Jun 4 22:20:42 2018 From: wpurvis at gmail.com (Walter Purvis) Date: Mon, 4 Jun 2018 16:20:42 -0400 Subject: [Development] Apple officially deprecates OpenGL Message-ID: Is this going to cause issues with Qt Quick applications? I.e., will Qt Quick apps be broken or unacceptably slow in future versions of macOS? (The next version of macOS merely deprecates OpenGL, but it raises the question of when it might be removed from macOS altogether.) https://developer.apple.com/macos/whats-new/ "Apps built using OpenGL and OpenCL will continue to run in macOS 10.14, but these legacy technologies are deprecated in macOS 10.14. Games and graphics-intensive apps that use OpenGL should now adopt Metal." -------------- next part -------------- An HTML attachment was scrubbed... URL: From Morten.Sorvig at qt.io Tue Jun 5 08:05:50 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Tue, 5 Jun 2018 06:05:50 +0000 Subject: [Development] Apple officially deprecates OpenGL In-Reply-To: References: Message-ID: <37F2FFFE-7E80-4ACF-9960-7B03A7ACE840@qt.io> > On 4 Jun 2018, at 22:20, Walter Purvis wrote: > > Is this going to cause issues with Qt Quick applications? I.e., will Qt Quick apps be broken or unacceptably slow in future versions of macOS? (The next version of macOS merely deprecates OpenGL, but it raises the question of when it might be removed from macOS altogether.) > > > https://developer.apple.com/macos/whats-new/ > > "Apps built using OpenGL and OpenCL will continue to run in macOS 10.14, but these legacy technologies are deprecated in macOS 10.14. Games and graphics-intensive apps that use OpenGL should now adopt Metal.” From the platform side, we’ve recently (dev/5.12) added support for QSurface:MetalSurface and also QSurface::VulkanSurface (via MoltenVK) on macOS. So this opens the door for developing new Qt Quick backends. Morten > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From announce at qt-project.org Tue Jun 5 13:39:33 2018 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Tue, 5 Jun 2018 11:39:33 +0000 Subject: [Development] [Announce] Qt Creator 4.7 Beta released Message-ID: We are happy to announce the release of Qt Creator 4.7 Beta! http://blog.qt.io/blog/2018/06/05/qt-creator-4-7-beta-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From qt at squorn.de Tue Jun 5 14:40:52 2018 From: qt at squorn.de (Daniel Teske) Date: Tue, 5 Jun 2018 14:40:52 +0200 Subject: [Development] unique_ptr and Qt Message-ID: Hi, I've done some research into how supporting unique_ptr in Qt might look like. I have a patch which adds apis using unique_ptr for ownership transfer to almost all of QtBase and a patch for Qt Creator to show how using those apis looks like. Qt: https://codereview.qt-project.org/231543 Qt Creator: https://codereview.qt-project.org/231545 It's nowhere finished, and I have no expectations of it going into Qt in the near future, nor the intention to finish the patch. The intent was, to have some fun, to explore the space of what is possible, to show how it could look like and to maybe start a discussion on what Qt can and should do in that direction. Also I run out of time to properly polish it. This patch is backwards compatible, existing code continues to work exactly the same and has a very high degree of source compatibility. It allows users to opt-in to warnings that indicate unclear ownership semantics and allows for piece by piece porting of code. It requires C++17 though. And unfortunately due to a bug MSVC 15.7 is not good enough. That bug in guaranteed copy elision is supposed to be fixed in 15.8. The additional apis are enabled via a configure flag and are inline functions. The core idea is this invariant: A Qt Object either is owned by a unique_ptr, is owned by a parent, or is allocated on the stack. (A stack allocated object, might or might not have a parent.) Thus the first addition are 3 new functions for creating objects, all very similar to std::make_unique. std::unique_ptr qmakeUnique(Args ...); T* QObject::makeChild(Args ...); T makeOnStack(ParentType, Args ...); Those functions ensure that the returned object observe the invariant. That is, qmakeUnique passes a nullptr as the parent pointer to T.  And widget->makeChild(...) passes widget as the parent pointer. Thus if the constructor uses the parent pointer to set it's parent, the invariant holds and is ensured at compile time. Some types, e.g. QEvent, QTreeWidgetItem are treated a bit differently, see the patch for details. I'll discuss various classes of functions: * Functions "taking" ownership, e.g. QLayout::addWidget( child ) Note: Qt functions that "take" ownership, don't actually always take ownership. If the passed in argument is already owned by the right parent, ownership is not transferred. To ensure that the invariant holds, there are two cases to consider: a) The child is owned by a parent. => Use the addWidget(QWidget *rawPointer) overload b) The child is owned by a unique_ptr => Use the new addWidget(std::unique_ptr widget) overload For example this code is then possible: auto label = qmakeUnique("label text"); layout->addWidget(std::move(label)); A undiagnosed and potential pitfall, is this code: auto label = qmakeUnique("label text"); layout->addWidget(label.get()); which leads to double deletion. Calling a qt function that takes ownership with a raw pointer derived from a unique_ptr is a user bug. While obvious in this case, that isn't always so. * Functions releasing ownership / creating new objects There aren't actually not a lot of functions in this category. For example QLayout::removeWidget() does not release ownership of the widget, instead ownership is transferred if the widget is added to a different layout. For functions that actually do release ownership / create objects, add a function returning a unique_ptr mostly named either "makeXXX" or "releaseXXX". So how do I prevent users from calling the old function? a) Not at all, this makes the code fully backwards compatible. b) The user can opt into deprecation warnings by defining: QT_DEPRECATED_UNSAFE_API For Qt Creator patch, I defined that only in the coreplugin plugin. * Other points I probably missed quite a few special cases, since my aim was to cover as much as qtbase as possible, without spending too much time on each individual class. But for the most part, there weren't that many special cases. I left a few "TODO"s in the patch for apis that would take more work. I don't think there was anything completely unsolvable, but quite a few pain points. Having unique_ptr as a vocabulary type also has some other benefits: Some apis in Qt would really love to have a way to ensure that the caller takes care of deleting the resource. But because there is no way in C++98 to ensure that, they don't transfer ownership. For example, the documentation of QTcpServer::nextPendingConnection() is: > The socket is created as a child of the server, which means that it is automatically deleted when the QTcpServer object is destroyed. > It is still a good idea to delete the object explicitly when you are done with it, to avoid wasting memory. With unique_ptr there would be a way to ensure that the caller takes ownership by returning the QTcpSocket wrapped in a unique_ptr. Also while writing this patch, I noticed several functions whose ownership semantics are too strange for my taste and should arguably be changed even without adding unique_ptr. For example: void QGraphicsGridLayout::removeAt(int index) transfers ownership of a item that is neither a parameter nor a return value. I also ported a very small part of Creator to use those new apis and I actually found only one place that leaks memory. Some of the code looks arguably better, imho makeChild does make the code easier to read. In other parts, Creator has fancy memory ownership semantics, which are not easily representable with unique_ptr's. And unique_ptr can be bit awkward to use. And as a last though, having unique_ptr as part of the vocabulary types also allows for better apis: Consider QScrollArea and its functions: void setWidget(QWidget *w); void setCornerWidget(QWidget *w); Even though they have the exact same signature, and very similar names, their behaviour is different in how they treat the old replaced widget. setWidget() deletes the old widget, there is afaik no way to reuse a widget once it has been set via setWidget. On the other hand, setCornerWidget() merely hides the old widget. (I think the use case here is switching between multiple corner widgets.) With unique_ptr, a imho better api would be: unique_ptr replaceWidget/replaceCornerWidget(QWidget *) If the user does not care about the old widget, just ignoring the return value gets the old widget deleted. If the user wants to reuse the widget somewhere, s/he has ownership of it. * Short guide to patch reading: Since the patches are pretty big and most of it is pretty uninteresting, for reading it I suggest: 1) Look at the changes in qglobal.h. 2) Look at the qwidget.h 3) Look at qtreewidgetitem.h 4) Look at the creator patch at a random file 5) Look at TODO comments which explain some of the remaining problems * My Conclusion Adding unique_ptr supporting apis is possible. (Though clearly this patch would need a lot of refining.) But, it adds a lot of complexity, and can be awkward to use. On the other hand, as more users become accustomed with using unique_ptr in their code, the demand for Qt to support them will grow. So imho research in that direction must happen. Since the mail is already pretty long, I'll stop here. If you have questions or suggestions, due to some technical difficulties, I can't respond until Friday. I'll be at the Contributor Summit, so if there's sufficient interest I can add a session to the schedule. daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From ville.voutilainen at gmail.com Tue Jun 5 16:55:20 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 5 Jun 2018 17:55:20 +0300 Subject: [Development] unique_ptr and Qt In-Reply-To: References: Message-ID: On 5 June 2018 at 15:40, Daniel Teske wrote: > Hi, > > I've done some research into how supporting unique_ptr in Qt might look > like. > > I have a patch which adds apis using unique_ptr for ownership transfer to > almost all of QtBase and a patch for Qt Creator to show how using those apis > looks like. > > Qt: https://codereview.qt-project.org/231543 > Qt Creator: https://codereview.qt-project.org/231545 Just quickly: interesting. Being able to be explicit about ownership transfer in Qt programming has been a wishlist item for a long time. I will take a closer look in the next couple of days, I'm in the middle of the C++ standards committee meeting. From perezmeyer at gmail.com Thu Jun 7 01:44:02 2018 From: perezmeyer at gmail.com (=?UTF-8?Q?Lisandro_Dami=C3=A1n_Nicanor_P=C3=A9rez_Meyer?=) Date: Wed, 6 Jun 2018 20:44:02 -0300 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite Message-ID: Hi! As neither the bug, the proposed patch or the pings have been replied I'm hereby pinging Marco Bubke or someone else who might take a look at this. Thanks! -- Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ From thiago.macieira at intel.com Thu Jun 7 03:22:35 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 6 Jun 2018 18:22:35 -0700 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: References: Message-ID: <3430791.3R8DKBB4GN@tjmaciei-mobl1> On Wednesday, 6 June 2018 16:44:02 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! As neither the bug, the proposed patch or the pings have been > replied I'm hereby pinging Marco Bubke or someone else who might take > a look at this. Also, please explain why it isn't using QtSql. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Thu Jun 7 04:09:00 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 06 Jun 2018 23:09:00 -0300 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: <3430791.3R8DKBB4GN@tjmaciei-mobl1> References: <3430791.3R8DKBB4GN@tjmaciei-mobl1> Message-ID: <1711966.bZdDl6GDHx@tonks> El miércoles, 6 de junio de 2018 22:22:35 -03 Thiago Macieira escribió: > On Wednesday, 6 June 2018 16:44:02 PDT Lisandro Damián Nicanor Pérez Meyer > > wrote: > > Hi! As neither the bug, the proposed patch or the pings have been > > replied I'm hereby pinging Marco Bubke or someone else who might take > > a look at this. > > Also, please explain why it isn't using QtSql. I also notd that SQLite was embedded in the source as a single file because "compilers can better optimize it". - Is this benchmarked? - Is it worth the trade off considering it makes finding security bugs more complicated? -- El futuro es WIN95.... A no ser que hagamos algo a tiempo. 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 Thu Jun 7 04:57:55 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 6 Jun 2018 19:57:55 -0700 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: <1711966.bZdDl6GDHx@tonks> References: <3430791.3R8DKBB4GN@tjmaciei-mobl1> <1711966.bZdDl6GDHx@tonks> Message-ID: <3163026.cyXPQGE9dz@tjmaciei-mobl1> On Wednesday, 6 June 2018 19:09:00 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > - Is it worth the trade off considering it makes finding security bugs more > complicated? We're not supposed to find or fix sqlite security issues. We get them from upstream and upstream supports the single-file build style. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jun 7 05:13:07 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 6 Jun 2018 20:13:07 -0700 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: <3163026.cyXPQGE9dz@tjmaciei-mobl1> References: <1711966.bZdDl6GDHx@tonks> <3163026.cyXPQGE9dz@tjmaciei-mobl1> Message-ID: <21607627.ifUZT3ds6p@tjmaciei-mobl1> On Wednesday, 6 June 2018 19:57:55 PDT Thiago Macieira wrote: > On Wednesday, 6 June 2018 19:09:00 PDT Lisandro Damián Nicanor Pérez Meyer > > wrote: > > - Is it worth the trade off considering it makes finding security bugs > > more > > > > complicated? > > We're not supposed to find or fix sqlite security issues. We get them from > upstream and upstream supports the single-file build style. Actually, this is a very important subject, so I just added a session to the QtCS program next week to discuss it. As you may be aware, Intel is taking security VERY seriously and I cannot accept a project I contribute to having any worse policies. Our open source security team also evaluates each project's security policies and they have blacklisted quite a few open source projects from being used in Intel products, so I'd like to make sure Qt continues to comply with the stricter guidelines. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Tim.Jenssen at qt.io Thu Jun 7 06:23:19 2018 From: Tim.Jenssen at qt.io (Tim Jenssen) Date: Thu, 7 Jun 2018 04:23:19 +0000 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: <21607627.ifUZT3ds6p@tjmaciei-mobl1> References: <1711966.bZdDl6GDHx@tonks> <3163026.cyXPQGE9dz@tjmaciei-mobl1>, <21607627.ifUZT3ds6p@tjmaciei-mobl1> Message-ID: I try to forward this message, but he is at a long vacation trip. So it could take a while. Outlook for Android herunterladen ________________________________ From: Development on behalf of Thiago Macieira Sent: Thursday, June 7, 2018 5:13:07 AM To: development at qt-project.org Subject: Re: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite On Wednesday, 6 June 2018 19:57:55 PDT Thiago Macieira wrote: > On Wednesday, 6 June 2018 19:09:00 PDT Lisandro Damián Nicanor Pérez Meyer > > wrote: > > - Is it worth the trade off considering it makes finding security bugs > > more > > > > complicated? > > We're not supposed to find or fix sqlite security issues. We get them from > upstream and upstream supports the single-file build style. Actually, this is a very important subject, so I just added a session to the QtCS program next week to discuss it. As you may be aware, Intel is taking security VERY seriously and I cannot accept a project I contribute to having any worse policies. Our open source security team also evaluates each project's security policies and they have blacklisted quite a few open source projects from being used in Intel products, so I'd like to make sure Qt continues to comply with the stricter guidelines. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Jun 7 08:03:40 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 06 Jun 2018 23:03:40 -0700 Subject: [Development] Did we have to remove cmake's qt5_use_modules? Message-ID: <2825593.EUdpXDWLPV@tjmaciei-mobl1> Commit 02ed1b36daebed5f3997bb676cf5e818c0db9d3c was Remove CMake code for CMake < 3.1 This removes the following functions from Qt5CoreMacros: - qt5_use_modules(...) Which follows 2013's d9ea4bb1441534cfb9253303ac258951dfcc4d9e Mark qt5_use_modules as obsolete. Forward-port of cb7f32f5b861fe115fa71f64500a5cbb0b643f1b (Mark qt4_use_modules and qt4_automoc as obsolete., 2013-07-04) from cmake.git. But it appears that in the 5 years since we deprecated it, people have not stopped using it. Did we have to remove it? Or should we have kept compatibility until Qt 6? Just look at the failures in https://build.opensuse.org/project/monitor/openSUSE:Factory? arch_x86_64=1&defaults=0&failed=1&repo_standard=1 The majority of them are caused by the Qt 5.11 update, a great number of which are the cmake update (the rest are indirect header dependency and are easy to fix). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Marco.Bubke at qt.io Thu Jun 7 08:52:35 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Thu, 7 Jun 2018 06:52:35 +0000 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: <21607627.ifUZT3ds6p@tjmaciei-mobl1> References: <1711966.bZdDl6GDHx@tonks> <3163026.cyXPQGE9dz@tjmaciei-mobl1> <21607627.ifUZT3ds6p@tjmaciei-mobl1> Message-ID: Hi I am on vacation till end of July, I am looking forward to discuss it in August. Best regards, Marco On June 7, 2018 11:13:24 Thiago Macieira wrote: > On Wednesday, 6 June 2018 19:57:55 PDT Thiago Macieira wrote: >> On Wednesday, 6 June 2018 19:09:00 PDT Lisandro Damián Nicanor Pérez Meyer >> >> wrote: >> > - Is it worth the trade off considering it makes finding security bugs >> > more >> > >> > complicated? >> >> We're not supposed to find or fix sqlite security issues. We get them from >> upstream and upstream supports the single-file build style. > > Actually, this is a very important subject, so I just added a session to the > QtCS program next week to discuss it. > > As you may be aware, Intel is taking security VERY seriously and I cannot > accept a project I contribute to having any worse policies. Our open source > security team also evaluates each project's security policies and they have > blacklisted quite a few open source projects from being used in Intel > products, so I'd like to make sure Qt continues to comply with the stricter > guidelines. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Thu Jun 7 09:06:32 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 07 Jun 2018 00:06:32 -0700 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: References: <21607627.ifUZT3ds6p@tjmaciei-mobl1> Message-ID: <1730406.clDETKRSiv@tjmaciei-mobl1> On Wednesday, 6 June 2018 23:52:35 PDT Marco Bubke wrote: > Hi > > I am on vacation till end of July, I am looking forward to discuss it in > August. Sure. Meanwhile, can we apply Lisandro's patch? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Thu Jun 7 11:19:26 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 7 Jun 2018 11:19:26 +0200 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: <21607627.ifUZT3ds6p@tjmaciei-mobl1> References: <1711966.bZdDl6GDHx@tonks> <3163026.cyXPQGE9dz@tjmaciei-mobl1> <21607627.ifUZT3ds6p@tjmaciei-mobl1> Message-ID: Hi, On 07/06/18 05:13, Thiago Macieira wrote: > As you may be aware, Intel is taking security VERY seriously and I cannot > accept a project I contribute to having any worse policies. Our open source > security team also evaluates each project's security policies and they have > blacklisted quite a few open source projects from being used in Intel > products, so I'd like to make sure Qt continues to comply with the stricter > guidelines. By any chance, are these guidelines public? Thanks, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From Marco.Bubke at qt.io Thu Jun 7 12:17:10 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Thu, 7 Jun 2018 10:17:10 +0000 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: <1730406.clDETKRSiv@tjmaciei-mobl1> References: <21607627.ifUZT3ds6p@tjmaciei-mobl1> <1730406.clDETKRSiv@tjmaciei-mobl1> Message-ID: It is used buy the Clang refactoring plugin, which is not build by default. So I see no urgency in it except it will break it. Let's discuss it if I am back. On June 7, 2018 15:06:57 Thiago Macieira wrote: > On Wednesday, 6 June 2018 23:52:35 PDT Marco Bubke wrote: >> Hi >> >> I am on vacation till end of July, I am looking forward to discuss it in >> August. > > Sure. Meanwhile, can we apply Lisandro's patch? > > -- > 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 sh at theharmers.co.uk Thu Jun 7 13:31:13 2018 From: sh at theharmers.co.uk (Sean Harmer) Date: Thu, 7 Jun 2018 12:31:13 +0100 Subject: [Development] Do we really need Assimp? In-Reply-To: <1557864.ivJVhQeBFm@tjmaciei-mobl1> References: <1557864.ivJVhQeBFm@tjmaciei-mobl1> Message-ID: Hi Thiago, Apologies for the delay in replying, I was on vacation. On 23/05/2018 01:16, Thiago Macieira wrote: > Given the number of warnings in this codebase, I am really skeptical about the > quality of the code. Today, compiling with GCC, Clang an ICC, I saw the > following warnings scroll by, which are real issues: > > LWSLoader.cpp:428:14: warning: duplicated ‘if’ condition [-Wduplicated-cond] > > new_allocator.h:140:22: warning: destructor called on non-final > 'Assimp::FICDATAValueImpl' that has virtual functions but non-virtual > destructor [-Wdelete-non-virtual-dtor] > > miniz.h(4430): warning #592: variable "level" is used before its value is set > > And then there are of course warnings that indicate none of their developers > are testing new compilers, like > > LWOLoader.cpp:1408:13: warning: this statement may fall through [-Wimplicit- > fallthrough=] > > Can we get rid of it? > > If not, can I ask someone to compile it with CONFIG += warn_off, to hide all > that ugliness? Those warnings make finding our warnings more difficult and it > affects our reputation because people see warnings and think they're Qt's > fault. > > Qt3D maintainers, please take action to make sure those warnings disappear > from our builds. Tbh I'd be glad to not have assimp in the source tree too as it just adds to maintenance. It's used for 2 things at present: 1) A sceneloader plugin. We could move this to be not compiled by default or even move it to another optional module for users to compile themselves. 2) The qgltf tool which converts from assimp-supported file formats to extended glTF 1 files. Again, we coudl do similar as with 1). Another option is to only rely upon a system installed assimp and build these tools only if found at configure time. In fact, that's probably easiest and best. Then we can remove assimp from the source. It means users woudl need to build these tools/plugins themselves (typically on macOS/Windows) but at least they would be easily available. Would that be acceptable to the project? Cheers, Sean From szehowe.koh at gmail.com Thu Jun 7 15:48:53 2018 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Thu, 7 Jun 2018 21:48:53 +0800 Subject: [Development] Is Qt for Automation available under GPLv3? Message-ID: Hello, According to http://doc.qt.io/QtForAutomation/qtautomation-install.html Qt for Automation is available under GPLv3. However, the installation instructions are not valid for open-source users. Furthermore, that page also says that Qt for Automation is built on Qt for Device Creation, which is commercial-only. Users are confused by that page: * https://forum.qt.io/topic/91042/how-to-install-qt-for-automation * https://forum.qt.io/topic/91439/no-option-to-install-qt-for-automation-in-the-online-installer Please resolve. Regards, Sze-Howe From perezmeyer at gmail.com Thu Jun 7 15:56:11 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 07 Jun 2018 10:56:11 -0300 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: References: <1730406.clDETKRSiv@tjmaciei-mobl1> Message-ID: <2248635.DajyMKOejl@tonks> El jueves, 7 de junio de 2018 07:17:10 -03 Marco Bubke escribió: > It is used buy the Clang refactoring plugin, which is not build by default. But we are still building sqlite3.c by default. -- Los chicos tienen un mayor dominio de la tecnología (y las habilidades y lenguaje que eso implica) que los adultos con los que se relacionan. Por lo general saben más que sus propios padres, sus docentes, sus pediatras, psicólogos, que los políticos y funcionarios de sus comunidades. Eso afectó la autoridad que tenía un adulto para habilitar al mundo. Luis Pescetti http://www.luispescetti.com/regale-su-obra/ 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 Thu Jun 7 16:05:54 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 07 Jun 2018 11:05:54 -0300 Subject: [Development] Did we have to remove cmake's qt5_use_modules? In-Reply-To: <2825593.EUdpXDWLPV@tjmaciei-mobl1> References: <2825593.EUdpXDWLPV@tjmaciei-mobl1> Message-ID: <2295326.lhr66GpsWy@tonks> El jueves, 7 de junio de 2018 03:03:40 -03 Thiago Macieira escribió: > Commit 02ed1b36daebed5f3997bb676cf5e818c0db9d3c was > > Remove CMake code for CMake < 3.1 > > This removes the following functions from Qt5CoreMacros: > - qt5_use_modules(...) > > Which follows 2013's d9ea4bb1441534cfb9253303ac258951dfcc4d9e > > Mark qt5_use_modules as obsolete. > > Forward-port of cb7f32f5b861fe115fa71f64500a5cbb0b643f1b (Mark > qt4_use_modules and qt4_automoc as obsolete., 2013-07-04) from > cmake.git. > > But it appears that in the 5 years since we deprecated it, people have not > stopped using it. Did we have to remove it? Or should we have kept > compatibility until Qt 6? > > Just look at the failures in > https://build.opensuse.org/project/monitor/openSUSE:Factory? > arch_x86_64=1&defaults=0&failed=1&repo_standard=1 > > The majority of them are caused by the Qt 5.11 update, a great number of > which are the cmake update (the rest are indirect header dependency and are > easy to fix). Interesting, this will affect other distros obviously. Was there anything breaking due to keeping this? -- May the source be with you. 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 Thu Jun 7 17:35:29 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 7 Jun 2018 15:35:29 +0000 Subject: [Development] HEADS-UP: Branching from '5.11' -> '5.11.1' ready Message-ID: Hi, We have now done final downmerge from '5.11' -> '5.11.1'. So from now on all changes targeted to Qt 5.11.1 release must be done in '5.11.1' and '5.11' is for Qt 5.11.2 release. Target is to create final Qt 5.11.1 packages Thu 14.6.2018 so please make sure fixes for all release blockers are in Wed 13.6.2018 EOB (latest, we will do final packages earlier if all fixes available). And please make sure that changes files for Qt 5.11.1 will be finalized immediately when initial ones available; target is to create those tomorrow. And once again: Please do not push any nice to have fixes in '5.11.1' anymore; Qt 5.11.2 will be done soon as well (end of August/beginning of September). br, Jani > -----Original Message----- > From: Jani Heikkinen > Sent: perjantai 1. kesäkuuta 2018 14.39 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: HEADS-UP: Branching from '5.11' -> '5.11.1' started > > Hi, > > We have soft branched 5.11.1 from 5.11 today. Target is to finalize branching & > have final downmerge from '5.11' -> '5.11.1' Thu 7.6.2018. > > Please start using '5.11.1' for new changes targeted to Qt 5.11.1 release. > > br, > Jani Heikkinen > Release Manager From thiago.macieira at intel.com Thu Jun 7 17:54:25 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 7 Jun 2018 08:54:25 -0700 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: <2248635.DajyMKOejl@tonks> References: <2248635.DajyMKOejl@tonks> Message-ID: <2265104.L8WK0SjDAp@tjmaciei-mobl1> On Thursday, 7 June 2018 06:56:11 PDT Lisandro Damián Nicanor Pérez Meyer wrote: > El jueves, 7 de junio de 2018 07:17:10 -03 Marco Bubke escribió: > > It is used buy the Clang refactoring plugin, which is not build by > > default. > > But we are still building sqlite3.c by default. So we just need a conditional to disable the building if the refactoring plugin isn't enabled either. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jun 7 18:01:54 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 7 Jun 2018 09:01:54 -0700 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: References: <21607627.ifUZT3ds6p@tjmaciei-mobl1> Message-ID: <7879589.rXESHO0b75@tjmaciei-mobl1> On Thursday, 7 June 2018 02:19:26 PDT Giuseppe D'Angelo wrote: > Hi, > > On 07/06/18 05:13, Thiago Macieira wrote: > > As you may be aware, Intel is taking security VERY seriously and I cannot > > accept a project I contribute to having any worse policies. Our open > > source > > security team also evaluates each project's security policies and they > > have > > blacklisted quite a few open source projects from being used in Intel > > products, so I'd like to make sure Qt continues to comply with the > > stricter > > guidelines. > > By any chance, are these guidelines public? No. I can summarise and paraphrase, though. It basically it boils down to "releases frequently and has a security team", which is fine for most projects. My gripe is with the third party content we have inside Qt, which throws a wrench into the gears. Intel products MUST use the latest release and follow all the security guidelines for all software it's using, so those bundled third-party hide releases and security notices that are relevant. This is what I want to discuss: how can we make sure we don't cause our users to use known- insecure software because we haven't updated our third-party content. For that reason, my current advice to ANY software using Qt is to never use any of the bundled third-party (always use system libraries). Note how this means "don't ever use the pre-built binaries from download.qt.io"... PS: I realise I am guilty of the thing I am accusing of too. TinyCBOR, just merged into 5.12, cannot be used as a system library as it stands. I had planned on having sufficient time to finish the API for 0.6 before the Qt 5.12 release, but it doesn't look like it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jun 7 18:03:43 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 7 Jun 2018 09:03:43 -0700 Subject: [Development] Do we really need Assimp? In-Reply-To: References: <1557864.ivJVhQeBFm@tjmaciei-mobl1> Message-ID: <2411553.gsf2nPub0W@tjmaciei-mobl1> On Thursday, 7 June 2018 04:31:13 PDT Sean Harmer wrote: > Another option is to only rely upon a system installed assimp and build > these tools only if found at configure time. In fact, that's probably > easiest and best. Then we can remove assimp from the source. It means > users woudl need to build these tools/plugins themselves (typically on > macOS/Windows) but at least they would be easily available. > > Would that be acceptable to the project? How often is the tool used and how needed is the plugin? Asked differently, if most users didn't have access to them, would they notice? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Thu Jun 7 18:24:32 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 07 Jun 2018 13:24:32 -0300 Subject: [Development] Do we really need Assimp? In-Reply-To: <2411553.gsf2nPub0W@tjmaciei-mobl1> References: <1557864.ivJVhQeBFm@tjmaciei-mobl1> <2411553.gsf2nPub0W@tjmaciei-mobl1> Message-ID: <2833731.DN3Gqi7Duy@tonks> El jueves, 7 de junio de 2018 13:03:43 -03 Thiago Macieira escribió: > On Thursday, 7 June 2018 04:31:13 PDT Sean Harmer wrote: > > Another option is to only rely upon a system installed assimp and build > > these tools only if found at configure time. In fact, that's probably > > easiest and best. Then we can remove assimp from the source. It means > > users woudl need to build these tools/plugins themselves (typically on > > macOS/Windows) but at least they would be easily available. > > > > Would that be acceptable to the project? > > How often is the tool used and how needed is the plugin? Asked differently, > if most users didn't have access to them, would they notice? In Debian we dropped it for some time due to some factor I can't remember now. After a couple of months we've got one user asking for it. I think had it been a very used component we would have received bugs more promptly. We are currently using system assimp [log], so I guess that if this route is decided upon then it should not be too complicated to accomplish. [log] -- 9: Que es el "Explorador" de Windows * El tipo que le roba las ideas a MacOs 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 Marco.Bubke at qt.io Thu Jun 7 19:37:42 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Thu, 7 Jun 2018 17:37:42 +0000 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: <2265104.L8WK0SjDAp@tjmaciei-mobl1> References: <2248635.DajyMKOejl@tonks> <2265104.L8WK0SjDAp@tjmaciei-mobl1> Message-ID: AFAIK the refactoring plugin is disabled for release. Just do the same for the Sqlite library. On June 7, 2018 23:54:43 Thiago Macieira wrote: > On Thursday, 7 June 2018 06:56:11 PDT Lisandro Damián Nicanor Pérez Meyer > wrote: >> El jueves, 7 de junio de 2018 07:17:10 -03 Marco Bubke escribió: >> > It is used buy the Clang refactoring plugin, which is not build by >> > default. >> >> But we are still building sqlite3.c by default. > > So we just need a conditional to disable the building if the refactoring > plugin isn't enabled either. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at qt.io Fri Jun 8 07:50:21 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Fri, 8 Jun 2018 05:50:21 +0000 Subject: [Development] Is Qt for Automation available under GPLv3? In-Reply-To: References: Message-ID: Hi, There are no binaries for open source users. However open source users are free to build their own binaries using GPLv3. -- Alex ________________________________________ From: Development on behalf of Sze Howe Koh Sent: Thursday, 7 June 2018 3:48:53 PM To: Qt development mailing list Subject: [Development] Is Qt for Automation available under GPLv3? Hello, According to http://doc.qt.io/QtForAutomation/qtautomation-install.html Qt for Automation is available under GPLv3. However, the installation instructions are not valid for open-source users. Furthermore, that page also says that Qt for Automation is built on Qt for Device Creation, which is commercial-only. Users are confused by that page: * https://forum.qt.io/topic/91042/how-to-install-qt-for-automation * https://forum.qt.io/topic/91439/no-option-to-install-qt-for-automation-in-the-online-installer Please resolve. Regards, Sze-Howe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From frank.meerkoetter at basyskom.com Fri Jun 8 08:51:47 2018 From: frank.meerkoetter at basyskom.com (=?UTF-8?Q?Frank_Meerk=c3=b6tter?=) Date: Fri, 8 Jun 2018 08:51:47 +0200 Subject: [Development] Is Qt for Automation available under GPLv3? In-Reply-To: References: Message-ID: Hi, I would like to point out that Qt OPC UA, which is part of Qt for Automation, can also be built with an LGPLv3 license as long as the open62541 backend is used. Regards, Frank Am 08.06.2018 um 07:50 schrieb Alex Blasche: > Hi, > > There are no binaries for open source users. However open source users are free to build their own binaries using GPLv3. > > -- > Alex > > ________________________________________ > From: Development on behalf of Sze Howe Koh > Sent: Thursday, 7 June 2018 3:48:53 PM > To: Qt development mailing list > Subject: [Development] Is Qt for Automation available under GPLv3? > > Hello, > > According to http://doc.qt.io/QtForAutomation/qtautomation-install.html > Qt for Automation is available under GPLv3. However, the installation > instructions are not valid for open-source users. Furthermore, that > page also says that Qt for Automation is built on Qt for Device > Creation, which is commercial-only. > > Users are confused by that page: > * https://forum.qt.io/topic/91042/how-to-install-qt-for-automation > * https://forum.qt.io/topic/91439/no-option-to-install-qt-for-automation-in-the-online-installer > > Please resolve. > > > Regards, > Sze-Howe > _______________________________________________ > 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 -- Frank Meerkötter Development Lead basysKom GmbH Robert-Bosch-Str. 7 | 64293 Darmstadt | Germany Tel : +49 6151 870 589 161 | Fax: +49 6151 - 870 589 162 frank.meerkoetter at basyskom.com | www.basyskom.com Handelsregister: Darmstadt HRB 9352 Geschäftsführung: Heike Ziegler From mike.krus at kdab.com Fri Jun 8 09:12:06 2018 From: mike.krus at kdab.com (Mike Krus) Date: Fri, 8 Jun 2018 08:12:06 +0100 Subject: [Development] Do we really need Assimp? In-Reply-To: <2833731.DN3Gqi7Duy@tonks> References: <1557864.ivJVhQeBFm@tjmaciei-mobl1> <2411553.gsf2nPub0W@tjmaciei-mobl1> <2833731.DN3Gqi7Duy@tonks> Message-ID: <18DB8468-1D57-4720-8AA4-BA654AE7D6BF@kdab.com> Hi Using system assimp is probably the best scenario indeed. Except I think users would expect install packages to have that enabled so ideally assimp should be installed on CI systems. Mike > On 7 Jun 2018, at 17:24, Lisandro Damián Nicanor Pérez Meyer wrote: > > El jueves, 7 de junio de 2018 13:03:43 -03 Thiago Macieira escribió: >> On Thursday, 7 June 2018 04:31:13 PDT Sean Harmer wrote: >>> Another option is to only rely upon a system installed assimp and build >>> these tools only if found at configure time. In fact, that's probably >>> easiest and best. Then we can remove assimp from the source. It means >>> users woudl need to build these tools/plugins themselves (typically on >>> macOS/Windows) but at least they would be easily available. >>> >>> Would that be acceptable to the project? >> >> How often is the tool used and how needed is the plugin? Asked differently, >> if most users didn't have access to them, would they notice? > > In Debian we dropped it for some time due to some factor I can't remember now. > After a couple of months we've got one user asking for it. > > I think had it been a very used component we would have received bugs more > promptly. > > We are currently using system assimp [log], so I guess that if this route is > decided upon then it should not be too complicated to accomplish. > > [log] > > > -- > 9: Que es el "Explorador" de Windows > * El tipo que le roba las ideas a MacOs > 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/ > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44 1625 809908 Mobile +44 7833 491941 KDAB - The Qt Experts, C++, OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4146 bytes Desc: not available URL: From edward.welbourne at qt.io Fri Jun 8 10:30:19 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 8 Jun 2018 08:30:19 +0000 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: References: <2248635.DajyMKOejl@tonks> <2265104.L8WK0SjDAp@tjmaciei-mobl1>, Message-ID: Marco Bubke (7 June 2018 19:37) wrote: > AFAIK the refactoring plugin is disabled for release. Just do the same for the Sqlite library. Probably better to do as Thiago said: On June 7, 2018 23:54:43 Thiago Macieira wrote: >> So we just need a conditional to disable the building if the refactoring >> plugin isn't enabled either. or, perhaps more to the point, only enable building of the sqlite plugin if (it's explicitly wanted or) something that needs it is enabled, Eddy. From jani.heikkinen at qt.io Fri Jun 8 10:54:44 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 8 Jun 2018 08:54:44 +0000 Subject: [Development] Maintainers, your action needed: Qt 5.11.1 changes files Message-ID: Hi, Initial ones here: https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.11.1%22,n,z Please do needed updates & get approval as soon as possible; We need to get these in soon to be able to keep our release schedule (final packages next week, release 19.6.2018) br, Jani Heikkinen Release Manager From qt.dantec at free.fr Fri Jun 8 15:20:28 2018 From: qt.dantec at free.fr (qt.dantec at free.fr) Date: Fri, 08 Jun 2018 15:20:28 +0200 Subject: [Development] Did we have to remove cmake's qt5_use_modules? In-Reply-To: <2825593.EUdpXDWLPV@tjmaciei-mobl1> References: <2825593.EUdpXDWLPV@tjmaciei-mobl1> Message-ID: <3nvkhdh1pubhlqb0g72ilh9ldv2g2vrm81@4ax.com> Le Wed, 06 Jun 2018 23:03:40 -0700, Thiago Macieira écrivait: >But it appears that in the 5 years since we deprecated it, people have not >stopped using it. Did we have to remove it? Or should we have kept >compatibility until Qt 6? The Qt promise is to maintain not only source code, but upward binary compatibility until a major version. When said promise is broken immediately after a major version release, as it was the case just after Qt5 release to fix an oversight, this is not harmful. When it happens years after release, and this is indeed the case here for deprecated modules, and was also the case with the switch away from Webkit, it can be a major problem not just for distributions, but for many projects that depend on it and did not budget a major change. To maintain source and binary compatibility, deprecated modules should not be removed until QT6. I do not even understand why there is a debate about this. From Marco.Bubke at qt.io Fri Jun 8 16:30:59 2018 From: Marco.Bubke at qt.io (Marco Bubke) Date: Fri, 8 Jun 2018 14:30:59 +0000 Subject: [Development] Pinging Marco Bubke for QTCREATORBUG-20401 - Allow to build with system's SQLite In-Reply-To: References: <2248635.DajyMKOejl@tonks> <2265104.L8WK0SjDAp@tjmaciei-mobl1>, Message-ID: The Sqlite module is not a plugin but a library. It is linked to a plugin but this plugin is not build in release and normally disabled. Like I said, it can be simply not build for release. Please stick to KISS. On June 8, 2018 16:30:19 Edward Welbourne wrote: > Marco Bubke (7 June 2018 19:37) wrote: >> AFAIK the refactoring plugin is disabled for release. Just do the same for the Sqlite library. > > Probably better to do as Thiago said: > > On June 7, 2018 23:54:43 Thiago Macieira wrote: >>> So we just need a conditional to disable the building if the refactoring >>> plugin isn't enabled either. > > or, perhaps more to the point, only enable building of the sqlite plugin > if (it's explicitly wanted or) something that needs it is enabled, > > Eddy. From kfunk at kde.org Fri Jun 8 16:59:10 2018 From: kfunk at kde.org (Kevin Funk) Date: Fri, 08 Jun 2018 16:59:10 +0200 Subject: [Development] Did we have to remove cmake's qt5_use_modules? In-Reply-To: <2825593.EUdpXDWLPV@tjmaciei-mobl1> References: <2825593.EUdpXDWLPV@tjmaciei-mobl1> Message-ID: <46325627.KDqyftmYMq@kerberos> On Thursday, 7 June 2018 08:03:40 CEST Thiago Macieira wrote: > Commit 02ed1b36daebed5f3997bb676cf5e818c0db9d3c was > > Remove CMake code for CMake < 3.1 > > This removes the following functions from Qt5CoreMacros: > - qt5_use_modules(...) > > Which follows 2013's d9ea4bb1441534cfb9253303ac258951dfcc4d9e > > Mark qt5_use_modules as obsolete. > > Forward-port of cb7f32f5b861fe115fa71f64500a5cbb0b643f1b (Mark > qt4_use_modules and qt4_automoc as obsolete., 2013-07-04) from > cmake.git. > > But it appears that in the 5 years since we deprecated it, people have not > stopped using it. Did we have to remove it? Or should we have kept > compatibility until Qt 6? Heya Thiago, thanks for bringing this up on the mailing list. I have authored the patch which (also) removed qt5_use_modules(). To my excuse, I haven't expected that so many projects still use said macro actively. I was maybe misguided by my perception from the KDE world; where most projects have used to using target_link_libraries(...). I understand that the removal of qt5_use_modules() creates tons of unnecessary extra work for distro and project maintainers. I would lean towards restoring qt5_use_modules() in Qt 5.11.1 (and keep it for the Qt5 lifetime). But I'd leave the other removals of 02ed1b36daebed5f3997bb676cf5e818c0db9d3c (mainly removal of support of older CMake versions) intact. Agreed? If so I'll file a patch soon-ish. PS: Regarding the motivation for such changes: Obviously I don't want to make other ppl's life more difficult -- but the CMake support in Qt5 has grown tons of fallback or compat code over the years which makes it very hard to improve it. We ideally should try to get rid off this in order to move forward. CMake has learned a lot throughout the years but in Qt's CMake support code there were and still are lots of places where we try to mimic what CMake supports out of the box since years. Regards, Kevin > Just look at the failures in > https://build.opensuse.org/project/monitor/openSUSE:Factory? > arch_x86_64=1&defaults=0&failed=1&repo_standard=1 > > The majority of them are caused by the Qt 5.11 update, a great number of > which are the cmake update (the rest are indirect header dependency and are > easy to fix). -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Fri Jun 8 17:10:12 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 08 Jun 2018 08:10:12 -0700 Subject: [Development] Did we have to remove cmake's qt5_use_modules? In-Reply-To: <46325627.KDqyftmYMq@kerberos> References: <2825593.EUdpXDWLPV@tjmaciei-mobl1> <46325627.KDqyftmYMq@kerberos> Message-ID: <1910009.gOkEypsziS@tjmaciei-mobl1> On Friday, 8 June 2018 07:59:10 PDT Kevin Funk wrote: > I would lean towards restoring qt5_use_modules() in Qt 5.11.1 (and keep it > for the Qt5 lifetime). But I'd leave the other removals of > 02ed1b36daebed5f3997bb676cf5e818c0db9d3c (mainly removal of support of older > CMake versions) intact. > > Agreed? If so I'll file a patch soon-ish. I think it makes sense. This doesn't look like a simple change. The missing #includes is a known issue and even then I looked at what caused the issue for QButtonGroup and QAction. I can't find the relevant change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at qt.io Fri Jun 8 17:20:42 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 8 Jun 2018 15:20:42 +0000 Subject: [Development] Did we have to remove cmake's qt5_use_modules? In-Reply-To: <3nvkhdh1pubhlqb0g72ilh9ldv2g2vrm81@4ax.com> References: <2825593.EUdpXDWLPV@tjmaciei-mobl1> <3nvkhdh1pubhlqb0g72ilh9ldv2g2vrm81@4ax.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > [...] > The Qt promise is to maintain not only source code, but upward binary > compatibility until a major version. > > When said promise is broken immediately after a major version release, as it > was the case just after Qt5 release to fix an oversight, this is not harmful. > > When it happens years after release, and this is indeed the case here for > deprecated modules, and was also the case with the switch away from Webkit, > it can be a major problem not just for distributions, but for many projects that > depend on it and did not budget a major change. Overall I do think we're on the very conservative side when it comes to removing things. We're still dragging modules along that were deprecated in Qt 5.0 already ... Qt WebKit was somewhat special in that a) it was quite big, and b) it's often used in a security critical setup. But eventually Konstantin volunteered to revive qtwebkit, so I guess it's ok now? > To maintain source and binary compatibility, deprecated modules should not > be removed until QT6. I do not even understand why there is a debate about > this. Note that the case in question is about deprecated functionality in the build system, not about removing any Qt modules. So the BC guarantee doesn't apply here. Kai From thiago.macieira at intel.com Fri Jun 8 22:10:12 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 8 Jun 2018 13:10:12 -0700 Subject: [Development] QtCS 2018: Third-party and security policy Message-ID: <4239021.ne1AJgac5Z@tjmaciei-mobl1> There's a session scheduled for Monday (unless it gets moved). Here's what I will propose. 0) Where not really necessary, delete the third-party code and force the use of a system library (see assimp discussion, can be applied to qtimageformats too). 1) Third-party bundled should be opt-in, not opt-out. That is, the system library always takes precedence, if found. 2) Qt Project sources always ship the latest third-party sources available one week before the Qt release. The grace period is just so that we can release the RC that passed QA. Every feature release receives updates to the latest and greatest upstream; every patch release receives updates in the same patch- series by upstream, if such exists. Release Management will put this as a P1 requirement for the release, like the changelog, header check, BC check, etc. 3) Qt Project sources receive a patch for a security fix in a library that cannot be built as a system library. That's the case of the bundled FreeBSD sources or TinyCBOR or right now with Qt Creator's sqlite. We do this within one week of the fix, even if it is high Summer in Finland. All releases after this point will contain the patched version. 4) No patches are necessarily issued for fixes to libraries that can be used as system libraries. But all releases from that point on will be patched. 5) Qt Project binaries containing third-party code are re-released every time the code has a fix for a CVE that isn't in what we're shipping. We do this within one week of the fix, same conditions. Note this applies to the "gnuwin32" dir in qt5.git too. 6) Each third-party bundled library must have an official maintainer and one deputy who know how to update it and are tracking that library's security advisories. They'll both be added to the Qt Security Team. They have to inform the Security Team if they are going to be completely unavailable for more than a week. If both are going to be unavailable, they need to ensure there's someone who is tracking the library. Corollary: existing code that cannot meet this requirement will be deleted from the Qt Project sources. I know this is harsh, but I think it's necessary. Let's discuss on Monday to see if there's any solution I've missed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From szehowe.koh at gmail.com Sat Jun 9 11:46:08 2018 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Sat, 9 Jun 2018 17:46:08 +0800 Subject: [Development] Is Qt for Automation available under GPLv3? In-Reply-To: References: Message-ID: On Fri, 8 Jun 2018 at 14:52, Frank Meerkötter wrote: > Hi, > > I would like to point out that Qt OPC UA, which is part of Qt for > Automation, can also be built with an LGPLv3 license as long as the > open62541 backend is used. > > Regards, > Frank Thanks for your clarifications, Alex and Frank. Thanks also to Leena for swiftly updating the documentation: https://codereview.qt-project.org/#/c/231875/ Just to check my understanding: Is "Qt for Automation" essentially a package/bundle that contains the following modules and their dependencies? * Qt Virtual Keyboard * Qt Quick Controls 2 * Qt Quick Compiler * Qt WebEngine * Qt Serial Bus * Qt Quick WebGL Streaming plugin * Qt MQTT * Qt KNX * Qt OPC UA Is there any special tooling (other than what's already available with the pre-built Qt Creator)? Regards, Sze-Howe > Am 08.06.2018 um 07:50 schrieb Alex Blasche: > > Hi, > > > > There are no binaries for open source users. However open source users are free to build their own binaries using GPLv3. > > > > -- > > Alex > > > > ________________________________________ > > From: Development on behalf of Sze Howe Koh > > Sent: Thursday, 7 June 2018 3:48:53 PM > > To: Qt development mailing list > > Subject: [Development] Is Qt for Automation available under GPLv3? > > > > Hello, > > > > According to http://doc.qt.io/QtForAutomation/qtautomation-install.html > > Qt for Automation is available under GPLv3. However, the installation > > instructions are not valid for open-source users. Furthermore, that > > page also says that Qt for Automation is built on Qt for Device > > Creation, which is commercial-only. > > > > Users are confused by that page: > > * https://forum.qt.io/topic/91042/how-to-install-qt-for-automation > > * https://forum.qt.io/topic/91439/no-option-to-install-qt-for-automation-in-the-online-installer > > > > Please resolve. > > > > > > Regards, > > Sze-Howe From Marco.Bubke at qt.io Sat Jun 9 17:38:46 2018 From: Marco.Bubke at qt.io (EXT Marco Bubke) Date: Sat, 9 Jun 2018 15:38:46 +0000 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <4239021.ne1AJgac5Z@tjmaciei-mobl1> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> Message-ID: On June 9, 2018 04:10:58 Thiago Macieira wrote: > There's a session scheduled for Monday (unless it gets moved). Here's what I > will propose. > > 0) Where not really necessary, delete the third-party code and force the use > of a system library (see assimp discussion, can be applied to qtimageformats > too). > > 1) Third-party bundled should be opt-in, not opt-out. That is, the system > library always takes precedence, if found. This is really problematic in the Sqlite case as an embedded library. An embedded library is meant to be customized to an application. Actually this whole process looks like it is customized to an server based world and much less to an embedded world. So what about some embedded scenario. What is a system library in that sense. If people ship their own binary it's not part of Qt anymore. So it's their problem but for the user it's still a problem and by a high probability you introduced an out dated library. Would it not be better to ship it as part of Qt in that context to make the life of the embedded developer easier? > 2) Qt Project sources always ship the latest third-party sources available one > week before the Qt release. The grace period is just so that we can release > the RC that passed QA. Every feature release receives updates to the latest > and greatest upstream; every patch release receives updates in the same patch- > series by upstream, if such exists. Release Management will put this as a P1 > requirement for the release, like the changelog, header check, BC check, etc. > > 3) Qt Project sources receive a patch for a security fix in a library that > cannot be built as a system library. That's the case of the bundled FreeBSD > sources or TinyCBOR or right now with Qt Creator's sqlite. We do this within > one week of the fix, even if it is high Summer in Finland. All releases after > this point will contain the patched version. That is a security fix? If there is an securifix for Sqlite but this not applicable for Qt Creator, should any action be taken? Actually it is hard to imagine any security related problem in this context. We should follow here a reasonable instead of a fundamental approach. In that sense we should distinguish between different Qt Project software packages. > > 4) No patches are necessarily issued for fixes to libraries that can be used > as system libraries. But all releases from that point on will be patched. > > 5) Qt Project binaries containing third-party code are re-released every time > the code has a fix for a CVE that isn't in what we're shipping. We do this > within one week of the fix, same conditions. Note this applies to the > "gnuwin32" dir in qt5.git too. > > 6) Each third-party bundled library must have an official maintainer and one > deputy who know how to update it and are tracking that library's security > advisories. They'll both be added to the Qt Security Team. They have to inform > the Security Team if they are going to be completely unavailable for more than > a week. If both are going to be unavailable, they need to ensure there's > someone who is tracking the library. > Corollary: existing code that cannot meet this requirement will be > deleted from the Qt Project sources. > > I know this is harsh, but I think it's necessary. Let's discuss on Monday to > see if there's any solution I've missed. > -- > 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 Sat Jun 9 23:02:56 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 09 Jun 2018 22:02:56 +0100 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> Message-ID: <2236481.Cv7qdxPlN9@tjmaciei-mobl1> On Saturday, 9 June 2018 16:38:46 IST EXT Marco Bubke wrote: > So what about some embedded scenario. What is a system library in that > sense. If people ship their own binary it's not part of Qt anymore. So it's > their problem but for the user it's still a problem and by a high > probability you introduced an out dated library. Would it not be better to > ship it as part of Qt in that context to make the life of the embedded > developer easier? We'll talk about it on Monday, as this is also the case for TinyCBOR. I designed it so it would be #include'd in other sources. > > 3) Qt Project sources receive a patch for a security fix in a library that > > cannot be built as a system library. That's the case of the bundled > > FreeBSD > > sources or TinyCBOR or right now with Qt Creator's sqlite. We do this > > within one week of the fix, even if it is high Summer in Finland. All > > releases after this point will contain the patched version. > > That is a security fix? If there is an securifix for Sqlite but this not > applicable for Qt Creator, should any action be taken? Actually it is hard > to imagine any security related problem in this context. We should follow > here a reasonable instead of a fundamental approach. In that sense we > should distinguish between different Qt Project software packages. Good points for discussion. I'll forego giving my comments now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Sun Jun 10 19:17:31 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 10 Jun 2018 19:17:31 +0200 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <4239021.ne1AJgac5Z@tjmaciei-mobl1> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> Message-ID: <059afdcd-d49a-9470-122d-69f3b53eebe5@kdab.com> Hi Thiago, thanks for starting these conversations on the mailing list. I'll miss this QtCS, so this is great for me and for whomever else won't be able to attend. Il 08/06/2018 22:10, Thiago Macieira ha scritto: > There's a session scheduled for Monday (unless it gets moved). Here's what I > will propose. > > 0) Where not really necessary, delete the third-party code and force the use > of a system library (see assimp discussion, can be applied to qtimageformats > too). What's the definition of "necessary" here? We're having several variations of 3rd party code (list probably not complete): * code that got "extracted" from upstream libraries (e.g. strtoll-like functions from FreeBSD), and most importantly doesn't exist in a suitably packaged format; * libraries that received heavy modifications by Qt (this used to be the case for harfbuzz-ng, not sure if it's still like that) and thus, the upstream version simply isn't usable as-is (we might even say that there isn't an upstream version); * libraries that are usable from upstream, but of which we require a version so recent that it's not included in major distributions (e.g. this used to be the case for PCRE2, it's probably still the case for some XCB code). This opens the can of worms of defining which distributions to include in this definiton (for Linux, I'd include only LTS distributions: latest Debian stable, RHEL latest+latest devtoolset, latest Ubuntu LTS, ...; also, on non-Linux, one has to check things like vcpkg / choco on Windows and homebrew on macOS). * libraries that are usable as-is from upstream and of which there's a reasonably recent version available in major distributions. On an orthogonal level, we also need to classify the usage of our library * we can't build without it * we can build without it, but this would disable this feature of importance X Should we build this sort of matrix? > > 1) Third-party bundled should be opt-in, not opt-out. That is, the system > library always takes precedence, if found. Isn't this already the current behaviour of Qt's configure scripts? > > 2) Qt Project sources always ship the latest third-party sources available one > week before the Qt release. The grace period is just so that we can release > the RC that passed QA. Every feature release receives updates to the latest > and greatest upstream; every patch release receives updates in the same patch- > series by upstream, if such exists. Release Management will put this as a P1 > requirement for the release, like the changelog, header check, BC check, etc. One week before the Qt release or one week before the RC? In other words if a library gets an update after the RC is released, and the update isn't related to any security issue, what do we do? > > 3) Qt Project sources receive a patch for a security fix in a library that > cannot be built as a system library. That's the case of the bundled FreeBSD > sources or TinyCBOR or right now with Qt Creator's sqlite. We do this within > one week of the fix, even if it is high Summer in Finland. All releases after > this point will contain the patched version. This requires a commitment above my powers.. > 4) No patches are necessarily issued for fixes to libraries that can be used > as system libraries. But all releases from that point on will be patched. > > 5) Qt Project binaries containing third-party code are re-released every time > the code has a fix for a CVE that isn't in what we're shipping. We do this > within one week of the fix, same conditions. Note this applies to the > "gnuwin32" dir in qt5.git too. Re-released keeping the same version of Qt? And which binaries are re-released, the ones currently supported (e.g. right now 5.6.latest, 5.9.latest, 5.11.latest)? > > 6) Each third-party bundled library must have an official maintainer and one > deputy who know how to update it and are tracking that library's security > advisories. They'll both be added to the Qt Security Team. They have to inform > the Security Team if they are going to be completely unavailable for more than > a week. If both are going to be unavailable, they need to ensure there's > someone who is tracking the library. > Corollary: existing code that cannot meet this requirement will be > deleted from the Qt Project sources. > > I know this is harsh, but I think it's necessary Mind elaborating why do you think it's necessary? Are we trying to educate Qt users to proper security policies and workflows? Are there business reasons for this (e.g. people not choosing Qt, or Qt getting a bad reputation, etc. because of our lax security policy)? Thanks, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Sun Jun 10 22:48:26 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 10 Jun 2018 21:48:26 +0100 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <059afdcd-d49a-9470-122d-69f3b53eebe5@kdab.com> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <059afdcd-d49a-9470-122d-69f3b53eebe5@kdab.com> Message-ID: <3519150.er6nee5kCn@tjmaciei-mobl1> On Sunday, 10 June 2018 18:17:31 IST Giuseppe D'Angelo wrote: > > 0) Where not really necessary, delete the third-party code and force the > > use of a system library (see assimp discussion, can be applied to > > qtimageformats too). > > What's the definition of "necessary" here? We're having several > variations of 3rd party code (list probably not complete): > > * code that got "extracted" from upstream libraries (e.g. strtoll-like > functions from FreeBSD), and most importantly doesn't exist in a > suitably packaged format; That's necessary. > * libraries that received heavy modifications by Qt (this used to be the > case for harfbuzz-ng, not sure if it's still like that) and thus, the > upstream version simply isn't usable as-is (we might even say that there > isn't an upstream version); That's also necessary, but we should strive harder to upstream those changes so we can have an option. > * libraries that are usable from upstream, but of which we require a > version so recent that it's not included in major distributions (e.g. > this used to be the case for PCRE2, it's probably still the case for > some XCB code). Those two are necessary. But as a counter example, libdouble-conversion was needed at a recent version, but could be disabled, if certain other system functions were present. Unfortunately, they're not on Linux. > This opens the can of worms of defining which distributions to include > in this definiton (for Linux, I'd include only LTS distributions: latest > Debian stable, RHEL latest+latest devtoolset, latest Ubuntu LTS, ...; > also, on non-Linux, one has to check things like vcpkg / choco on > Windows and homebrew on macOS). Right, those are points for consideration. > On an orthogonal level, we also need to classify the usage of our library > > * we can't build without it > * we can build without it, but this would disable this feature of > importance X That's my point above. If we can't build without it, then it's necessary. If we can build without it, we could disable it. For example, we can build without XCB. Do we want to? On the other hand, which distribution doesn't have it? > Should we build this sort of matrix? > > > 1) Third-party bundled should be opt-in, not opt-out. That is, the system > > library always takes precedence, if found. > > Isn't this already the current behaviour of Qt's configure scripts? No. > > 2) Qt Project sources always ship the latest third-party sources available > > one week before the Qt release. The grace period is just so that we can > > release the RC that passed QA. Every feature release receives updates to > > the latest and greatest upstream; every patch release receives updates in > > the same patch- series by upstream, if such exists. Release Management > > will put this as a P1 requirement for the release, like the changelog, > > header check, BC check, etc. > One week before the Qt release or one week before the RC? In other words > if a library gets an update after the RC is released, and the update > isn't related to any security issue, what do we do? One week before release. That is, if there's a new release by upstream the same day we released an RC, then we will need a new RC. If it's updated after the RC is released and the released RC is not going to be rev'ed by other reasons, then we don't update. Regardless of reason why upstream released. They're fixing bugs and not all security-worthy bugfixes are noted as such. > > 3) Qt Project sources receive a patch for a security fix in a library that > > cannot be built as a system library. That's the case of the bundled > > FreeBSD > > sources or TinyCBOR or right now with Qt Creator's sqlite. We do this > > within one week of the fix, even if it is high Summer in Finland. All > > releases after this point will contain the patched version. > > This requires a commitment above my powers.. I know. That's why I am bringing this to QtCS. I am setting the bar high enough so that new maintenance of third-party code is unwelcome enough that people will not do it. Right now, it's too easy to import some code into src/3rdparty and forget about it. We can't have that. > > 5) Qt Project binaries containing third-party code are re-released every > > time the code has a fix for a CVE that isn't in what we're shipping. We Read: for a CVE that *is* in what we're shipping. I meant to say that if the particular line of code is not compiled, then we don't need to go through this process. But prove you didn't compile it (such as .c source not listed in SOURCES). This excludes "Qt can't reach that code but it was compiled" because people do crazy things, like calling into those libraries supplied with Qt directly from their code. > > do this within one week of the fix, same conditions. Note this applies to > > the "gnuwin32" dir in qt5.git too. > > Re-released keeping the same version of Qt? And which binaries are > re-released, the ones currently supported (e.g. right now 5.6.latest, > 5.9.latest, 5.11.latest)? Everything affected and supported in whichever way is easiest to re-release. If we have an RC for a new patch release ready to go, then so be it. If we need to apply the patch and release a "5.11.0-2", then we do that. (we can do dashes in binary releases) So you're right: if an issue is found affecting the code in 5.6 and 5.9, but not 5.11 because 5.11 has a new enough copy, then we rebuild 5.6 and 5.9. > > 6) Each third-party bundled library must have an official maintainer and > > one deputy who know how to update it and are tracking that library's > > security advisories. They'll both be added to the Qt Security Team. They > > have to inform the Security Team if they are going to be completely > > unavailable for more than a week. If both are going to be unavailable, > > they need to ensure there's someone who is tracking the library. > > > > Corollary: existing code that cannot meet this requirement will be > > deleted from the Qt Project sources. > > > > I know this is harsh, but I think it's necessary > > Mind elaborating why do you think it's necessary? Are we trying to > educate Qt users to proper security policies and workflows? Are there > business reasons for this (e.g. people not choosing Qt, or Qt getting a > bad reputation, etc. because of our lax security policy)? I meant the harshness about the deleting of sources no one maintains and no one knows how to update, as well as the need to track CVEs. If we don't track CVEs, we may be shipping code that is vulnerable and not know it. I'm not trying to educate users. If someone downstream from us has more lax policies, it's their business. It's their liability if something happens. My problem is those downstream who have more strict policies. Our not complying to them could mean Qt cannot be used. It could mean loss of business, but I of course can't get into details here. It's possible to not be so strict inside Qt and also comply with strict security policies downstream if the code in question is a system library or if we issue a parallel CVE every time the non-unbundleable code we ship is affected. This allows downstreams to apply the fix, even if we don't. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexander.blasche at qt.io Mon Jun 11 09:54:23 2018 From: alexander.blasche at qt.io (EXT Alex Blasche) Date: Mon, 11 Jun 2018 07:54:23 +0000 Subject: [Development] Is Qt for Automation available under GPLv3? In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Sze Howe Koh > On Fri, 8 Jun 2018 at 14:52, Frank Meerkötter > wrote: > > Hi, > > > > I would like to point out that Qt OPC UA, which is part of Qt for > > Automation, can also be built with an LGPLv3 license as long as the > > open62541 backend is used. > > > > Regards, > > Frank > > Thanks for your clarifications, Alex and Frank. Thanks also to Leena for swiftly > updating the documentation: > https://codereview.qt-project.org/#/c/231875/ > > Just to check my understanding: Is "Qt for Automation" essentially a > package/bundle that contains the following modules and their dependencies? > > * Qt Virtual Keyboard > * Qt Quick Controls 2 > * Qt Quick Compiler > * Qt WebEngine > * Qt Serial Bus > * Qt Quick WebGL Streaming plugin > * Qt MQTT > * Qt KNX > * Qt OPC UA These are software solutions addressing Automation related needs. From a marketing/solution perspective this grouping makes sense. On the technical side, only the last three are part of the Qt Automation package/release. All other modules are part of Qt itself. > Is there any special tooling (other than what's already available with the pre- > built Qt Creator)? Note at this stage. -- Alex From Eike.Ziller at qt.io Mon Jun 11 10:56:42 2018 From: Eike.Ziller at qt.io (EXT Eike Ziller) Date: Mon, 11 Jun 2018 08:56:42 +0000 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <3519150.er6nee5kCn@tjmaciei-mobl1> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <059afdcd-d49a-9470-122d-69f3b53eebe5@kdab.com> <3519150.er6nee5kCn@tjmaciei-mobl1> Message-ID: <2911AACC-F53B-41F2-9033-863A351FB74A@qt.io> > On 10. Jun 2018, at 22:48, Thiago Macieira wrote: > > On Sunday, 10 June 2018 18:17:31 IST Giuseppe D'Angelo wrote: >>> 0) Where not really necessary, delete the third-party code and force the >>> use of a system library (see assimp discussion, can be applied to >>> qtimageformats too). >> >> What's the definition of "necessary" here? We're having several >> variations of 3rd party code (list probably not complete): >> >> * code that got "extracted" from upstream libraries (e.g. strtoll-like >> functions from FreeBSD), and most importantly doesn't exist in a >> suitably packaged format; > > That's necessary. > >> * libraries that received heavy modifications by Qt (this used to be the >> case for harfbuzz-ng, not sure if it's still like that) and thus, the >> upstream version simply isn't usable as-is (we might even say that there >> isn't an upstream version); > > That's also necessary, but we should strive harder to upstream those changes > so we can have an option. > >> * libraries that are usable from upstream, but of which we require a >> version so recent that it's not included in major distributions (e.g. >> this used to be the case for PCRE2, it's probably still the case for >> some XCB code). > > Those two are necessary. But as a counter example, libdouble-conversion was > needed at a recent version, but could be disabled, if certain other system > functions were present. Unfortunately, they're not on Linux. > >> This opens the can of worms of defining which distributions to include >> in this definiton (for Linux, I'd include only LTS distributions: latest >> Debian stable, RHEL latest+latest devtoolset, latest Ubuntu LTS, ...; >> also, on non-Linux, one has to check things like vcpkg / choco on >> Windows and homebrew on macOS). > > Right, those are points for consideration. > >> On an orthogonal level, we also need to classify the usage of our library >> >> * we can't build without it >> * we can build without it, but this would disable this feature of >> importance X > > That's my point above. If we can't build without it, then it's necessary. If > we can build without it, we could disable it. > > For example, we can build without XCB. Do we want to? On the other hand, which > distribution doesn't have it? > >> Should we build this sort of matrix? >> >>> 1) Third-party bundled should be opt-in, not opt-out. That is, the system >>> library always takes precedence, if found. >> >> Isn't this already the current behaviour of Qt's configure scripts? > > No. > >>> 2) Qt Project sources always ship the latest third-party sources available >>> one week before the Qt release. The grace period is just so that we can >>> release the RC that passed QA. Every feature release receives updates to >>> the latest and greatest upstream; every patch release receives updates in >>> the same patch- series by upstream, if such exists. Release Management >>> will put this as a P1 requirement for the release, like the changelog, >>> header check, BC check, etc. >> One week before the Qt release or one week before the RC? In other words >> if a library gets an update after the RC is released, and the update >> isn't related to any security issue, what do we do? > > One week before release. That is, if there's a new release by upstream the > same day we released an RC, then we will need a new RC. If it's updated after > the RC is released and the released RC is not going to be rev'ed by other > reasons, then we don't update. > > Regardless of reason why upstream released. They're fixing bugs And introducing new ones, potentially including security bugs. I think just updating to a new version regardless of reasons is a bad idea. A delay of the release because of an 3rd-party update also has the potential to create a cascading required update effect. Take an example for Qt Creator: If we are about to release Qt Creator with LLVM/Clang 6.0, and LLVM/Clang 6.1 is released, this has good chances to introduce bugs. Aside from that, updating the binaries that we ship is an effort, since they are profile optimized etc etc. If instead LLVM/Clang 7.0 should be released, Qt Creator might not even compile anymore. The probability that some functionality is broken increases even more. After we fix all these issues (it’s 1-2 weeks later now than the original schedule), a new version of sqlite is released. > and not all > security-worthy bugfixes are noted as such. > >>> 3) Qt Project sources receive a patch for a security fix in a library that >>> cannot be built as a system library. That's the case of the bundled >>> FreeBSD >>> sources or TinyCBOR or right now with Qt Creator's sqlite. We do this >>> within one week of the fix, even if it is high Summer in Finland. All >>> releases after this point will contain the patched version. >> >> This requires a commitment above my powers.. > > I know. That's why I am bringing this to QtCS. > > I am setting the bar high enough so that new maintenance of third-party code > is unwelcome enough that people will not do it. Right now, it's too easy to > import some code into src/3rdparty and forget about it. We can't have that. > >>> 5) Qt Project binaries containing third-party code are re-released every >>> time the code has a fix for a CVE that isn't in what we're shipping. We > > Read: for a CVE that *is* in what we're shipping. I meant to say that if the > particular line of code is not compiled, then we don't need to go through this > process. But prove you didn't compile it (such as .c source not listed in > SOURCES). This excludes "Qt can't reach that code but it was compiled" because > people do crazy things, like calling into those libraries supplied with Qt > directly from their code. > >>> do this within one week of the fix, same conditions. Note this applies to >>> the "gnuwin32" dir in qt5.git too. >> >> Re-released keeping the same version of Qt? And which binaries are >> re-released, the ones currently supported (e.g. right now 5.6.latest, >> 5.9.latest, 5.11.latest)? > > Everything affected and supported in whichever way is easiest to re-release. > If we have an RC for a new patch release ready to go, then so be it. If we > need to apply the patch and release a "5.11.0-2", then we do that. (we can do > dashes in binary releases) > > So you're right: if an issue is found affecting the code in 5.6 and 5.9, but > not 5.11 because 5.11 has a new enough copy, then we rebuild 5.6 and 5.9. > >>> 6) Each third-party bundled library must have an official maintainer and >>> one deputy who know how to update it and are tracking that library's >>> security advisories. They'll both be added to the Qt Security Team. They >>> have to inform the Security Team if they are going to be completely >>> unavailable for more than a week. If both are going to be unavailable, >>> they need to ensure there's someone who is tracking the library. >>> >>> Corollary: existing code that cannot meet this requirement will be >>> deleted from the Qt Project sources. >>> >>> I know this is harsh, but I think it's necessary >> >> Mind elaborating why do you think it's necessary? Are we trying to >> educate Qt users to proper security policies and workflows? Are there >> business reasons for this (e.g. people not choosing Qt, or Qt getting a >> bad reputation, etc. because of our lax security policy)? > > I meant the harshness about the deleting of sources no one maintains and no > one knows how to update, as well as the need to track CVEs. If we don't track > CVEs, we may be shipping code that is vulnerable and not know it. > > I'm not trying to educate users. If someone downstream from us has more lax > policies, it's their business. It's their liability if something happens. > > My problem is those downstream who have more strict policies. Our not > complying to them could mean Qt cannot be used. It could mean loss of > business, but I of course can't get into details here. > > It's possible to not be so strict inside Qt and also comply with strict > security policies downstream if the code in question is a system library or if > we issue a parallel CVE every time the non-unbundleable code we ship is > affected. This allows downstreams to apply the fix, even if we don't. > > -- > 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 -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From thiago.macieira at intel.com Mon Jun 11 13:17:00 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 11 Jun 2018 13:17:00 +0200 Subject: [Development] QtCS 2018 - Serialisation session notes Message-ID: <5839774.zNMdgMTLy9@tjmaciei-mobl1> Link: https://wiki.qt.io/QtCS2018_Serialisation === Binary JSON === * Was created for qtjsondb * fast reading * mmap()able * Deprecate soon (Qt 5.12?) ** Remove from QJsonDocument in Qt 6 ** Provide compat API to read *** BSJON → JSON → parse again === QJsonDocument === * Limited to 128 MB of RAM footprint (due to Binary JSON) * Needs to be fixed before Qt 6 * Can use the same backend as QCborValue * Complaint: updating in-place is not easy ** If you update an entry in a node, you have to update the chain leading to it ** QCborValue has the same problem, as it was designed to have the same API QJsonValue foo = ...; foo["s"] = "value"; // does not compile foo.toObject()["s"] = "value"; // updates the temporary! // must write instead: QJsonObject fooObject = foo.toObject(); fooObject["s"] = "value"; setFoo(fooObject); === Common DOM API? === * Should we have a common API for manipulating trees of JSON-like values? * QCborValue is a superset of QJsonValue ** But it would be confusing to users to use CBOR classes to manipulate JSON ** Generic name? * What other uses would this API have? ** Replace QJSValue (QtQml)? ** Replace QVariantMap? ** Entry point for a Protobuf API? * How to make sure people can't insert combinations not allowed in the output? ** For example, associative containers using integers as keys in JSON ** Do they do that? Maybe they won't write such code *** They know what their content is used for ** We could use templates, specialising for CBOR, JSON, etc. ** We could have a wrapper class that has inlines and provides only the possible combinations * QCborValue integrated last Friday into QtCore 5.12 ** Need to know in the next few weeks if we keep it for 5.12 ** Can yank it out and move to a new module for Tech Preview === Serialising Qt state === * Needed by Qt Remote Objects * Slightly different from CBOR and JSON purposes ** Not about a standardised representation of a data model ** More about transmitting state from two independent processes of the same application * Currently using QDataStream ** Has a lot of problems, can't really detect errors and not extensible enough * Need more exploration, no conclusion === Protobuf === * Need volunteers to write a Proof of Concept ** plugin to protoc? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jun 11 13:18:13 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 11 Jun 2018 13:18:13 +0200 Subject: [Development] QtCS 2018: Third-party and security policy In-Reply-To: <2911AACC-F53B-41F2-9033-863A351FB74A@qt.io> References: <4239021.ne1AJgac5Z@tjmaciei-mobl1> <3519150.er6nee5kCn@tjmaciei-mobl1> <2911AACC-F53B-41F2-9033-863A351FB74A@qt.io> Message-ID: <109198973.Zd6vTh2GyC@tjmaciei-mobl1> On Monday, 11 June 2018 10:56:42 CEST EXT Eike Ziller wrote: > If we are about to release Qt Creator with LLVM/Clang 6.0, and LLVM/Clang > 6.1 is released, this has good chances to introduce bugs. Aside from that, > updating the binaries that we ship is an effort, since they are profile > optimized etc etc. If instead LLVM/Clang 7.0 should be released, Qt Creator > might not even compile anymore. The probability that some functionality is > broken increases even more. After we fix all these issues (it’s 1-2 weeks > later now than the original schedule), a new version of sqlite is released. Good point about chasing a moving target. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From cavendish.qi at gmail.com Mon Jun 11 13:23:21 2018 From: cavendish.qi at gmail.com (Liang Qi) Date: Mon, 11 Jun 2018 13:23:21 +0200 Subject: [Development] QtCS 2018 - Serialisation session notes In-Reply-To: <5839774.zNMdgMTLy9@tjmaciei-mobl1> References: <5839774.zNMdgMTLy9@tjmaciei-mobl1> Message-ID: On Mon, 11 Jun 2018 at 13:17, Thiago Macieira wrote: > Link: https://wiki.qt.io/QtCS2018_Serialisation > > === Protobuf === > > * Need volunteers to write a Proof of Concept > ** plugin to protoc? > > About protobuf support in Qt, I have an old WIP change at https://codereview.qt-project.org/#/c/205316/ . But not sure whether it can help here or not. Best Regards, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Jun 11 13:39:07 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 11 Jun 2018 13:39:07 +0200 Subject: [Development] QtCS 2018 - Serialisation session notes In-Reply-To: References: <5839774.zNMdgMTLy9@tjmaciei-mobl1> Message-ID: <13298173.WA0eDHNfb7@tjmaciei-mobl1> On Monday, 11 June 2018 13:23:21 CEST Liang Qi wrote: > On Mon, 11 Jun 2018 at 13:17, Thiago Macieira > > wrote: > > Link: https://wiki.qt.io/QtCS2018_Serialisation > > > > === Protobuf === > > > > * Need volunteers to write a Proof of Concept > > ** plugin to protoc? > > > > About protobuf support in Qt, I have an old WIP change at > > https://codereview.qt-project.org/#/c/205316/ . But not sure whether it can > help here or not. The point is that I want a proof of concept of what can be done. There can be two objectives: 1) protobuf is an implementation detail We use it to transport Qt state, but it's not exposed in the API 2) protobuf is an objective Communication with another endpoint (non-Qt) that uses the same Protobuf IDL Either might be an interesting addition to Qt. I'd like to see an exploration of the possibilities and what limitations would turn up. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Mon Jun 11 13:47:01 2018 From: jani.heikkinen at qt.io (EXT Jani Heikkinen) Date: Mon, 11 Jun 2018 11:47:01 +0000 Subject: [Development] Qt 5.9.6 and Qt Creator 4.6.2 released Message-ID: Hi, We have released Qt 5.9.6 and Qt Creator 4.6.2 today. Please read blog posts to get more information: http://blog.qt.io/blog/2018/06/11/qt-5-9-6-released/ and http://blog.qt.io/blog/2018/06/11/qt-creator-4-6-2-released/ Thanks to everyone involved! br, Jani Heikkinen Release Manager From thiago.macieira at intel.com Mon Jun 11 14:59:55 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 11 Jun 2018 14:59:55 +0200 Subject: [Development] QtCS 2018 - Date/time session Message-ID: <2065253.K3EpsGvngf@tjmaciei-mobl1> Link: https://wiki.qt.io/QtCS2018_Date_Time Howard Hinnant's new civil calendar and timezone proposals have made it to the C++ 20 draft (N4750) * Not implemented yet in any C++ Standard Library === Time Zone === * Why would we use this, if we have to keep our existing code? ** Allows us to hook to a standard tzdb implementation without forcing an ICU dependency ** Good for Windows (MS doesn't want us to use the registry DB anyway) ** Good for iOS (no need for Apple's ICU-wrapper API) * Can it be used without exceptions? * We should add a backend for it when we can ** Drop unneeded backends === Front-end API === * What do we do for QDate and QTime? ** We should add conversion API for the new types as soon as we can ** QT_HAS_INCLUDE(), like QDeadlineTimer does for std::chrono::duration and std::chrono::time_point * Is there anything missing in C++20 draft which would prevent a QDateTime refactor in the 2020s? ** (Keeping QDateTime convenience API but replace the QDateTimePrivate backend) ** Eddy is working with Howard to make sure everything is there * Compilers don't have this yet, but should have it in 2019 or early 2020 ** But we don't think we can reimplement QDateTime using date.h for Qt 6 ** Too close to call, regarding BC guarantees * Review QDateTime API: ** Anything we want to deprecate anyway? ** Anything that would be difficult to implement with date.h and we'd want to provide different API for? === Calendar systems === * Didn't have enough time to discuss this * We have a contribution for QAbstractCalendar ** We need a solution that enables code outside of Qt to implement their own calendars -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rafael.roquetto at kdab.com Mon Jun 11 22:50:09 2018 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Tue, 12 Jun 2018 06:50:09 +1000 Subject: [Development] QtCS 2018 - Serialisation session notes In-Reply-To: <13298173.WA0eDHNfb7@tjmaciei-mobl1> References: <5839774.zNMdgMTLy9@tjmaciei-mobl1> <13298173.WA0eDHNfb7@tjmaciei-mobl1> Message-ID: <20180611205007.GB27957@polaris.localdomain> On Mon, Jun 11, 2018 at 01:39:07PM +0200, Thiago Macieira wrote: > On Monday, 11 June 2018 13:23:21 CEST Liang Qi wrote: > > On Mon, 11 Jun 2018 at 13:17, Thiago Macieira > > > > wrote: > > > Link: https://wiki.qt.io/QtCS2018_Serialisation > > > > > > === Protobuf === > > > > > > * Need volunteers to write a Proof of Concept > > > ** plugin to protoc? > > > > > > About protobuf support in Qt, I have an old WIP change at > > > > https://codereview.qt-project.org/#/c/205316/ . But not sure whether it can > > help here or not. > > The point is that I want a proof of concept of what can be done. > > There can be two objectives: > > 1) protobuf is an implementation detail > We use it to transport Qt state, but it's not exposed in the API > > 2) protobuf is an objective > Communication with another endpoint (non-Qt) that uses the same Protobuf IDL > > Either might be an interesting addition to Qt. I'd like to see an exploration > of the possibilities and what limitations would turn up. Would it also make sense to explore msgpack? https://msgpack.org/ I haven't attended to QtCS so please disregard if this does not make sense. > > -- > 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 -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Jun 12 00:41:38 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 12 Jun 2018 00:41:38 +0200 Subject: [Development] QtCS 2018 - Serialisation session notes In-Reply-To: <20180611205007.GB27957@polaris.localdomain> References: <5839774.zNMdgMTLy9@tjmaciei-mobl1> <13298173.WA0eDHNfb7@tjmaciei-mobl1> <20180611205007.GB27957@polaris.localdomain> Message-ID: <8451151.YxzRa4OLOy@tjmaciei-mobl1> On Monday, 11 June 2018 22:50:09 CEST Rafael Roquetto wrote: > Would it also make sense to explore msgpack? https://msgpack.org/ No. Msgpack is the older version of CBOR, which we already have. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Tue Jun 12 01:01:51 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Mon, 11 Jun 2018 20:01:51 -0300 Subject: [Development] Did we have to remove cmake's qt5_use_modules? In-Reply-To: <46325627.KDqyftmYMq@kerberos> References: <2825593.EUdpXDWLPV@tjmaciei-mobl1> <46325627.KDqyftmYMq@kerberos> Message-ID: <2005747.P1MVVVICcl@tonks> El viernes, 8 de junio de 2018 11:59:10 -03 Kevin Funk escribió: [snip] > Heya Thiago, > > thanks for bringing this up on the mailing list. I have authored the patch > which (also) removed qt5_use_modules(). To my excuse, I haven't expected > that so many projects still use said macro actively. I was maybe misguided > by my perception from the KDE world; where most projects have used to using > target_link_libraries(...). > > I understand that the removal of qt5_use_modules() creates tons of > unnecessary extra work for distro and project maintainers. > > I would lean towards restoring qt5_use_modules() in Qt 5.11.1 (and keep it > for the Qt5 lifetime). That would be much appreciated. > But I'd leave the other removals of > 02ed1b36daebed5f3997bb676cf5e818c0db9d3c (mainly removal of support of older > CMake versions) intact. I think this is safe, we normally do not expect building new Qt versions with older CMake versions in distros. I think. Thanks a lot!! -- 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 Tue Jun 12 08:39:03 2018 From: jani.heikkinen at qt.io (EXT Jani Heikkinen) Date: Tue, 12 Jun 2018 06:39:03 +0000 Subject: [Development] Maintainers, your action needed: Qt 5.11.1 changes files In-Reply-To: References: Message-ID: Hi, Really many changes file without approval. Please finalize these now to make sure we can do the release as planned br, Jani ________________________________________ From: Jani Heikkinen Sent: Friday, June 8, 2018 11:54 AM To: development at qt-project.org Cc: releasing at qt-project.org Subject: Maintainers, your action needed: Qt 5.11.1 changes files Hi, Initial ones here: https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.11.1%22,n,z Please do needed updates & get approval as soon as possible; We need to get these in soon to be able to keep our release schedule (final packages next week, release 19.6.2018) br, Jani Heikkinen Release Manager From qt at colby.id.au Tue Jun 12 23:37:37 2018 From: qt at colby.id.au (Paul Colby) Date: Tue, 12 Jun 2018 23:37:37 +0200 Subject: [Development] Thanks for the Summit Message-ID: Hi all, I just wanted to say thank you for letting me come alone to the Qt Contributors Summit! It was great to see such a strong sense of community amongst you all, and it was a pleasure to be included. Thanks! :) Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Wed Jun 13 09:03:13 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Wed, 13 Jun 2018 07:03:13 +0000 (UTC) Subject: [Development] QInputMethod woes Message-ID: Hi all, when working on our virtual keyboard I had to realize that the design of QInputMethod is inappropriate to achieve what we need: a) the input method is tied to the item having the focus We have a touch screen but also an special input device, that offers a wheel to navigate along the focus tab chain and a few buttons like 'ok'. So the virtual keyboard is part of the focus tab chain and all its buttons need to be accessible with this input device. And here is where the implemented input method concept fails - as soon as navigating inside the virtual keyboard the initial input control loses the focus and the input method gets disconnected. b) multiple screens Our application runs on several screens, where it is possible to have several virtual keyboards - one per screen - at the same time. The singleton concept of QInputMethod does not support this at all. Maybe this is worth to be put on the list for Qt6 ? Uwe From Simon.Hausmann at qt.io Wed Jun 13 09:54:50 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 13 Jun 2018 07:54:50 +0000 Subject: [Development] QInputMethod woes In-Reply-To: References: Message-ID: Hi, I would imagine that there is a way for your virtual keyboard to not hide itself if the focus object is transferred to an element of your virtual keyboard itself. That said, I haven't your code, so I can't tell for sure. But my initial guess is that this isn't an inherent design problem of the input method API. Regarding support for multiple screens I agree that the singleton design is a problem. I don't know of an easy way to work around it and I agree that this sounds like something that is worth fixing (associating input methods with screens). In the event that that requires binary incompatible changes or (more likely) changing the input method API itself - which I would say is rather low level - then that would make it something worth changing together with Qt 6. Simon ________________________________ From: Development on behalf of Uwe Rathmann Sent: Wednesday, June 13, 2018 9:03:13 AM To: development at qt-project.org Subject: [Development] QInputMethod woes Hi all, when working on our virtual keyboard I had to realize that the design of QInputMethod is inappropriate to achieve what we need: a) the input method is tied to the item having the focus We have a touch screen but also an special input device, that offers a wheel to navigate along the focus tab chain and a few buttons like 'ok'. So the virtual keyboard is part of the focus tab chain and all its buttons need to be accessible with this input device. And here is where the implemented input method concept fails - as soon as navigating inside the virtual keyboard the initial input control loses the focus and the input method gets disconnected. b) multiple screens Our application runs on several screens, where it is possible to have several virtual keyboards - one per screen - at the same time. The singleton concept of QInputMethod does not support this at all. Maybe this is worth to be put on the list for Qt6 ? Uwe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Wed Jun 13 10:07:10 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 13 Jun 2018 08:07:10 +0000 Subject: [Development] Changing maintainership for Qt Creator modules In-Reply-To: References: Message-ID: The proposed changes have been enacted. -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Eike Ziller > Sent: Wednesday, 23 May 2018 15:31 > To: Kai Koehne > Cc: development at qt-project.org > Subject: Re: [Development] Changing maintainership for Qt Creator modules > > +1. > Both are the de-facto maintainers of that code nowadays :) > > > On 23. May 2018, at 15:23, Kai Koehne wrote: > > > > Hi, > > > > I haven't actively worked on Qt Creator since a while, and would therefore like > to step down as the maintainer for the Qt Creator modules I'm still listed for in > https://wiki.qt.io/Maintainers: > > > > > > Debugging & Profiling / QML > > > > I propose Ulf Hermann as replacement. > > > > > > Project Management & Targets / QML > > > > I propose Thomas Hartmann as replacement. > > > > > > Regards > > > > Kai > > > > -- > > Kai Koehne, 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 > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Eike Ziller > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > eike.ziller at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Uwe.Rathmann at tigertal.de Wed Jun 13 11:09:46 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Wed, 13 Jun 2018 09:09:46 +0000 (UTC) Subject: [Development] QInputMethod woes References: Message-ID: Hi Simon, > But my initial guess is that this isn't an inherent design > problem of the input method API. Well, one problem is that the input context needs to know about the current item, as it has to correspond with it. But QInputMethod::show/ commit/reset/update/hide do not transfer any information about the item calling them. In case of show() all the context can do is to assume that the item having the active focus is the one to correspond ( what actually is not always correct in our application ) with. In case of all other calls the context has no chance to find out if the caller was the item it is corresponding with - at least not, when the active focus has moved somewhere else. And you find various situations in QQuickWindow or the controls, where inputMethod calls are done from items not being the corresponding one. F.e. in QQuickWindowPrivate::setFocusInScope/clearFocusInScope QInputMethod::commit() gets called, whenever the focus is changing. As this is might be wrong all our context can do is to ignore these calls in general. -- As we also implement our own type of controls ( in C++ ) I can work around most of these issue with bypassing the QInputMethod API and calling our context manually using a proprietary API, where I'm adding the caller as parameter. But this is obviously no option for the average Qt user. Uwe From alex at vikingsoftware.com Wed Jun 13 12:26:59 2018 From: alex at vikingsoftware.com (Alejandro Exojo) Date: Wed, 13 Jun 2018 12:26:59 +0200 Subject: [Development] QtCS 2018 - Serialisation session notes In-Reply-To: <8451151.YxzRa4OLOy@tjmaciei-mobl1> References: <5839774.zNMdgMTLy9@tjmaciei-mobl1> <20180611205007.GB27957@polaris.localdomain> <8451151.YxzRa4OLOy@tjmaciei-mobl1> Message-ID: <3872305.RjJeReVXWv@walt> On Tuesday 12 June 2018 00:41:38 Thiago Macieira wrote: > On Monday, 11 June 2018 22:50:09 CEST Rafael Roquetto wrote: > > Would it also make sense to explore msgpack? https://msgpack.org/ > > No. Msgpack is the older version of CBOR, which we already have. CBOR is IMHO better than Message Pack, but I don't see it as "the older version of CBOR". Rather, a different community (which in my experience has a larger adoption rate because it came first). I don't think we need support for it on Qt, but people who need to interoperate with it, will need one of the existing libraries. -- Viking Software, Qt and C++ developers for hire http://www.vikingsoftware.com From bogdan.vatra at kdab.com Wed Jun 13 13:40:43 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Wed, 13 Jun 2018 14:40:43 +0300 Subject: [Development] QtCS 2018 - Serialisation session notes In-Reply-To: <5839774.zNMdgMTLy9@tjmaciei-mobl1> References: <5839774.zNMdgMTLy9@tjmaciei-mobl1> Message-ID: <4082401.UpNWdDs3Qb@zmeu> Hi, > > === Protobuf === > > * Need volunteers to write a Proof of Concept > ** plugin to protoc? IMHO flatbuffers (https://google.github.io/flatbuffers/) has quite a few advantages over protocol buffers (one that I really like is that the only dependency your app has is a single .h file, which makes it very portable). Here https://github.com/bog-dan-ro/flatbuffers I have an old fork that adds Qt support to flatbuffers. The only disadvantage that I found is that the maintainer was a little bit difficult to work with :). Cheers, BogDan. From Simon.Hausmann at qt.io Wed Jun 13 14:07:01 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 13 Jun 2018 12:07:01 +0000 Subject: [Development] QInputMethod woes In-Reply-To: References: , Message-ID: Hi, While it's true that show(), etc. don't have the focus object as a parameter, you do have a three ways of tracking the focus object, via QWindow and QGuiApplication's signal as well as via setFocusObject in the input context itself. I'm missing something then, why is your virtual keyboard hidden when the focus object transitions from an element in the regular UI to an element in your virtual keyboard? Hiding is usually connected to the acceptance of the newly focused object with regards to IME enabling when issuing an IME query. Are those elements perhaps missing the handling of QInputMethodEvent, the querying kind in particular? Simon ________________________________ From: Development on behalf of Uwe Rathmann Sent: Wednesday, June 13, 2018 11:09:46 AM To: development at qt-project.org Subject: Re: [Development] QInputMethod woes Hi Simon, > But my initial guess is that this isn't an inherent design > problem of the input method API. Well, one problem is that the input context needs to know about the current item, as it has to correspond with it. But QInputMethod::show/ commit/reset/update/hide do not transfer any information about the item calling them. In case of show() all the context can do is to assume that the item having the active focus is the one to correspond ( what actually is not always correct in our application ) with. In case of all other calls the context has no chance to find out if the caller was the item it is corresponding with - at least not, when the active focus has moved somewhere else. And you find various situations in QQuickWindow or the controls, where inputMethod calls are done from items not being the corresponding one. F.e. in QQuickWindowPrivate::setFocusInScope/clearFocusInScope QInputMethod::commit() gets called, whenever the focus is changing. As this is might be wrong all our context can do is to ignore these calls in general. -- As we also implement our own type of controls ( in C++ ) I can work around most of these issue with bypassing the QInputMethod API and calling our context manually using a proprietary API, where I'm adding the caller as parameter. But this is obviously no option for the average Qt user. Uwe _______________________________________________ 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 Tor.arne.Vestbo at qt.io Wed Jun 13 15:29:36 2018 From: Tor.arne.Vestbo at qt.io (=?iso-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Wed, 13 Jun 2018 13:29:36 +0000 Subject: [Development] QInputMethod woes In-Reply-To: References: Message-ID: <11889064-502B-434C-8B1D-52C7E8FDACF2@qt.io> > On 13 Jun 2018, at 14:07, Simon Hausmann wrote: > > Hi, > > While it's true that show(), etc. don't have the focus object as a parameter, you do have a three ways of tracking the focus object, via QWindow and QGuiApplication's signal as well as via setFocusObject in the input context itself. This is how we track the focus object on e.g. iOS, where we also reconfigure the keyboard to match the focus object, e.g. if it needs numbers only input. Or we hide the keyboard or show the keyboard when moving from/to a focus object that has IM enabled or not. Tor Arne > > I'm missing something then, why is your virtual keyboard hidden when the focus object transitions from an element in the regular UI to an element in your virtual keyboard? Hiding is usually connected to the acceptance of the newly focused object with regards to IME enabling when issuing an IME query. Are those elements perhaps missing the handling of QInputMethodEvent, the querying kind in particular? > > Simon > From: Development on behalf of Uwe Rathmann > Sent: Wednesday, June 13, 2018 11:09:46 AM > To: development at qt-project.org > Subject: Re: [Development] QInputMethod woes > > Hi Simon, > > > But my initial guess is that this isn't an inherent design > > problem of the input method API. > > Well, one problem is that the input context needs to know about the > current item, as it has to correspond with it. But QInputMethod::show/ > commit/reset/update/hide do not transfer any information about the item > calling them. > > In case of show() all the context can do is to assume that the item > having the active focus is the one to correspond ( what actually is not > always correct in our application ) with. > > In case of all other calls the context has no chance to find out if the > caller was the item it is corresponding with - at least not, when the > active focus has moved somewhere else. > > And you find various situations in QQuickWindow or the controls, where > inputMethod calls are done from items not being the corresponding one. > > F.e. in QQuickWindowPrivate::setFocusInScope/clearFocusInScope > QInputMethod::commit() gets called, whenever the focus is changing. As > this is might be wrong all our context can do is to ignore these calls in > general. > > -- > > As we also implement our own type of controls ( in C++ ) I can work > around most of these issue with bypassing the QInputMethod API and > calling our context manually using a proprietary API, where I'm adding > the caller as parameter. > > But this is obviously no option for the average Qt user. > > Uwe > > _______________________________________________ > 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 pasi.keranen at qt.io Wed Jun 13 16:59:36 2018 From: pasi.keranen at qt.io (=?Windows-1252?Q?Pasi_Ker=E4nen?=) Date: Wed, 13 Jun 2018 14:59:36 +0000 Subject: [Development] Qt 3D Studio RC2 is available Message-ID: Hi, We have released Qt 3D Studio 2.0 RC2 today. It is available as both commercial and open source versions from online and offline installers. Qt 3D Studio 2.0 has a whole new 3D engine built on top of Qt 3D, a new timeline built from ground up with Qt based on the new timeline code in upcoming Qt Design Studio. Also there are a lot of improvements to the designer user experience, interactions in the 3D edit view and visualisation of lights and cameras being most notable ones. And of course we have numerous bug fixes. For instructions on how to get started and install everything correctly, see Laszlo’s excellent blog on the subject here: http://blog.qt.io/blog/2018/05/18/get-started-qt-3d-studio-2-0-beta-1/ Regards, Pasi Keränen Senior Manager, 3D Team -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Jun 14 02:08:00 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 13 Jun 2018 17:08:00 -0700 Subject: [Development] RFC: unified data model API in QtCore Message-ID: <8267758.2E6LWvaWOF@tjmaciei-mobl1> Out of the serialisation discussion at QtCS 2018, we have a call for action to discuss the possibility of *not* adding QCborValue in Qt 5.12 and instead add a generic, data model API that could be used for JSON, CBOR and future uses. The reason was that we do not need the duplication of very similar-looking APIs, with the duplication of documentation that goes along with it. Other languages parse serialised data into their own data structures which provide a generic access and modification API. This email is to start that discussion and answer these questions: a) should we have this API? b) if so, what would this API look like? c) if not, should we unify at least JSON and CBOR? c) either way, should remove QCborValue until we have it? The current "Qt native" data structure is the trio QVariant, QVariantList and QVariantMap. It is what some early (pre-Qt5) JSON parsers used, as JSON data can be losslessly converted to a handful of metatypes. And as long as only those types were used, the conversion to JSON is also lossless. This API would also be the replacement of the JSON and CBOR parsers, for which we'd have a unified API, something like: QFoo json = QJson::fromJson(jcontent); QFoo cbor = QCbor::fromCbor(ccontent); qDebug() << QCbor::toDiagnosticFormat(json); // yes, json And here's why I am having problems with this proposal: what else? We know we can have a common API for JSON and CBOR because I've done it (it's QCborValue) and because CBOR is designed to be compatible with JSON. But what about other protocols? Are we trying to shoehorn a square peg in a round hole? Recreate multidimensional hierarchical tables (a.k.a., QAbstractItemModel))? For example, the next data model over would be XML. And we are indeed missing a DOM structure for it since we deprecated QDomDocument. Can anyone see a data structure that works for both JSON/CBOR and generic XML? More importantly, one that is worthy of being Qt, with nice, intuitive API? I'm skeptical. What do you think?f -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Uwe.Rathmann at tigertal.de Thu Jun 14 08:42:37 2018 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Thu, 14 Jun 2018 06:42:37 +0000 (UTC) Subject: [Development] QInputMethod woes References: Message-ID: Hi Simon, > While it's true that show(), etc. don't have the focus object as a > parameter, you do have a three ways .... Yes, sure: show() is not the problem. ( We also have situations, where the virtual keyboard is started by pressing a button, while the input should go to some sort of label - but let's forget about them here ) > I'm missing something then, why is your virtual keyboard hidden... It isn't. > ... when the > focus object transitions from an element in the regular UI to an element > in your virtual keyboard? Our keyboard is a container item having the tabFence/focusProxy flags being enabled. It is shown on QInputMethod::show and automatically gets the focus. Automatically transferring the focus on hide/show of popups ( = items with tabFence/focusProxy ) is part of the qskinny framework. ( in case you are looking for ideas for Qt6: almost every EGLFS application needs some sort of replacement for what a window manager does with regular windows ) But anyway - the text input loses the focus and one of the buttons inside the virtual keyboard receives it: then the first thing that needs to managed is, that whenever the focus changes - f.e when the focus gets transferred to the virtual keyboard, or simply when navigating along the buttons inside the keyboard - the input context receives QInputMethod::commit() requests. -- But let's also have a look at QQuickTextInput: it automatically calls QInputMethod::show, when receiving the focus. This makes the focus tab chain almost unusable, as the virtual keyboard pops up, only when trying to navigate over a text input - always stealing the focus. Then when closing the virtual keybaord and the focus returns to the text input: it immediately reopens the virtual keyboard. Automatically calling QInputMethod::show can be avoided by disabling the focusOnPress ( = Qt::ClickFocus ) property, but what to do, when it is needed ? So without hacking QQuickTextInput ( = accessing private headers ) on the C++ side you can't get any proper focus management working. Uwe From lars.knoll at qt.io Thu Jun 14 08:46:54 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 14 Jun 2018 06:46:54 +0000 Subject: [Development] RFC: unified data model API in QtCore In-Reply-To: <8267758.2E6LWvaWOF@tjmaciei-mobl1> References: <8267758.2E6LWvaWOF@tjmaciei-mobl1> Message-ID: <3C4B9565-62E8-4BE6-8629-B391A5791E41@qt.io> > On 14 Jun 2018, at 02:08, Thiago Macieira wrote: > > Out of the serialisation discussion at QtCS 2018, we have a call for action to > discuss the possibility of *not* adding QCborValue in Qt 5.12 and instead add > a generic, data model API that could be used for JSON, CBOR and future uses. > The reason was that we do not need the duplication of very similar-looking > APIs, with the duplication of documentation that goes along with it. Other > languages parse serialised data into their own data structures which provide a > generic access and modification API. > > This email is to start that discussion and answer these questions: > > a) should we have this API? > > b) if so, what would this API look like? > > c) if not, should we unify at least JSON and CBOR? > > c) either way, should remove QCborValue until we have it? > > The current "Qt native" data structure is the trio QVariant, QVariantList and > QVariantMap. It is what some early (pre-Qt5) JSON parsers used, as JSON data > can be losslessly converted to a handful of metatypes. And as long as only > those types were used, the conversion to JSON is also lossless. I guess we all agree that QVariant is not really a good API for this :) > > This API would also be the replacement of the JSON and CBOR parsers, for which > we'd have a unified API, something like: > > QFoo json = QJson::fromJson(jcontent); > QFoo cbor = QCbor::fromCbor(ccontent); > qDebug() << QCbor::toDiagnosticFormat(json); // yes, json > > And here's why I am having problems with this proposal: what else? We know we > can have a common API for JSON and CBOR because I've done it (it's QCborValue) > and because CBOR is designed to be compatible with JSON. But what about other > protocols? Are we trying to shoehorn a square peg in a round hole? Recreate > multidimensional hierarchical tables (a.k.a., QAbstractItemModel))? I agree that we should avoid something like QAIM. What we can (and IMO should) do is share the implementation of the data model between CBOR and JSON. > > For example, the next data model over would be XML. And we are indeed missing > a DOM structure for it since we deprecated QDomDocument. Can anyone see a data > structure that works for both JSON/CBOR and generic XML? More importantly, one > that is worthy of being Qt, with nice, intuitive API? I’d leave XML out of this. It is difficult to integrate, as it has so many special features (entities, CDATA and lot of other things) making it a rather complex specification. But there are a couple of other formats that might fit a more generic data model. Yaml comes to my mind as an example, protobuf and flatbuffers might also be possible to stream into such a structure with some additional schema verification. > > I'm skeptical. What do you think?f One option could also be that we have a common implementation, and then a very thin API wrapper for each of the formats on top that will enforce the format specific limitations and give you a fully typed API. Cheers, Lars From Liang.Qi at qt.io Thu Jun 14 09:18:32 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Thu, 14 Jun 2018 07:18:32 +0000 Subject: [Development] Merge and Integration status report Message-ID: Integrations * qt5 dev integration failed from June 2, a submodule update without qtdeclarative was done on June. 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68666 declarative_core::MappingManagerError::test_error() failed * * * https://codereview.qt-project.org/#/c/222768 Simon is working on that since yesterday * qt5 5.11 integration failed from June 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - can't find some headers * * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, Oswald please help to review it. * * Issue: https://bugreports.qt.io/browse/QTBUG-68741 tst_QQmlDebuggingEnabler::qmlscene() failed From Simon.Hausmann at qt.io Thu Jun 14 09:32:52 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 14 Jun 2018 07:32:52 +0000 Subject: [Development] Merge and Integration status report In-Reply-To: References: Message-ID: Hi, Thank you Liang for the report. On top of that, qtdeclarative is not accepting any changes in the 5.9, 5.11, 5.11.1 and dev branches right now. Those who may have tried staging changes there may have noticed that they are failing in one of the tests that launch a separate process for testing the debugging integration, limited to Windows 10 (x86 and x86-64). Until we've found the root cause or a suitable workaround, please don't stage changes to qtdeclarative. I can't see any recent common changes to qtbase or declarative that apply to all _four_ branches, so I suspect this flaky issue was caused by something below those two modules. I'll post an update here when we've figured it out (workaround or solution). Simon ________________________________ From: Development on behalf of Liang Qi Sent: Thursday, June 14, 2018 9:18:32 AM To: development at qt-project.org Subject: [Development] Merge and Integration status report Integrations * qt5 dev integration failed from June 2, a submodule update without qtdeclarative was done on June. 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68666 declarative_core::MappingManagerError::test_error() failed * * * https://codereview.qt-project.org/#/c/222768 Simon is working on that since yesterday * qt5 5.11 integration failed from June 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - can't find some headers * * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, Oswald please help to review it. * * Issue: https://bugreports.qt.io/browse/QTBUG-68741 tst_QQmlDebuggingEnabler::qmlscene() failed _______________________________________________ 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 Thu Jun 14 10:47:43 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 14 Jun 2018 08:47:43 +0000 Subject: [Development] Merge and Integration status report In-Reply-To: References: , Message-ID: Actually at least 5.11.1 declarative integration failure is timeout in qtbase -> Linux QEMU (gcc-armv7) build. So the failure is different there (in case it helps anything) br, Jani ________________________________________ From: Development on behalf of Simon Hausmann Sent: Thursday, June 14, 2018 10:32 AM To: development at qt-project.org Subject: Re: [Development] Merge and Integration status report Hi, Thank you Liang for the report. On top of that, qtdeclarative is not accepting any changes in the 5.9, 5.11, 5.11.1 and dev branches right now. Those who may have tried staging changes there may have noticed that they are failing in one of the tests that launch a separate process for testing the debugging integration, limited to Windows 10 (x86 and x86-64). Until we've found the root cause or a suitable workaround, please don't stage changes to qtdeclarative. I can't see any recent common changes to qtbase or declarative that apply to all _four_ branches, so I suspect this flaky issue was caused by something below those two modules. I'll post an update here when we've figured it out (workaround or solution). Simon ________________________________ From: Development on behalf of Liang Qi Sent: Thursday, June 14, 2018 9:18:32 AM To: development at qt-project.org Subject: [Development] Merge and Integration status report Integrations * qt5 dev integration failed from June 2, a submodule update without qtdeclarative was done on June. 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68666 declarative_core::MappingManagerError::test_error() failed * * * https://codereview.qt-project.org/#/c/222768 Simon is working on that since yesterday * qt5 5.11 integration failed from June 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - can't find some headers * * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, Oswald please help to review it. * * Issue: https://bugreports.qt.io/browse/QTBUG-68741 tst_QQmlDebuggingEnabler::qmlscene() failed _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Thu Jun 14 10:53:13 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 14 Jun 2018 08:53:13 +0000 Subject: [Development] Merge and Integration status report In-Reply-To: References: , , Message-ID: Yes, that is another issue. But before that qtbase issue started showing up, the same change to 5.11.1 that you're trying to integrated failed when running a test that launches a separate process of testing the debugging integration. So once the qtbase issue is resolved it's likely that you'll run into the declarative failure again. Simon ________________________________ From: Jani Heikkinen Sent: Thursday, June 14, 2018 10:47:43 AM To: Simon Hausmann; development at qt-project.org Subject: Re: Merge and Integration status report Actually at least 5.11.1 declarative integration failure is timeout in qtbase -> Linux QEMU (gcc-armv7) build. So the failure is different there (in case it helps anything) br, Jani ________________________________________ From: Development on behalf of Simon Hausmann Sent: Thursday, June 14, 2018 10:32 AM To: development at qt-project.org Subject: Re: [Development] Merge and Integration status report Hi, Thank you Liang for the report. On top of that, qtdeclarative is not accepting any changes in the 5.9, 5.11, 5.11.1 and dev branches right now. Those who may have tried staging changes there may have noticed that they are failing in one of the tests that launch a separate process for testing the debugging integration, limited to Windows 10 (x86 and x86-64). Until we've found the root cause or a suitable workaround, please don't stage changes to qtdeclarative. I can't see any recent common changes to qtbase or declarative that apply to all _four_ branches, so I suspect this flaky issue was caused by something below those two modules. I'll post an update here when we've figured it out (workaround or solution). Simon ________________________________ From: Development on behalf of Liang Qi Sent: Thursday, June 14, 2018 9:18:32 AM To: development at qt-project.org Subject: [Development] Merge and Integration status report Integrations * qt5 dev integration failed from June 2, a submodule update without qtdeclarative was done on June. 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68666 declarative_core::MappingManagerError::test_error() failed * * * https://codereview.qt-project.org/#/c/222768 Simon is working on that since yesterday * qt5 5.11 integration failed from June 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - can't find some headers * * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, Oswald please help to review it. * * Issue: https://bugreports.qt.io/browse/QTBUG-68741 tst_QQmlDebuggingEnabler::qmlscene() failed _______________________________________________ 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 Jun 14 15:13:32 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 14 Jun 2018 06:13:32 -0700 Subject: [Development] RFC: unified data model API in QtCore In-Reply-To: <3C4B9565-62E8-4BE6-8629-B391A5791E41@qt.io> References: <8267758.2E6LWvaWOF@tjmaciei-mobl1> <3C4B9565-62E8-4BE6-8629-B391A5791E41@qt.io> Message-ID: <3584000.lrc5nGosJe@tjmaciei-mobl1> On Wednesday, 13 June 2018 23:46:54 PDT Lars Knoll wrote: > I’d leave XML out of this. It is difficult to integrate, as it has so many > special features (entities, CDATA and lot of other things) making it a > rather complex specification. But there are a couple of other formats that > might fit a more generic data model. Yaml comes to my mind as an example, > protobuf and flatbuffers might also be possible to stream into such a > structure with some additional schema verification. YAML, like CBOR, was designed with compatibility in mind. In fact, it's designed so JSON-YAML conversion is lossless in both directions. So YAML makes a lot of sense. I don't know much about PB and FB, but from what I've seen it's meant to be a serialisation format based on an IDL you describe. It's closer to QDataStream than to JSON. From what I've seen, it makes no sense to merge those with the other three than it does XML. > > I'm skeptical. What do you think?f > > One option could also be that we have a common implementation, and then a > very thin API wrapper for each of the formats on top that will enforce the > format specific limitations and give you a fully typed API. That was my original plan. The QCborValue backend can be reused for JSON as a thin wrapper API. There's just a lot of copy & paste. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kfunk at kde.org Thu Jun 14 15:19:51 2018 From: kfunk at kde.org (Kevin Funk) Date: Thu, 14 Jun 2018 15:19:51 +0200 Subject: [Development] Did we have to remove cmake's qt5_use_modules? In-Reply-To: <2825593.EUdpXDWLPV@tjmaciei-mobl1> References: <2825593.EUdpXDWLPV@tjmaciei-mobl1> Message-ID: <1752235.OIoEV3iW7f@kerberos> On Thursday, 7 June 2018 08:03:40 CEST Thiago Macieira wrote: > Commit 02ed1b36daebed5f3997bb676cf5e818c0db9d3c was > > Remove CMake code for CMake < 3.1 > > This removes the following functions from Qt5CoreMacros: > - qt5_use_modules(...) > > Which follows 2013's d9ea4bb1441534cfb9253303ac258951dfcc4d9e > > Mark qt5_use_modules as obsolete. > > Forward-port of cb7f32f5b861fe115fa71f64500a5cbb0b643f1b (Mark > qt4_use_modules and qt4_automoc as obsolete., 2013-07-04) from > cmake.git. > > But it appears that in the 5 years since we deprecated it, people have not > stopped using it. Did we have to remove it? Or should we have kept > compatibility until Qt 6? Heya, Patch for restoring qt5_use_modules() is here: https://codereview.qt-project.org/#/c/232367/ Regards, Kevin > Just look at the failures in > https://build.opensuse.org/project/monitor/openSUSE:Factory? > arch_x86_64=1&defaults=0&failed=1&repo_standard=1 > > The majority of them are caused by the Qt 5.11 update, a great number of > which are the cmake update (the rest are indirect header dependency and are > easy to fix). -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: This is a digitally signed message part. URL: From thiago.macieira at intel.com Thu Jun 14 15:27:17 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 14 Jun 2018 06:27:17 -0700 Subject: [Development] Did we have to remove cmake's qt5_use_modules? In-Reply-To: <1752235.OIoEV3iW7f@kerberos> References: <2825593.EUdpXDWLPV@tjmaciei-mobl1> <1752235.OIoEV3iW7f@kerberos> Message-ID: <1547673.nIrO5dCvEY@tjmaciei-mobl1> On Thursday, 14 June 2018 06:19:51 PDT Kevin Funk wrote: > Heya, > > Patch for restoring qt5_use_modules() is here: > https://codereview.qt-project.org/#/c/232367/ Thanks, Kevin! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jeanmichael.celerier at gmail.com Thu Jun 14 15:47:56 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Thu, 14 Jun 2018 15:47:56 +0200 Subject: [Development] RFC: unified data model API in QtCore In-Reply-To: <3584000.lrc5nGosJe@tjmaciei-mobl1> References: <8267758.2E6LWvaWOF@tjmaciei-mobl1> <3C4B9565-62E8-4BE6-8629-B391A5791E41@qt.io> <3584000.lrc5nGosJe@tjmaciei-mobl1> Message-ID: > So YAML makes a lot of sense. https://github.com/yaml/YAML2/wiki/People-Raging-About-YAML https://users.rust-lang.org/t/why-does-cargo-use-toml/3577/15 I would like to understand what all this discussion is about. What is the goal for Qt ? a) allow developers using Qt to have a simple, human-readable (that's the n°1 feature my users always asked about save and file formats) and easy to write serialization method ? b) compatibility with existing formats, e.g. I want to communicate with a webservice which speaks JSON or whatever c) maximum performance for e.g. message passing between two processes ? In any case, every time I ever used JSON it is because it was necessary for compatibility with existing interfaces - sometimes web APIs, sometimes human beings who are used to reading JSON. I don't see this going away any time soon... In any case, what would be the added value of Qt providing new serialization formats & APIs, especially wrt exisiting header-only libraries (rapidjson, nlohmann/json for instance in the json world) which provide better performance AND compliance than Qt's ? (again, for json, https://github.com/miloyip/nativejson-benchmark) Best, ------- Jean-Michaël Celerier http://www.jcelerier.name On Thu, Jun 14, 2018 at 3:13 PM, Thiago Macieira wrote: > On Wednesday, 13 June 2018 23:46:54 PDT Lars Knoll wrote: > > I’d leave XML out of this. It is difficult to integrate, as it has so > many > > special features (entities, CDATA and lot of other things) making it a > > rather complex specification. But there are a couple of other formats > that > > might fit a more generic data model. Yaml comes to my mind as an example, > > protobuf and flatbuffers might also be possible to stream into such a > > structure with some additional schema verification. > > YAML, like CBOR, was designed with compatibility in mind. In fact, it's > designed so JSON-YAML conversion is lossless in both directions. So YAML > makes > a lot of sense. > > I don't know much about PB and FB, but from what I've seen it's meant to > be a > serialisation format based on an IDL you describe. It's closer to > QDataStream > than to JSON. From what I've seen, it makes no sense to merge those with > the > other three than it does XML. > > > > I'm skeptical. What do you think?f > > > > One option could also be that we have a common implementation, and then a > > very thin API wrapper for each of the formats on top that will enforce > the > > format specific limitations and give you a fully typed API. > > That was my original plan. The QCborValue backend can be reused for JSON > as a > thin wrapper API. There's just a lot of copy & paste. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Jun 14 17:29:29 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 14 Jun 2018 08:29:29 -0700 Subject: [Development] RFC: unified data model API in QtCore In-Reply-To: References: <8267758.2E6LWvaWOF@tjmaciei-mobl1> <3584000.lrc5nGosJe@tjmaciei-mobl1> Message-ID: <11586504.7sAF0Ppuh6@tjmaciei-mobl1> On Thursday, 14 June 2018 06:47:56 PDT Jean-Michaël Celerier wrote: > > So YAML makes a lot of sense. > > https://github.com/yaml/YAML2/wiki/People-Raging-About-YAML > https://users.rust-lang.org/t/why-does-cargo-use-toml/3577/15 > > I would like to understand what all this discussion is about. What is the > goal for Qt ? > > a) allow developers using Qt to have a simple, human-readable (that's the > n°1 feature my users always asked about save and file formats) and easy to > write serialization method ? > b) compatibility with existing formats, e.g. I want to communicate with a > webservice which speaks JSON or whatever > c) maximum performance for e.g. message passing between two processes ? THIS discussion is none of those. This discussion is about the API we want to have for Qt for at least JSON and CBOR. We may want to add more formats and the one that comes to mind as the lowest hanging fruit is YAML. You brought up TOML, which in turn brings to mind: should we merge with QSettings too? > In any case, what would be the added value of Qt providing new > serialization formats & APIs, especially wrt exisiting header-only > libraries (rapidjson, nlohmann/json for instance in the json world) which > provide better performance AND compliance than Qt's ? (again, for json, > https://github.com/miloyip/nativejson-benchmark) That is not the discussion, but let me answer: people expect to have an API. From the 41 libraries that were listed in there, can you list which ones support QString? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Thu Jun 14 18:46:22 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 14 Jun 2018 18:46:22 +0200 Subject: [Development] RFC: unified data model API in QtCore In-Reply-To: References: <8267758.2E6LWvaWOF@tjmaciei-mobl1> <3C4B9565-62E8-4BE6-8629-B391A5791E41@qt.io> <3584000.lrc5nGosJe@tjmaciei-mobl1> Message-ID: An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Thu Jun 14 19:23:24 2018 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Thu, 14 Jun 2018 14:23:24 -0300 Subject: [Development] Did we have to remove cmake's qt5_use_modules? In-Reply-To: <1752235.OIoEV3iW7f@kerberos> References: <2825593.EUdpXDWLPV@tjmaciei-mobl1> <1752235.OIoEV3iW7f@kerberos> Message-ID: <15145073.BezLM1DoxO@tonks> El jueves, 14 de junio de 2018 10:19:51 -03 Kevin Funk escribió: > On Thursday, 7 June 2018 08:03:40 CEST Thiago Macieira wrote: [snip] > Heya, > > Patch for restoring qt5_use_modules() is here: > https://codereview.qt-project.org/#/c/232367/ yay, thanks a lot! I have read your comment on adding a deprecation warning on 5.12: please go ahead (you might even add that in 5.11.2 if it ever gets to exist). -- Si vives cada día de tu vida como si fuera el último, algún día realmente tendrás razón. Steve Jobs 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 bstottle at ford.com Fri Jun 15 00:37:09 2018 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Thu, 14 Jun 2018 22:37:09 +0000 Subject: [Development] QtCS 2018 - Qt Remote Objects session Message-ID: <4A27B5D4-015C-445A-AD8A-349DA0B60917@ford.com> I’ve posted notes from the session: https://wiki.qt.io/QtCS2018_RemoteObjects Thanks to everyone who participated, and feel free to update if you see anything I missed. Regards, Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Fri Jun 15 08:55:33 2018 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 15 Jun 2018 08:55:33 +0200 Subject: [Development] RFC: unified data model API in QtCore In-Reply-To: <8267758.2E6LWvaWOF@tjmaciei-mobl1> References: <8267758.2E6LWvaWOF@tjmaciei-mobl1> Message-ID: On 2018-06-14 02:08, Thiago Macieira wrote: > [...] > For example, the next data model over would be XML. And we are indeed missing > a DOM structure for it since we deprecated QDomDocument. Can anyone see a data > structure that works for both JSON/CBOR and generic XML? More importantly, one > that is worthy of being Qt, with nice, intuitive API? QDomDocument is, in fact, not deprecated. As Lars said, XML has more concepts, such as namespace, attributes, ... that it'd be difficult to fit it in the same API. I suppose it is fine to keep QDomDocument as a separate class. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From olivier at woboq.com Fri Jun 15 09:15:19 2018 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 15 Jun 2018 09:15:19 +0200 Subject: [Development] unique_ptr and Qt In-Reply-To: References: Message-ID: <3352f77a-a55a-f70a-c672-c757df07d532@woboq.com> On 2018-06-05 14:40, Daniel Teske wrote: > Hi, > > I've done some research into how supporting unique_ptr in Qt might look like. > > I have a patch which adds apis using unique_ptr for ownership transfer to > almost all of QtBase and a patch for Qt Creator to show how using those apis > looks like. > > Qt: https://codereview.qt-project.org/231543 > Qt Creator: https://codereview.qt-project.org/231545 > [...] Hi Daniel, Thanks for doing this. Here is what i suggest to make the change less intrusive: For the constructors themself in every classes. // Removed the '=nullptr' default parent, and added QT_UNSAFE_API QT_UNSAFE_API explicit QLineEdit(QWidget *parent); QT_UNSAFE_API explicit QLineEdit(const QString &, QWidget *parent); // Added new non-deprecated constructor not taking parent. explicit QLineEdit(const QString & = {}); //The QObject::makeChild method: template T* QObject::makeChild(Args&&... args) { auto n = new T(std::forward(args)...); n->setParent(this); return n; } That way, std::make_unique still work, and constructing objects on the stack does not change. For the cases where the parent in the constructor has another meaning, we would need another factory function (makeChild) in the relevant class. Or interept the ParentChanged, or reimplement setParent in that class. What do you think? -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From philwave at gmail.com Fri Jun 15 09:32:13 2018 From: philwave at gmail.com (Philippe) Date: Fri, 15 Jun 2018 09:32:13 +0200 Subject: [Development] QSharedPointer specialization Message-ID: <20180615093212.5F0F.6F0322A@gmail.com> QObject has built-in support to a reference count block to support QPointer (which is composed of a QWeakPointer) When doing QSharedPointer, is there a technical reason that prevents the QObject control block to be used, rather allocating a new one, like it is necessary for common objects? IOW, is a QSharedPointer specialization feasible? Philippe From arnaud.clere at minmaxmedical.com Fri Jun 15 13:31:04 2018 From: arnaud.clere at minmaxmedical.com (=?iso-8859-1?Q?Arnaud_Cl=E8re?=) Date: Fri, 15 Jun 2018 11:31:04 +0000 Subject: [Development] RFC: unified data model API in QtCore => thin wrapper proposal Message-ID: -----Original Message----- From: Thiago Macieira Sent: jeudi 14 juin 2018 02:08 > This email is to start that discussion and answer these questions: > a) should we have this API? > b) if so, what would this API look like? > c) if not, should we unify at least JSON and CBOR? > c) either way, should remove QCborValue until we have it? ... > This API would also be the replacement of the JSON and CBOR parsers, for which > we'd have a unified API, something like: > QFoo json = QJson::fromJson(jcontent); > QFoo cbor = QCbor::fromCbor(ccontent); > qDebug() << QCbor::toDiagnosticFormat(json); // yes, json Hi all, As I was saying during QtCS "QDebug and others" session, structured traces need a way to serialize in-memory data structures in a number of formats for interoperability reasons. This requires a generic way to traverse data structures, not necessarily a generic data structure. A common data structure for Cbor and Json makes sense since they share so much. But even these 2 formats have peculiarities that may need distinct APIs like Cbor tags. This is even more true for Xml. I think that Cbor found a sweet spot between generality and efficiency, so the data structure behind QCborValue will be good for many use cases. But like as a generic data structure, it will not suit all use cases. Look at Python: although it has general purpose list, dict, and so on, its Json decoder provides hooks to bind data to specialized types. So, I think it is perfectly Ok to have a common data structure for Cbor and Json but it does not preclude the need for specific APIs. Also, specific documentation is usually easier to understand than generic one since you can refer to Json and Cbor standards and examples. I think it is also Ok to have QCborValue in 5.12 because we can always add a more generic API as a thin layer on top of specialized data structures, especially in Qt6 if we take advantage of C++17. Since the title of the discussion is so general, please let me sketch here what such API could be. That may help find a definitive answer to your questions. The basic existing API for reading/writing is streams. One problem with streams is that the structure of the data being traversed is lost. So, a reader must know the structure to read the data. And in some cases, ambiguities may even prevent from reading back the data: cout << 1.0 << 1; cin >> myFloat >> myInt; // may well read myFloat==1.1, myInt==0 QDebug avoids most problems by inserting spaces between << by default but does not allow reading. Also, a user-defined type T must write slightly different code for writing in QDebug, and other formats, and for reading the resulting text... The approach we took in the MODMED project originates in functional Zippers which are generalized iterators for arbitrary data structures, not just sequences. It makes the data structure apparent in the traversal. Also, the traversal can be adapted to the task at end. For instance, a user-defined type may ignore some Json data it does not understand while reading. Thus, the approach, allows to bind "any data with a common structure" such as a generic QCborValue and a user-defined type or a QByteArray containing Cbor data or utf8 encoded Json. Let me dream what this approach could look like in Qt, by first using the approach to directly write some usual data types in Cbor or Json: QVector vector = {1.,2.}; QByteArray buffer; QCborWriter cborw(&buffer); cborw.sequence().bind("val").bind(true).bind(vector); // buffer = 0x9F6376616... Note: A generic encoder would use Cbor indefinite length arrays and few or no Cbor tags so a specialized encoder would still be needed for some use cases. buffer.clear(); QJsonWriter jsonw(&buffer); jsonw.sequence().bind("val").bind(true).bind(vector); // same code as above // buffer = ["val",true,[1.0,2.0]] In our approach, "bind" handles Read and Write the same way, so it is possible to do: QString val; bool b; QJsonReader jsonr(&buffer); jsonr.sequence().bind(val).bind(b).bind(vector); // same code with lvalues // val = "val", b = true, ... This can work with any in-memory data type like QMap, QVector or QCborValue. It just requires a bind method or QBind functor definition. Let me show you the default templated QBind definition: template struct QBind { static TResult bind(Val value, T t) { return t.bind(value); // In case of error, define a T::bind(Val) method or an external QBind::bind(Val,T) functor } }; Most user-defined bind methods would be very simple and the type system would guarantee that data is well-formed (no sequence or record left open...): struct Person { QString m_firstName, m_lastName; int m_age; template TResult bind(Val value) { return value .record() .sequence("name") .bind(m_firstName) .bind(m_lastName) .out() .bind("age" , m_age); // automagically closes opened record } }; One advantage of the approach is that such boiler-plate code would have to be written once for any TResult (be it a QJsonReader, QCborWriter, etc.), so the above code would be enough to allow: QByteArray json; QJsonWriter(&json) jsonw; jsonw.bind(Person {"John","Doe",42}); // json = {"name":["John","Doe"],"age":42} Person p; QJsonReader(&json) jsonr; jsonr.bind(p); // p = Person {"John","Doe",42} QByteArray cbor; QCborWriter(&cbor) cborw; cborw.bind(p); // cbor = 0xBF646E616D659F64... Note: Dynamic data structures' bind methods need to handle Write and Read differently but user-defined types are rarely dynamically-sized. The approach even works with QIODevice and no intermediate in-memory data, so it is possible to do: QIODevice in, out; // open appropriately QJsonReader(&in ) jsonr; QCborWriter(&out) cborw; if (cborw.bind(jsonr)) cout << "Done."; // transforms any Json to Cbor without loading everything in memory To sum up: * this approach can use QCborValue which is a nice balance between generality and efficiency that provides in-place editing * QBind could provide QCborValue (or any other data type) generic read/write to a number of formats, but... * specific writers/readers may always be necessary * QCborValue may differ from QJsonValue at one time to handle Cbor tags and other peculiarities To move on, we have a working structured traces library implementing this approach. However, its write performance is 10 times that of boiler-plate code using QDebug. Based on our previous work and using modern C++ compilers, it seems possible to implement the approach with more reasonable write performance. So, I will try to submit a proof of concept in the following days. In the meanwhile, I've put a few details on our approach and links to related discussions on the "QDebug" session wiki page: https://wiki.qt.io/QDebug_and_other_tracing_facilities Hope it helps, Arnaud From thiago.macieira at intel.com Fri Jun 15 15:19:47 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 15 Jun 2018 06:19:47 -0700 Subject: [Development] QSharedPointer specialization In-Reply-To: <20180615093212.5F0F.6F0322A@gmail.com> References: <20180615093212.5F0F.6F0322A@gmail.com> Message-ID: <1626461.4vMIbg2EeP@tjmaciei-mobl1> On Friday, 15 June 2018 00:32:13 PDT Philippe wrote: > QObject has built-in support to a reference count block to support QPointer > (which is composed of a QWeakPointer) > > When doing QSharedPointer, is there a technical reason that > prevents the QObject control block to be used, rather allocating a new one, > like it is necessary for common objects? That's what we did in Qt 4 and that wasn't a good idea. The fact that QPointer uses QSharedPointer's control block is an implementation detail, not to be relied upon. Maybe we could save the extra 16 bytes allocation, but the use of both QSharedPointer and QPointer isn't likely. And for Qt 6, we may reimplement QSharedPointer on top of std::shard_ptr, so this wouldn't be available for long as a feature. > IOW, is a QSharedPointer specialization feasible? To do what? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jun 15 15:23:32 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 15 Jun 2018 06:23:32 -0700 Subject: [Development] RFC: unified data model API in QtCore In-Reply-To: References: <8267758.2E6LWvaWOF@tjmaciei-mobl1> Message-ID: <2097861.QvGm3yeNti@tjmaciei-mobl1> On Thursday, 14 June 2018 23:55:33 PDT Olivier Goffart wrote: > QDomDocument is, in fact, not deprecated. Fair enough. But the QtXml module as a whole is Done. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Tor.arne.Vestbo at qt.io Fri Jun 15 15:46:43 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Fri, 15 Jun 2018 13:46:43 +0000 Subject: [Development] RFC: unified data model API in QtCore => thin wrapper proposal In-Reply-To: References: Message-ID: <2100B6F7-960A-4F49-BA4D-960EEDCA9EF4@qt.io> > On 15 Jun 2018, at 13:31, Arnaud Clère wrote: > [snip] > Most user-defined bind methods would be very simple and the type system would > guarantee that data is well-formed (no sequence or record left open...): > > struct Person { > QString m_firstName, m_lastName; > int m_age; > > template > TResult bind(Val value) { return value > .record() > .sequence("name") > .bind(m_firstName) > .bind(m_lastName) > .out() > .bind("age" , m_age); // automagically closes opened record > } > }; Not commenting on this API, but I’d like to note that the API I brought up as “missing” from my use-case was a more “light weight” in-place edit API, where the user does not have to define bindings to data structures like above. Similar to e.g. python: >>> data = json.loads('{ "foo": [1, 2, 3] }') >>> data {u'foo': [1, 2, 3]} >>> data["foo"][0] = 42 >>> data {u'foo': [42, 2, 3]} With our existing APIs I’d expect: QJsonDocument doc; doc[“foo”][0] = 42; Tor Arne From philwave at gmail.com Fri Jun 15 16:23:49 2018 From: philwave at gmail.com (Philippe) Date: Fri, 15 Jun 2018 16:23:49 +0200 Subject: [Development] QSharedPointer specialization In-Reply-To: <1626461.4vMIbg2EeP@tjmaciei-mobl1> References: <20180615093212.5F0F.6F0322A@gmail.com> <1626461.4vMIbg2EeP@tjmaciei-mobl1> Message-ID: <20180615162347.FC20.6F0322A@gmail.com> > > IOW, is a QSharedPointer specialization feasible? > > To do what? I meant, to have QSharedPointer<"derived QObject class"> using the QObject control block, rather than creating a new one. (in the same way this is done with QWeakPointer) My whole reflexion was: I need to have shared ownership on QObject derived objects, and there is already built-in support in QObject for this. But thanks for your answer, I can do with the existing. Philippe From Simon.Hausmann at qt.io Sat Jun 16 11:08:21 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Sat, 16 Jun 2018 09:08:21 +0000 Subject: [Development] Merge and Integration status report In-Reply-To: References: , , , Message-ID: Hi, Unfortunately we haven’t found a solution or workaround yet - the module remains blocked. We can observe some virtual machines slowing down to a grinding halt and we can observe that quite often at boot time. The latter causes the CI to kill the vm after some time and try creating a new one. That story repeats itself until finally a situation/host is found where everything works. This also makes overall integration times slower. We can also observe how every test in debug-and-release is run three times and with flaky tests as in this case that increases the probability of an overall failure and it increases the overall time to test for all projects. What nobody has managed to do so far is reproduce the declarative failure in front of human eyes. Whenever observed through the hypervisor’s vnc interface it appears to work smoothly. One thing that is unclear to me is what exactly has changed that causes this, because I think that given the spread across branches it was not a change in declarative or qtbase. Unfortunately we do not have a journal of sorts that records what changes were done on the infrastructure at what time. It might even be an innocent change that triggered an actual bug in declarative. Does anybody see odd test failures that seem performance related in other modules, across branches? Simon On 14. Jun 2018, at 10:53, Simon Hausmann > wrote: Yes, that is another issue. But before that qtbase issue started showing up, the same change to 5.11.1 that you're trying to integrated failed when running a test that launches a separate process of testing the debugging integration. So once the qtbase issue is resolved it's likely that you'll run into the declarative failure again. Simon ________________________________ From: Jani Heikkinen Sent: Thursday, June 14, 2018 10:47:43 AM To: Simon Hausmann; development at qt-project.org Subject: Re: Merge and Integration status report Actually at least 5.11.1 declarative integration failure is timeout in qtbase -> Linux QEMU (gcc-armv7) build. So the failure is different there (in case it helps anything) br, Jani ________________________________________ From: Development > on behalf of Simon Hausmann > Sent: Thursday, June 14, 2018 10:32 AM To: development at qt-project.org Subject: Re: [Development] Merge and Integration status report Hi, Thank you Liang for the report. On top of that, qtdeclarative is not accepting any changes in the 5.9, 5.11, 5.11.1 and dev branches right now. Those who may have tried staging changes there may have noticed that they are failing in one of the tests that launch a separate process for testing the debugging integration, limited to Windows 10 (x86 and x86-64). Until we've found the root cause or a suitable workaround, please don't stage changes to qtdeclarative. I can't see any recent common changes to qtbase or declarative that apply to all _four_ branches, so I suspect this flaky issue was caused by something below those two modules. I'll post an update here when we've figured it out (workaround or solution). Simon ________________________________ From: Development > on behalf of Liang Qi > Sent: Thursday, June 14, 2018 9:18:32 AM To: development at qt-project.org Subject: [Development] Merge and Integration status report Integrations * qt5 dev integration failed from June 2, a submodule update without qtdeclarative was done on June. 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68666 declarative_core::MappingManagerError::test_error() failed * * * https://codereview.qt-project.org/#/c/222768 Simon is working on that since yesterday * qt5 5.11 integration failed from June 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - can't find some headers * * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, Oswald please help to review it. * * Issue: https://bugreports.qt.io/browse/QTBUG-68741 tst_QQmlDebuggingEnabler::qmlscene() failed _______________________________________________ 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 abbapoh at gmail.com Sat Jun 16 11:29:48 2018 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sat, 16 Jun 2018 12:29:48 +0300 Subject: [Development] unique_ptr and Qt In-Reply-To: <3352f77a-a55a-f70a-c672-c757df07d532@woboq.com> References: <3352f77a-a55a-f70a-c672-c757df07d532@woboq.com> Message-ID: <150F494C-BA1F-4724-A09B-25F01CFE8591@gmail.com> It would be nice if makeChild returned a some kind of «stupid» smart pointer (gsl::not_null maybe?) to indicate that object is not owned by holder (compare with raw pointer where the ownership is not known without reading doc): template QNonOwningPointer QObject::makeChild(Args&&... args); Another thought is that it may make sense to invert child->setParent(parent) function to something like this: template void QObject::addChild(std::unique_ptr &&p); template void QObject::addChild(const QNonOwningPointer p); So the code with std::shared_pointer won’t compile: auto o = std::make_shared(«object»); parent->addChild(o); // oops, how do we suppose «share» ownership between user and QObject? However, it is ok with unique_ptr or «stupid» ptr: auto o = std::make_unique(«object»); parent->addChild(std::move(o)); // ok, ownership transfered QNonOwningPointer o = QObject::makeChild(parent1, «object»); parent2->addChild(o); // ok, ownership transfered from parent1 to parent2 My 2 cents. > 15 июня 2018 г., в 10:15, Olivier Goffart написал(а): > > On 2018-06-05 14:40, Daniel Teske wrote: >> Hi, >> I've done some research into how supporting unique_ptr in Qt might look like. >> I have a patch which adds apis using unique_ptr for ownership transfer to almost all of QtBase and a patch for Qt Creator to show how using those apis looks like. >> Qt: https://codereview.qt-project.org/231543 >> Qt Creator: https://codereview.qt-project.org/231545 > > [...] > > Hi Daniel, > > Thanks for doing this. > > Here is what i suggest to make the change less intrusive: > For the constructors themself in every classes. > > // Removed the '=nullptr' default parent, and added QT_UNSAFE_API > QT_UNSAFE_API explicit QLineEdit(QWidget *parent); > QT_UNSAFE_API explicit QLineEdit(const QString &, QWidget *parent); > // Added new non-deprecated constructor not taking parent. > explicit QLineEdit(const QString & = {}); > > > //The QObject::makeChild method: > template T* QObject::makeChild(Args&&... args) > { > auto n = new T(std::forward(args)...); > n->setParent(this); > return n; > } > > > That way, std::make_unique still work, and constructing objects on the stack does not change. > > For the cases where the parent in the constructor has another meaning, we would need another factory function (makeChild) in the relevant class. Or interept the ParentChanged, or reimplement setParent in that class. > > What do you think? > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From olszak.tomasz at gmail.com Sat Jun 16 12:59:46 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Sat, 16 Jun 2018 12:59:46 +0200 Subject: [Development] Merge and Integration status report In-Reply-To: References: Message-ID: Do you use up to date Win 10? Recent updates introduced many issue. E.g one of our app couldn't install with some privilege/policy access denied error. It was not clear from logs what happened. By trial and errors we just enabled camera for applications in security settings and it started to work. It might be good idea to reverse a few updates and check if it works. sob., 16 cze 2018, 11:08 użytkownik Simon Hausmann napisał: > Hi, > > Unfortunately we haven’t found a solution or workaround yet - the module > remains blocked. > > We can observe some virtual machines slowing down to a grinding halt and > we can observe that quite often at boot time. The latter causes the CI to > kill the vm after some time and try creating a new one. That story repeats > itself until finally a situation/host is found where everything works. This > also makes overall integration times slower. > > We can also observe how every test in debug-and-release is run three times > and with flaky tests as in this case that increases the probability of an > overall failure and it increases the overall time to test for all projects. > > What nobody has managed to do so far is reproduce the declarative failure > in front of human eyes. Whenever observed through the hypervisor’s vnc > interface it appears to work smoothly. > > One thing that is unclear to me is what exactly has changed that causes > this, because I think that given the spread across branches it was not a > change in declarative or qtbase. Unfortunately we do not have a journal of > sorts that records what changes were done on the infrastructure at what > time. > > It might even be an innocent change that triggered an actual bug in > declarative. Does anybody see odd test failures that seem performance > related in other modules, across branches? > > Simon > > On 14. Jun 2018, at 10:53, Simon Hausmann wrote: > > > Yes, that is another issue. But before that qtbase issue started showing > up, the same change to 5.11.1 that you're trying to integrated failed when > running a test that launches a separate process of testing the debugging > integration. So once the qtbase issue is resolved it's likely that you'll > run into the declarative failure again. > > > > Simon > ------------------------------ > *From:* Jani Heikkinen > *Sent:* Thursday, June 14, 2018 10:47:43 AM > *To:* Simon Hausmann; development at qt-project.org > *Subject:* Re: Merge and Integration status report > > Actually at least 5.11.1 declarative integration failure is timeout in > qtbase -> Linux QEMU (gcc-armv7) build. So the failure is different there > (in case it helps anything) > > br, > Jani > ________________________________________ > From: Development > on behalf of Simon Hausmann > Sent: Thursday, June 14, 2018 10:32 AM > To: development at qt-project.org > Subject: Re: [Development] Merge and Integration status report > > Hi, > > > Thank you Liang for the report. > > > On top of that, qtdeclarative is not accepting any changes in the 5.9, > 5.11, 5.11.1 and dev branches right now. > > > Those who may have tried staging changes there may have noticed that they > are failing in one of the tests that launch a separate process for testing > the debugging integration, limited to Windows 10 (x86 and x86-64). > > > Until we've found the root cause or a suitable workaround, please don't > stage changes to qtdeclarative. > > > I can't see any recent common changes to qtbase or declarative that apply > to all _four_ branches, so I suspect this flaky issue was caused by > something below those two modules. > > > I'll post an update here when we've figured it out (workaround or > solution). > > > Simon > > ________________________________ > From: Development > on behalf of Liang Qi > Sent: Thursday, June 14, 2018 9:18:32 AM > To: development at qt-project.org > Subject: [Development] Merge and Integration status report > > Integrations > > * qt5 dev integration failed from June 2, a submodule update without > qtdeclarative was done on June. 9 > * * Issue: https://bugreports.qt.io/browse/QTBUG-68666 > declarative_core::MappingManagerError::test_error() failed > * * * https://codereview.qt-project.org/#/c/222768 Simon is working on > that since yesterday > > * qt5 5.11 integration failed from June 9 > * * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build > failed - can't find some headers > * * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a > fix, Oswald please help to review it. > * * Issue: https://bugreports.qt.io/browse/QTBUG-68741 > tst_QQmlDebuggingEnabler::qmlscene() failed > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qt at squorn.de Sun Jun 17 21:16:05 2018 From: qt at squorn.de (Daniel Teske) Date: Sun, 17 Jun 2018 21:16:05 +0200 Subject: [Development] unique_ptr and Qt In-Reply-To: <3352f77a-a55a-f70a-c672-c757df07d532@woboq.com> References: <3352f77a-a55a-f70a-c672-c757df07d532@woboq.com> Message-ID: > Thanks for doing this. > > Here is what i suggest to make the change less intrusive: > For the constructors themself in every classes. > >   // Removed the '=nullptr' default parent, and added QT_UNSAFE_API >   QT_UNSAFE_API explicit QLineEdit(QWidget *parent); >   QT_UNSAFE_API explicit QLineEdit(const QString &, QWidget *parent); >   // Added new non-deprecated constructor not taking parent. >   explicit QLineEdit(const QString & = {}); > > > //The QObject::makeChild method: > template T* QObject::makeChild(Args&&... args) > { >   auto n = new T(std::forward(args)...); >   n->setParent(this); >   return n; > } > > > That way, std::make_unique still work, and constructing objects on the > stack does not change. > > For the cases where the parent in the constructor has another meaning, > we would need another factory function (makeChild) in the relevant > class. Or interept the ParentChanged, or reimplement setParent in that > class. > > What do you think? > Consider this "old" code: QWidget widget; QVBoxLayout *topLayout = new QVBoxLayout(&widget); QVBoxLayout *childLayout = new QVBoxLayout(); topLayout->addLayout(childLayout); That would, if I understood you correctly, translate too: QWidget widget; QVboxLayout *topLayout = widget.makeChild(); auto childLayout = std::make_unique(); topLayout-addLayout(std::move(childLayout)); Both topLayout and childLayout do end up with the same parent. In the old code, the QLayout ctor which takes a parent widget, calls QWidget::setLayout. Thus I think overriding setParent or interpreting ParentChanged would not work. Though makeChild could work, that is we would need: template T* QWidget::makeChild(Args&&... args) {   auto n = new T(std::forward(args)...);   n->setParent(this);   if constexpr(std::is_base_of)     setLayout(n);   return n; } I guess whether that is feasible depends on many ctors assign additional semantics to the parent parameter. daniel From alexander.blasche at qt.io Mon Jun 18 09:53:31 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 18 Jun 2018 07:53:31 +0000 Subject: [Development] =?windows-1252?q?Changing_maintainer-ship_for_Qt_A?= =?windows-1252?q?ssistant=2C_Qt_Help_and_Qt_Creator=92s_help_Integration?= In-Reply-To: References: , Message-ID: The proposed changes have been enacted. -- Alex ________________________________________ From: Development on behalf of Eike Ziller Sent: Monday, 28 May 2018 12:33:44 PM To: Karsten Heimrich Cc: development at qt-project.org Subject: Re: [Development] Changing maintainer-ship for Qt Assistant, Qt Help and Qt Creator’s help Integration +1 ! > On 28. May 2018, at 12:19, Karsten Heimrich wrote: > > Hi, > > officially I'm still the maintainer of Qt Assistant & Qt Help and Qt Creator’s help Integration. Since I actually no longer working on this code, I propose Jaroslaw Kobus as the new maintainer. Jarek has done a lot of good work on these modules recently and has been a very long time with Qt in general. > > > Regards, > Karsten > > Karsten Heimrich, Software engineer | The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der > Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From frederik.gladhorn at qt.io Mon Jun 18 11:04:33 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 18 Jun 2018 11:04:33 +0200 Subject: [Development] clang-format Message-ID: <1665868.Big65L9shF@frederik-thinkcentre-m93p> Hi all, as part of the closing ceremony of this year's Qt Contributors' Summit we agreed to start using clang-format, to have fewer discussions around coding style and rather focus on the actual code. I have not yet thought about all angles, how to best implement this, here are some notes: We have a clang-format file in qtrepotools. You can use it today, simply make sure it's in any parent directory of the files you are editing. I'd actually propose simply moving this into the root directory of qt5.git. https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format If you want to clean one file: clang-format -i myfile.cpp/h To clean a commit (only modifies the working tree): git clang-format Getting clang-format seems easy enough: On macOS: brew install clang-format Linux: install clang-format Windows: it comes with normal clang Then there is the tooling/workflow perspective. Creator and other IDEs have support (you may need to enable the beautifier plugin in about plugins). I imagine we add this to the sanity bot ("git clang-format --diff -q" should return empty, otherwise post a message). Local hooks are basically the same, any ideas how to best set up the git hooks appreciated :) And then there is the big question when we run it once over the entire codebase. Cheers, Frederik From kari.oikarinen at qt.io Mon Jun 18 11:23:53 2018 From: kari.oikarinen at qt.io (Kari Oikarinen) Date: Mon, 18 Jun 2018 12:23:53 +0300 Subject: [Development] clang-format In-Reply-To: <1665868.Big65L9shF@frederik-thinkcentre-m93p> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> Message-ID: <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> On 18.06.2018 12:04, Frederik Gladhorn wrote: Other parts sound good, so I'll just touch on the big question. > And then there is the big question when we run it once over the entire > codebase. I'd hesitate to ever run it over the entire codebase. * It will ruin plain git blame, since so much will point to that particular commit. Yes, you can use `git blame -w` to avoid whitespace changes, but that does not catch rewrapped lines. * Open changes would need to be rebased on top of it. When would be a good point in time with few open changes? * Which branch do you run it in? If an early one, there's many merges to do. If a late one, all the subsequent merges are tricky. It is quite a bit of pain while the benefit isn't that big. Actively worked on areas would shape up incrementally anyway and the other areas are not read that much, so the damage of inconsistent formatting is limited. For the above reasons I'd lean towards not running it globally and just using it on new changes. -- Kari From cavendish.qi at gmail.com Mon Jun 18 11:28:41 2018 From: cavendish.qi at gmail.com (Liang Qi) Date: Mon, 18 Jun 2018 11:28:41 +0200 Subject: [Development] clang-format In-Reply-To: <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> Message-ID: On Mon, 18 Jun 2018 at 11:23, Kari Oikarinen wrote: > On 18.06.2018 12:04, Frederik Gladhorn wrote: > > > Other parts sound good, so I'll just touch on the big question. > > > And then there is the big question when we run it once over the entire > > codebase. > > I'd hesitate to ever run it over the entire codebase. > > * It will ruin plain git blame, since so much will point to that particular > commit. Yes, you can use `git blame -w` to avoid whitespace changes, > but that > does not catch rewrapped lines. > > git-hyper-blame ? https://commondatastorage.googleapis.com/chrome-infra-docs/flat/depot_tools/docs/html/git-hyper-blame.html --Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Mon Jun 18 11:49:08 2018 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 18 Jun 2018 11:49:08 +0200 Subject: [Development] Fix for the Regression caused by the fix for QTBUG-16252 (QTBUG-68939) Message-ID: <3438586.Lb8nl5Vo2j@bola> Hi, I have come up with a PoC fix for the rendering glitch regression that was introduced by the fix for QTBUG-16252. In fact, it seems this fix forgot that the size(hint) for a dock area should be (0,0) when none of the widgets attached to that area are visible; failing to take that into account causes the dock area to be rendered as an empty space. To the user this looks as if the content view in the area surrounded by the docks doesn't size to take up all space available to it. My PoC fix just scans over all widgets attached to each of the dock areas under consideration, until it finds one that is not skipped, visible and not floating. I looked for but couldn't find a QDockArea state variable that registers whether or not the area in question is collapsed or expanded - did I miss something? Thanks, R. From alexander.blasche at qt.io Mon Jun 18 13:08:35 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 18 Jun 2018 11:08:35 +0000 Subject: [Development] Jira changes going forward In-Reply-To: References: , Message-ID: This implementation has started. Please be aware of changing component names. -- Alex ________________________________________ From: Development on behalf of Alex Blasche Sent: Thursday, 31 May 2018 2:42:51 PM To: development at qt-project.org; interest at qt-project.org Interest Subject: Re: [Development] Jira changes going forward This review has come to a conclusion. Based on reviews the major points have settled. The highlights of the changes are: - Internal Qt company requirements management will shift to public projects - Renaming and reordering of components (breaks existing filters) - Additional fields for Jira issues - Automatic closure/check of long pending "Need more Info" bugs where the bug reporter fails to provide information Implementation of those changes will happen during June. -- Alex ________________________________________ From: Development on behalf of Alex Blasche Sent: Wednesday, 2 May 2018 2:18:54 PM To: development at qt-project.org Subject: [Development] Jira changes going forward Hi, there are quite a few changes to Jira on my todo list. Some of them result from some internal TQtC process changes (related to public requirements mgmt) and others were put forward by individuals with a keen interest in improving things (thank you for that). Unfortunately some of proposals will break existing setups (especially filters). Since there are a lot of changes I chose to use gerrit for the discussion. A long mail is not able to provide the means to update and review the latest consensus. Please have a look at https://codereview.qt-project.org/#/c/225694/ The patch is not intended to be merged. It merely exists to facilitate the community discussion. However I might document some of the outcomes (especially process outcomes) somewhere later on. Thank you for your feedback. -- Alex _______________________________________________ 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 jhihn at gmx.com Mon Jun 18 13:33:21 2018 From: jhihn at gmx.com (Jason H) Date: Mon, 18 Jun 2018 13:33:21 +0200 Subject: [Development] RFC: unified data model API in QtCore => thin wrapper proposal In-Reply-To: <2100B6F7-960A-4F49-BA4D-960EEDCA9EF4@qt.io> References: <2100B6F7-960A-4F49-BA4D-960EEDCA9EF4@qt.io> Message-ID: +1 this. I'd prefer Arne's over the bind below. I do want value updates to be emitted so that we only have to change the data to keep dependent structures updated. I've suggested having some kind of xpath watcher facility... Having done some web UIs powered by a Ajax, (and qt will undoubtedly power some web backends) you need a facility to keep 2 trees in sync - the server data and the web UI model. However it should be the same for QML or widget UIs... And in my dream world, a proper QML web UI. But no matter how it works, you need to be able to broadcast minimal data changes to the tree to listeners (clients). > Sent: Friday, June 15, 2018 at 3:46 PM > From: "Tor Arne Vestbø" > To: "Arnaud Clère" > Cc: "Thiago Macieira" , "development at qt-project.org" > Subject: Re: [Development] RFC: unified data model API in QtCore => thin wrapper proposal > > > > > On 15 Jun 2018, at 13:31, Arnaud Clère wrote: > > > [snip] > > > Most user-defined bind methods would be very simple and the type system would > > guarantee that data is well-formed (no sequence or record left open...): > > > > struct Person { > > QString m_firstName, m_lastName; > > int m_age; > > > > template > > TResult bind(Val value) { return value > > .record() > > .sequence("name") > > .bind(m_firstName) > > .bind(m_lastName) > > .out() > > .bind("age" , m_age); // automagically closes opened record > > } > > }; > > Not commenting on this API, but I’d like to note that the API I brought up as “missing” from my use-case was a more “light weight” in-place edit API, where the user does not have to define bindings to data structures like above. Similar to e.g. python: > > >>> data = json.loads('{ "foo": [1, 2, 3] }') > >>> data > {u'foo': [1, 2, 3]} > >>> data["foo"][0] = 42 > >>> data > {u'foo': [42, 2, 3]} > > With our existing APIs I’d expect: > > QJsonDocument doc; > doc[“foo”][0] = 42; > > Tor Arne > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From dmitry.volosnykh at gmail.com Mon Jun 18 13:40:02 2018 From: dmitry.volosnykh at gmail.com (Dmitry Volosnykh) Date: Mon, 18 Jun 2018 14:40:02 +0300 Subject: [Development] RFC: unified data model API in QtCore => thin wrapper proposal In-Reply-To: References: <2100B6F7-960A-4F49-BA4D-960EEDCA9EF4@qt.io> Message-ID: FYI, there's QTBUG-29095 and QTBUG-25723 that feel like somewhat related to the problem under discussion. On Mon, Jun 18, 2018 at 2:33 PM Jason H wrote: > +1 this. > > I'd prefer Arne's over the bind below. I do want value updates to be > emitted so that we only have to change the data to keep dependent > structures updated. I've suggested having some kind of xpath watcher > facility... > > Having done some web UIs powered by a Ajax, (and qt will undoubtedly power > some web backends) you need a facility to keep 2 trees in sync - the server > data and the web UI model. However it should be the same for QML or widget > UIs... And in my dream world, a proper QML web UI. But no matter how it > works, you need to be able to broadcast minimal data changes to the tree to > listeners (clients). > > > > > > Sent: Friday, June 15, 2018 at 3:46 PM > > From: "Tor Arne Vestbø" > > To: "Arnaud Clère" > > Cc: "Thiago Macieira" , " > development at qt-project.org" > > Subject: Re: [Development] RFC: unified data model API in QtCore => thin > wrapper proposal > > > > > > > > > On 15 Jun 2018, at 13:31, Arnaud Clère > wrote: > > > > > [snip] > > > > > Most user-defined bind methods would be very simple and the type > system would > > > guarantee that data is well-formed (no sequence or record left > open...): > > > > > > struct Person { > > > QString m_firstName, m_lastName; > > > int m_age; > > > > > > template > > > TResult bind(Val value) { return value > > > .record() > > > .sequence("name") > > > .bind(m_firstName) > > > .bind(m_lastName) > > > .out() > > > .bind("age" , m_age); // automagically closes opened > record > > > } > > > }; > > > > Not commenting on this API, but I’d like to note that the API I brought > up as “missing” from my use-case was a more “light weight” in-place edit > API, where the user does not have to define bindings to data structures > like above. Similar to e.g. python: > > > > >>> data = json.loads('{ "foo": [1, 2, 3] }') > > >>> data > > {u'foo': [1, 2, 3]} > > >>> data["foo"][0] = 42 > > >>> data > > {u'foo': [42, 2, 3]} > > > > With our existing APIs I’d expect: > > > > QJsonDocument doc; > > doc[“foo”][0] = 42; > > > > Tor Arne > > _______________________________________________ > > 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 arnaud.clere at minmaxmedical.com Mon Jun 18 18:35:43 2018 From: arnaud.clere at minmaxmedical.com (=?utf-8?B?QXJuYXVkIENsw6hyZQ==?=) Date: Mon, 18 Jun 2018 16:35:43 +0000 Subject: [Development] RFC: unified data model API in QtCore => thin wrapper proposal In-Reply-To: References: <2100B6F7-960A-4F49-BA4D-960EEDCA9EF4@qt.io> Message-ID: > From: Dmitry Volosnykh > Sent: lundi 18 juin 2018 13:40 > > FYI, there's QTBUG-29095 and QTBUG-25723 that feel like somewhat related to the problem under discussion. I guess QTBUG-25723 is the kind of problem that Thiago solved for QCborValue For the use case described in QTBUG-29095, I think my QBind proposal could be used instead of QJsonDocument. For instance, it can iterate over a possibly infinite JSON sequence, binding one item at a time to an appropriate in-memory data structure. So you would have to worry about accidental detaches and could use the in-memory data structure to filter or modify each item. MyItem myItem; auto i = QJsonReader(&file).begin().sequence().item(); while (i) { i = i.bind(myItem); // do whatever you want to myItem } > On Mon, Jun 18, 2018 at 2:33 PM Jason H wrote: > +1 this. > I'd prefer Arne's over the bind below. I do want value updates to be emitted so that we only have to change the data to keep dependent structures updated. I've suggested having some kind of xpath watcher facility... > Having done some web UIs powered by a Ajax, (and qt will undoubtedly power some web backends) you need a facility to keep 2 trees in sync - the server data and the web UI model. However it should be the same for QML or widget UIs... And in my dream world, a proper QML web UI. But no matter how it works, you need to be able to broadcast minimal data changes to the tree to listeners (clients). Not sure I understand you correctly. If you miss a generic data structure with in-place editing, QCborValue or QJsonValue (sharing the same backend) may be a candidate, as are QVariant* or your own classes. QBind is not a data structure but a kind of generic iterator for data structures. However, since QBind can traverse any data structure in a generic way, it can be used to serialize/deserialize you own specific data structures without having to first convert them to a generic data structure such as QCborValue. Converting to QCborValue would only be required to use specific Cbor features such as tags. > > Sent: Friday, June 15, 2018 at 3:46 PM > > From: "Tor Arne Vestbø" > > > > Not commenting on this API, but I’d like to note that the API I brought up as “missing” from my use-case was a more “light weight” in-place edit API, where the user does not have to define bindings to data structures like above. Similar to e.g. python: I guess the same answer as above applies. BTW, I have committed a QBind POC on our gitlab to explain what I am talking about: https://gricad-gitlab.univ-grenoble-alpes.fr/modmed/modmedLog/tree/f6b257d806ee50db2c5c86d90757b54ec898391b/tests/QBind Again, this POC does not provide any in-memory data structure, it just demonstrates how to traverse data structures in a way that is generic enough to be serialized in different ways. The POC is voluntarily "condensed" in a single main.cpp file + an alternate QCborWriter.hpp implementation. The QJsonWriter now demonstrates same or better performance than hand-written serialization using QDebug, and QCborWriter is 2 to 3 times more efficient than QDebug. As opposed to QDebug, it guarantees well-formedness of the data, so it can always be re-read. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joerg.bornemann at qt.io Tue Jun 19 09:58:52 2018 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Tue, 19 Jun 2018 09:58:52 +0200 Subject: [Development] clang-format In-Reply-To: <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> Message-ID: <8a80c634-f1e0-c682-8ccf-9fd173b65fe2@qt.io> On 06/18/2018 11:23 AM, Kari Oikarinen wrote: > I'd hesitate to ever run it over the entire codebase. > > * It will ruin plain git blame, since so much will point to that particular >   commit. Yes, you can use `git blame -w` to avoid whitespace changes, > but that >   does not catch rewrapped lines. In my experience, plain "git blame" is not enough in most cases anyway. You go back in history and skip commits you're not interested in. One cleanup commit more to skip doesn't really hurt. > * Open changes would need to be rebased on top of it. When would be a > good point >   in time with few open changes? Summer holidays? :) I guess there's no perfect point in time. Some open changes will have to be rebased. This also happens if someone else is working in the area your commit touched. Just a minor annoyance IMO. > * Which branch do you run it in? If an early one, there's many merges to > do. If >   a late one, all the subsequent merges are tricky. Our commit policy suggests that the right branch would be dev. You're right that the merges will be harder. What's the opinion of our merge master? Cheers, Joerg From lars.knoll at qt.io Tue Jun 19 11:34:09 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 19 Jun 2018 09:34:09 +0000 Subject: [Development] clang-format In-Reply-To: <8a80c634-f1e0-c682-8ccf-9fd173b65fe2@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <8a80c634-f1e0-c682-8ccf-9fd173b65fe2@qt.io> Message-ID: > On 19 Jun 2018, at 09:58, Joerg Bornemann wrote: > > On 06/18/2018 11:23 AM, Kari Oikarinen wrote: > >> I'd hesitate to ever run it over the entire codebase. >> * It will ruin plain git blame, since so much will point to that particular >> commit. Yes, you can use `git blame -w` to avoid whitespace changes, but that >> does not catch rewrapped lines. > > In my experience, plain "git blame" is not enough in most cases anyway. You go back in history and skip commits you're not interested in. One cleanup commit more to skip doesn't really hurt. I agree, and Qt Creator makes that actually pretty easy in practice. > >> * Open changes would need to be rebased on top of it. When would be a good point >> in time with few open changes? > > Summer holidays? :) > I guess there's no perfect point in time. Some open changes will have to be rebased. This also happens if someone else is working in the area your commit touched. Just a minor annoyance IMO. Some time during summer is fine for me. But we’ll need to have the infra in place, so that formatting is enforced for new changes. > >> * Which branch do you run it in? If an early one, there's many merges to do. If >> a late one, all the subsequent merges are tricky. > > Our commit policy suggests that the right branch would be dev. > You're right that the merges will be harder. What's the opinion of our merge master? Currently, we only merge from 5.11 to dev, so I hope this won’t be too bad. But we could of course also run the tool over both branches. Cheers, Lars From jani.heikkinen at qt.io Tue Jun 19 13:43:33 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 19 Jun 2018 11:43:33 +0000 Subject: [Development] Qt 5.11.1 Released In-Reply-To: References: Message-ID: Hi! We have released Qt 5.11.1 today, see http://blog.qt.io/blog/2018/06/19/qt-5-11-1-released/ Big thanks to everyone involved! br, Jani Heikkinen Release Manager From kde at carewolf.com Tue Jun 19 16:35:03 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Tue, 19 Jun 2018 16:35:03 +0200 Subject: [Development] clang-format In-Reply-To: <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> Message-ID: <2480324.3FRIcKpKcF@twilight> On Montag, 18. Juni 2018 11:23:53 CEST Kari Oikarinen wrote: > On 18.06.2018 12:04, Frederik Gladhorn wrote: > > > Other parts sound good, so I'll just touch on the big question. > > > And then there is the big question when we run it once over the entire > > codebase. > > I'd hesitate to ever run it over the entire codebase. > I would prefer the same. Especially since the first few iterations of the formating are not going to be good. If the goal is to minimize the amount of back-and-forth during code-review, then we only need to apply it to new patches. And while there are ways around the noise generated, there is really no good reason to generate all that noise and auto-uglify the code. 'Allan From Liang.Qi at qt.io Tue Jun 19 16:53:41 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Tue, 19 Jun 2018 14:53:41 +0000 Subject: [Development] clang-format In-Reply-To: <8a80c634-f1e0-c682-8ccf-9fd173b65fe2@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <8a80c634-f1e0-c682-8ccf-9fd173b65fe2@qt.io> Message-ID: > On 19 Jun 2018, at 09:58, Joerg Bornemann wrote: > >> * Which branch do you run it in? If an early one, there's many merges to do. If >> a late one, all the subsequent merges are tricky. > > Our commit policy suggests that the right branch would be dev. > You're right that the merges will be harder. What's the opinion of our merge master? > > We will have 5.11 for a while, perhaps a 5.11.2 after summer at least. So better to do it in 5.11, and after it got merged in dev, then do it in dev again. That should help merge a lot. — Liang From kde at carewolf.com Tue Jun 19 17:33:30 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Tue, 19 Jun 2018 17:33:30 +0200 Subject: [Development] clang-format In-Reply-To: <1665868.Big65L9shF@frederik-thinkcentre-m93p> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> Message-ID: <2301967.FbfvzRaAGg@twilight> Btw. Just for your information. I have attached a few random examples of what we can look forward too after running an auto-"beautifying" tool over our hand-formated Qt code. And these changes are NOT something we can configure out ouf of in clang-format, it is just cases where it can't do any better. -------------- next part -------------- Before: // QStringRef <> QByteArray inline QT_ASCII_CAST_WARN bool operator==(const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) == 0; } inline QT_ASCII_CAST_WARN bool operator!=(const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) != 0; } inline QT_ASCII_CAST_WARN bool operator< (const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) < 0; } inline QT_ASCII_CAST_WARN bool operator> (const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) > 0; } inline QT_ASCII_CAST_WARN bool operator<=(const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) <= 0; } inline QT_ASCII_CAST_WARN bool operator>=(const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) >= 0; } inline QT_ASCII_CAST_WARN bool operator==(const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) == 0; } inline QT_ASCII_CAST_WARN bool operator!=(const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) != 0; } inline QT_ASCII_CAST_WARN bool operator< (const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) > 0; } inline QT_ASCII_CAST_WARN bool operator> (const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) < 0; } inline QT_ASCII_CAST_WARN bool operator<=(const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) >= 0; } inline QT_ASCII_CAST_WARN bool operator>=(const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) <= 0; } After: // QStringRef <> QByteArray inline QT_ASCII_CAST_WARN bool operator==(const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) == 0; } inline QT_ASCII_CAST_WARN bool operator!=(const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) != 0; } inline QT_ASCII_CAST_WARN bool operator<(const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) < 0; } inline QT_ASCII_CAST_WARN bool operator>(const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) > 0; } inline QT_ASCII_CAST_WARN bool operator<=(const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) <= 0; } inline QT_ASCII_CAST_WARN bool operator>=(const QStringRef &lhs, const QByteArray &rhs) { return lhs.compare(rhs) >= 0; } inline QT_ASCII_CAST_WARN bool operator==(const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) == 0; } inline QT_ASCII_CAST_WARN bool operator!=(const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) != 0; } inline QT_ASCII_CAST_WARN bool operator<(const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) > 0; } inline QT_ASCII_CAST_WARN bool operator>(const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) < 0; } inline QT_ASCII_CAST_WARN bool operator<=(const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) >= 0; } inline QT_ASCII_CAST_WARN bool operator>=(const QByteArray &lhs, const QStringRef &rhs) { return rhs.compare(lhs) <= 0; } Before: #define QT_MEMCPY_USHORT(dest, src, length) \ do { \ /* Duff's device */ \ ushort *_d = (ushort*)(dest); \ const ushort *_s = (const ushort*)(src); \ int n = ((length) + 7) / 8; \ switch ((length) & 0x07) \ { \ case 0: do { *_d++ = *_s++; Q_FALLTHROUGH(); \ case 7: *_d++ = *_s++; Q_FALLTHROUGH(); \ case 6: *_d++ = *_s++; Q_FALLTHROUGH(); \ case 5: *_d++ = *_s++; Q_FALLTHROUGH(); \ case 4: *_d++ = *_s++; Q_FALLTHROUGH(); \ case 3: *_d++ = *_s++; Q_FALLTHROUGH(); \ case 2: *_d++ = *_s++; Q_FALLTHROUGH(); \ case 1: *_d++ = *_s++; \ } while (--n > 0); \ } \ } while (false) inline ushort qConvertRgb32To16(uint c) { return (((c) >> 3) & 0x001f) | (((c) >> 5) & 0x07e0) | (((c) >> 8) & 0xf800); } inline QRgb qConvertRgb16To32(uint c) { return 0xff000000 | ((((c) << 3) & 0xf8) | (((c) >> 2) & 0x7)) | ((((c) << 5) & 0xfc00) | (((c) >> 1) & 0x300)) | ((((c) << 8) & 0xf80000) | (((c) << 3) & 0x70000)); } After: #define QT_MEMCPY_USHORT(dest, src, length) \ do { \ /* Duff's device */ \ ushort *_d = (ushort *)(dest); \ const ushort *_s = (const ushort *)(src); \ int n = ((length) + 7) / 8; \ switch ((length)&0x07) { \ case 0: \ do { \ *_d++ = *_s++; \ Q_FALLTHROUGH(); \ case 7: \ *_d++ = *_s++; \ Q_FALLTHROUGH(); \ case 6: \ *_d++ = *_s++; \ Q_FALLTHROUGH(); \ case 5: \ *_d++ = *_s++; \ Q_FALLTHROUGH(); \ case 4: \ *_d++ = *_s++; \ Q_FALLTHROUGH(); \ case 3: \ *_d++ = *_s++; \ Q_FALLTHROUGH(); \ case 2: \ *_d++ = *_s++; \ Q_FALLTHROUGH(); \ case 1: \ *_d++ = *_s++; \ } while (--n > 0); \ } \ } while (false) inline ushort qConvertRgb32To16(uint c) { return (((c) >> 3) & 0x001f) | (((c) >> 5) & 0x07e0) | (((c) >> 8) & 0xf800); } inline QRgb qConvertRgb16To32(uint c) { return 0xff000000 | ((((c) << 3) & 0xf8) | (((c) >> 2) & 0x7)) | ((((c) << 5) & 0xfc00) | (((c) >> 1) & 0x300)) | ((((c) << 8) & 0xf80000) | (((c) << 3) & 0x70000)); } From thiago.macieira at intel.com Tue Jun 19 17:38:06 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jun 2018 08:38:06 -0700 Subject: [Development] clang-format In-Reply-To: <1665868.Big65L9shF@frederik-thinkcentre-m93p> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> Message-ID: <2298245.Zha9a4ZE8i@tjmaciei-mobl1> On Monday, 18 June 2018 02:04:33 PDT Frederik Gladhorn wrote: > as part of the closing ceremony of this year's Qt Contributors' Summit we > agreed to start using clang-format, to have fewer discussions around coding > style and rather focus on the actual code. Are we going to review the resulting format? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jun 19 17:51:28 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jun 2018 08:51:28 -0700 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8a80c634-f1e0-c682-8ccf-9fd173b65fe2@qt.io> Message-ID: <1994953.cDbqxsKW4M@tjmaciei-mobl1> On Tuesday, 19 June 2018 02:34:09 PDT Lars Knoll wrote: > Currently, we only merge from 5.11 to dev, so I hope this won’t be too bad. > But we could of course also run the tool over both branches. I have right now 149 changes on top of qtbase's dev branch. For something that is ostensibly a whitespace change, I will dedicate no more than 1 minute per change to resolve a conflict or 15 minutes total to rebase my branch once it goes in. Any change that times out will be dropped. That includes all the Qt 6 container work, the un-accepted QtDBus updates (which include a QDBusConnection::connect taking PMF), a large refactoring of QFileSystemEngine that no one has reviewed yet despite being on Gerrit for over a year, some work for CBOR and a few other miscellaneous changes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philwave at gmail.com Tue Jun 19 18:13:41 2018 From: philwave at gmail.com (Philippe) Date: Tue, 19 Jun 2018 18:13:41 +0200 Subject: [Development] clang-format In-Reply-To: <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> Message-ID: <20180619181340.5380.6F0322A@gmail.com> > For the above reasons I'd lean towards not running it globally and just using it > on new changes. +1, based on my clang-format experience on a big application. BTW, keep in mind that you can disable clang-format on code sections with: // clang-format off // clang-format on Philippe On Mon, 18 Jun 2018 12:23:53 +0300 Kari Oikarinen wrote: > > > On 18.06.2018 12:04, Frederik Gladhorn wrote: > > > Other parts sound good, so I'll just touch on the big question. > > > And then there is the big question when we run it once over the entire > > codebase. > > I'd hesitate to ever run it over the entire codebase. > > * It will ruin plain git blame, since so much will point to that particular > commit. Yes, you can use `git blame -w` to avoid whitespace changes, but that > does not catch rewrapped lines. > > * Open changes would need to be rebased on top of it. When would be a good point > in time with few open changes? > > * Which branch do you run it in? If an early one, there's many merges to do. If > a late one, all the subsequent merges are tricky. > > It is quite a bit of pain while the benefit isn't that big. Actively worked on > areas would shape up incrementally anyway and the other areas are not read that > much, so the damage of inconsistent formatting is limited. > > For the above reasons I'd lean towards not running it globally and just using it > on new changes. > > -- Kari > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ville.voutilainen at gmail.com Tue Jun 19 18:19:11 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Tue, 19 Jun 2018 19:19:11 +0300 Subject: [Development] clang-format In-Reply-To: <20180619181340.5380.6F0322A@gmail.com> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> Message-ID: On 19 June 2018 at 19:13, Philippe wrote: >> For the above reasons I'd lean towards not running it globally and just using it >> on new changes. > > +1, based on my clang-format experience on a big application. > > BTW, keep in mind that you can disable clang-format on code sections with: > > // clang-format off > // clang-format on When I last experienced a large-scale clang-format reformat, it really hurt development during the churn. We should somehow manage to do it during a time when there aren't many pending patches in the pipeline. I'm not concerned about git-blame; that has never been a problem after reformats. However, I do not care about indentation nor do I want to spend time on it either way, it has no actual effect on readability and maintainability of code, and consistency outside the file you're in has never mattered to me one bit. IOW, I'm not opposed to reformats and auto-checking of clang-format (or even hooking it), but I do not see it as a thing with all that great return-of-investment. From Simon.Hausmann at qt.io Tue Jun 19 18:33:28 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 19 Jun 2018 16:33:28 +0000 Subject: [Development] Merge and Integration status report In-Reply-To: References: , Message-ID: Hi, It is not a permission issue as far as I can see (literally). Our best guess at the moment is that some underlying change caused a performance degradation. That combined with the fact that the CI runs all tests three times in debug-and-release configurations increases the changes of the failure aborting the integration enough to cause the blockage. Ulf has now submitted a workaround that should also allow us to get an overview of running processes if it doesn't work. We've got a set of changes trying integration in 5.11 with that workaround merged and I'll try to get this also into dev. Simon ________________________________ From: Tomasz Olszak Sent: Saturday, June 16, 2018 12:59:46 PM To: Simon Hausmann Cc: Jani Heikkinen; development at qt-project.org Subject: Re: [Development] Merge and Integration status report Do you use up to date Win 10? Recent updates introduced many issue. E.g one of our app couldn't install with some privilege/policy access denied error. It was not clear from logs what happened. By trial and errors we just enabled camera for applications in security settings and it started to work. It might be good idea to reverse a few updates and check if it works. sob., 16 cze 2018, 11:08 użytkownik Simon Hausmann > napisał: Hi, Unfortunately we haven’t found a solution or workaround yet - the module remains blocked. We can observe some virtual machines slowing down to a grinding halt and we can observe that quite often at boot time. The latter causes the CI to kill the vm after some time and try creating a new one. That story repeats itself until finally a situation/host is found where everything works. This also makes overall integration times slower. We can also observe how every test in debug-and-release is run three times and with flaky tests as in this case that increases the probability of an overall failure and it increases the overall time to test for all projects. What nobody has managed to do so far is reproduce the declarative failure in front of human eyes. Whenever observed through the hypervisor’s vnc interface it appears to work smoothly. One thing that is unclear to me is what exactly has changed that causes this, because I think that given the spread across branches it was not a change in declarative or qtbase. Unfortunately we do not have a journal of sorts that records what changes were done on the infrastructure at what time. It might even be an innocent change that triggered an actual bug in declarative. Does anybody see odd test failures that seem performance related in other modules, across branches? Simon On 14. Jun 2018, at 10:53, Simon Hausmann > wrote: Yes, that is another issue. But before that qtbase issue started showing up, the same change to 5.11.1 that you're trying to integrated failed when running a test that launches a separate process of testing the debugging integration. So once the qtbase issue is resolved it's likely that you'll run into the declarative failure again. Simon ________________________________ From: Jani Heikkinen Sent: Thursday, June 14, 2018 10:47:43 AM To: Simon Hausmann; development at qt-project.org Subject: Re: Merge and Integration status report Actually at least 5.11.1 declarative integration failure is timeout in qtbase -> Linux QEMU (gcc-armv7) build. So the failure is different there (in case it helps anything) br, Jani ________________________________________ From: Development > on behalf of Simon Hausmann > Sent: Thursday, June 14, 2018 10:32 AM To: development at qt-project.org Subject: Re: [Development] Merge and Integration status report Hi, Thank you Liang for the report. On top of that, qtdeclarative is not accepting any changes in the 5.9, 5.11, 5.11.1 and dev branches right now. Those who may have tried staging changes there may have noticed that they are failing in one of the tests that launch a separate process for testing the debugging integration, limited to Windows 10 (x86 and x86-64). Until we've found the root cause or a suitable workaround, please don't stage changes to qtdeclarative. I can't see any recent common changes to qtbase or declarative that apply to all _four_ branches, so I suspect this flaky issue was caused by something below those two modules. I'll post an update here when we've figured it out (workaround or solution). Simon ________________________________ From: Development > on behalf of Liang Qi > Sent: Thursday, June 14, 2018 9:18:32 AM To: development at qt-project.org Subject: [Development] Merge and Integration status report Integrations * qt5 dev integration failed from June 2, a submodule update without qtdeclarative was done on June. 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68666 declarative_core::MappingManagerError::test_error() failed * * * https://codereview.qt-project.org/#/c/222768 Simon is working on that since yesterday * qt5 5.11 integration failed from June 9 * * Issue: https://bugreports.qt.io/browse/QTBUG-68773 qtwayland build failed - can't find some headers * * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, Oswald please help to review it. * * Issue: https://bugreports.qt.io/browse/QTBUG-68741 tst_QQmlDebuggingEnabler::qmlscene() failed _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.hermann at qt.io Tue Jun 19 18:41:02 2018 From: ulf.hermann at qt.io (Ulf Hermann) Date: Tue, 19 Jun 2018 18:41:02 +0200 Subject: [Development] Merge and Integration status report In-Reply-To: References: Message-ID: <526c92ba-78ad-7c53-034c-259111d4b9a8@qt.io> Hi, > Ulf has now submitted a workaround that should also allow us to get > an overview of running processes if it doesn't work. We've got a set > of changes trying integration in 5.11 with that workaround merged and > I'll try to get this also into dev. Nope, that didn't work. The slowdown lasts less than 15 minutes, but long enough to trigger a timeout in the debugging tests after it goes away. So, we don't get the watchdog to kill the tests (which would show the concurrently running processes), but the tests still fail. See https://bugreports.qt.io/browse/QTBUG-68741 for details. We either got incredibly lucky with https://codereview.qt-project.org/231618 or the CI has another bug and accepted this test although it shouldn't. br, Ulf From thiago.macieira at intel.com Tue Jun 19 21:46:28 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jun 2018 12:46:28 -0700 Subject: [Development] Monitoring of upstream vulnerabilities Message-ID: <10055298.oqixaenVh0@tjmaciei-mobl1> As part of the discussion on 3rdparty and security at QtCS, I took an action to look into what we use in Clear Linux to monitor for reported vulnerabilities. Currently, we use https://github.com/clearlinux/cve-check-tool. This is going to be replaced with CVEMAN - https://github.intel.com/kcwells/cveman. Both tools consume the feed from the National Vulnerability Database from the US NIST - https://nvd.nist.gov/. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Tue Jun 19 22:15:18 2018 From: jhihn at gmx.com (Jason H) Date: Tue, 19 Jun 2018 22:15:18 +0200 Subject: [Development] Monitoring of upstream vulnerabilities In-Reply-To: <10055298.oqixaenVh0@tjmaciei-mobl1> References: <10055298.oqixaenVh0@tjmaciei-mobl1> Message-ID: > Sent: Tuesday, June 19, 2018 at 3:46 PM > From: "Thiago Macieira" > To: development at qt-project.org > Subject: [Development] Monitoring of upstream vulnerabilities > > As part of the discussion on 3rdparty and security at QtCS, I took an action > to look into what we use in Clear Linux to monitor for reported > vulnerabilities. > > Currently, we use https://github.com/clearlinux/cve-check-tool. This is going > to be replaced with CVEMAN - https://github.intel.com/kcwells/cveman. Both > tools consume the feed from the National Vulnerability Database from the US > NIST - https://nvd.nist.gov/. Is that intel server publicly accessible? From thiago.macieira at intel.com Tue Jun 19 22:50:54 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jun 2018 13:50:54 -0700 Subject: [Development] Monitoring of upstream vulnerabilities In-Reply-To: References: <10055298.oqixaenVh0@tjmaciei-mobl1> Message-ID: <3034541.PsX7Z8mn3E@tjmaciei-mobl1> On Tuesday, 19 June 2018 13:15:18 PDT Jason H wrote: > > Currently, we use https://github.com/clearlinux/cve-check-tool. This is > > going to be replaced with CVEMAN - > > https://github.intel.com/kcwells/cveman. Both tools consume the feed from > > the National Vulnerability Database from the US NIST - > > https://nvd.nist.gov/. > > Is that intel server publicly accessible? The dashboard the tool produces isn't, but I also don't see why you'd want that. It's not applicable to Qt. The only people who would want access to it are the people who are working on the distribution and will apply the patches. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From schluchti at gmail.com Tue Jun 19 23:04:45 2018 From: schluchti at gmail.com (Bernhard B) Date: Tue, 19 Jun 2018 23:04:45 +0200 Subject: [Development] Monitoring of upstream vulnerabilities In-Reply-To: <3034541.PsX7Z8mn3E@tjmaciei-mobl1> References: <10055298.oqixaenVh0@tjmaciei-mobl1> <3034541.PsX7Z8mn3E@tjmaciei-mobl1> Message-ID: Sorry, I don't get it. But what's the point of providing a link to the Intel github rpo if we can't access it? Am Dienstag, 19. Juni 2018 schrieb Thiago Macieira : > On Tuesday, 19 June 2018 13:15:18 PDT Jason H wrote: > > > Currently, we use https://github.com/clearlinux/cve-check-tool. This > is > > > going to be replaced with CVEMAN - > > > https://github.intel.com/kcwells/cveman. Both tools consume the feed > from > > > the National Vulnerability Database from the US NIST - > > > https://nvd.nist.gov/. > > > > Is that intel server publicly accessible? > > The dashboard the tool produces isn't, but I also don't see why you'd want > that. It's not applicable to Qt. The only people who would want access to > it > are the people who are working on the distribution and will apply the > patches. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Jun 19 23:13:58 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jun 2018 14:13:58 -0700 Subject: [Development] Monitoring of upstream vulnerabilities In-Reply-To: References: <10055298.oqixaenVh0@tjmaciei-mobl1> <3034541.PsX7Z8mn3E@tjmaciei-mobl1> Message-ID: <2082046.6kd3sdcPCf@tjmaciei-mobl1> On Tuesday, 19 June 2018 14:04:45 PDT Bernhard B wrote: > Sorry, I don't get it. But what's the point of providing a link to the > Intel github rpo if we can't access it? Because I didn't realise the tool wasn't public. I saw github and thought it was. Sorry about that. Well, CVEMAN will be made public some time, hopefully. It's still in development. For now, the other tool works. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jhihn at gmx.com Tue Jun 19 23:15:30 2018 From: jhihn at gmx.com (Jason H) Date: Tue, 19 Jun 2018 23:15:30 +0200 Subject: [Development] Monitoring of upstream vulnerabilities In-Reply-To: <3034541.PsX7Z8mn3E@tjmaciei-mobl1> References: <10055298.oqixaenVh0@tjmaciei-mobl1> <3034541.PsX7Z8mn3E@tjmaciei-mobl1> Message-ID: > Sent: Tuesday, June 19, 2018 at 4:50 PM > From: "Thiago Macieira" > To: development at qt-project.org > Subject: Re: [Development] Monitoring of upstream vulnerabilities > > On Tuesday, 19 June 2018 13:15:18 PDT Jason H wrote: > > > Currently, we use https://github.com/clearlinux/cve-check-tool. This is > > > going to be replaced with CVEMAN - > > > https://github.intel.com/kcwells/cveman. Both tools consume the feed from > > > the National Vulnerability Database from the US NIST - > > > https://nvd.nist.gov/. > > > > Is that intel server publicly accessible? > > The dashboard the tool produces isn't, but I also don't see why you'd want > that. It's not applicable to Qt. The only people who would want access to it > are the people who are working on the distribution and will apply the patches. !? The first link is a publicly accessible project. I thought you were referring to a replacement project. I wanted to see what CVEMAN was, why it was better, etc., (having never hard of it before) and see if it was something I might be interested in. But if it's not publicly accessible I wonder how open Qt is if we can't use all the tools Qt does. It could be valid that I don't need to worry, but how does the bind Qt to a private tool? I don't want to make a mountain out of a mole hill, but with all the transparency in Qt, I just expected it to be accessible is all. From schluchti at gmail.com Tue Jun 19 23:22:56 2018 From: schluchti at gmail.com (Bernhard B) Date: Tue, 19 Jun 2018 23:22:56 +0200 Subject: [Development] Monitoring of upstream vulnerabilities In-Reply-To: <2082046.6kd3sdcPCf@tjmaciei-mobl1> References: <10055298.oqixaenVh0@tjmaciei-mobl1> <3034541.PsX7Z8mn3E@tjmaciei-mobl1> <2082046.6kd3sdcPCf@tjmaciei-mobl1> Message-ID: > > Because I didn't realise the tool wasn't public. I saw github and thought > it > was. Sorry about that. > > Well, CVEMAN will be made public some time, hopefully. It's still in > development. For now, the other tool works. > Many thanks for the clarification! On a side note: Do you know an estimated timeframe for when it will be publicly available? Would be really interested in the details. 2018-06-19 23:13 GMT+02:00 Thiago Macieira : > On Tuesday, 19 June 2018 14:04:45 PDT Bernhard B wrote: > > Sorry, I don't get it. But what's the point of providing a link to the > > Intel github rpo if we can't access it? > > Because I didn't realise the tool wasn't public. I saw github and thought > it > was. Sorry about that. > > Well, CVEMAN will be made public some time, hopefully. It's still in > development. For now, the other tool works. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Jun 19 23:48:39 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jun 2018 14:48:39 -0700 Subject: [Development] Monitoring of upstream vulnerabilities In-Reply-To: References: <10055298.oqixaenVh0@tjmaciei-mobl1> <2082046.6kd3sdcPCf@tjmaciei-mobl1> Message-ID: <1973172.4j8hnCvAr7@tjmaciei-mobl1> On Tuesday, 19 June 2018 14:22:56 PDT Bernhard B wrote: > On a side note: Do you know an estimated timeframe for when it will be > publicly available? > Would be really interested in the details. I didn't know it existed until this morning, so no. And, of course, we began discussing the logo the tool should use, so... The cve-check-tool should suffice for now. Or reading directly from the NIST database, with specific filters for the software that Qt has as third-party. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gmail.com Wed Jun 20 07:06:43 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Wed, 20 Jun 2018 17:06:43 +1200 Subject: [Development] clang-format In-Reply-To: <2301967.FbfvzRaAGg@twilight> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <2301967.FbfvzRaAGg@twilight> Message-ID: On 20 June 2018 at 03:33, Allan Sandfeld Jensen wrote: > Btw. Just for your information. > > I have attached a few random examples of what we can look forward too after > running an auto-"beautifying" tool over our hand-formated Qt code. And these > changes are NOT something we can configure out ouf of in clang-format, it is > just cases where it can't do any better. You can surround code with "// clang-format off" and "// clang-format on". We've switched to clang-format in git hooks when clang-6 got out, and it works well. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From lars.knoll at qt.io Wed Jun 20 08:30:26 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 20 Jun 2018 06:30:26 +0000 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> Message-ID: <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> > On 19 Jun 2018, at 18:19, Ville Voutilainen wrote: > > On 19 June 2018 at 19:13, Philippe wrote: >>> For the above reasons I'd lean towards not running it globally and just using it >>> on new changes. >> >> +1, based on my clang-format experience on a big application. >> >> BTW, keep in mind that you can disable clang-format on code sections with: >> >> // clang-format off >> // clang-format on > > When I last experienced a large-scale clang-format reformat, it really > hurt development > during the churn. We should somehow manage to do it during a time when > there aren't > many pending patches in the pipeline. I'm not concerned about > git-blame; that has never > been a problem after reformats. However, I do not care about > indentation nor do I want > to spend time on it either way, it has no actual effect on readability > and maintainability > of code, and consistency outside the file you're in has never mattered > to me one bit. > > IOW, I'm not opposed to reformats and auto-checking of clang-format > (or even hooking it), > but I do not see it as a thing with all that great return-of-investment. It helps in that you do not need to point those things out in code reviews, and that I (and others) won’t even create changes with wrong formatting that I’ll need to fix up later on. It’s part of a larger story, where I would like to get as much automatic checking of changes done before humans start reviewing. One idea could be to introduce this incrementally. Let’s first start off with enforcing it for new changes. Then we run it globally over the code base shortly before Qt 6.0 is being released. At that time merges shouldn’t be as much of a problem (as we’ll probably cherry-pick into Qt 5.15) and by then all new changes in Gerrit will be properly formatted (due to the earlier hook). Cheers, Lars From kari.oikarinen at qt.io Wed Jun 20 09:02:43 2018 From: kari.oikarinen at qt.io (Kari Oikarinen) Date: Wed, 20 Jun 2018 10:02:43 +0300 Subject: [Development] clang-format In-Reply-To: <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> Message-ID: On 20.06.2018 09:30, Lars Knoll wrote: > > >> On 19 Jun 2018, at 18:19, Ville Voutilainen wrote: >> >> On 19 June 2018 at 19:13, Philippe wrote: >>>> For the above reasons I'd lean towards not running it globally and just using it >>>> on new changes. >>> >>> +1, based on my clang-format experience on a big application. >>> >>> BTW, keep in mind that you can disable clang-format on code sections with: >>> >>> // clang-format off >>> // clang-format on >> >> When I last experienced a large-scale clang-format reformat, it really >> hurt development >> during the churn. We should somehow manage to do it during a time when >> there aren't >> many pending patches in the pipeline. I'm not concerned about >> git-blame; that has never >> been a problem after reformats. However, I do not care about >> indentation nor do I want >> to spend time on it either way, it has no actual effect on readability >> and maintainability >> of code, and consistency outside the file you're in has never mattered >> to me one bit. >> >> IOW, I'm not opposed to reformats and auto-checking of clang-format >> (or even hooking it), >> but I do not see it as a thing with all that great return-of-investment. > > It helps in that you do not need to point those things out in code reviews, and that I (and others) won’t even create changes with wrong formatting that I’ll need to fix up later on. It’s part of a larger story, where I would like to get as much automatic checking of changes done before humans start reviewing. > > One idea could be to introduce this incrementally. Let’s first start off with enforcing it for new changes. Then we run it globally over the code base shortly before Qt 6.0 is being released. At that time merges shouldn’t be as much of a problem (as we’ll probably cherry-pick into Qt 5.15) and by then all new changes in Gerrit will be properly formatted (due to the earlier hook). > I think this is a good approach. It includes a period of time between taking the formatting options into use and applying them globally. There's a good chance that the used clang-format settings may change due to discussion as more people and code are exposed to it. It would be a shame to have to globally reformat *again* after a short period of time. (I'm still not sold on the benefit of running the reformatting on existing code outweighs the cost, but the suggested time would probably give the best balance there.) -- Kari From Liang.Qi at qt.io Wed Jun 20 09:53:13 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Wed, 20 Jun 2018 07:53:13 +0000 Subject: [Development] Merge and Integration status report Message-ID: <9EE22CD3-671E-49AF-A336-5823CF3DE13C@qt.io> Integrations * qt5 dev integration failed from June 18 * * Issue: [QTBUG-68848][1] tst_QQmlDebugJS fails too often in CI, perhaps a duplicate of [QTBUG-68741][2], the issue is there about two weeks, more talks in [previous report][4] * qt5 5.11 integration failed from June 9 * * Issue: [QTBUG-68773][3] qtwayland build failed - can't find some headers * * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, Oswald please help to review it. Suggest to revert to get 5.11 integrated again. Merges * qtbase 5.11->dev, the merge is blocked because [QTBUG-68773][3] is not fixed yet. -- Liang [1]: https://bugreports.qt.io/browse/QTBUG-68666 [2]: https://bugreports.qt.io/browse/QTBUG-68741 [3]: https://bugreports.qt.io/browse/QTBUG-68773 [4]: http://lists.qt-project.org/pipermail/development/2018-June/032893.html From Eike.Ziller at qt.io Wed Jun 20 11:00:55 2018 From: Eike.Ziller at qt.io (Eike Ziller) Date: Wed, 20 Jun 2018 09:00:55 +0000 Subject: [Development] Monitoring of upstream vulnerabilities In-Reply-To: References: <10055298.oqixaenVh0@tjmaciei-mobl1> <3034541.PsX7Z8mn3E@tjmaciei-mobl1> Message-ID: > On 19. Jun 2018, at 23:15, Jason H wrote: > > > >> Sent: Tuesday, June 19, 2018 at 4:50 PM >> From: "Thiago Macieira" >> To: development at qt-project.org >> Subject: Re: [Development] Monitoring of upstream vulnerabilities >> >> On Tuesday, 19 June 2018 13:15:18 PDT Jason H wrote: >>>> Currently, we use https://github.com/clearlinux/cve-check-tool. This is >>>> going to be replaced with CVEMAN - >>>> https://github.intel.com/kcwells/cveman. Both tools consume the feed from >>>> the National Vulnerability Database from the US NIST - >>>> https://nvd.nist.gov/. >>> >>> Is that intel server publicly accessible? >> >> The dashboard the tool produces isn't, but I also don't see why you'd want >> that. It's not applicable to Qt. The only people who would want access to it >> are the people who are working on the distribution and will apply the patches. > > !? > > The first link is a publicly accessible project. I thought you were referring to a replacement project. I wanted to see what CVEMAN was, why it was better, etc., (having never hard of it before) and see if it was something I might be interested in. But if it's not publicly accessible I wonder how open Qt is if we can't use all the tools Qt does. It could be valid that I don't need to worry, but how does the bind Qt to a private tool? > > I don't want to make a mountain out of a mole hill, but with all the transparency in Qt, I just expected it to be accessible is all. These tools are currently not used for Qt. Thiago is talking about "what we use in Clear Linux”, where “we” has nothing to do with the Qt Project. -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From apoenitz at t-online.de Tue Jun 19 23:23:10 2018 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 19 Jun 2018 23:23:10 +0200 Subject: [Development] clang-format In-Reply-To: <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> Message-ID: <20180619212310.GA2054@klara.mpi.htwm.de> On Wed, Jun 20, 2018 at 06:30:26AM +0000, Lars Knoll wrote: > > > > On 19 Jun 2018, at 18:19, Ville Voutilainen > > wrote: > > > > On 19 June 2018 at 19:13, Philippe wrote: > >>> For the above reasons I'd lean towards not running it globally and > >>> just using it on new changes. > >> > >> +1, based on my clang-format experience on a big application. > >> > >> BTW, keep in mind that you can disable clang-format on code > >> sections with: > >> > >> // clang-format off // clang-format on > > > > When I last experienced a large-scale clang-format reformat, it > > really hurt development during the churn. We should somehow manage > > to do it during a time when there aren't many pending patches in the > > pipeline. I'm not concerned about git-blame; that has never been a > > problem after reformats. However, I do not care about indentation > > nor do I want to spend time on it either way, it has no actual > > effect on readability and maintainability of code, and consistency > > outside the file you're in has never mattered to me one bit. > > > > IOW, I'm not opposed to reformats and auto-checking of clang-format > > (or even hooking it), but I do not see it as a thing with all that > > great return-of-investment. > > It helps in that you do not need to point those things out in code > reviews, and that I (and others) won’t even create changes with wrong > formatting that I’ll need to fix up later on. It’s part of a larger > story, where I would like to get as much automatic checking of changes > done before humans start reviewing. It's also a cultural thing. Quite a few people seem to take less offense from a "Your formatting is bad" when the comment comes from a bot than when it comes from a human. > One idea could be to introduce this incrementally. Let’s first start > off with enforcing it for new changes. Then we run it globally over > the code base shortly before Qt 6.0 is being released. At that time > merges shouldn’t be as much of a problem (as we’ll probably > cherry-pick into Qt 5.15) and by then all new changes in Gerrit will > be properly formatted (due to the earlier hook). Incrementally sounds good to me. Still I am a bit of a fence here. So far I've seen a couple of auto- formatting attempts biting back, so I thinl it would help to convince me to see the kind of changes that would happen first before deciding on the global change. Andre' From Tor.arne.Vestbo at qt.io Wed Jun 20 11:52:55 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Wed, 20 Jun 2018 09:52:55 +0000 Subject: [Development] clang-format In-Reply-To: <20180619212310.GA2054@klara.mpi.htwm.de> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io>, <20180619212310.GA2054@klara.mpi.htwm.de> Message-ID: <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> How about we also start with only one or two obvious rules that everyone agrees on? I don’t want Qt development to turn into Python PEP8 type rigid rules that makes you jump through a million hoops. If the latter is the goal here then I’m against enforcing clang-format, and it should be implemented as a bot that just warns, similar to the current style bot. - Tor Arne > On 20 Jun 2018, at 11:21, André Pönitz wrote: > >> On Wed, Jun 20, 2018 at 06:30:26AM +0000, Lars Knoll wrote: >> >> >>> On 19 Jun 2018, at 18:19, Ville Voutilainen >>> wrote: >>> >>> On 19 June 2018 at 19:13, Philippe wrote: >>>>> For the above reasons I'd lean towards not running it globally and >>>>> just using it on new changes. >>>> >>>> +1, based on my clang-format experience on a big application. >>>> >>>> BTW, keep in mind that you can disable clang-format on code >>>> sections with: >>>> >>>> // clang-format off // clang-format on >>> >>> When I last experienced a large-scale clang-format reformat, it >>> really hurt development during the churn. We should somehow manage >>> to do it during a time when there aren't many pending patches in the >>> pipeline. I'm not concerned about git-blame; that has never been a >>> problem after reformats. However, I do not care about indentation >>> nor do I want to spend time on it either way, it has no actual >>> effect on readability and maintainability of code, and consistency >>> outside the file you're in has never mattered to me one bit. >>> >>> IOW, I'm not opposed to reformats and auto-checking of clang-format >>> (or even hooking it), but I do not see it as a thing with all that >>> great return-of-investment. >> >> It helps in that you do not need to point those things out in code >> reviews, and that I (and others) won’t even create changes with wrong >> formatting that I’ll need to fix up later on. It’s part of a larger >> story, where I would like to get as much automatic checking of changes >> done before humans start reviewing. > > It's also a cultural thing. > > Quite a few people seem to take less offense from a "Your formatting is > bad" when the comment comes from a bot than when it comes from a human. > >> One idea could be to introduce this incrementally. Let’s first start >> off with enforcing it for new changes. Then we run it globally over >> the code base shortly before Qt 6.0 is being released. At that time >> merges shouldn’t be as much of a problem (as we’ll probably >> cherry-pick into Qt 5.15) and by then all new changes in Gerrit will >> be properly formatted (due to the earlier hook). > > Incrementally sounds good to me. > > Still I am a bit of a fence here. So far I've seen a couple of auto- > formatting attempts biting back, so I thinl it would help to convince me > to see the kind of changes that would happen first before deciding > on the global change. > > Andre' > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Wed Jun 20 12:13:18 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 20 Jun 2018 10:13:18 +0000 Subject: [Development] clang-format In-Reply-To: <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> Message-ID: I can’t see how clang-format will make you jump through any sort of hoops. Creator already has a hook for doing it on file saving time afaik, git-clang-format will clean up your change from the command line. Lars > On 20 Jun 2018, at 11:52, Tor Arne Vestbø wrote: > > How about we also start with only one or two obvious rules that everyone agrees on? I don’t want Qt development to turn into Python PEP8 type rigid rules that makes you jump through a million hoops. If the latter is the goal here then I’m against enforcing clang-format, and it should be implemented as a bot that just warns, similar to the current style bot. > > - Tor Arne > >> On 20 Jun 2018, at 11:21, André Pönitz wrote: >> >>> On Wed, Jun 20, 2018 at 06:30:26AM +0000, Lars Knoll wrote: >>> >>> >>>> On 19 Jun 2018, at 18:19, Ville Voutilainen >>>> wrote: >>>> >>>> On 19 June 2018 at 19:13, Philippe wrote: >>>>>> For the above reasons I'd lean towards not running it globally and >>>>>> just using it on new changes. >>>>> >>>>> +1, based on my clang-format experience on a big application. >>>>> >>>>> BTW, keep in mind that you can disable clang-format on code >>>>> sections with: >>>>> >>>>> // clang-format off // clang-format on >>>> >>>> When I last experienced a large-scale clang-format reformat, it >>>> really hurt development during the churn. We should somehow manage >>>> to do it during a time when there aren't many pending patches in the >>>> pipeline. I'm not concerned about git-blame; that has never been a >>>> problem after reformats. However, I do not care about indentation >>>> nor do I want to spend time on it either way, it has no actual >>>> effect on readability and maintainability of code, and consistency >>>> outside the file you're in has never mattered to me one bit. >>>> >>>> IOW, I'm not opposed to reformats and auto-checking of clang-format >>>> (or even hooking it), but I do not see it as a thing with all that >>>> great return-of-investment. >>> >>> It helps in that you do not need to point those things out in code >>> reviews, and that I (and others) won’t even create changes with wrong >>> formatting that I’ll need to fix up later on. It’s part of a larger >>> story, where I would like to get as much automatic checking of changes >>> done before humans start reviewing. >> >> It's also a cultural thing. >> >> Quite a few people seem to take less offense from a "Your formatting is >> bad" when the comment comes from a bot than when it comes from a human. >> >>> One idea could be to introduce this incrementally. Let’s first start >>> off with enforcing it for new changes. Then we run it globally over >>> the code base shortly before Qt 6.0 is being released. At that time >>> merges shouldn’t be as much of a problem (as we’ll probably >>> cherry-pick into Qt 5.15) and by then all new changes in Gerrit will >>> be properly formatted (due to the earlier hook). >> >> Incrementally sounds good to me. >> >> Still I am a bit of a fence here. So far I've seen a couple of auto- >> formatting attempts biting back, so I thinl it would help to convince me >> to see the kind of changes that would happen first before deciding >> on the global change. >> >> Andre' >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Wed Jun 20 12:14:43 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 20 Jun 2018 10:14:43 +0000 Subject: [Development] Qt 5.12 feature freeze is getting closer Message-ID: Hi all, Only two months to Qt 5.12 feature freeze, see https://wiki.qt.io/Qt_5.12_Release. And summer vacations will take big part of that remaining period... So at this point we should already know if there will be some new submodule modules in Qt 5.12. We are doing packaging confs etc for 5.12 now so please inform qt.team.releases at qt.io (I am starting my vacation today) immediately if there will be some new in. And of course get the new submodule in qt5 as soon as possible; those really needs to be in before we start soft branching mid August! br, Jani From Tor.arne.Vestbo at qt.io Wed Jun 20 13:01:10 2018 From: Tor.arne.Vestbo at qt.io (=?utf-8?B?VG9yIEFybmUgVmVzdGLDuA==?=) Date: Wed, 20 Jun 2018 11:01:10 +0000 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <8bce8c0e-4469-ddd9-23b7-61371736136c@qt.io> <20180619181340.5380.6F0322A@gmail.com> <8D9EACE6-3696-4663-BE81-F0617CFD86FB@qt.io> <20180619212310.GA2054@klara.mpi.htwm.de> <8E303054-7F6B-4E60-8494-22222B76DAB3@qt.io> Message-ID: On 20 Jun 2018, at 12:13, Lars Knoll wrote: > > I can’t see how clang-format will make you jump through any sort of hoops. Creator already has a hook for doing it on file saving time afaik, git-clang-format will clean up your change from the command line. Good point, I was imagining it used only to verify style, not to auto-format. Still, starting out with a few non-controversial rules would be a good thing. Tor Arne > > Lars > >> On 20 Jun 2018, at 11:52, Tor Arne Vestbø wrote: >> >> How about we also start with only one or two obvious rules that everyone agrees on? I don’t want Qt development to turn into Python PEP8 type rigid rules that makes you jump through a million hoops. If the latter is the goal here then I’m against enforcing clang-format, and it should be implemented as a bot that just warns, similar to the current style bot. >> >> - Tor Arne >> >>> On 20 Jun 2018, at 11:21, André Pönitz wrote: >>> >>>> On Wed, Jun 20, 2018 at 06:30:26AM +0000, Lars Knoll wrote: >>>> >>>> >>>>> On 19 Jun 2018, at 18:19, Ville Voutilainen >>>>> wrote: >>>>> >>>>> On 19 June 2018 at 19:13, Philippe wrote: >>>>>>> For the above reasons I'd lean towards not running it globally and >>>>>>> just using it on new changes. >>>>>> >>>>>> +1, based on my clang-format experience on a big application. >>>>>> >>>>>> BTW, keep in mind that you can disable clang-format on code >>>>>> sections with: >>>>>> >>>>>> // clang-format off // clang-format on >>>>> >>>>> When I last experienced a large-scale clang-format reformat, it >>>>> really hurt development during the churn. We should somehow manage >>>>> to do it during a time when there aren't many pending patches in the >>>>> pipeline. I'm not concerned about git-blame; that has never been a >>>>> problem after reformats. However, I do not care about indentation >>>>> nor do I want to spend time on it either way, it has no actual >>>>> effect on readability and maintainability of code, and consistency >>>>> outside the file you're in has never mattered to me one bit. >>>>> >>>>> IOW, I'm not opposed to reformats and auto-checking of clang-format >>>>> (or even hooking it), but I do not see it as a thing with all that >>>>> great return-of-investment. >>>> >>>> It helps in that you do not need to point those things out in code >>>> reviews, and that I (and others) won’t even create changes with wrong >>>> formatting that I’ll need to fix up later on. It’s part of a larger >>>> story, where I would like to get as much automatic checking of changes >>>> done before humans start reviewing. >>> >>> It's also a cultural thing. >>> >>> Quite a few people seem to take less offense from a "Your formatting is >>> bad" when the comment comes from a bot than when it comes from a human. >>> >>>> One idea could be to introduce this incrementally. Let’s first start >>>> off with enforcing it for new changes. Then we run it globally over >>>> the code base shortly before Qt 6.0 is being released. At that time >>>> merges shouldn’t be as much of a problem (as we’ll probably >>>> cherry-pick into Qt 5.15) and by then all new changes in Gerrit will >>>> be properly formatted (due to the earlier hook). >>> >>> Incrementally sounds good to me. >>> >>> Still I am a bit of a fence here. So far I've seen a couple of auto- >>> formatting attempts biting back, so I thinl it would help to convince me >>> to see the kind of changes that would happen first before deciding >>> on the global change. >>> >>> Andre' >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development > From Morten.Sorvig at qt.io Wed Jun 20 13:23:49 2018 From: Morten.Sorvig at qt.io (=?utf-8?B?TW9ydGVuIFPDuHJ2aWc=?=) Date: Wed, 20 Jun 2018 11:23:49 +0000 Subject: [Development] clang-format In-Reply-To: <2301967.FbfvzRaAGg@twilight> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <2301967.FbfvzRaAGg@twilight> Message-ID: > On 19 Jun 2018, at 17:33, Allan Sandfeld Jensen wrote: > > Btw. Just for your information. > > I have attached a few random examples of what we can look forward too after > running an auto-"beautifying" tool over our hand-formated Qt code. And these > changes are NOT something we can configure out ouf of in clang-format, it is > just cases where it can't do any better._______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Thanks, this should really be the first thing we do: run a pre-project so that we can have an informed discussion. The point of machine formatting is perhaps not to make code beautiful, rather it is to have automated formatting in order to offload work from the humans. Looking at qConvertRgb16To32: Manual formatting: return 0xff000000 | ((((c) << 3) & 0xf8) | (((c) >> 2) & 0x7)) | ((((c) << 5) & 0xfc00) | (((c) >> 1) & 0x300)) | ((((c) << 8) & 0xf80000) | (((c) << 3) & 0x70000)); Clang-format: return 0xff000000 | ((((c) << 3) & 0xf8) | (((c) >> 2) & 0x7)) | ((((c) << 5) & 0xfc00) | (((c) >> 1) & 0x300)) | ((((c) << 8) & 0xf80000) | (((c) << 3) & 0x70000)); The manually formatted version clearly has something going for it. The benefit of reformatting the entire code base and enforcing clang-format is that there is now a single correct way to format code (At least until we change the .clang-format file; do we re-format everything again then?). This makes it possible to enforce the format via bots. But this change may be too disruptive for an established C++ project. If the goal is to offload the humans we could get away with a small code style policy addition: * Clang-formatted code is acceptable from a code style perspective. Which enables the workflow where patch authors can run clang-format and be done with code formatting. At the same time we keep the door open for manual formatting where needed. We may then have a bot which +1 stamps correctly clang-formatted patches, but I don’t think it should nitpick manually formatted code. Morten From sergio.martins at kdab.com Wed Jun 20 13:56:25 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Wed, 20 Jun 2018 12:56:25 +0100 Subject: [Development] clang-format In-Reply-To: <1665868.Big65L9shF@frederik-thinkcentre-m93p> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> Message-ID: <70bd6075886b07042b03f20dd220398d@kdab.com> On 2018-06-18 10:04, Frederik Gladhorn wrote: > Hi all, > > as part of the closing ceremony of this year's Qt Contributors' Summit > we > agreed to start using clang-format, to have fewer discussions around > coding > style and rather focus on the actual code. > > I have not yet thought about all angles, how to best implement this, > here are > some notes: > > We have a clang-format file in qtrepotools. You can use it today, > simply make > sure it's in any parent directory of the files you are editing. I'd > actually > propose simply moving this into the root directory of qt5.git. > https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format > > If you want to clean one file: > clang-format -i myfile.cpp/h > > To clean a commit (only modifies the working tree): > git clang-format > > > Getting clang-format seems easy enough: > On macOS: brew install clang-format > Linux: install clang-format > Windows: it comes with normal clang > > Then there is the tooling/workflow perspective. Creator and other IDEs > have > support (you may need to enable the beautifier plugin in about > plugins). > I imagine we add this to the sanity bot ("git clang-format --diff -q" > should > return empty, otherwise post a message). > > Local hooks are basically the same, any ideas how to best set up the > git hooks > appreciated :) > > And then there is the big question when we run it once over the entire > codebase. I find clang-format a bit limited and always need to manually format some things that clang-format doesn't allow to tune. It's quite useful when integrated with gerrit so it can automatically -1 the most common mistakes, but I wouldn't run it on the entire codebase. So YES to all you said, except the massive cleanup. 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 ivan.donchevskii at qt.io Wed Jun 20 14:09:20 2018 From: ivan.donchevskii at qt.io (Ivan Donchevskii) Date: Wed, 20 Jun 2018 12:09:20 +0000 Subject: [Development] clang-format In-Reply-To: <70bd6075886b07042b03f20dd220398d@kdab.com> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p>, <70bd6075886b07042b03f20dd220398d@kdab.com> Message-ID: One more thing about clang-format. It might be really nice if we use it as a default formatting tool in Qt Creator. And I really want to experiment with it and see how clang-format can replace the indenter that we currently use (which has a lot of bug reports about broken formatting for example with modern C++). BR, Ivan ________________________________ From: Development on behalf of Sérgio Martins via Development Sent: Wednesday, June 20, 2018 1:56 PM To: Frederik Gladhorn Cc: Development; development at qt-project.org Subject: Re: [Development] clang-format On 2018-06-18 10:04, Frederik Gladhorn wrote: > Hi all, > > as part of the closing ceremony of this year's Qt Contributors' Summit > we > agreed to start using clang-format, to have fewer discussions around > coding > style and rather focus on the actual code. > > I have not yet thought about all angles, how to best implement this, > here are > some notes: > > We have a clang-format file in qtrepotools. You can use it today, > simply make > sure it's in any parent directory of the files you are editing. I'd > actually > propose simply moving this into the root directory of qt5.git. > https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format > > If you want to clean one file: > clang-format -i myfile.cpp/h > > To clean a commit (only modifies the working tree): > git clang-format > > > Getting clang-format seems easy enough: > On macOS: brew install clang-format > Linux: install clang-format > Windows: it comes with normal clang > > Then there is the tooling/workflow perspective. Creator and other IDEs > have > support (you may need to enable the beautifier plugin in about > plugins). > I imagine we add this to the sanity bot ("git clang-format --diff -q" > should > return empty, otherwise post a message). > > Local hooks are basically the same, any ideas how to best set up the > git hooks > appreciated :) > > And then there is the big question when we run it once over the entire > codebase. I find clang-format a bit limited and always need to manually format some things that clang-format doesn't allow to tune. It's quite useful when integrated with gerrit so it can automatically -1 the most common mistakes, but I wouldn't run it on the entire codebase. So YES to all you said, except the massive cleanup. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.clere at minmaxmedical.com Wed Jun 20 15:05:35 2018 From: arnaud.clere at minmaxmedical.com (=?iso-8859-1?Q?Arnaud_Cl=E8re?=) Date: Wed, 20 Jun 2018 13:05:35 +0000 Subject: [Development] unified data model API in QtCore => thin wrapper proposal In-Reply-To: References: Message-ID: Hi, Thiago, did you decide on something regarding QCborValue in Qt5.12? For structured traces, we have to deal with any user-defined data types so, we can do with QCborValue, QJsonValue or QFoo too. Now, the value of exposing the common backend of QJson and QCbor as a QFoo binary format is not clear to me, and the "lowest common denominator" approach is inherently limited. In my latest QBind prototype, we can write any user-defined type in various formats, and we can even take a copy of the user-defined type to serialize it later. So, QFoo is not required as an intermediate storage and would probably be slower. The latest benchmark shows the QBind approach can be *very* efficient: (usecs) |QDebug|Json|Cbor|Writable|Writable>Cbor MSVC 17 < Sent: jeudi 14 juin 2018 02:08 > This email is to start that discussion and answer these questions: > a) should we have this API? > b) if so, what would this API look like? > c) if not, should we unify at least JSON and CBOR? > c) either way, should remove QCborValue until we have it? ... > This API would also be the replacement of the JSON and CBOR parsers, > for which we'd have a unified API, something like: > QFoo json = QJson::fromJson(jcontent); > QFoo cbor = QCbor::fromCbor(ccontent); > qDebug() << QCbor::toDiagnosticFormat(json); // yes, json From kde at carewolf.com Wed Jun 20 15:08:29 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 20 Jun 2018 15:08:29 +0200 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <70bd6075886b07042b03f20dd220398d@kdab.com> Message-ID: <1692396.DI8C0e8O9o@twilight> On Mittwoch, 20. Juni 2018 14:09:20 CEST Ivan Donchevskii wrote: > One more thing about clang-format. > > It might be really nice if we use it as a default formatting tool in Qt > Creator. And I really want to experiment with it and see how clang-format > can replace the indenter that we currently use (which has a lot of bug > reports about broken formatting for example with modern C++). > I never seen anything QtCreator had trouble with. But on the subject, there is one standard indentation features QtCreator has that clang-format can't reproduce. When you line-break an expression, clang-format will indent it a fixed amount from the beginning of the next line, where QtCreator will try to find places to line up with from the line above, including indenting from the last paranthesis For instance: int a = foobar(x) + foo(looooooongfunctionname( looongvariablename)); vs int a = foobar(x) + foo(looooooongfunctionname( looongvariablename)); This semantic indentation is not something clang-format can do at the moment. At least if someone knows how, I would love to know, I have search everywhere, including the clang-format code. It is not so bad in this case, but once you have multiple line-break like that in a long function call, clang-formated code is essentionally just unformatted. In any case if we want to enforce clang-format everywhere, perhaps we shouldn't have QtCreator do smarter and more readable indentation that we do not allow in our repository? 'Allan From eirik.aavitsland at qt.io Wed Jun 20 15:14:50 2018 From: eirik.aavitsland at qt.io (Eirik Aavitsland) Date: Wed, 20 Jun 2018 15:14:50 +0200 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <2301967.FbfvzRaAGg@twilight> Message-ID: <36fdaa3f-f5da-2a0d-c898-5e69128c963e@qt.io> On 20. juni 2018 13:23, Morten Sørvig wrote: > > >> On 19 Jun 2018, at 17:33, Allan Sandfeld Jensen wrote: >> >> Btw. Just for your information. >> >> I have attached a few random examples of what we can look forward too after >> running an auto-"beautifying" tool over our hand-formated Qt code. And these >> changes are NOT something we can configure out ouf of in clang-format, it is >> just cases where it can't do any better._______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > Thanks, this should really be the first thing we do: run a pre-project > so that we can have an informed discussion. > > The point of machine formatting is perhaps not to make code beautiful, rather > it is to have automated formatting in order to offload work from the humans. > > > Looking at qConvertRgb16To32: > > Manual formatting: > return 0xff000000 > | ((((c) << 3) & 0xf8) | (((c) >> 2) & 0x7)) > | ((((c) << 5) & 0xfc00) | (((c) >> 1) & 0x300)) > | ((((c) << 8) & 0xf80000) | (((c) << 3) & 0x70000)); > > Clang-format: > return 0xff000000 | ((((c) << 3) & 0xf8) | (((c) >> 2) & 0x7)) | ((((c) << 5) & 0xfc00) | (((c) >> 1) & 0x300)) > | ((((c) << 8) & 0xf80000) | (((c) << 3) & 0x70000)); > > The manually formatted version clearly has something going for it. > Yup, I also did some manual testing on existing Qt code, and I generally found that - clang-format's intra-line changes were fine (correcting white space in expressions etc.) - but whenever clang-format would add or remove linebreaks, which it would quite often do, the changes were typically detrimental to readability, and often significantly so (as in the example above). In my view, the readability improvements of the former in no way outweighs the readability damage of the latter. So to me this tool (or its config) is not ready to be trusted with the power of doing automatic (not developer reviewed & approved) changes. - Eirik Aa. From philwave at gmail.com Wed Jun 20 17:03:26 2018 From: philwave at gmail.com (Philippe) Date: Wed, 20 Jun 2018 17:03:26 +0200 Subject: [Development] clang-format In-Reply-To: <1692396.DI8C0e8O9o@twilight> References: <1692396.DI8C0e8O9o@twilight> Message-ID: <20180620170325.6196.6F0322A@gmail.com> > When you line-break an expression, clang-format will indent it a >fixed amount from the beginning of the next line, > where QtCreator will try to find places to line up with from the line above, including indenting from the > last paranthesis For instance: I don't use QtCreator, but clang-format does it as you describe for QtCreator. And this works very nicely (...most of the time). Now, I don't remember which one of the many settings is responsible for this. Philippe On Wed, 20 Jun 2018 15:08:29 +0200 Allan Sandfeld Jensen wrote: > On Mittwoch, 20. Juni 2018 14:09:20 CEST Ivan Donchevskii wrote: > > One more thing about clang-format. > > > > It might be really nice if we use it as a default formatting tool in Qt > > Creator. And I really want to experiment with it and see how clang-format > > can replace the indenter that we currently use (which has a lot of bug > > reports about broken formatting for example with modern C++). > > > > I never seen anything QtCreator had trouble with. But on the subject, there is > one standard indentation features QtCreator has that clang-format can't > reproduce. When you line-break an expression, clang-format will indent it a > fixed amount from the beginning of the next line, where QtCreator will try to > find places to line up with from the line above, including indenting from the > last paranthesis For instance: > > int a = foobar(x) + foo(looooooongfunctionname( > looongvariablename)); > > vs > > int a = foobar(x) + foo(looooooongfunctionname( > looongvariablename)); > > > This semantic indentation is not something clang-format can do at the moment. > At least if someone knows how, I would love to know, I have search everywhere, > including the clang-format code. > > It is not so bad in this case, but once you have multiple line-break like that > in a long function call, clang-formated code is essentionally just > unformatted. > > In any case if we want to enforce clang-format everywhere, perhaps we > shouldn't have QtCreator do smarter and more readable indentation that we do > not allow in our repository? > > 'Allan > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jeanmichael.celerier at gmail.com Wed Jun 20 18:24:46 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Wed, 20 Jun 2018 18:24:46 +0200 Subject: [Development] clang-format In-Reply-To: <1692396.DI8C0e8O9o@twilight> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <70bd6075886b07042b03f20dd220398d@kdab.com> <1692396.DI8C0e8O9o@twilight> Message-ID: > I never seen anything QtCreator had trouble with. really ? paste this in a .cpp and indent it : #define WHATEVER struct foo { WHATEVER public: explicit foo(); }; struct bar { public: explicit bar(); }; ------- Jean-Michaël Celerier http://www.jcelerier.name On Wed, Jun 20, 2018 at 3:08 PM, Allan Sandfeld Jensen wrote: > On Mittwoch, 20. Juni 2018 14:09:20 CEST Ivan Donchevskii wrote: > > One more thing about clang-format. > > > > It might be really nice if we use it as a default formatting tool in Qt > > Creator. And I really want to experiment with it and see how clang-format > > can replace the indenter that we currently use (which has a lot of bug > > reports about broken formatting for example with modern C++). > > > > I never seen anything QtCreator had trouble with. But on the subject, > there is > one standard indentation features QtCreator has that clang-format can't > reproduce. When you line-break an expression, clang-format will indent it > a > fixed amount from the beginning of the next line, where QtCreator will try > to > find places to line up with from the line above, including indenting from > the > last paranthesis For instance: > > int a = foobar(x) + foo(looooooongfunctionname( > looongvariablename)); > > vs > > int a = foobar(x) + foo(looooooongfunctionname( > looongvariablename)); > > > This semantic indentation is not something clang-format can do at the > moment. > At least if someone knows how, I would love to know, I have search > everywhere, > including the clang-format code. > > It is not so bad in this case, but once you have multiple line-break like > that > in a long function call, clang-formated code is essentionally just > unformatted. > > In any case if we want to enforce clang-format everywhere, perhaps we > shouldn't have QtCreator do smarter and more readable indentation that we > do > not allow in our repository? > > '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 thiago.macieira at intel.com Thu Jun 21 05:40:33 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jun 2018 20:40:33 -0700 Subject: [Development] Android binary size with Clang Message-ID: <1935804.rQl6G1Ud0Q@tjmaciei-mobl1> Hello Yesterday during the PDXCPP Meet Up, I was asked if we had come up with a good solution to the increase in size of native binaries on Android when switching from GCC to Clang. I reported I had no idea there was even a problem. So, what's the status here? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Thu Jun 21 09:00:44 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 21 Jun 2018 09:00:44 +0200 Subject: [Development] Android binary size with Clang In-Reply-To: <1935804.rQl6G1Ud0Q@tjmaciei-mobl1> References: <1935804.rQl6G1Ud0Q@tjmaciei-mobl1> Message-ID: <5eafe9e6-31f4-a72a-ea47-bfd6734bce43@kdab.com> Hi, On 21/06/18 05:40, Thiago Macieira wrote: > Yesterday during the PDXCPP Meet Up, I was asked if we had come up with a good > solution to the increase in size of native binaries on Android when switching > from GCC to Clang. I reported I had no idea there was even a problem. > > So, what's the status here? Unsolved, AFAIK. It's tracked here: https://github.com/android-ndk/ndk/issues/133 Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From sergio.martins at kdab.com Thu Jun 21 10:38:29 2018 From: sergio.martins at kdab.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Thu, 21 Jun 2018 09:38:29 +0100 Subject: [Development] Android binary size with Clang In-Reply-To: <1935804.rQl6G1Ud0Q@tjmaciei-mobl1> References: <1935804.rQl6G1Ud0Q@tjmaciei-mobl1> Message-ID: On 2018-06-21 04:40, Thiago Macieira wrote: > Hello > > Yesterday during the PDXCPP Meet Up, I was asked if we had come up with > a good > solution to the increase in size of native binaries on Android when > switching > from GCC to Clang. I reported I had no idea there was even a problem. > > So, what's the status here? -fno-exceptions was missing and someone discovered -Oz (you actually?), so it's not so bad now. Around 10% binary increase instead of 40% IIRC. QtXmlPatterns suffers much more than 10% for some reason though, so mileage might vary. As far as qt-project is concerned the status is SOLVED IMHO. Users should pressure google directly for further improvement. 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 bogdan.vatra at kdab.com Thu Jun 21 10:45:36 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Thu, 21 Jun 2018 11:45:36 +0300 Subject: [Development] Android binary size with Clang In-Reply-To: References: <1935804.rQl6G1Ud0Q@tjmaciei-mobl1> Message-ID: <1648402.Orvshsm30B@zmeu> În ziua de joi, 21 iunie 2018, la 11:38:29 EEST, Sérgio Martins via Development a scris: > On 2018-06-21 04:40, Thiago Macieira wrote: > > Hello > > > > Yesterday during the PDXCPP Meet Up, I was asked if we had come up with > > a good > > solution to the increase in size of native binaries on Android when > > switching > > from GCC to Clang. I reported I had no idea there was even a problem. > > > > So, what's the status here? > > -fno-exceptions was missing and someone discovered -Oz (you actually?), > so it's not so bad now. > Around 10% binary increase instead of 40% IIRC. QtXmlPatterns suffers > much more than 10% for some reason though, so mileage might vary. > > As far as qt-project is concerned the status is SOLVED IMHO. Users > should pressure google directly for further improvement. > Is not solved, at least not until we test also the speed, check https:// github.com/android-ndk/ndk/issues/495 Cheers, BogDan. From Bart.Vandewoestyne at telenet.be Thu Jun 21 12:05:38 2018 From: Bart.Vandewoestyne at telenet.be (Bart Vandewoestyne) Date: Thu, 21 Jun 2018 12:05:38 +0200 Subject: [Development] Trying to build Qt 4.8.7 with Visual Studio 2017 Message-ID: Hello list, I am trying to build Qt 4.8.7 using Visual Studio 2017. Partly because I need it (upgrading to 5.X is currently not an option due to time constraints and other priorities), partly as a hobby project and because it's fun, and partly because it might be interesting for other people who are stuck on Qt 4.8.7. A patch file with my attempt so far is at https://github.com/BartVandewoestyne/qt_4_8_7_with_vs2017_patch As you can see from the patch, one of the things that needs adaptation is the configure tool. However, I haven't succeeded in rebuilding the configure tool using my MSVC2017. Can anyone tell me if it is possible to rebuild only the configure tool (preferably also using VS2017) and if 'yes', what steps do I need to take to do that (using a fresh checkout/unzip of the 4.8.7 sources)? Kind regards, Bart From frederik.gladhorn at qt.io Thu Jun 21 13:51:38 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 21 Jun 2018 13:51:38 +0200 Subject: [Development] clang-format In-Reply-To: <1994953.cDbqxsKW4M@tjmaciei-mobl1> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <1994953.cDbqxsKW4M@tjmaciei-mobl1> Message-ID: <6273264.Biq9fbbCE3@frederik-thinkcentre-m93p> On tirsdag 19. juni 2018 17.51.28 CEST Thiago Macieira wrote: > On Tuesday, 19 June 2018 02:34:09 PDT Lars Knoll wrote: > > Currently, we only merge from 5.11 to dev, so I hope this won’t be too > > bad. > > But we could of course also run the tool over both branches. > > I have right now 149 changes on top of qtbase's dev branch. For something > that is ostensibly a whitespace change, I will dedicate no more than 1 > minute per change to resolve a conflict or 15 minutes total to rebase my > branch once it goes in. > > Any change that times out will be dropped. That includes all the Qt 6 > container work, the un-accepted QtDBus updates (which include a > QDBusConnection::connect taking PMF), a large refactoring of > QFileSystemEngine that no one has reviewed yet despite being on Gerrit for > over a year, some work for CBOR and a few other miscellaneous changes. That should be scriptable afaict, correct me if I'm wrong. checkout the change before we run clang-format run clang-format on the changed files push on top of the formatting change Cheers, Frederik From thiago.macieira at intel.com Thu Jun 21 15:57:56 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 21 Jun 2018 06:57:56 -0700 Subject: [Development] Trying to build Qt 4.8.7 with Visual Studio 2017 In-Reply-To: References: Message-ID: <1633080.Xvv6ezrT2C@tjmaciei-mobl1> On Thursday, 21 June 2018 03:05:38 PDT Bart Vandewoestyne wrote: > Can anyone tell me if it is possible to rebuild only the configure > tool (preferably also using VS2017) and if 'yes', what steps do I need > to take to do that (using a fresh checkout/unzip of the 4.8.7 > sources)? Just tell configure you have win32-msvc2015. Don't try to patch to recognise 2017. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jun 21 16:02:44 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 21 Jun 2018 07:02:44 -0700 Subject: [Development] clang-format In-Reply-To: <6273264.Biq9fbbCE3@frederik-thinkcentre-m93p> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <1994953.cDbqxsKW4M@tjmaciei-mobl1> <6273264.Biq9fbbCE3@frederik-thinkcentre-m93p> Message-ID: <10886251.mGFSMTrdMt@tjmaciei-mobl1> On Thursday, 21 June 2018 04:51:38 PDT Frederik Gladhorn wrote: > checkout the change before we run clang-format > run clang-format on the changed files > push on top of the formatting change I'd appreciate such a script. As I said, I will dedicate no more than 15 minutes total for rebasing after such a massive change that deals with whitespace only and that includes writing such a script. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Fri Jun 22 01:36:46 2018 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 22 Jun 2018 01:36:46 +0200 Subject: [Development] clang-format In-Reply-To: <10886251.mGFSMTrdMt@tjmaciei-mobl1> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <1994953.cDbqxsKW4M@tjmaciei-mobl1> <6273264.Biq9fbbCE3@frederik-thinkcentre-m93p> <10886251.mGFSMTrdMt@tjmaciei-mobl1> Message-ID: On 2018-06-21 16:02, Thiago Macieira wrote: > On Thursday, 21 June 2018 04:51:38 PDT Frederik Gladhorn wrote: >> checkout the change before we run clang-format >> run clang-format on the changed files >> push on top of the formatting change > > I'd appreciate such a script. As I said, I will dedicate no more than 15 > minutes total for rebasing after such a massive change that deals with > whitespace only and that includes writing such a script. I suggest you first rebase on top of the change right before the whitespace changes and fix all conflicts as you usually do. Then: git rebase -x "git-clang-format HEAD^" -i On conflicts, use git mergetool and always pick your changes, or even git checkout --ours This should probably go quite fast. From ville.voutilainen at gmail.com Fri Jun 22 01:56:00 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 22 Jun 2018 02:56:00 +0300 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <1994953.cDbqxsKW4M@tjmaciei-mobl1> <6273264.Biq9fbbCE3@frederik-thinkcentre-m93p> <10886251.mGFSMTrdMt@tjmaciei-mobl1> Message-ID: On 22 June 2018 at 02:36, Olivier Goffart wrote: > On 2018-06-21 16:02, Thiago Macieira wrote: >> >> On Thursday, 21 June 2018 04:51:38 PDT Frederik Gladhorn wrote: >>> >>> checkout the change before we run clang-format >>> run clang-format on the changed files >>> push on top of the formatting change >> >> >> I'd appreciate such a script. As I said, I will dedicate no more than 15 >> minutes total for rebasing after such a massive change that deals with >> whitespace only and that includes writing such a script. > > > > I suggest you first rebase on top of the change right before the whitespace > changes and fix all conflicts as you usually do. > > > Then: > > git rebase -x "git-clang-format HEAD^" -i > > On conflicts, use git mergetool and always pick your changes, or even > git checkout --ours > > This should probably go quite fast. While I appreciate your git-fu, I must bat my eyelids if we consider that a normal procedure for people wishing to submit patches. From thiago.macieira at intel.com Fri Jun 22 04:24:31 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 21 Jun 2018 19:24:31 -0700 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> Message-ID: <1698937.PNfHVcvpGg@tjmaciei-mobl1> On Thursday, 21 June 2018 16:56:00 PDT Ville Voutilainen wrote: > While I appreciate your git-fu, I must bat my eyelids if we consider that > a normal procedure for people wishing to submit patches. Not many people have over 100 pending patches for Qt. In fact, you can probably count them in the fingers of one hand. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From frederik.gladhorn at qt.io Fri Jun 22 09:47:04 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Fri, 22 Jun 2018 09:47:04 +0200 Subject: [Development] clang-format In-Reply-To: <1665868.Big65L9shF@frederik-thinkcentre-m93p> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> Message-ID: <2083983.5gU0Wftla1@frederik-thinkcentre-m93p> OK, so for now, my take-away from this thread is that we should simply create nice commit-hooks that help everyone along. As a next step we can also enhance the sanity bot with friendly messages. I ran clang-format a few times over different parts of the code-base and I agree that it sometimes ends up with stuff looking worse. Either use the opt out for those parts or live with it. Not having to debate the format again and again is a big win in my opinion. Let's move the _clang-format file from qtrepotools to qt5.git: https://codereview.qt-project.org/#/c/233051/ https://codereview.qt-project.org/#/c/233050/ Cheers, Frederik On mandag 18. juni 2018 11.04.33 CEST Frederik Gladhorn wrote: > Hi all, > > as part of the closing ceremony of this year's Qt Contributors' Summit we > agreed to start using clang-format, to have fewer discussions around coding > style and rather focus on the actual code. > > I have not yet thought about all angles, how to best implement this, here > are some notes: > > We have a clang-format file in qtrepotools. You can use it today, simply > make sure it's in any parent directory of the files you are editing. I'd > actually propose simply moving this into the root directory of qt5.git. > https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format > > If you want to clean one file: > clang-format -i myfile.cpp/h > > To clean a commit (only modifies the working tree): > git clang-format > > > Getting clang-format seems easy enough: > On macOS: brew install clang-format > Linux: install clang-format > Windows: it comes with normal clang > > Then there is the tooling/workflow perspective. Creator and other IDEs have > support (you may need to enable the beautifier plugin in about plugins). > I imagine we add this to the sanity bot ("git clang-format --diff -q" should > return empty, otherwise post a message). > > Local hooks are basically the same, any ideas how to best set up the git > hooks appreciated :) > > And then there is the big question when we run it once over the entire > codebase. > > Cheers, > Frederik > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From scott at towel42.com Fri Jun 22 16:40:58 2018 From: scott at towel42.com (Scott Bloom) Date: Fri, 22 Jun 2018 14:40:58 +0000 Subject: [Development] clang-format In-Reply-To: <2083983.5gU0Wftla1@frederik-thinkcentre-m93p> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <2083983.5gU0Wftla1@frederik-thinkcentre-m93p> Message-ID: Im going to throw out my 2 bits .. Im not an active Qt developer, so take it for what its worth.. Back in the old days (read CVS, pre git, pre svn, pre perforce) we had created the ability to have the "Checked in format" vs the "Developer format" In a series of wrapper scripts, essentially, everything checked in was converted to the check in format. However each developer had their own format . And on checkout, the code would be compare to it. On "Diff" analysis of two reversions, you had to see the diff based on the checked in format. It really made things, that much simpler... and we never heard people bitch and moan about where the curley brackets belong -----Original Message----- From: Development On Behalf Of Frederik Gladhorn Sent: Friday, June 22, 2018 00:47 To: development at qt-project.org Subject: Re: [Development] clang-format OK, so for now, my take-away from this thread is that we should simply create nice commit-hooks that help everyone along. As a next step we can also enhance the sanity bot with friendly messages. I ran clang-format a few times over different parts of the code-base and I agree that it sometimes ends up with stuff looking worse. Either use the opt out for those parts or live with it. Not having to debate the format again and again is a big win in my opinion. Let's move the _clang-format file from qtrepotools to qt5.git: https://codereview.qt-project.org/#/c/233051/ https://codereview.qt-project.org/#/c/233050/ Cheers, Frederik On mandag 18. juni 2018 11.04.33 CEST Frederik Gladhorn wrote: > Hi all, > > as part of the closing ceremony of this year's Qt Contributors' Summit > we agreed to start using clang-format, to have fewer discussions > around coding style and rather focus on the actual code. > > I have not yet thought about all angles, how to best implement this, > here are some notes: > > We have a clang-format file in qtrepotools. You can use it today, > simply make sure it's in any parent directory of the files you are > editing. I'd actually propose simply moving this into the root directory of qt5.git. > https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format > > If you want to clean one file: > clang-format -i myfile.cpp/h > > To clean a commit (only modifies the working tree): > git clang-format > > > Getting clang-format seems easy enough: > On macOS: brew install clang-format > Linux: install clang-format > Windows: it comes with normal clang > > Then there is the tooling/workflow perspective. Creator and other IDEs > have support (you may need to enable the beautifier plugin in about plugins). > I imagine we add this to the sanity bot ("git clang-format --diff -q" > should return empty, otherwise post a message). > > Local hooks are basically the same, any ideas how to best set up the > git hooks appreciated :) > > And then there is the big question when we run it once over the entire > codebase. > > Cheers, > Frederik > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Jun 22 17:26:05 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jun 2018 08:26:05 -0700 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <2083983.5gU0Wftla1@frederik-thinkcentre-m93p> Message-ID: <2608989.0EdPNPQHza@tjmaciei-mobl1> On Friday, 22 June 2018 07:40:58 PDT Scott Bloom wrote: > In a series of wrapper scripts, essentially, everything checked in was > converted to the check in format. However each developer had their own > format . And on checkout, the code would be compare to it. > > On "Diff" analysis of two reversions, you had to see the diff based on the > checked in format. > > It really made things, that much simpler... and we never heard people bitch > and moan about where the curley brackets belong Git has such a functionality, it's called the clean/smudge filters. See man gitattributes for more information. But that still means the code you see is subject to the smudge filter's whims. We've concluded that it doesn't always do the right thing. And besides, there's something new that didn't exist in the old days: code reviews. Gerrit has no such functionality and in any case, reviewers need to agree between themselves on what they ar reviewing. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From scott at towel42.com Fri Jun 22 17:34:09 2018 From: scott at towel42.com (Scott Bloom) Date: Fri, 22 Jun 2018 15:34:09 +0000 Subject: [Development] clang-format In-Reply-To: <2608989.0EdPNPQHza@tjmaciei-mobl1> References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <2083983.5gU0Wftla1@frederik-thinkcentre-m93p> <2608989.0EdPNPQHza@tjmaciei-mobl1> Message-ID: Fair enough.. It just seems that this thread has fundamentally become a religious issue over format, and when it should be forced on people... I fight this all the time in my organization... I usually come to the conclusion, code in the style you want, unless it's a bad format. And like pornography, I cant define it but I know it when I see it... But IMO, wholesale "format changes" have zero value to the customer, so any pain associated with them, should be weighed against the time and effort necessary to implement a format change that is being taken away from customer oriented development. Scott -----Original Message----- From: Development On Behalf Of Thiago Macieira Sent: Friday, June 22, 2018 08:26 To: development at qt-project.org Subject: Re: [Development] clang-format On Friday, 22 June 2018 07:40:58 PDT Scott Bloom wrote: > In a series of wrapper scripts, essentially, everything checked in was > converted to the check in format. However each developer had their > own format . And on checkout, the code would be compare to it. > > On "Diff" analysis of two reversions, you had to see the diff based on > the checked in format. > > It really made things, that much simpler... and we never heard people > bitch and moan about where the curley brackets belong Git has such a functionality, it's called the clean/smudge filters. See man gitattributes for more information. But that still means the code you see is subject to the smudge filter's whims. We've concluded that it doesn't always do the right thing. And besides, there's something new that didn't exist in the old days: code reviews. Gerrit has no such functionality and in any case, reviewers need to agree between themselves on what they ar reviewing. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Jun 22 17:44:26 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jun 2018 08:44:26 -0700 Subject: [Development] clang-format In-Reply-To: References: <1665868.Big65L9shF@frederik-thinkcentre-m93p> <2608989.0EdPNPQHza@tjmaciei-mobl1> Message-ID: <1865674.nntCcgq3Y0@tjmaciei-mobl1> On Friday, 22 June 2018 08:34:09 PDT Scott Bloom wrote: > But IMO, wholesale "format changes" have zero value to the customer, so any > pain associated with them, should be weighed against the time and effort > necessary to implement a format change that is being taken away from > customer oriented development. Right. I'm ok with the bot announcing formatting errors and getting people to agree on a single format. So long as we agree that there's no whitespace before a comma. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philwave at gmail.com Fri Jun 22 18:11:40 2018 From: philwave at gmail.com (Philippe) Date: Fri, 22 Jun 2018 18:11:40 +0200 Subject: [Development] clang-format In-Reply-To: References: <2608989.0EdPNPQHza@tjmaciei-mobl1> Message-ID: <20180622181139.E6C1.6F0322A@gmail.com> > I usually come to the conclusion, code in the style you want, > unless it's a bad format. "bad format" is subjective and the use of clang-format precisely bypasses subjectivity. > But IMO, wholesale "format changes" have zero value to the customer, so any > pain associated with them, should be weighed against the time and > effort necessary to implement a format change that is being taken away from > customer oriented development. I have a different POV: everything that eases the developer's work, means spared development time, hence more productivity, hence benefits to customers at the end. Not having to take care of code-formatting, thanks to clang-format, eases programming. And looking at someone else code with a familiar format, gives the feeling "I am home" (provided some naming guideline is respected). Philippe On Fri, 22 Jun 2018 15:34:09 +0000 Scott Bloom wrote: > Fair enough.. It just seems that this thread has fundamentally become a religious issue over format, and when it should be forced on people... > > I fight this all the time in my organization... I usually come to the conclusion, code in the style you want, unless it's a bad format. And like pornography, I cant define it but I know it when I see it... > > But IMO, wholesale "format changes" have zero value to the customer, so any pain associated with them, should be weighed against the time and effort necessary to implement a format change that is being taken away from customer oriented development. > > Scott > > -----Original Message----- > From: Development On Behalf Of Thiago Macieira > Sent: Friday, June 22, 2018 08:26 > To: development at qt-project.org > Subject: Re: [Development] clang-format > > On Friday, 22 June 2018 07:40:58 PDT Scott Bloom wrote: > > In a series of wrapper scripts, essentially, everything checked in was > > converted to the check in format. However each developer had their > > own format . And on checkout, the code would be compare to it. > > > > On "Diff" analysis of two reversions, you had to see the diff based on > > the checked in format. > > > > It really made things, that much simpler... and we never heard people > > bitch and moan about where the curley brackets belong > > Git has such a functionality, it's called the clean/smudge filters. See man gitattributes for more information. > > But that still means the code you see is subject to the smudge filter's whims. > We've concluded that it doesn't always do the right thing. > > And besides, there's something new that didn't exist in the old days: code reviews. Gerrit has no such functionality and in any case, reviewers need to agree between themselves on what they ar reviewing. > > -- > 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 scott at towel42.com Fri Jun 22 18:39:55 2018 From: scott at towel42.com (Scott Bloom) Date: Fri, 22 Jun 2018 16:39:55 +0000 Subject: [Development] clang-format In-Reply-To: <20180622181139.E6C1.6F0322A@gmail.com> References: <2608989.0EdPNPQHza@tjmaciei-mobl1> <20180622181139.E6C1.6F0322A@gmail.com> Message-ID: I cant even get my developers to agree the emacs takes to many fingers, and VI(m) is the only editor they need.... Let alone, where the brackets and spaces belong.... Let alone, if statements on the same line as the conditional.... The problem ive seen, is while you may LOVE the curly brackts on the same line, you will never convince me... 😊 -----Original Message----- From: Development On Behalf Of Philippe Sent: Friday, June 22, 2018 09:12 To: development at qt-project.org Subject: Re: [Development] clang-format > I usually come to the conclusion, code in the style you want, unless > it's a bad format. "bad format" is subjective and the use of clang-format precisely bypasses subjectivity. > But IMO, wholesale "format changes" have zero value to the customer, > so any pain associated with them, should be weighed against the time > and effort necessary to implement a format change that is being taken > away from customer oriented development. I have a different POV: everything that eases the developer's work, means spared development time, hence more productivity, hence benefits to customers at the end. Not having to take care of code-formatting, thanks to clang-format, eases programming. And looking at someone else code with a familiar format, gives the feeling "I am home" (provided some naming guideline is respected). Philippe On Fri, 22 Jun 2018 15:34:09 +0000 Scott Bloom wrote: > Fair enough.. It just seems that this thread has fundamentally become a religious issue over format, and when it should be forced on people... > > I fight this all the time in my organization... I usually come to the conclusion, code in the style you want, unless it's a bad format. And like pornography, I cant define it but I know it when I see it... > > But IMO, wholesale "format changes" have zero value to the customer, so any pain associated with them, should be weighed against the time and effort necessary to implement a format change that is being taken away from customer oriented development. > > Scott > > -----Original Message----- > From: Development > On Behalf Of > Thiago Macieira > Sent: Friday, June 22, 2018 08:26 > To: development at qt-project.org > Subject: Re: [Development] clang-format > > On Friday, 22 June 2018 07:40:58 PDT Scott Bloom wrote: > > In a series of wrapper scripts, essentially, everything checked in > > was converted to the check in format. However each developer had > > their own format . And on checkout, the code would be compare to it. > > > > On "Diff" analysis of two reversions, you had to see the diff based > > on the checked in format. > > > > It really made things, that much simpler... and we never heard > > people bitch and moan about where the curley brackets belong > > Git has such a functionality, it's called the clean/smudge filters. See man gitattributes for more information. > > But that still means the code you see is subject to the smudge filter's whims. > We've concluded that it doesn't always do the right thing. > > And besides, there's something new that didn't exist in the old days: code reviews. Gerrit has no such functionality and in any case, reviewers need to agree between themselves on what they ar reviewing. > > -- > 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 _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From ville.voutilainen at gmail.com Fri Jun 22 18:47:14 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Fri, 22 Jun 2018 19:47:14 +0300 Subject: [Development] clang-format In-Reply-To: References: <2608989.0EdPNPQHza@tjmaciei-mobl1> <20180622181139.E6C1.6F0322A@gmail.com> Message-ID: On 22 June 2018 at 19:39, Scott Bloom wrote: > I cant even get my developers to agree the emacs takes to many fingers, and VI(m) is the only editor they need.... > > Let alone, where the brackets and spaces belong.... > > Let alone, if statements on the same line as the conditional.... > > The problem ive seen, is while you may LOVE the curly brackts on the same line, you will never convince me... 😊 The problem I have with this oft-recurring formatting discussion is that it's advertised as a big benefit, sometimes downplaying its cost. It doesn't help me all that much to have familiar formatting and naming in a translation unit; that consistency is dwarfed by the effort needed to understand the logical design of the code to reasonable modify/refactor/maintain it. I think it's reasonable and harmless to clang-format new changes; I continue to be unconvinced of the cost/benefit ratio of reformatting all of our existing code. From scott at towel42.com Fri Jun 22 18:55:35 2018 From: scott at towel42.com (Scott Bloom) Date: Fri, 22 Jun 2018 16:55:35 +0000 Subject: [Development] clang-format In-Reply-To: References: <2608989.0EdPNPQHza@tjmaciei-mobl1> <20180622181139.E6C1.6F0322A@gmail.com> Message-ID: > I cant even get my developers to agree the emacs takes to many fingers, and VI(m) is the only editor they need.... > > Let alone, where the brackets and spaces belong.... > > Let alone, if statements on the same line as the conditional.... > > The problem ive seen, is while you may LOVE the curly brackts on the > same line, you will never convince me... 😊 The problem I have with this oft-recurring formatting discussion is that it's advertised as a big benefit, sometimes downplaying its cost. It doesn't help me all that much to have familiar formatting and naming in a translation unit; that consistency is dwarfed by the effort needed to understand the logical design of the code to reasonable modify/refactor/maintain it. I think it's reasonable and harmless to clang-format new changes; I continue to be unconvinced of the cost/benefit ratio of reformatting all of our existing code. ---------------- Agreed. I have moved to the "over all policy" of don’t check in crap code... 😊 And run your styler as you need to, on code you are working on, if it helps you understand it. And "try" to avoid checking in "format only changes" Scott From philwave at gmail.com Fri Jun 22 19:27:16 2018 From: philwave at gmail.com (Philippe) Date: Fri, 22 Jun 2018 19:27:16 +0200 Subject: [Development] clang-format In-Reply-To: References: Message-ID: <20180622192715.E6CB.6F0322A@gmail.com> > It doesn't help me all that much to have > familiar formatting and naming in a translation > unit This is a good skill. But the idea is to help developers that don't have this skill. Philippe On Fri, 22 Jun 2018 19:47:14 +0300 Ville Voutilainen wrote: > On 22 June 2018 at 19:39, Scott Bloom wrote: > > I cant even get my developers to agree the emacs takes to many fingers, and VI(m) is the only editor they need.... > > > > Let alone, where the brackets and spaces belong.... > > > > Let alone, if statements on the same line as the conditional.... > > > > The problem ive seen, is while you may LOVE the curly brackts on the same line, you will never convince me... ?? > > The problem I have with this oft-recurring formatting discussion is > that it's advertised as a big benefit, sometimes > downplaying its cost. It doesn't help me all that much to have > familiar formatting and naming in a translation > unit; that consistency is dwarfed by the effort needed to understand > the logical design of the code to reasonable > modify/refactor/maintain it. > > I think it's reasonable and harmless to clang-format new changes; I > continue to be unconvinced of the cost/benefit ratio > of reformatting all of our existing code. From Liang.Qi at qt.io Mon Jun 25 09:37:44 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Mon, 25 Jun 2018 07:37:44 +0000 Subject: [Development] Merge and Integration status report Message-ID: Integrations * qt5 dev integration is healthy, last one is yesterday * qt5 5.11 integration failed from June 9, last integration was done on June 22, but skipped qtbase and qtwayland. * * Issue: [QTBUG-68773][1] qtwayland build failed - can't find some headers * * * https://codereview.qt-project.org/#/c/232288/ Robert Griebl has a fix, Oswald please help to review it. Suggest to revert to get 5.11 integrated again, [see the revert][2] Merges * qtbase 5.11->dev, the merge is blocked because [QTBUG-68773][1] is not fixed yet. -- Liang [1]: https://bugreports.qt.io/browse/QTBUG-68773 [2]: https://codereview.qt-project.org/#/c/233198/ From olszak.tomasz at gmail.com Mon Jun 25 11:12:30 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Mon, 25 Jun 2018 11:12:30 +0200 Subject: [Development] Merge and Integration status report In-Reply-To: <526c92ba-78ad-7c53-034c-259111d4b9a8@qt.io> References: <526c92ba-78ad-7c53-034c-259111d4b9a8@qt.io> Message-ID: Do you announce here once qtdeclarative ci is fixed and one can merge patch to staging? wt., 19 cze 2018 o 18:41 Ulf Hermann napisał(a): > > Hi, > > > Ulf has now submitted a workaround that should also allow us to get > > an overview of running processes if it doesn't work. We've got a set > > of changes trying integration in 5.11 with that workaround merged and > > I'll try to get this also into dev. > > Nope, that didn't work. The slowdown lasts less than 15 minutes, but long enough to trigger a timeout in the debugging tests after it goes away. So, we don't get the watchdog to kill the tests (which would show the concurrently running processes), but the tests still fail. See https://bugreports.qt.io/browse/QTBUG-68741 for details. We either got incredibly lucky with https://codereview.qt-project.org/231618 or the CI has another bug and accepted this test although it shouldn't. > > br, > Ulf > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Mon Jun 25 11:25:46 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 25 Jun 2018 09:25:46 +0000 Subject: [Development] Merge and Integration status report In-Reply-To: References: <526c92ba-78ad-7c53-034c-259111d4b9a8@qt.io>, Message-ID: Yes, declarative is open again. Simon ________________________________ From: Development on behalf of Tomasz Olszak Sent: Monday, June 25, 2018 11:12:30 AM To: development at qt-project.org Subject: Re: [Development] Merge and Integration status report Do you announce here once qtdeclarative ci is fixed and one can merge patch to staging? wt., 19 cze 2018 o 18:41 Ulf Hermann napisał(a): > > Hi, > > > Ulf has now submitted a workaround that should also allow us to get > > an overview of running processes if it doesn't work. We've got a set > > of changes trying integration in 5.11 with that workaround merged and > > I'll try to get this also into dev. > > Nope, that didn't work. The slowdown lasts less than 15 minutes, but long enough to trigger a timeout in the debugging tests after it goes away. So, we don't get the watchdog to kill the tests (which would show the concurrently running processes), but the tests still fail. See https://bugreports.qt.io/browse/QTBUG-68741 for details. We either got incredibly lucky with https://codereview.qt-project.org/231618 or the CI has another bug and accepted this test although it shouldn't. > > br, > Ulf > _______________________________________________ > 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 Oliver.Wolff at qt.io Wed Jun 27 07:14:07 2018 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Wed, 27 Jun 2018 07:14:07 +0200 Subject: [Development] qtbase auto tests on UWP (formerly known as WinRT) enabled Message-ID: <0226ea22-f142-cd03-51b4-69416a4b4604@qt.io> Hi, yesterday I merged a change, that enables execution of qtbase auto tests on UWP (formerly known as WinRT). The used configuration uses MSVC 2015 so error messages should be somewhat familiar, but some UWP headers tend to give weird error messages. If you run into a problem you cannot fix yourself, please just ping on #qt-winrt on freenode or send me a mail. I have already seen on integration which fails due to the WinRT config (https://codereview.qt-project.org/#/c/233249/) and am currently having a look at what's wrong there. BR, Olli From Oliver.Wolff at qt.io Wed Jun 27 07:38:17 2018 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Wed, 27 Jun 2018 07:38:17 +0200 Subject: [Development] qtbase auto tests on UWP (formerly known as WinRT) enabled In-Reply-To: <0226ea22-f142-cd03-51b4-69416a4b4604@qt.io> References: <0226ea22-f142-cd03-51b4-69416a4b4604@qt.io> Message-ID: On 27/06/2018 07:14, Oliver Wolff wrote: > Hi, > > yesterday I merged a change, that enables execution of qtbase auto > tests on UWP (formerly known as WinRT). > > The used configuration uses MSVC 2015 so error messages should be > somewhat familiar, but some UWP headers tend to give weird error > messages. If you run into a problem you cannot fix yourself, please > just ping on #qt-winrt on freenode or send me a mail. > > I have already seen on integration which fails due to the WinRT config > (https://codereview.qt-project.org/#/c/233249/) and am currently > having a look at what's wrong there. https://codereview.qt-project.org/#/c/233403/ reviews welcome and sorry for the breakage > > BR, > Olli > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From a.rehn at menlosystems.com Wed Jun 27 10:24:53 2018 From: a.rehn at menlosystems.com (Arno Rehn) Date: Wed, 27 Jun 2018 10:24:53 +0200 Subject: [Development] QWebChannel pure C++14 client Message-ID: <7a8b1730-2cd1-b810-6d58-8a40198bd6bf@menlosystems.com> Hey everyone, FYI: We've now also completed the QWebChannel C++14 client: https://github.com/MenloSystems/webchannelpp It's header-only and depends only on the C++ JSON library by Niels Lohmann (https://github.com/nlohmann/json). Usage is a little different from usage of QWebChannel in dynamic languages like javascript or python. But with C++14 features it's still quite pleasant to work with. I haven't gotten around to creating a proper example, but I'll do that as soon as I find the time. Regards, Arno -- Arno Rehn Tel +49 89 189 166 0 Fax +49 89 189 166 111 a.rehn at menlosystems.com www.menlosystems.com Menlo Systems GmbH Am Klopferspitz 19a, 82152 Martinsried, Germany Amtsgericht München HRB 138145 Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr. DE217772017, St.-Nr. 14316170324 From thiago.macieira at intel.com Wed Jun 27 16:55:08 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 27 Jun 2018 07:55:08 -0700 Subject: [Development] QWebChannel pure C++14 client In-Reply-To: <7a8b1730-2cd1-b810-6d58-8a40198bd6bf@menlosystems.com> References: <7a8b1730-2cd1-b810-6d58-8a40198bd6bf@menlosystems.com> Message-ID: <3711460.0QcWIJXMHT@tjmaciei-mobl1> On Wednesday, 27 June 2018 01:24:53 PDT Arno Rehn wrote: > FYI: We've now also completed the QWebChannel C++14 client: > https://github.com/MenloSystems/webchannelpp > > It's header-only and depends only on the C++ JSON library by Niels > Lohmann (https://github.com/nlohmann/json). You forgot the Asio dependency, which makes it not pure C++. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From eric.lemanissier at gmail.com Thu Jun 28 16:44:41 2018 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Thu, 28 Jun 2018 16:44:41 +0200 Subject: [Development] Relocating a Qt compilation Message-ID: Hello, I'm currently working on a Qt package for conan, and the fact that qt files have absolute path hard-coded in them is problematic. The use case is the following : a user downloads a binary distribution of Qt (qmake+moc+include+libs etc.), which is then stored in a directory which cannot be known when compiling said distribution. MaintenanceTool does the exact same job of downloading existing binaries and storing them in directory chosen by the user, so it has to patch the files. Are MaintenceTool's sources available, or at least the patching process ? There used to be a small tool (qpatch? qtpatch?) doing that, but I cannot find it Thanks! Eric -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Jun 28 16:57:34 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 28 Jun 2018 07:57:34 -0700 Subject: [Development] Relocating a Qt compilation In-Reply-To: References: Message-ID: <1943750.UJHkPfllz3@tjmaciei-mobl1> On Thursday, 28 June 2018 07:44:41 PDT Eric Lemanisser wrote: > Hello, > > I'm currently working on a Qt package for conan, and the fact that qt files > have absolute path hard-coded in them is problematic. The use case is the > following : a user downloads a binary distribution of Qt > (qmake+moc+include+libs etc.), which is then stored in a directory which > cannot be known when compiling said distribution. > MaintenanceTool does the exact same job of downloading existing binaries > and storing them in directory chosen by the user, so it has to patch the > files. Are MaintenceTool's sources available, or at least the patching > process ? There used to be a small tool (qpatch? qtpatch?) doing that, but > I cannot find it For a single-use build, you don't need to do that. Everything that needs to be found at runtime which would use those hardcoded paths can also be overridden by environment variables (XDG_CONFIG_DIRS, QT_PLUGIN_PATH and QML2_IMPORT_PATH). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mark.dewit at iesve.com Thu Jun 28 19:29:05 2018 From: mark.dewit at iesve.com (Mark De Wit) Date: Thu, 28 Jun 2018 17:29:05 +0000 Subject: [Development] Relocating a Qt compilation In-Reply-To: <1943750.UJHkPfllz3@tjmaciei-mobl1> References: <1943750.UJHkPfllz3@tjmaciei-mobl1> Message-ID: <74c36ecef1ff4dddb16106595520b446@iesve.com> A qt.conf file could also help point to correct locations. It doesn't have to be absolute, it can be relative? This is how we deal with the hard-coded paths. Mark -----Original Message----- From: Development On Behalf Of Thiago Macieira Sent: 28 June 2018 15:58 To: development at qt-project.org Subject: Re: [Development] Relocating a Qt compilation On Thursday, 28 June 2018 07:44:41 PDT Eric Lemanisser wrote: > Hello, > > I'm currently working on a Qt package for conan, and the fact that qt > files have absolute path hard-coded in them is problematic. The use > case is the following : a user downloads a binary distribution of Qt > (qmake+moc+include+libs etc.), which is then stored in a directory > which cannot be known when compiling said distribution. > MaintenanceTool does the exact same job of downloading existing > binaries and storing them in directory chosen by the user, so it has > to patch the files. Are MaintenceTool's sources available, or at least > the patching process ? There used to be a small tool (qpatch? > qtpatch?) doing that, but I cannot find it For a single-use build, you don't need to do that. Everything that needs to be found at runtime which would use those hardcoded paths can also be overridden by environment variables (XDG_CONFIG_DIRS, QT_PLUGIN_PATH and QML2_IMPORT_PATH). -- 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 Sat Jun 30 18:14:21 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 30 Jun 2018 09:14:21 -0700 Subject: [Development] Urgent: increase timeout for tst_qcomplextext Message-ID: <11510557.QrXFdc88bb@tjmaciei-mobl1> It has failed now four times in the last 24 hours and is responsible for all failures that didn't fail with a network issue first. I ran it on my machine and it took about a minute, while I was also compiling something else. Given the usual 30:1 slowness of the CI, it could take as much as half an hour there. I tried to add a change to increase the timeout https://codereview.qt-project.org/233691 but Liang pointed out that my inspiration is a change by Rohan McGovern back in 2012: dd3e4f1dbe8 tests/auto/network/access/qnetworkreply/test/test.pro (Rohan McGovern 2012-05-29 16:20:22 +1000 2) testcase.timeout = 600 # this test is slow So it's highly unlikely that the current CI still obeys this setting. I'm assuming therefore that it's hidden somewhere non-obvious (= anywhere not next to the test itself) and therefore I'm just bugging you. I'll create a P0 if my current integration fails again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Sat Jun 30 19:09:11 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Sat, 30 Jun 2018 17:09:11 +0000 Subject: [Development] Urgent: increase timeout for tst_qcomplextext In-Reply-To: <11510557.QrXFdc88bb@tjmaciei-mobl1> References: <11510557.QrXFdc88bb@tjmaciei-mobl1> Message-ID: <7CB793EC-D68A-4E6E-BF0B-A9A740B3E7CD@qt.io> Hi Thiago, maybe https://codereview.qt-project.org/#/c/233693/ helps with this case. Cheers, Lars On 30 Jun 2018, at 18:14, Thiago Macieira > wrote: It has failed now four times in the last 24 hours and is responsible for all failures that didn't fail with a network issue first. I ran it on my machine and it took about a minute, while I was also compiling something else. Given the usual 30:1 slowness of the CI, it could take as much as half an hour there. I tried to add a change to increase the timeout https://codereview.qt-project.org/233691 but Liang pointed out that my inspiration is a change by Rohan McGovern back in 2012: dd3e4f1dbe8 tests/auto/network/access/qnetworkreply/test/test.pro (Rohan McGovern 2012-05-29 16:20:22 +1000 2) testcase.timeout = 600 # this test is slow So it's highly unlikely that the current CI still obeys this setting. I'm assuming therefore that it's hidden somewhere non-obvious (= anywhere not next to the test itself) and therefore I'm just bugging you. I'll create a P0 if my current integration fails again. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: