From samuel.gaist at edeltech.ch Wed Feb 1 00:32:43 2017 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Wed, 1 Feb 2017 00:32:43 +0100 Subject: [Development] New library in qtbase In-Reply-To: <1484489067.2943961.848263240.33267E5F@webmail.messagingengine.com> References: <13507339.QtWAKzEl5T@tjmaciei-mobl1> <00277C8A-FA69-44DF-85A3-CA224DE8B688@edeltech.ch> <2976940.gPpOHW8DdO@tjmaciei-mobl1> <9D014B0F-982B-4A5E-AC85-91B5A85F7170@edeltech.ch> <5C427FD9-5003-41CD-9B43-91F5D34DCC39@qt.io> <938B8FC5-626C-47B1-BB12-6017C475490A@edeltech.ch> <357754E1-D65A-4037-948D-CCDA582D2D97@qt.io> <2ED199A8-0E6C-4EEE-9CE1-9F32C72BFA8B@edeltech.ch> <1484489067.2943961.848263240.33267E5F@webmail.messagingengine.com> Message-ID: <4EB513C7-4577-4672-90C9-2E67E2D17D76@edeltech.ch> > On 15 Jan 2017, at 15:04, Robin Burchell wrote: > > On Fri, Jan 13, 2017, at 11:58 PM, Samuel Gaist wrote: >> Short summary, we have three possibilities: >> 1) Own module (and current implementation) >> 2) One “core" module and one GUI module to separate concerns for system >> not requiring a GUI connection (Jake’s suggestion) >> 3) Put everything in QtGui and implement the stuff in the QPA parts with >> the implication that a QGuiApplication will be required. >> >> Can we come to an agreement about which one to implement ? > > My own vote would be tending towards 3 once the concept is nailed down. > The existing change looks a little confused from a quick skim, e.g. you > have a QCocoaNotifier which seems to be public API, but this is not the > way I would expect to see this (at least, not in QtGui); I'd expect to > see a "notification" class without any platform specifics, as far as > possible, which then hooked into platform-specific code to "do its > magic". > > As the "magic" would tend to be platform-specific, QPA seems to be the > logical place to me; this then also allows a platform implementer to > provide their own custom notification handling, should it be required – > thinking more on the embedded or new platform front here, which is > typically where QPA comes in anyway, where you may not necessarily have > existing services or standards to follow. > > I can agree that it's "sad" to have to switch a QCoreApplication to a > QGuiApplication once you need something in it, even if you don't have a > GUI to present (though really, is this a common problem?), but aside > from puritanical concerns, does that actually cause many concrete > issues? > > So, considering that, and as it's a problem that already exists for > non-graphical applications to have to interact with images/clipboard, > for syntax highlighting and other text manipulation, etc, I don't think > that adding another case to that problem is a death sentence. I think > it's an extension of a minor inconvenience, but I don't think that > arbitrary splitting of a feature or class is a good way to address that. > It leads to a harder to use & understand API for little gain as I > imagine it, though it is hard to say without a concrete suggestion on > API to review. > > In the much longer term, on a separate tangent from your work, it might > be interesting to think about rearranging things to properly address > this problem if the gain is worth it, but even then, that starts to get > tricky & requires a lot of care and research, especially when you > realize that not everything you may want can be done without a windowing > system: clipboard access, for instance, I'd say is almost certainly > impossible to do without a windowing system on all platforms > > The same may apply to presenting notifications. Do you know the specific > requirements of the APIs for, say, Windows/macOS/iOS/Android? If any of > those (or future platforms) required the WS, then you'd essentially be > left with a useless API on anything that did not have a QGuiApplication. > > I'd say that ultimately, requiring a QGuiApplication instance is a > lesser evil than providing an API that won't work universally. > > -- > Robin Burchell > robin at crimson.no > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > Hi Robin, Thanks for your thorough analysis. The implemented plugin classes are not meant to be public API at all. They follow the naming scheme from QPA since the original implementation was done through it but in a less re-usable manner. This is definitely an area that will be cleaned up. Thinking about your comments and the suggestion from Jake, I was wondering if cutting things a bit in the middle would be an interesting solution: what about having the integration in QPA and the implementation in a separated module ? This would allow to avoid making the GUI module bigger with code that is not directly GUI related (as in actively drawing) while keeping the platform specific stuff together. Cheers Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From m.weghorn at posteo.de Wed Feb 1 09:52:47 2017 From: m.weghorn at posteo.de (Michael Weghorn) Date: Wed, 01 Feb 2017 09:52:47 +0100 Subject: [Development] Printer-specific options in Qt5's print dialog (Linux, CUPS) In-Reply-To: <9807a11e-9dd1-87c8-b1a9-89b4f33e69c2@kde.org> References: <3899068.oCfgoQ7oib@tjmaciei-mobl1> <6025AF62-E52E-4AF6-A263-AD5E712FA25E@qt.io> <6a998402d6deb9fb2b8f505d9860b4af@posteo.de> <9807a11e-9dd1-87c8-b1a9-89b4f33e69c2@kde.org> Message-ID: On 2017-01-31 14:32, Christoph Feck wrote: > On 31.01.2017 09:55, Michael Weghorn wrote: > >> [...] The links about the plans for the Qt print system that >> John provided in his email [1] give some kind of overview, but are >> currently not enough for me to deduce the concrete next steps that >> need >> to be taken for the implementation. >> >> If you (or somebody else) can give more information on that, this is >> certainly something we would be happy about and that we will examine >> more closely. > > According to > http://www.layt.net/john/blog/odysseus/focusing_on_printing_in_qt_5 > John also did a big triage of reported issues in the printing system, > which has a master bug at https://bugreports.qt.io/browse/QTBUG-37696 > Thank you for that link, I will have a look at that. From a.volkov at rusbitech.ru Wed Feb 1 10:53:45 2017 From: a.volkov at rusbitech.ru (Alexander Volkov) Date: Wed, 1 Feb 2017 12:53:45 +0300 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <2520893.RM0PXepoGU@tjmaciei-mobl1> References: <201701302003.25214.marc.mutz@kdab.com> <4690544.OpgdffnZ55@tjmaciei-mobl1> <201701311853.56327.marc.mutz@kdab.com> <2520893.RM0PXepoGU@tjmaciei-mobl1> Message-ID: 31.01.2017 21:52, Thiago Macieira пишет: > Good point, that's a point in favour of having Q{String,ByteArray}View. > > We need to think how that will work with having classes for exclusive > ownership (not implicitly shared). That's the counterpart of the Views: they > don't own, but they only have read-only access. I want to provide a solution > for the mutating operations too. It would be nice to have not implicitly shared string class for QTextStream::readLineInto(). Currently it reads into QString as in a buffer and if you need to copy the buffer, then you have to manually make a deep copy of it: QTextStream ts(...); QString line; line.reserve(1024); QStringList found; while (ts.readLineInto(&line)) { ... found.append(QString(line.constData(), line.size())); // deep copy } Otherwise the buffer will be detached and copied on the next calling of readLineInto() and will lose its capacity. From Simon.Hausmann at qt.io Wed Feb 1 14:17:50 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 1 Feb 2017 13:17:50 +0000 Subject: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows? In-Reply-To: References: <20170129093339.GA15723@klara.mpi.htwm.de> <5938704.sfqBRPjXeF@tjmaciei-mobl1> <40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io> <22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com> , Message-ID: Hi, Apart from André's imaginary wall ;-), I wonder if we can take this statement and change the "Conventions in Qt source code" part of http://wiki.qt.io/Coding_Conventions from "All code is ascii only (7-bit characters only, run man ascii if unsure)" to "All code is utf-8 only" and remove the first bullet point? Or alternatively an edit by somebody with more expertise would be appreciated of course :) Simon ________________________________ From: Lars, Knoll Sent: Monday, January 30, 2017 12:48:09 PM To: Simon, Hausmann Cc: Viktor, Engelmann; Qt development mailing list Subject: Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows? On 30 Jan 2017, at 12:23, Simon, Hausmann > wrote: Making a warning go away for compilers that we know support utf-8 may not come at the price of your life :) I for one am all in favor of requiring just the Qt source code (not talking about customer code) to be encoded in a 24 year old standard and add all the necessary flags to the compilers to make them understand it instead of producing a warning. We practically support three different front-ends: GCC, clang and MSVC. All three - MSVC with the help of an option - can grok UTF-8. Let's use it at least inside Qt :) +1. Let's enable it. Btw, this had actually been planned for Qt 5.0. Unfortunately we couldn't implement it back then, as MSVC was not allowing us to set the input encoding to utf8. Cheers, Lars Simon ________________________________ From: Development > on behalf of Viktor Engelmann > Sent: Monday, January 30, 2017 12:06:19 PM To: development at qt-project.org Subject: Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows? Am 30.01.2017 um 11:40 schrieb Giuseppe D'Angelo: > Il 30/01/2017 11:35, Viktor Engelmann ha scritto: >> As far as I can see, all our codes *are* UTF-8 encoded (a least they >> should be, IMHO), so why would we sneak our UTF8 in behind it's back (in >> 2017!) instead of just telling the compiler the encoding we are using? > So *all* of our compilers happily support UTF-8 encoded sources? I wouldn't bet my life on that (especially not for windows!) -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 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 _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Wed Feb 1 14:25:53 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Wed, 1 Feb 2017 13:25:53 +0000 Subject: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows? In-Reply-To: <20170130174154.GB1702@klara.mpi.htwm.de> References: <20170129093339.GA15723@klara.mpi.htwm.de> <5938704.sfqBRPjXeF@tjmaciei-mobl1> <40cc1ade-02d6-2c70-6c13-cdcb1bcd9e40@qt.io> <22857b87-c4c1-f629-5a0d-e4fb1ab7a3f8@kdab.com> , <20170130174154.GB1702@klara.mpi.htwm.de> Message-ID: Hi, What may be a door for you (or maybe it isn't actually) may be a wall for somebody else. Imagine an individual contributor who would like to contribute a portion of code that is large enough to for the contributor to make an explicit copyright/author claim at the top of the file. For KDAB that's easy, but for an individual from other countries and cultures forcing the choice of an ASCII encoded "version" of their name may be perceived in a negative way (from "not welcome" to perhaps even "discriminating"). So what's a door and what isn't is subjective, but I really don't see a reason to keep the wall there altogether when we can remove it with what seems little effort. Simon ________________________________ From: André Pönitz Sent: Monday, January 30, 2017 6:41:54 PM To: Simon, Hausmann Cc: Viktor, Engelmann; development at qt-project.org Subject: Re: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows? On Mon, Jan 30, 2017 at 11:23:30AM +0000, Simon, Hausmann wrote: > We practically support three different front-ends: GCC, clang and > MSVC. All three - MSVC with the help of an option - can > grok UTF-8. Let's use it at least inside Qt :) Qt source is handled by a variety of tools, not only compilers. Nowadays they kind of all kind of always support kind of UTF-8, yeah, so use it, if it works. Fine. But I absolutely don't get the point of trying to run with my head into a wall because I know there is a door in the wall on the construction drawing in this place, even if my eyes tell me it's a couple of feet to the left. Andre' -------------- next part -------------- An HTML attachment was scrubbed... URL: From Liang.Qi at qt.io Wed Feb 1 14:33:33 2017 From: Liang.Qi at qt.io (Liang Qi) Date: Wed, 1 Feb 2017 13:33:33 +0000 Subject: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows? In-Reply-To: <17777359.jmSXjxjUd5@tjmaciei-mobl1> References: <5938704.sfqBRPjXeF@tjmaciei-mobl1> <79af8d51-4137-8c1d-f903-19d0ff985aa1@kdab.com> <17777359.jmSXjxjUd5@tjmaciei-mobl1> Message-ID: http://doc.qt.io/qt-5/supported-platforms.html msvc 2013 is still supported in 5.8 http://doc.qt.io/qt-5.6/supported-platforms.html msvc 2010/2012/2013 are still supported in 5.6 Compiler options for msvc 2015: https://msdn.microsoft.com/en-us/library/fwkeyyhe.aspx Compiler options for msvc 2013: https://msdn.microsoft.com/en-us/library/fwkeyyhe(v=vs.120).aspx If not all supported compilers support /utf-8 or similar options, what should be done next step? Best Regards, Liang > On 30 Jan 2017, at 17:30, Thiago Macieira wrote: > > On segunda-feira, 30 de janeiro de 2017 09:56:46 PST Giuseppe D'Angelo wrote: >> Il 30/01/2017 02:21, Thiago Macieira ha scritto: >>> So, we should: >>> a) still avoid non-ASCII in our source files, aside from comments >>> b) allow non-ASCII in comments, as needed >> >> Didn't we have issues with UTF-8 in comments too, when using MSVC? > > Yes, which means that if it chokes on KDAB's name in qglobal.h, too bad. > >>> c) turn the -utf-8 option on for MSVC2015U3. >> >> But just for Qt own build, not push this option onto the users. Also, >> does this fix anything? Is MSVC 2015 U3 the only one complaining, and we >> can live with UTF-8 in the source when using other compilers? > > This will affect the Qt build only. Only MSVC 2015 U3 gets the fix, the older > versions and MSVC 2013 will still be affected. > > Sorry, tough luck for the others. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Wed Feb 1 15:20:02 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 1 Feb 2017 15:20:02 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: References: <201701302003.25214.marc.mutz@kdab.com> <2520893.RM0PXepoGU@tjmaciei-mobl1> Message-ID: <201702011520.02832.marc.mutz@kdab.com> On Wednesday 01 February 2017 10:53:45 Alexander Volkov wrote: > found.append(QString(line.constData(), line.size())); // deep copy Ummm.. found.append(line.constData(), line.size()); Problem solved? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Wed Feb 1 15:22:22 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 1 Feb 2017 15:22:22 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <201702011520.02832.marc.mutz@kdab.com> References: <201701302003.25214.marc.mutz@kdab.com> <201702011520.02832.marc.mutz@kdab.com> Message-ID: <201702011522.22634.marc.mutz@kdab.com> On Wednesday 01 February 2017 15:20:02 Marc Mutz wrote: > On Wednesday 01 February 2017 10:53:45 Alexander Volkov wrote: > > found.append(QString(line.constData(), line.size())); // deep > > copy > > Ummm.. > > found.append(line.constData(), line.size()); > > Problem solved? Ah, nevermind, 'found' is a QString_List_. I'm curious how a non-implicitly-shared string type would help you there, though. You can always clear() (or, in case of QVector, std::move()) the string, and capacity is left with the sole owner in the container. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From a.volkov at rusbitech.ru Wed Feb 1 16:09:17 2017 From: a.volkov at rusbitech.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCS0L7Qu9C60L7Qsg==?=) Date: Wed, 1 Feb 2017 18:09:17 +0300 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <201702011522.22634.marc.mutz@kdab.com> References: <201701302003.25214.marc.mutz@kdab.com> <201702011520.02832.marc.mutz@kdab.com> <201702011522.22634.marc.mutz@kdab.com> Message-ID: <0fa6e612-0a5a-3d73-3c7c-51095ee3dd4b@rusbitech.ru> 01.02.2017 17:22, Marc Mutz пишет: > Ah, nevermind, 'found' is a QString_List_. > > I'm curious how a non-implicitly-shared string type would help you there, > though. You can always clear() (or, in case of QVector, std::move()) > the string, and capacity is left with the sole owner in the container. QString s1; s1.reserve(1024); s1.resize(100, '*'); qDebug() << s1.capacity(); // 1024 QString s2 = s1; s1[0] = '-'; qDebug() << s1.capacity(); // 100 qDebug() << s2.capacity(); // 1024 With non-implicitly-shared string the capacity of s1 won't change. The idea of readLineInto() is to avoid memory allocations by writing into the pre-allocated buffer. But when readLineInto() is trying to write into an implicitly shared string buffer, then the content of the buffer is copied and readLineInto() writes into the copy. From sean.harmer at kdab.com Wed Feb 1 18:01:36 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Wed, 01 Feb 2017 17:01:36 +0000 Subject: [Development] GPL tooling in Qt module? Message-ID: <1860993.H2X5KvD4NB@titan> Hi, as part of the current animation support in Qt3D we've written an addon for blender that is able to export all the animation clips in a blender file to a format that Qt 3D can use (json based). As such addons need to run within the blender runtime which is GPL, the addon also needs to be GPL licensed. Which is fine. The only question is, is it OK to add such a tool (python script) to the Qt 3D repo? It's not used within Qt 3D itself at all. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From annulen at yandex.ru Wed Feb 1 18:06:13 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 01 Feb 2017 20:06:13 +0300 Subject: [Development] GPL tooling in Qt module? In-Reply-To: <1860993.H2X5KvD4NB@titan> References: <1860993.H2X5KvD4NB@titan> Message-ID: <3086651485968773@web23g.yandex.ru> 01.02.2017, 20:01, "Sean Harmer" : > Hi, > > as part of the current animation support in Qt3D we've written an addon for > blender that is able to export all the animation clips in a blender file to a > format that Qt 3D can use (json based). > > As such addons need to run within the blender runtime which is GPL, the addon > also needs to be GPL licensed. IANAL but I believe it's enough for addon to have any GPL-compatible license (unless you include parts of 3rd party code that was already GPLed). > Which is fine. The only question is, is it OK to > add such a tool (python script) to the Qt 3D repo? It's not used within Qt 3D > itself at all. > > Cheers, > > Sean > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > Klarälvdalens Datakonsult AB, a KDAB Group company > Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 > KDAB - Qt Experts - Platform-independent software solutions > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Wed Feb 1 18:34:59 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 01 Feb 2017 09:34:59 -0800 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <0fa6e612-0a5a-3d73-3c7c-51095ee3dd4b@rusbitech.ru> References: <201701302003.25214.marc.mutz@kdab.com> <201702011522.22634.marc.mutz@kdab.com> <0fa6e612-0a5a-3d73-3c7c-51095ee3dd4b@rusbitech.ru> Message-ID: <2877062.OFqzryrZfy@tjmaciei-mobl1> Em quarta-feira, 1 de fevereiro de 2017, às 18:09:17 PST, Александр Волков escreveu: > But when readLineInto() is trying to write into an implicitly shared > string buffer, > then the content of the buffer is copied and readLineInto() writes into > the copy. And that is the problem. If you're using readLineInto, you should organise your code so that the object you pass isn't shared. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Feb 1 18:37:41 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 01 Feb 2017 09:37:41 -0800 Subject: [Development] GPL tooling in Qt module? In-Reply-To: <1860993.H2X5KvD4NB@titan> References: <1860993.H2X5KvD4NB@titan> Message-ID: <2038421.ZYaxqaMZ8x@tjmaciei-mobl1> Em quarta-feira, 1 de fevereiro de 2017, às 17:01:36 PST, Sean Harmer escreveu: > As such addons need to run within the blender runtime which is GPL, the > addon also needs to be GPL licensed. If there's a process separation, then Blender's licence does not impact on the selection of the licence of the parent code. If I understand you correctly, you have code that is a plugin to Blender. That plugin does not need to be licenced as GPL either, but since it is loaded into Blender, it needs to be GPL-compatible and the program+plugin combination, when run, will be under the GPL too. As such, I don't see any need to provide any GPL-only code into a Qt repository at all. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From s at dragly.com Wed Feb 1 19:09:34 2017 From: s at dragly.com (Svenn-Arne Dragly) Date: Wed, 1 Feb 2017 19:09:34 +0100 Subject: [Development] GPL tooling in Qt module? In-Reply-To: <1860993.H2X5KvD4NB@titan> References: <1860993.H2X5KvD4NB@titan> Message-ID: <7eab4446-fb0e-1cb8-6e6c-06c2959a52f8@dragly.com> On 01. feb. 2017 18:01, Sean Harmer wrote: > As such addons need to run within the blender runtime which is GPL, the addon > also needs to be GPL licensed. I don't think this is the case for addons. They are scripts run by Blender's Python interpreter, but (usually) don't link Blender's libraries. Blender.org even hosts addons with other licenses. For instance, "Reproject image" has an MIT license: https://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/UV/Reproject_image Best regards, Svenn-Arne From sean.harmer at kdab.com Wed Feb 1 19:14:05 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Wed, 01 Feb 2017 18:14:05 +0000 Subject: [Development] GPL tooling in Qt module? In-Reply-To: <2038421.ZYaxqaMZ8x@tjmaciei-mobl1> References: <1860993.H2X5KvD4NB@titan> <2038421.ZYaxqaMZ8x@tjmaciei-mobl1> Message-ID: <1863329.Xg21YdSj1A@titan> On Wednesday 01 February 2017 09:37:41 Thiago Macieira wrote: > Em quarta-feira, 1 de fevereiro de 2017, às 17:01:36 PST, Sean Harmer > > escreveu: > > As such addons need to run within the blender runtime which is GPL, the > > addon also needs to be GPL licensed. > > If there's a process separation, then Blender's licence does not impact on > the selection of the licence of the parent code. > > If I understand you correctly, you have code that is a plugin to Blender. > That plugin does not need to be licenced as GPL either, but since it is > loaded into Blender, it needs to be GPL-compatible and the program+plugin > combination, when run, will be under the GPL too. > > As such, I don't see any need to provide any GPL-only code into a Qt > repository at all. Thanks, I somehow skipped over the words "compliant with" in the blender FAQ. So LGPL/MIT etc looks to be fine. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From oswald.buddenhagen at qt.io Wed Feb 1 21:13:25 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 1 Feb 2017 21:13:25 +0100 Subject: [Development] HEADS-UP: Branching from 'dev' to '5.9' completed Message-ID: <20170201201324.GA28779@ugly> On Thu, Jan 26, 2017 at 05:28:23AM +0000, Jani Heikkinen wrote: > We have now soft branched '5.9' from 'dev'. Target is to have final downmerge from 'dev' to '5.9' and Qt 5.9 Feature Freeze 1st of February. > > Please finalize ongoing changes in 'dev' and start using '5.9' for new changes targeted to Qt 5.9.0 release. > > Make sure all Qt 5.9.0 new features are ready in 'dev' latest Tuesday 31st January (see feature freeze checklist from https://wiki.qt.io/Qt_5_Feature_Freeze). At this time we really want to respect the feature freeze so if your feature isn't ready early enough please postpone it to 5.10 instead. So no new feature development in '5.9'; just stabilization and bug fixing. Remember also update new features page (https://wiki.qt.io/New_Features_in_Qt_5.9) > the downmerge is complete. 5.9 is in feature freeze now, while dev is 5.10 material. continue sending re-targeting requests as needed. From edward.welbourne at qt.io Thu Feb 2 11:02:23 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 2 Feb 2017 10:02:23 +0000 Subject: [Development] [Releasing] HEADS-UP: Branching from 'dev' to '5.9' completed In-Reply-To: <20170201201324.GA28779@ugly> References: <20170201201324.GA28779@ugly> Message-ID: On Thu, Jan 26, 2017 at 05:28:23AM +0000, Jani Heikkinen wrote: >> We have now soft branched '5.9' from 'dev'. Target is to have final >> downmerge from 'dev' to '5.9' and Qt 5.9 Feature Freeze 1st of >> February. >> >> Please finalize ongoing changes in 'dev' and start using '5.9' for >> new changes targeted to Qt 5.9.0 release. >> >> Make sure all Qt 5.9.0 new features are ready in 'dev' latest Tuesday >> 31st January (see feature freeze checklist from >> https://wiki.qt.io/Qt_5_Feature_Freeze). At this time we really want >> to respect the feature freeze so if your feature isn't ready early >> enough please postpone it to 5.10 instead. So no new feature >> development in '5.9'; just stabilization and bug fixing. Remember >> also update new features page >> (https://wiki.qt.io/New_Features_in_Qt_5.9) Oswald Buddenhagen (1 February 2017 21:13) added: > the downmerge is complete. 5.9 is in feature freeze now, while dev is > 5.10 material. continue sending re-targeting requests as needed. I see no 5.9 branch in qtnetworkauth, although qt5/.gitmodules says to use 5.9 for it. I shall prepare an initial API review, for the modules that have a 5.9 and a v5.8.0 tag, comparing the two. Then I shall get back to the vast flood of code-review that's been coming in all week ... Eddy. From edward.welbourne at qt.io Thu Feb 2 15:21:01 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 2 Feb 2017 14:21:01 +0000 Subject: [Development] Meeting minutes from Qt Release Team meeting 31.1.2017 In-Reply-To: References: , , Message-ID: Jani Heikkinen reported an action item of the release team meeting: >>> * API review to be started immediately after final downmerge. I replied with (January 31, 2017 6:52 PM): >> Let me know as soon as that down-merge is done. >> Speaking of API review, review of >> https://codereview.qt-project.org/157299 >> would be welcome. If we can get it integrated - who knows - maybe some >> day someone *else* can run the scripts ... Jani Heikkinen (2 February 2017 06:17) told me: > It is done now. and so today I've duly produced initial API reviews for 5.9 (with a minor delay while I tried to get s/QtPrivete::QEnableIf<...>::Type/std::enable_if<...>::type/ ignored; but there were too many complications in that "..."): https://codereview.qt-project.org/184384 qtbase https://codereview.qt-project.org/184385 qtsvg https://codereview.qt-project.org/184386 qtdeclarative https://codereview.qt-project.org/184387 qtactiveqt https://codereview.qt-project.org/184388 qtlocation https://codereview.qt-project.org/184389 qtsensors https://codereview.qt-project.org/184390 qtconnectivity https://codereview.qt-project.org/184391 qtwayland https://codereview.qt-project.org/184392 qt3d https://codereview.qt-project.org/184393 qtserialbus https://codereview.qt-project.org/184394 qtwebsockets https://codereview.qt-project.org/184395 qtwebengine https://codereview.qt-project.org/184396 qtquickcontrols2 https://codereview.qt-project.org/184397 qtcharts https://codereview.qt-project.org/184398 qtdatavis3d https://codereview.qt-project.org/184399 qtgamepad https://codereview.qt-project.org/184400 qtscxml Please study the changes to modules you care about, Eddy. From olivier at woboq.com Thu Feb 2 16:12:37 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 02 Feb 2017 16:12:37 +0100 Subject: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows? In-Reply-To: <2044329.rGcy5TJXY3@tjmaciei-mobl1> References: <1582481485776602@web28h.yandex.ru> <2044329.rGcy5TJXY3@tjmaciei-mobl1> Message-ID: <3290522.XspIm5aX8A@maurice> On Montag, 30. Januar 2017 08:32:50 CET Thiago Macieira wrote: > On segunda-feira, 30 de janeiro de 2017 14:43:22 PST Konstantin Tokarev wrote: > > What about Intel? (IIRC they use EDG frontend, aren't they?) > > icc on Mac and Windows operates like GCC and Clang. > > I'll check icl.exe on Windows. It is supposed to operate like MSVC, but it > might have some other options or have never complained. How about unicode in the identifiers? ☺ Code like this: const char andré[] = u8"andré"; int δx = -1; This is valid C++11, but even GCC can't compile this code. (Works with clang) I know this is out of topic, as we are mostly interested in comments and string literal. My opinion is that unicode in the source code in the comments or string has some value as the way we express the programs. And so if the compiler we support can handle it, we should allow it. The problem at hand seems to be only with MSVC 2015 which shows a warning if we don't pass the /utf8 command. So let's just pass that command. And how about QML? Why can't I write such code? Item { property int δx: -1 André { anchors.fill:parent; } }; Moc supports property names with utf8 in it, btw. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Thu Feb 2 17:03:11 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 02 Feb 2017 08:03:11 -0800 Subject: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows? In-Reply-To: <3290522.XspIm5aX8A@maurice> References: <2044329.rGcy5TJXY3@tjmaciei-mobl1> <3290522.XspIm5aX8A@maurice> Message-ID: <4070986.6yLa1KAmXh@tjmaciei-mobl1> On quinta-feira, 2 de fevereiro de 2017 16:12:37 PST Olivier Goffart wrote: > On Montag, 30. Januar 2017 08:32:50 CET Thiago Macieira wrote: > > On segunda-feira, 30 de janeiro de 2017 14:43:22 PST Konstantin Tokarev > > wrote: > > > What about Intel? (IIRC they use EDG frontend, aren't they?) > > > > icc on Mac and Windows operates like GCC and Clang. > > > > I'll check icl.exe on Windows. It is supposed to operate like MSVC, but it > > might have some other options or have never complained. BTW, I checked: it does not have an option and does not support translating interpreting UTF-8 in C++11 Unicode Strings. On all platforms. > How about unicode in the identifiers? ☺ C'mon :-) > My opinion is that unicode in the source code in the comments or string has > some value as the way we express the programs. And so if the compiler we > support can handle it, we should allow it. The problem at hand seems to be > only with MSVC 2015 which shows a warning if we don't pass the /utf8 > command. So let's just pass that command. You've misunderstood. The problem is MSVC 2013 that shows a warning, one that gets upgraded to error in -developer-build. I suspect MSVC 2015 RTM and U1 do too, but no one has tested them. MSVC 2015 U2 does support the option, which we'll pass. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Thu Feb 2 18:23:07 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 2 Feb 2017 18:23:07 +0100 Subject: [Development] Shall we turn on /utf-8 compiler option when build qt for Windows? In-Reply-To: <3290522.XspIm5aX8A@maurice> References: <1582481485776602@web28h.yandex.ru> <2044329.rGcy5TJXY3@tjmaciei-mobl1> <3290522.XspIm5aX8A@maurice> Message-ID: <20170202172306.GA1611@klara.mpi.htwm.de> On Thu, Feb 02, 2017 at 04:12:37PM +0100, Olivier Goffart wrote: > On Montag, 30. Januar 2017 08:32:50 CET Thiago Macieira wrote: > > On segunda-feira, 30 de janeiro de 2017 14:43:22 PST Konstantin Tokarev > wrote: > > > What about Intel? (IIRC they use EDG frontend, aren't they?) > > > > icc on Mac and Windows operates like GCC and Clang. > > > > I'll check icl.exe on Windows. It is supposed to operate like MSVC, but it > > might have some other options or have never complained. > > How about unicode in the identifiers? ☺ > > Code like this: > > const char andré[] = u8"andré"; > int δx = -1; > > This is valid C++11, but even GCC can't compile this code. (Works with clang) > I know this is out of topic, as we are mostly interested in comments and > string literal. > > My opinion is that unicode in the source code in the comments or string has > some value as the way we express the programs. And so if the compiler we > support can handle it, we should allow it. The problem at hand seems to be > only with MSVC 2015 which shows a warning if we don't pass the /utf8 command. > So let's just pass that command. > > And how about QML? > Why can't I write such code? ... > André { anchors.fill:parent; } I somehow missed the memo announcing the start of the ongoing competition of how to use sensible concepts (UTF-8 presumably counts as such) in the most insensible way. Similarly I missed the memo anouncing me as the referee of said competition, but since I am in this position now, I feel obliged to have a look at the submissions so far nevertheless: The idea of making log messages effectively ungreppable by using single characters from unicode ranges that common people do not even know to exist is pretty convincing, especially for a newcomer in the arena. Nice try. The main problem is of course that it does not really break the build process as such, but with the moon nearing its first quarter that's clearly excused. Spicing sources with funny characters to make them uncompilable in some environments is perhaps a bit more efficient, we clearly see a professional submitter here. However, the idea is fairly unimaginative in comparision, that deficiency is also not really ironed out by the quite creative reasoning with legal arguments in the neighbourhood. Now, the unicode identifier idea, a.k.a. restrict editing of sources to people who know how to map the few keys of their keyboard to the full unicode range by heart is, regarding wiliness, certainly on par with the broken log idea. In fact, I'd give extra points for opening the stage for an awful lot of possible extra bikeshedding, like, for instance in the area of combining marks, canonical equivalence, positional variants etc. So, that would be the winner, but since it comes from someone who doesn't even have a single accent or umlaut in his real name, i.e. someone who was never truly exposed to the parallel worlds outside the 7-bit universe, I am afraid I have to disqualify this submission out of spite on purely subjective grounds. Tough luck. So, the final winner, for eternity, is --- tata --- Broken Logs! Now, of course, this here is just today's eternal result. As usual within the project, the competition will continue for an unlimited period of time, every now and then new final eternal winners will be announced, and the competition re-opens automatically whenever a someone or somebot manages to send a reply to this thread. Andre' From hamed.masafi at gmail.com Thu Feb 2 20:38:00 2017 From: hamed.masafi at gmail.com (Hamed Masafi) Date: Thu, 02 Feb 2017 19:38:00 +0000 Subject: [Development] Request moving project to playground area Message-ID: Project Name: Nut (currently renamed to ORM) Description: ORM is a project aimed to help users working with databases. Developer will write his/her own classes and ORM will generates database schema and corresponding tables. ORM can generate database migration code (create, drop and alter table and fields) according to database version changes. ORM Currently has following features: - Easy to use; - PosgtreSQL, MySQL, SQLite and Microsoft Sql Server support; - Automatically create and update database schema; - IDE auto complete support, No hard-code nedded; - Table join detect (currently limited to one join) Further information is available via this git repo: https://github.com/HamedMasafi/Nut Declaring persistant objects in ORM is straightforward: class Comment : public Table { Q_OBJECT NUT_PRIMARY_AUTO_INCREMENT(id) NUT_DECLARE_FIELD(int, id, id, setId) NUT_DECLARE_FIELD(QString, message, message, setMessage) NUT_DECLARE_FIELD(QDateTime, saveDate, saveDate, setSaveDate) NUT_DECLARE_FIELD(qreal, point, point, setPoint) NUT_FOREGION_KEY(Post, int, post, post, setPost) public: Q_INVOKABLE explicit Comment(QObject *tableSet = 0); }; ORM will automatically generate corresponding schema generation scripts. This project currently... : - has code name 'Nut' and suggested name is ORM. But it may have any other name. - Use macro hack for model rules. But it may merge with moc in feature. TODO: - Support index - Some enhanced for better experience to developer. - qml full binding support. - Multi join (to master and slave) support -------------- next part -------------- An HTML attachment was scrubbed... URL: From milian.wolff at kdab.com Thu Feb 2 23:07:08 2017 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 02 Feb 2017 23:07:08 +0100 Subject: [Development] Request moving project to playground area In-Reply-To: References: Message-ID: <5412805.bOW9DRN70l@agathebauer> On Donnerstag, 2. Februar 2017 20:38:00 CET Hamed Masafi wrote: > Project Name: Nut (currently renamed to ORM) > > Description: ORM is a project aimed to help users working with databases. > Developer will write his/her own classes and ORM will generates database > schema and corresponding tables. ORM can generate database migration code > (create, drop and alter table and fields) according to database version > changes. > > ORM Currently has following features: What are the advantages of NUT/ORM over existing, proven technologies like ODB? http://www.codesynthesis.com/products/odb/ -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From kevin.kofler at chello.at Thu Feb 2 23:42:32 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 02 Feb 2017 23:42:32 +0100 Subject: [Development] Feature Freeze Exception: QStringView References: <201701302003.25214.marc.mutz@kdab.com> <4690544.OpgdffnZ55@tjmaciei-mobl1> <201701311853.56327.marc.mutz@kdab.com> <2520893.RM0PXepoGU@tjmaciei-mobl1> Message-ID: Alexander Volkov wrote: > Currently it reads into QString as in a buffer and if you need to copy > the buffer, then you > have to manually make a deep copy of it: > QTextStream ts(...); > QString line; > line.reserve(1024); > QStringList found; > while (ts.readLineInto(&line)) { > ... > found.append(QString(line.constData(), line.size())); // deep > copy > } This should also work: QTextStream ts(...); QString line; line.reserve(1024); QStringList found; while (ts.readLineInto(&line)) { ... QString copy = line; copy.data(); // force detach (deep copy) found.append(copy); } Kevin Kofler From kevin.kofler at chello.at Thu Feb 2 23:52:26 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 02 Feb 2017 23:52:26 +0100 Subject: [Development] Feature Freeze Exception: QStringView References: <20170131135025.C230.6F0322A@gmail.com> <570984572ae2917f474044799f3db362@kdab.com> <20170131152417.C23F.6F0322A@gmail.com> <201701311839.44054.marc.mutz@kdab.com> Message-ID: > On Tuesday 31 January 2017 15:24:18 Philippe wrote: >> I just want to highlight, that QStringView is not COW friendly. AFAIK. That alone makes it actually a pessimization. Marc Mutz wrote: > Q6String will likely have the small-string optimisation, so short strings > aren't actually COWed, but deep-copied. Passing through QStringView then > is about the same efficiency as passing through a const QString&. As I already wrote, I think that that is also not a good idea at all. The smallness of QString makes it very efficient to pass around. And you will not be able to assume things like AVX moves any time soon: Currently, on Fedora, 32-bit x86 code may not even require MMX, let alone SSE/SSE2; x86_64 code can require MMX, SSE and SSE2, but nothing beyond that; 32-bit ARM code is also not allowed to require NEON. > But that's why we'll have QStringView Level 3, where only the QStringView > QLabel::setText() overload will be compiled in. Then, we compile Qt with > either level and check the respective performance of the result. I'll > wager that the results will be very interesting. If you think so, then why don't you provide such results BEFORE getting the changes merged, potentially leaving Qt with a counterproductive API addition that it will not be able to get rid of anymore? Kevin Kofler From kevin.kofler at chello.at Fri Feb 3 00:05:03 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 03 Feb 2017 00:05:03 +0100 Subject: [Development] Request moving project to playground area References: Message-ID: Hamed Masafi wrote: > This project currently... : > - has code name 'Nut' and suggested name is ORM. But it may have any > other name. ORM is way too generic a name. It needs to be called at least QORM or QtORM or ORM-Qt or something, if you cannot think of a more original name. (But the name "Nut" is also already taken.) Kevin Kofler From marc.mutz at kdab.com Fri Feb 3 01:19:49 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Feb 2017 01:19:49 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: References: <20170131135025.C230.6F0322A@gmail.com> <201701311839.44054.marc.mutz@kdab.com> Message-ID: <201702030119.50069.marc.mutz@kdab.com> On Thursday 02 February 2017 23:52:26 Kevin Kofler wrote: > > But that's why we'll have QStringView Level 3, where only the QStringView > > QLabel::setText() overload will be compiled in. Then, we compile Qt with > > either level and check the respective performance of the result. I'll > > wager that the results will be very interesting. > > If you think so, then why don't you provide such results BEFORE getting > the changes merged, potentially leaving Qt with a counterproductive API > addition that it will not be able to get rid of anymore? The question of whether to replace QString sink arguments with QStringView ones is an open one. It does not affect the usefulness of QStringView as a way to pass UTF-16 data from a wide variety of sources through a single function. I'd invite you to look at the QColor port to QStringView (https://codereview.qt-project.org/184038) to see for yourself, but past experience has left me with the feeling that it'd be pointless... Thanks, Marc PS: Still waiting for your promised patch to port QToolBox and/or QDataWidgetMapper away from QList... -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From philwave at gmail.com Fri Feb 3 08:00:16 2017 From: philwave at gmail.com (Philippe) Date: Fri, 03 Feb 2017 08:00:16 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: References: <201701311839.44054.marc.mutz@kdab.com> Message-ID: <20170203080015.8826.6F0322A@gmail.com> On Thu, 02 Feb 2017 23:52:26 +0100 Kevin Kofler wrote: > > On Tuesday 31 January 2017 15:24:18 Philippe wrote: > >> I just want to highlight, that QStringView is not COW friendly. AFAIK. > > That alone makes it actually a pessimization. This is why Thiago commented with: >But we still have to have QString overloads in public functions, >otherwise creating full copies would now suddenly cost something. Philippe From hamed.masafi at gmail.com Fri Feb 3 08:28:17 2017 From: hamed.masafi at gmail.com (Hamed Masafi) Date: Fri, 3 Feb 2017 10:58:17 +0330 Subject: [Development] Request moving project to playground area In-Reply-To: References: Message-ID: > What are the advantages of NUT/ORM over existing, proven technologies like > ODB? Odb is other than QtSql module, but Nut use Qt so is familiar to Qt developers. Odb has own compiler for pre-compiler declaratives and is hard to use for beginners. But Nut use macro hack and no need another tool for compile. Nut has builtin Qt support and serialization of QVariant types like QImage is in todo list, so everything that can be store in QVariant can be store on database. Nut like QtSql module can written once and used everywhere, but odb use different classes for each database type. Odb has GPL license, but Nut may use under term of LGPL. Nut don't use any RTTI but use Qt metaproperty system. ... and Nut may have a collection of features if community need them > ORM is way too generic a name. It needs to be called at least QORM or QtORM > or ORM-Qt or something, if you cannot think of a more original name. (But > the name "Nut" is also already taken.) ORM is just a suggest, "QtORM" is good, or any other name community approve. From marc.mutz at kdab.com Fri Feb 3 08:49:24 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Feb 2017 08:49:24 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <20170203080015.8826.6F0322A@gmail.com> References: <201701311839.44054.marc.mutz@kdab.com> <20170203080015.8826.6F0322A@gmail.com> Message-ID: <201702030849.24933.marc.mutz@kdab.com> On Friday 03 February 2017 08:00:16 Philippe wrote: > On Thu, 02 Feb 2017 23:52:26 +0100 > > Kevin Kofler wrote: > > > On Tuesday 31 January 2017 15:24:18 Philippe wrote: > > >> I just want to highlight, that QStringView is not COW friendly. AFAIK. > > > > That alone makes it actually a pessimization. > > This is why Thiago commented with: > >But we still have to have QString overloads in public functions, > >otherwise creating full copies would now suddenly cost something. Here's another reason to have a compile-time option to turn off QString overloads: Many, many projects (incl. almost all of the Qt tests) pass QLatin1String or (8-bit) C string literals to functions taking QString. When the QString overload is replaced by a QStringView one, these calls become errors. I don't mean to say that's a good thing going forward into Qt 6, but I do say that having this option (and nothing more is being discussed atm) will be very helpful in porting existing users of QL1S and C string literals to QStringView: - lb->setText("&OK"); // should probably use tr(), but assume it doesn't + lb->setText(u"&OK"); // should probably use tr(), but assume it doesn't Done. Now the QStringView overload is chosen, and the QString creation is hidden in an out-of-line function. You wanted to know what the effect is. Brace yourself. Test functions: extern void setLabelQStringCRef(const QString &); extern void setLabelQStringView(QStringView); void callSetLabelQStringCRef() { setLabelQStringCRef("&OK"); // pass by value is identical on call site, because the compiler // cannot prove that the dtor is a no-op, but at run-time, there // will be no manipulation of the atomic int ref count. } void callSetLabelQStringView() { setLabelQStringView(u"&OK"); } Results on GCC 6.1.1, compiled with the same settings as our tests: _Z23callSetLabelQStringCRefv: | _Z23callSetLabelQStringViewv: pushq %rbp | subq $8, %rsp pushq %rbx | xorl %edi, %edi leaq .LC8(%rip), %rdi | cmpw $0, .LC9(%rip) movl $3, %esi | je .L74 subq $24, %rsp | leaq .LC9(%rip), %rax call _ZN7QString16fromAscii_helperEPKci at PLT |.L75: movq %rsp, %rdi | addq $1, %rdi movq %rax, (%rsp) | cmpw $0, (%rax,%rdi,2) movq %rsp, %rbx | jne .L75 call _Z19setLabelQStringCRefRK7QString at PLT |.L74: movq (%rsp), %rdi | leaq .LC9(%rip), %rsi movl (%rdi), %eax | call _Z19setLabelQStringView11QStringView at PLT testl %eax, %eax | addq $8, %rsp je .L58 | ret cmpl $-1, %eax | je .L53 | lock; subl $1, (%rdi) | je .L62 | .L53: | addq $24, %rsp | popq %rbx | popq %rbp | ret | .L62: | movq (%rsp), %rdi | .L58: | movl $8, %edx | movl $2, %esi | call _ZN10QArrayData10deallocateEPS_mm at PLT | addq $24, %rsp | popq %rbx | popq %rbp | ret | .L60: | movq %rax, %rbp | movq %rbx, %rdi | call _ZN7QStringD1Ev at PLT | movq %rbp, %rdi | call _Unwind_Resume at PLT | .section .gcc_except_table | .byte 0xff | .byte 0xff | .byte 0x1 | .uleb128 .LLSDACSE7819-.LLSDACSB7819 | .uleb128 .LEHB3-.LFB7819 | .uleb128 .LEHE3-.LEHB3 | .uleb128 0 | .uleb128 0 | .uleb128 .LEHB4-.LFB7819 | .uleb128 .LEHE4-.LEHB4 | .uleb128 .L60-.LFB7819 | .uleb128 0 | .uleb128 .LEHB5-.LFB7819 | .uleb128 .LEHE5-.LEHB5 | .uleb128 0 | .uleb128 0 | And with a bit of optimisation, we should be able to kill off the loop .L75, which determines the length of the string literal, too, replacing it with a compile-time constant. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From marc.mutz at kdab.com Fri Feb 3 08:55:56 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Feb 2017 08:55:56 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <201702030849.24933.marc.mutz@kdab.com> References: <201701311839.44054.marc.mutz@kdab.com> <20170203080015.8826.6F0322A@gmail.com> <201702030849.24933.marc.mutz@kdab.com> Message-ID: <201702030855.56734.marc.mutz@kdab.com> On Friday 03 February 2017 08:49:24 Marc Mutz wrote: > Results on GCC 6.1.1, compiled with the same settings as our tests: Better-formatted version posted in comment to https://codereview.qt-project.org/143763 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Fri Feb 3 09:29:22 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Feb 2017 00:29:22 -0800 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <201702030849.24933.marc.mutz@kdab.com> References: <201701311839.44054.marc.mutz@kdab.com> <20170203080015.8826.6F0322A@gmail.com> <201702030849.24933.marc.mutz@kdab.com> Message-ID: <15525147.Lm1KGjIrF9@tjmaciei-mobl1> On sexta-feira, 3 de fevereiro de 2017 08:49:24 PST Marc Mutz wrote: > When the QString overload is replaced by a QStringView one, these calls > become errors. I don't mean to say that's a good thing going forward into > Qt 6, but I do say that having this option (and nothing more is being > discussed atm) will be very helpful in porting existing users of QL1S and C > string literals to QStringView: Your tests do not take QString improvements in Qt 6 into account. extern void setLabelQStringCRef(const QString &); void callSetLabelQStringLiteral() { setLabelQStringCRef(QStringLiteral("&OK")); } _Z26callSetLabelQStringLiteralv: pushq %rbx subq $32, %rsp movq _ZN10QArrayData18shared_static_dataE at GOTPCREL(%rip), %rax movq %rsp, %rdi movl $3, 16(%rsp) movq %rax, (%rsp) leaq .LC0(%rip), %rax movq %rax, 8(%rsp) call _Z19setLabelQStringCRefRK7QString at PLT movq (%rsp), %rax testl $512, (%rax) je .L12 # always fails .L1: addq $32, %rsp popq %rbx ret [followed by exception handling code irrelevant for us] Don't get me wrong: I like QStringView improvements. But we're going to improve QString too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From m.weghorn at posteo.de Fri Feb 3 09:53:57 2017 From: m.weghorn at posteo.de (Michael Weghorn) Date: Fri, 3 Feb 2017 09:53:57 +0100 Subject: [Development] Fwd: Google Summer of Code 2017 - Common Print Dialog project In-Reply-To: <72550fec-b90a-8028-b2c8-1c424f7bbf4d@gmail.com> References: <72550fec-b90a-8028-b2c8-1c424f7bbf4d@gmail.com> Message-ID: <9f29fa7b-f820-5d7d-e584-f62df2de0ff9@posteo.de> Hi, when reading about our thoughts on implementing printer-specific options for the Qt print dialog, Till Kamppeter contacted me, mentioning the project of a Common Print Dialog at OpenPrinting. I am forwarding our discussion to this mailing list. I will send the other two emails separately to make it easier to follow. Please find more information in the email below and the other two emails to come. What do you think about this and supporting it in Qt? I think it would be good to discuss that together early to make sure that the expectations on both sides are clear from the beginning on. Please keep Till as "CC" as he is possibly not subscribed to this mailing list. Regards, Michael -------- Forwarded Message -------- Subject: Google Summer of Code 2017 - Common Print Dialog project Date: Wed, 1 Feb 2017 09:53:08 -0200 From: Till Kamppeter To: Michael Weghorn CC: [...] Hi Michael, I am also organizing the Google Summer of Code participation of the Linux Foundation and especially of OpenPrinting. The most important project we want to do this summer is a Common Print Dialog, meaning that there is one print dialog design for all desktops and all applications. The dialog should be provided by the user's desktop, so it is needed in versions of the common UI toolkits, GTK and Qt. For applications not needing to link to both Qt and GTK for that the applications should communicate via D-Bus with the desktop's dialog. This way the user has always the same print dialog with the same UX and the same printers listed, independent which applications he uses and which tooolkit the applications use. See our project idea here (first item): https://wiki.linuxfoundation.org/gsoc/google-summer-code-2017-openprinting-projects This could also solve the problem of Qt missing a decent print dialog. We are currently recruiting students and also hope to find some working on Qt (dialog implementation and D-Bus bridge addition to Qt). WDYT? Would you like to cooperate with us? Forward this message to Qt upstream devs? Do mentoring on the Qt side? Till P. S.: Link [4] is missing in your mail. On 01/31/2017 06:21 AM, Michael Weghorn wrote: > Background: The Qt 4 print dialog handled printer-specific options using > the PPD API but the implementation had been rather broken in Qt 4 and > was removed for Qt 5, with the plan to reimplement them as part of a new > printing system. However, work on the new printing system could not be > continued due to lack of time and money. Currently, printer-specific > options are not available in the Qt 5 print dialog (apart from duplex > and color mode). We are currently considering to implement support for > printer-specific options in Qt 5 and would like to do it "right", i.e. > avoiding deprecated APIs and doing it in a way that is supported in the > future as well. (More information on the discussion for the Qt print > dialog can be found on Qt's mailing lists. [2], [3], [4]) > > Regards, > Michael > > > [1] https://www.cups.org/doc/api-ppd.html > [2] http://lists.qt-project.org/pipermail/interest/2017-January/025970.html > [3] > http://lists.qt-project.org/pipermail/development/2017-January/028597.html From m.weghorn at posteo.de Fri Feb 3 09:57:20 2017 From: m.weghorn at posteo.de (Michael Weghorn) Date: Fri, 3 Feb 2017 09:57:20 +0100 Subject: [Development] Fwd: Google Summer of Code 2017 - Common Print Dialog project In-Reply-To: <9f29fa7b-f820-5d7d-e584-f62df2de0ff9@posteo.de> References: <72550fec-b90a-8028-b2c8-1c424f7bbf4d@gmail.com> <9f29fa7b-f820-5d7d-e584-f62df2de0ff9@posteo.de> Message-ID: <944b10d8-83bc-52af-70e8-6085181173f9@posteo.de> [below: my answer to Till's initial email regarding the Common Print Dialog] -------- Forwarded Message -------- Subject: Re: Google Summer of Code 2017 - Common Print Dialog project Date: Thu, 2 Feb 2017 00:04:03 +0100 From: Michael Weghorn To: Till Kamppeter CC: [...] Hi Till, thank you very much for your email. in general, I very much like the idea of such a Common Print Dialog (CPD). I think it would really improve user experience a lot. The many different print dialogs are confusing for the users. In my opinion, the CPD would be a huge improvement from a developer/maintenance point of view as well. Because I liked the idea of a Common Print Dialog a lot, I also asked about the status of the project (that had been there) in March last year on OpenPrinting's printing-architecture mailing list [1] where you also participated in the discussion. The replies there made me understand that the project had been paused/cancelled and as far as I understand, one of the main reasons was that there was no huge interest on Gtk's and Qt's side to actually integrate support for the CPD back then for different reasons. While I do still very much like the idea of a CPD, I cannot estimate whether the situation and chances for the CPD have fundamentally changed since then and the new approach has better chances. Maybe you can estimate that better than I can. I think it would be very important to work together with the Qt and Gtk projects from the start and to make sure that there is actually interest in supporting/integrating the CPD in both projects, as that seems to be crucial to me for the success of the project. Maybe it would also be good to evaluate whether it makes sense to work together with LibreOffice from the start as well. LibreOffice also works/worked on a redesign of its print dialog, s. concept at [2]. This is also mentioned as a potential GSOC project in LibreOffice's wiki [3]. > Would you like to cooperate with us? Forward this message to Qt upstream devs? Do mentoring on the Qt side? I would be happy to help in case I can. However, I do not think I would be the right person to do mentoring on the Qt side as I have not been involved in the project itself so far and have also just started contacting the project regarding the print dialog. I think it might be good to address that topic on Qt's development mailing list. As far as I understand Andy Shaw's reply to my email there, the Qt project currently does not seem to be working toward a particular vision on the future direction of its print dialog right now and this might be a good situation to discuss different alternatives, including support for the CPD. The first message on the mentioned thread is [4], which was the forwarding of an email I had first written to the qt-interest mailing list. Feel free to forward our conversation there as well in case you consider that useful. > P. S.: Link [4] is missing in your mail. Thank you for that note. I currently cannot think of any totally different resource I wanted to mention; possibly I wanted to refer to the thread where the discussion started in 2015, which is [5] and is also mentioned in the new thread. I would be grateful to hear when more details about the CPD and the next steps are known. I am already subscribed to OpenPrinting's "printing-architecture" mailing list. Are there any other resources I should regularly have a look at to stay informed? Regards, Michael [1] https://lists.linuxfoundation.org/pipermail/printing-architecture/2016/thread.html#3282 [2] http://pad.documentfoundation.org/p/UX-PrintDialog [3] https://wiki.documentfoundation.org/Development/GSoC/Ideas#Revamp_print_dialog [4] http://lists.qt-project.org/pipermail/development/2017-January/028597.html [5] http://lists.qt-project.org/pipermail/interest/2015-September/thread.html#18692 On 2017-02-01 12:53, Till Kamppeter wrote: > Hi Michael, > > I am also organizing the Google Summer of Code participation of the > Linux Foundation and especially of OpenPrinting. > > The most important project we want to do this summer is a Common Print > Dialog, meaning that there is one print dialog design for all desktops > and all applications. > > The dialog should be provided by the user's desktop, so it is needed in > versions of the common UI toolkits, GTK and Qt. For applications not > needing to link to both Qt and GTK for that the applications should > communicate via D-Bus with the desktop's dialog. This way the user has > always the same print dialog with the same UX and the same printers > listed, independent which applications he uses and which tooolkit the > applications use. > > See our project idea here (first item): > > https://wiki.linuxfoundation.org/gsoc/google-summer-code-2017-openprinting-projects > > > This could also solve the problem of Qt missing a decent print dialog. > > We are currently recruiting students and also hope to find some working > on Qt (dialog implementation and D-Bus bridge addition to Qt). > > WDYT? > > Would you like to cooperate with us? Forward this message to Qt upstream > devs? Do mentoring on the Qt side? > > Till > > P. S.: Link [4] is missing in your mail. > > On 01/31/2017 06:21 AM, Michael Weghorn wrote: >> Background: The Qt 4 print dialog handled printer-specific options using >> the PPD API but the implementation had been rather broken in Qt 4 and >> was removed for Qt 5, with the plan to reimplement them as part of a new >> printing system. However, work on the new printing system could not be >> continued due to lack of time and money. Currently, printer-specific >> options are not available in the Qt 5 print dialog (apart from duplex >> and color mode). We are currently considering to implement support for >> printer-specific options in Qt 5 and would like to do it "right", i.e. >> avoiding deprecated APIs and doing it in a way that is supported in the >> future as well. (More information on the discussion for the Qt print >> dialog can be found on Qt's mailing lists. [2], [3], [4]) >> >> Regards, >> Michael >> >> >> [1] https://www.cups.org/doc/api-ppd.html >> [2] >> http://lists.qt-project.org/pipermail/interest/2017-January/025970.html >> [3] >> http://lists.qt-project.org/pipermail/development/2017-January/028597.html >> > From m.weghorn at posteo.de Fri Feb 3 09:59:51 2017 From: m.weghorn at posteo.de (Michael Weghorn) Date: Fri, 3 Feb 2017 09:59:51 +0100 Subject: [Development] Fwd: Google Summer of Code 2017 - Common Print Dialog project In-Reply-To: <944b10d8-83bc-52af-70e8-6085181173f9@posteo.de> References: <72550fec-b90a-8028-b2c8-1c424f7bbf4d@gmail.com> <9f29fa7b-f820-5d7d-e584-f62df2de0ff9@posteo.de> <944b10d8-83bc-52af-70e8-6085181173f9@posteo.de> Message-ID: <7463a9d1-cca8-8d49-e853-c313ec4575e5@posteo.de> [below: Till's reply and request to forward our discussion to this mailing list] -------- Forwarded Message -------- Subject: Re: Google Summer of Code 2017 - Common Print Dialog project Date: Thu, 2 Feb 2017 21:56:47 -0200 From: Till Kamppeter To: Michael Weghorn CC: Aveek Basu , John Layt , Bjoern Michaelsen , Will Cooke On 02/01/2017 09:04 PM, Michael Weghorn wrote: > Hi Till, > > thank you very much for your email. > > in general, I very much like the idea of such a Common Print Dialog > (CPD). I think it would really improve user experience a lot. The many > different print dialogs are confusing for the users. In my opinion, the > CPD would be a huge improvement from a developer/maintenance point of > view as well. > > Because I liked the idea of a Common Print Dialog a lot, I also asked > about the status of the project (that had been there) in March last year > on OpenPrinting's printing-architecture mailing list [1] where you also > participated in the discussion. > > The replies there made me understand that the project had been > paused/cancelled and as far as I understand, one of the main reasons was > that there was no huge interest on Gtk's and Qt's side to actually > integrate support for the CPD back then for different reasons. > I think the problem was the UI design in the first run, it was too ambitious. The Ubuntu design is simpler and easier to implement. As a minimum for this GSoC we need to get to a working model, so that we have patches for at least one of GTK/Qt/LibreOffice to send jobs into the D-Bus, and the dialog in at least one of GTK or Qt version, with at least the CUPS backend, receiving jobs from the D-Bus. GTK interface and dialog being the most important for the working model as there we have most apps and desktops. > While I do still very much like the idea of a CPD, I cannot estimate > whether the situation and chances for the CPD have fundamentally changed > since then and the new approach has better chances. Maybe you can > estimate that better than I can. > As I told above, we are replacing the dialog UI design by a simpler one. > I think it would be very important to work together with the Qt and Gtk > projects from the start and to make sure that there is actually interest > in supporting/integrating the CPD in both projects, as that seems to be > crucial to me for the success of the project. > This would be great, if they already agree with the project and show their support before this GSoC this would help a lot. > Maybe it would also be good to evaluate whether it makes sense to work > together with LibreOffice from the start as well. LibreOffice also > works/worked on a redesign of its print dialog, s. concept at [2]. This > is also mentioned as a potential GSOC project in LibreOffice's wiki [3]. > LibreOffice is very important here. As it is only an app and not a desktop for its integration we would need only its interface into the D-Bus bridge, but it needs to be well thought out and each of the components (Writer, Calc, Impress, ...) of LibreOffice would need to tell the appropriate component-specific options to the dialog. Bjoern, what would you think about a Common Print Dialog, meaning that independent of from which application you print, the same desktop-provided, print dialog will appear, no user confusion by different UIs, no missing features (like Google Cloud Print for example) for some of the apps. The change on LibreOffice would be to add the D-Bus interface, so that a "File" -> "Print" would call the (desktop-provided) dialog as a D-Bus service, send the document (as PDF) to the dialog and also the list of application/component-specific options. The dialog would show a preview, and offer general, printer-specific, and component-specific options. When the user changes them, the preview is updated and if needed, a new PDF is requested from the client. The dialog does all communication with CUPS, as polling printer lists and the capabilities of the selected printer. >> Would you like to cooperate with us? Forward this message to Qt upstream devs? Do mentoring on the Qt side? > > I would be happy to help in case I can. However, I do not think I would > be the right person to do mentoring on the Qt side as I have not been > involved in the project itself so far and have also just started > contacting the project regarding the print dialog. > If you find appropriate people in the Qt project, please forward our dialog to them. > I think it might be good to address that topic on Qt's development > mailing list. As far as I understand Andy Shaw's reply to my email > there, the Qt project currently does not seem to be working toward a > particular vision on the future direction of its print dialog right now > and this might be a good situation to discuss different alternatives, > including support for the CPD. The first message on the mentioned thread > is [4], which was the forwarding of an email I had first written to the > qt-interest mailing list. > So please do it and reach out to their mailing list, with me CCed. Thanks. > Feel free to forward our conversation there as well in case you consider > that useful. > >> P. S.: Link [4] is missing in your mail. > > Thank you for that note. I currently cannot think of any totally > different resource I wanted to mention; possibly I wanted to refer to > the thread where the discussion started in 2015, which is [5] and is > also mentioned in the new thread. > > I would be grateful to hear when more details about the CPD and the next > steps are known. I am already subscribed to OpenPrinting's > "printing-architecture" mailing list. Are there any other resources I > should regularly have a look at to stay informed? > That is OK. Discussion there will probably soon appear when we go further into the project. Till From Jesus.Fernandez at qt.io Fri Feb 3 10:18:13 2017 From: Jesus.Fernandez at qt.io (Jesus Fernandez) Date: Fri, 3 Feb 2017 10:18:13 +0100 Subject: [Development] Request moving project to playground area In-Reply-To: References: Message-ID: <1779607.fZtTT6mJVo@linux-5lbc> On Thursday, February 02, 2017 07:38:00 PM Hamed Masafi wrote: > Declaring persistant objects in ORM is straightforward: > > class Comment : public Table > { > Q_OBJECT > > NUT_PRIMARY_AUTO_INCREMENT(id) > NUT_DECLARE_FIELD(int, id, id, setId) > NUT_DECLARE_FIELD(QString, message, message, setMessage) > NUT_DECLARE_FIELD(QDateTime, saveDate, saveDate, setSaveDate) > NUT_DECLARE_FIELD(qreal, point, point, setPoint) > > NUT_FOREGION_KEY(Post, int, post, post, setPost) > > public: > Q_INVOKABLE explicit Comment(QObject *tableSet = 0); > }; Why not using Q_PROPERTY instead of NUT_DECLARE_FIELD? And what's the reason to have a constructor as Q_INVOKABLE? -- Best regards, Jesus From andre at familiesomers.nl Fri Feb 3 10:27:26 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 3 Feb 2017 10:27:26 +0100 Subject: [Development] Request moving project to playground area In-Reply-To: <1779607.fZtTT6mJVo@linux-5lbc> References: <1779607.fZtTT6mJVo@linux-5lbc> Message-ID: <9469da08-8d61-736f-9efb-b6cf4ca4e7aa@familiesomers.nl> Op 03/02/2017 om 10:18 schreef Jesus Fernandez: > On Thursday, February 02, 2017 07:38:00 PM Hamed Masafi wrote: >> Declaring persistant objects in ORM is straightforward: >> >> class Comment : public Table >> { >> Q_OBJECT >> >> NUT_PRIMARY_AUTO_INCREMENT(id) >> NUT_DECLARE_FIELD(int, id, id, setId) >> NUT_DECLARE_FIELD(QString, message, message, setMessage) >> NUT_DECLARE_FIELD(QDateTime, saveDate, saveDate, setSaveDate) >> NUT_DECLARE_FIELD(qreal, point, point, setPoint) >> >> NUT_FOREGION_KEY(Post, int, post, post, setPost) >> >> public: >> Q_INVOKABLE explicit Comment(QObject *tableSet = 0); >> }; > Why not using Q_PROPERTY instead of NUT_DECLARE_FIELD? > > And what's the reason to have a constructor as Q_INVOKABLE? That would be to have instances of the type be creatable by the ORM machinery, I'd guess. André From kevin.kofler at chello.at Fri Feb 3 10:59:21 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 03 Feb 2017 10:59:21 +0100 Subject: [Development] Feature Freeze Exception: QStringView References: <20170131135025.C230.6F0322A@gmail.com> <201701311839.44054.marc.mutz@kdab.com> <201702030119.50069.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > The question of whether to replace QString sink arguments with QStringView > ones is an open one. It does not affect the usefulness of QStringView as a > way to pass UTF-16 data from a wide variety of sources through a single > function. > > I'd invite you to look at the QColor port to QStringView > (https://codereview.qt-project.org/184038) to see for yourself, but past > experience has left me with the feeling that it'd be pointless... I had actually already looked at that patch, but looking at it again, it is true that it at least avoids the deep-copy issue because setColorFromString is a template that takes any string type. If, on the other hand, it would take a QString, or it would take a QStringView, but then have to store the string persistently (which means it needs to be converted to QString or something equivalent to remain valid), we would get an extra deep copy. I am not sure how many contexts can be safely changed as in your patch. But even the way it is, there may still be a loss of efficiency in the common case where what is passed is a QString, depending on what the compiler inlines, whether the wrapper with the QString argument is compiled in or not, etc. > PS: Still waiting for your promised patch to port QToolBox and/or > QDataWidgetMapper away from QList... I never promised such a patch and you know that. Please stop repeating that nonsense over and over. Whoever wrote the broken code should be expected to fix it. Kevin Kofler From annulen at yandex.ru Fri Feb 3 10:59:35 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 03 Feb 2017 12:59:35 +0300 Subject: [Development] Request moving project to playground area In-Reply-To: <5412805.bOW9DRN70l@agathebauer> References: <5412805.bOW9DRN70l@agathebauer> Message-ID: <8966291486115975@web16h.yandex.ru> 03.02.2017, 01:07, "Milian Wolff" : > On Donnerstag, 2. Februar 2017 20:38:00 CET Hamed Masafi wrote: >>  Project Name: Nut (currently renamed to ORM) >> >>  Description: ORM is a project aimed to help users working with databases. >>  Developer will write his/her own classes and ORM will generates database >>  schema and corresponding tables. ORM can generate database migration code >>  (create, drop and alter table and fields) according to database version >>  changes. >> >>  ORM Currently has following features: > > What are the advantages of NUT/ORM over existing, proven technologies like > ODB? > > http://www.codesynthesis.com/products/odb/ Actually, there are more ORM solutions for Qt, e.g. QxOrm and QDjango > > -- > Milian Wolff | milian.wolff at kdab.com | Software Engineer > KDAB (Deutschland) GmbH&Co KG, a KDAB Group company > Tel: +49-30-521325470 > KDAB - The Qt Experts > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From milian.wolff at kdab.com Fri Feb 3 11:36:44 2017 From: milian.wolff at kdab.com (Milian Wolff) Date: Fri, 03 Feb 2017 11:36:44 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: References: <20170131135025.C230.6F0322A@gmail.com> <201702030119.50069.marc.mutz@kdab.com> Message-ID: <32335399.M4m9AeNrdV@agathebauer> On Freitag, 3. Februar 2017 10:59:21 CET Kevin Kofler wrote: > Marc Mutz wrote: > > The question of whether to replace QString sink arguments with QStringView > > ones is an open one. It does not affect the usefulness of QStringView as a > > way to pass UTF-16 data from a wide variety of sources through a single > > function. > > > > I'd invite you to look at the QColor port to QStringView > > (https://codereview.qt-project.org/184038) to see for yourself, but past > > experience has left me with the feeling that it'd be pointless... > > I had actually already looked at that patch, but looking at it again, it is > true that it at least avoids the deep-copy issue because setColorFromString > is a template that takes any string type. If, on the other hand, it would > take a QString, or it would take a QStringView, but then have to store the > string persistently (which means it needs to be converted to QString or > something equivalent to remain valid), we would get an extra deep copy. I am > not sure how many contexts can be safely changed as in your patch. But even > the way it is, there may still be a loss of efficiency in the common case > where what is passed is a QString, depending on what the compiler inlines, > whether the wrapper with the QString argument is compiled in or not, etc. If that is the case, then the API can have an overload taking an existing QString and store it directly. This would be a simply optimization. -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From kevin.kofler at chello.at Fri Feb 3 12:45:41 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 03 Feb 2017 12:45:41 +0100 Subject: [Development] Feature Freeze Exception: QStringView References: <201701311839.44054.marc.mutz@kdab.com> <20170203080015.8826.6F0322A@gmail.com> <201702030849.24933.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > setLabelQStringCRef("&OK"); That is an unfair comparison. The QString code should use QStringLiteral. Of course converting from 8-bit to 16-bit is horribly inefficient compared to just using a 16-bit literal. Kevin Kofler From marc.mutz at kdab.com Fri Feb 3 12:59:19 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 3 Feb 2017 12:59:19 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <15525147.Lm1KGjIrF9@tjmaciei-mobl1> References: <201701311839.44054.marc.mutz@kdab.com> <201702030849.24933.marc.mutz@kdab.com> <15525147.Lm1KGjIrF9@tjmaciei-mobl1> Message-ID: <201702031259.19797.marc.mutz@kdab.com> On Friday 03 February 2017 09:29:22 Thiago Macieira wrote: > On sexta-feira, 3 de fevereiro de 2017 08:49:24 PST Marc Mutz wrote: > > When the QString overload is replaced by a QStringView one, these calls > > become errors. I don't mean to say that's a good thing going forward into > > Qt 6, but I do say that having this option (and nothing more is being > > discussed atm) will be very helpful in porting existing users of QL1S and > > C > > > string literals to QStringView: > Your tests do not take QString improvements in Qt 6 into account. > > extern void setLabelQStringCRef(const QString &); > void callSetLabelQStringLiteral() { > setLabelQStringCRef(QStringLiteral("&OK")); > } QStringLiteral is not what most people use. It's too verbose. They use "&OK", cf. our tests and, to a lesser extend, because we encourage tr() there, examples and docs. u"&OK", however, has almost no readbility overhead compared to "&OK", or even a hypothetical "&OK"_qs, which would probably have to be written u"&OK"_qs, anyway? > _Z26callSetLabelQStringLiteralv: > pushq %rbx > subq $32, %rsp > movq _ZN10QArrayData18shared_static_dataE at GOTPCREL(%rip), %rax > movq %rsp, %rdi > movl $3, 16(%rsp) > movq %rax, (%rsp) > leaq .LC0(%rip), %rax > movq %rax, 8(%rsp) > call _Z19setLabelQStringCRefRK7QString at PLT > movq (%rsp), %rax > testl $512, (%rax) > je .L12 # always fails But jumps to code that is emitted anyway, bloating the executable, reducing effective icache-size- The test for -1 in my assembly listing also always succeeds on a moved-from QString, but so far I have failed to make the compiler drop the dead code. I tried Q_ASSUME in sharedNull() to make it known what that QArrayData's ref- count was, but no matter how I formulate the inline part of the QString dtor, the call to deallocate() never vanished from the assembly. On GCC 7, with -O3. > .L1: > addq $32, %rsp > popq %rbx > ret > [followed by exception handling code irrelevant for us] I disagree. The exception code is not irrelevant for our users (and not for us, either, e.g. in QtCore). My listing contained it, because the compiler emitted it, with the unchanged flags for tst_qstringview, which, apart from enabling C++14, does not change the default flags for testcases, and probably user projects, too. > Don't get me wrong: I like QStringView improvements. But we're going to > improve QString too. And I like the QString improvements. It will make substringing cheap, afaiu, and if we hopefully get SSO, QStringView-setter overhead will be greatly reduced. The two work hand-in-hand. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From kevin.kofler at chello.at Fri Feb 3 13:48:46 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 03 Feb 2017 13:48:46 +0100 Subject: [Development] Feature Freeze Exception: QStringView References: <201701311839.44054.marc.mutz@kdab.com> <201702030849.24933.marc.mutz@kdab.com> <15525147.Lm1KGjIrF9@tjmaciei-mobl1> <201702031259.19797.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > QStringLiteral is not what most people use. It's too verbose. #define U(x) QStringLiteral(x) or some other 1-letter macro or even $ (which most compilers will let you get away with). > They use "&OK", We really need a plan to deprecate implicit casts between QString and ASCII. They are not only the source of such inefficiencies from inexperienced or lazy programmers, but also of encoding-related bugs. If you need to convert between 8-bit encodings and QString, you should always use a function that specifies the correct encoding for the context (e.g. fromLocal8Bit). If your string is constant, you should use QStringLiteral. > and if we hopefully get SSO, QStringView-setter overhead will be greatly > reduced. The overhead compared to using QString will be reduced, but only part of it (the avoided memory allocation) is really an optimization. The rest of the "reduced" overhead is because QString will get the same overhead bloated onto it (copying the entire string). So, sure, technically, QStringView will have less overhead over QString, but the way you achieved that is counterproductive. And all this is only valid for very short strings, longer strings will still behave the same as before, except for the overhead of the unused SSO array in both cases. Kevin Kofler From giuseppe.dangelo at kdab.com Fri Feb 3 14:27:53 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 3 Feb 2017 14:27:53 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: References: <201701311839.44054.marc.mutz@kdab.com> <201702030849.24933.marc.mutz@kdab.com> <15525147.Lm1KGjIrF9@tjmaciei-mobl1> <201702031259.19797.marc.mutz@kdab.com> Message-ID: <6a06c3d2-d23b-7042-33c6-8f901feb1237@kdab.com> Il 03/02/2017 13:48, Kevin Kofler ha scritto: > We really need a plan to deprecate implicit casts between QString and ASCII. > They are not only the source of such inefficiencies from inexperienced or > lazy programmers, but also of encoding-related bugs. If you need to convert > between 8-bit encodings and QString, you should always use a function that > specifies the correct encoding for the context (e.g. fromLocal8Bit). If your > string is constant, you should use QStringLiteral. This is all stuff that we already have and that nobody uses because we fail at advertising it: QT_RESTRICTED_CAST_FROM_ASCII, QT_NO_CAST_FROM_ASCII, QT_ASCII_CAST_WARNINGS... Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - 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 andre at familiesomers.nl Fri Feb 3 14:30:36 2017 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 3 Feb 2017 14:30:36 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <6a06c3d2-d23b-7042-33c6-8f901feb1237@kdab.com> References: <201701311839.44054.marc.mutz@kdab.com> <201702030849.24933.marc.mutz@kdab.com> <15525147.Lm1KGjIrF9@tjmaciei-mobl1> <201702031259.19797.marc.mutz@kdab.com> <6a06c3d2-d23b-7042-33c6-8f901feb1237@kdab.com> Message-ID: <4b88ada1-9b26-8cc1-bbd4-f1535810fcac@familiesomers.nl> Op 03/02/2017 om 14:27 schreef Giuseppe D'Angelo: > Il 03/02/2017 13:48, Kevin Kofler ha scritto: >> We really need a plan to deprecate implicit casts between QString and ASCII. >> They are not only the source of such inefficiencies from inexperienced or >> lazy programmers, but also of encoding-related bugs. If you need to convert >> between 8-bit encodings and QString, you should always use a function that >> specifies the correct encoding for the context (e.g. fromLocal8Bit). If your >> string is constant, you should use QStringLiteral. > This is all stuff that we already have and that nobody uses because we > fail at advertising it: QT_RESTRICTED_CAST_FROM_ASCII, > QT_NO_CAST_FROM_ASCII, QT_ASCII_CAST_WARNINGS... > Perhaps it is time to flip the defaults then? Make ASCII cast stuff opt-in instead of opt-out? Anyway, off topic in this thread. André From thiago.macieira at intel.com Fri Feb 3 17:45:31 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Feb 2017 08:45:31 -0800 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <201702031259.19797.marc.mutz@kdab.com> References: <201701311839.44054.marc.mutz@kdab.com> <15525147.Lm1KGjIrF9@tjmaciei-mobl1> <201702031259.19797.marc.mutz@kdab.com> Message-ID: <13214911.RNMolzDENi@tjmaciei-mobl1> On sexta-feira, 3 de fevereiro de 2017 12:59:19 PST Marc Mutz wrote: > QStringLiteral is not what most people use. It's too verbose. They use > "&OK", cf. our tests and, to a lesser extend, because we encourage tr() > there, examples and docs. > > u"&OK", however, has almost no readbility overhead compared to "&OK", or > even a hypothetical "&OK"_qs, which would probably have to be written > u"&OK"_qs, anyway? u"&OK"_q (no need for s) would be just a short way to write QStringLiteral and would return the below code. The only reason that we haven't implemented it yet is because the C++ committee dropped the most interesting feature of UDLs prior to C++11, recognised that before C++14 but hasn't brought it back yet. There was a discussion on compile-time strings being equivalent and I remember being swayed by the arguments, but I don't remember the technique now. > > _Z26callSetLabelQStringLiteralv: > > pushq %rbx > > subq $32, %rsp > > movq _ZN10QArrayData18shared_static_dataE at GOTPCREL(%rip), %rax > > movq %rsp, %rdi > > movl $3, 16(%rsp) > > movq %rax, (%rsp) > > leaq .LC0(%rip), %rax > > movq %rax, 8(%rsp) > > call _Z19setLabelQStringCRefRK7QString at PLT > > movq (%rsp), %rax > > testl $512, (%rax) > > je .L12 # always fails > > But jumps to code that is emitted anyway, bloating the executable, reducing > effective icache-size- True. As long as QString can own data, it needs to know whether the data it has is yours or not. I've tried to make the shared_static_data static be constexpr, but the problem is the called function: const is not const That is, the called function may const_cast the object passed by reference and modify the d pointer. So long as C++ allows this and we don't have a way to inform the compiler that a parameter (including the this parameter) is *really* const, this useless code emission will continue to happen. > > [followed by exception handling code irrelevant for us] > > I disagree. The exception code is not irrelevant for our users (and not for > us, either, e.g. in QtCore). It's irrelevant when the function called is one of ours, in a library of ours that got compiled with -fno-exceptions. It'll never throw. Even the few libraries we compile with exceptions will never throw. *Especially* the functions that would not allocate memory anyway, just increase a refcount. And QStringView overloads are likely to be exclusively found in Qt API, for the first three years of its existence, to an approximation of 95%. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Feb 3 17:47:38 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 03 Feb 2017 08:47:38 -0800 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: References: <201701311839.44054.marc.mutz@kdab.com> <201702031259.19797.marc.mutz@kdab.com> Message-ID: <2448685.QTMn7ycGF3@tjmaciei-mobl1> On sexta-feira, 3 de fevereiro de 2017 13:48:46 PST Kevin Kofler wrote: > The overhead compared to using QString will be reduced, but only part of it > (the avoided memory allocation) is really an optimization. The rest of the > "reduced" overhead is because QString will get the same overhead bloated > onto it (copying the entire string). So, sure, technically, QStringView will > have less overhead over QString, but the way you achieved that is > counterproductive. And all this is only valid for very short strings, longer > strings will still behave the same as before, except for the overhead of > the unused SSO array in both cases. Note how libstdc++ implemented SSO: instead of bit-check and branch, std::__cxx11::string always keeps a pointer to the beginning of the data, only that reflects back to itself. Interestingly, that's what QStringData did in Qt 4. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oswald.buddenhagen at qt.io Fri Feb 3 23:22:22 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 3 Feb 2017 23:22:22 +0100 Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business Message-ID: <20170203222222.GO12242@troll08> moin, we finally managed to add a cherry-pick validator to the sanity bot, so i dared to open the 5.6 branch for staging again. caveat: patchsets created before the final forward merge got a positive review while they aren't cherry-picks. i don't suppose anyone would stage such an old patchset as-is anyway, but please check. note that there is an exception to the policy as well: the qt5 super repo continues to operate in forward-merge mode also for the LTS branch. you probably don't care unless you're in the release or CI team. there is also another consideration: these off 5.6 integration runs of course cost CI resources. maybe it would be smart as a matter of policy to have a dedicated team do the staging in batches. From hamed.masafi at gmail.com Sat Feb 4 08:05:41 2017 From: hamed.masafi at gmail.com (Hamed Masafi) Date: Sat, 04 Feb 2017 07:05:41 +0000 Subject: [Development] Request moving project to playground area In-Reply-To: <8966291486115975@web16h.yandex.ru> References: <5412805.bOW9DRN70l@agathebauer> <8966291486115975@web16h.yandex.ru> Message-ID: Why not using Q_PROPERTY instead of NUT_DECLARE_FIELD? A property im table is more thsn a just Qt property, that macro create property and static field for query writing and class info about property to add to database. And what's the reason to have a constructor as Q_INVOKABLE? Andre right about that, Actually, there are more ORM solutions for Qt, e.g. QxOrm and QDjango Yes, there are, either other languages/frameworks like .net and java has. But I really live Qt so I think it can be a good idea if prepare free one of them to integrate into Qt. I think Nut is easy to use and feature rich (in alpha state for now) that support much database manager. Some of them are complicated and some others are so simple to real using. We can provide a full feature module with LGPL to community use. Excuses for my bad English, but I want give that tool to Qt community that very helped me. I want suggest two of my libraries to playground area. After all of this, can I know your idea about an orm in playground area? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jesus.Fernandez at qt.io Sat Feb 4 10:29:27 2017 From: Jesus.Fernandez at qt.io (Jesus Fernandez) Date: Sat, 4 Feb 2017 10:29:27 +0100 Subject: [Development] Request moving project to playground area In-Reply-To: References: <8966291486115975@web16h.yandex.ru> Message-ID: <1674216.J8x9Brqilc@linux-5lbc> On Saturday, February 04, 2017 07:05:41 AM Hamed Masafi wrote: > Why not using Q_PROPERTY instead of NUT_DECLARE_FIELD? > > A property im table is more thsn a just Qt property, that macro create > property and static field for query writing and class info about property > to add to database. To achieve this I think it's possible to use the property system + a custom subclass of QObject. If you want to expose this objects to QML you will need to declare a Q_PROPERTY, so It's not convenient. > > And what's the reason to have a constructor as Q_INVOKABLE? > > Andre right about that, If you register the class as "MetaType" you will be able to create instances of the class using QMetaType::create(). > > Actually, there are more ORM solutions for Qt, e.g. QxOrm and QDjango > > Yes, there are, either other languages/frameworks like .net and java has. > But I really live Qt so I think it can be a good idea if prepare free one > of them to integrate into Qt. > > I think Nut is easy to use and feature rich (in alpha state for now) that > support much database manager. > > Some of them are complicated and some others are so simple to real using. > We can provide a full feature module with LGPL to community use. > > Excuses for my bad English, but I want give that tool to Qt community that > very helped me. I want suggest two of my libraries to playground area. > > After all of this, can I know your idea about an orm in playground area? -- Best regards, Jesus From hamed.masafi at gmail.com Sat Feb 4 14:46:05 2017 From: hamed.masafi at gmail.com (Hamed Masafi) Date: Sat, 4 Feb 2017 17:16:05 +0330 Subject: [Development] Request moving project to playground area In-Reply-To: <1674216.J8x9Brqilc@linux-5lbc> References: <8966291486115975@web16h.yandex.ru> <1674216.J8x9Brqilc@linux-5lbc> Message-ID: > To achieve this I think it's possible to use the property system + a custom subclass > of QObject. If you watnt to expose this objects to QML you will need to declare a > Q_PROPERTY, so It's not convenient. Nut macro declare a static method to helping query writing as descripted in github page, this also declare Q_PROPERTY, so for now can not replace with anything else. From hamed.masafi at gmail.com Sun Feb 5 10:35:32 2017 From: hamed.masafi at gmail.com (Hamed Masafi) Date: Sun, 05 Feb 2017 09:35:32 +0000 Subject: [Development] Request moving project (noron) to playground area Message-ID: Project name: Noron Project description: This tool implements remote object sharing (Object Oriented RPC) in Qt. >From a technical point of view, it can compare with Java RMI or similar technologies. Noron has an advanced signaling mechanism. A property change on a peer (server or client) will immediately signal a change on other peers. It can transfer every QVariant type (even QPixmap and complex types). The Noron project is a framework that performs remote method invocation on client/server shared objects, the object-oriented equivalent of remote procedure calls (RPC). With support for direct transfer of serialized c++ types and QObject based objects. A shared object, shares properties and methods on client and server. Every property change on a peer reflect change to another one. A method-call on one peer (server/client) call same method on another peer and return result to caller. There are 3 type of shared objects: 1) Peer: this object represents a connected client and in server QList available as list of connected clients. 2) Global shared object. there is one instance of global shared object on server and every method call invoke this object. 3) Shared objects: this type can be creating and share between of some clients. In chess game example player is type (1), a game created between 2 players and some viewer is type (2) and server global object, for getting some data from server like new messages or updates is type (3) Noron can serialize and sent every type of QVariant over tcp, even QImage and other types Every method call on shared object can be return in some case to caller: - Normal method call with UI freeze - Return value to std::function - Return value to slot of object - Return value to qml function type - Call method asynchronous without value return every request sends with a key so request can send parallel. Noron check request injection with a secret key and hashing data. And also can track connection lost, after connection lost it will be auto reconnect to server and on server it will be locate on old location on before connection lost. Noron can be used for this type of apps: - Distributed application - Online games - Connection based apps (like chat applications and social networks) - 3 layer applications - ... Noron is so easy to use and for now use a tool for interface generation but in new version (not committed) use macro hack without any tool. The chat example in the repo shows simple usage of Noron. Further information is available via this git repo: https://github.com/HamedMasafi/Noron -------------- next part -------------- An HTML attachment was scrubbed... URL: From soroush.rabiei at gmail.com Sun Feb 5 11:16:28 2017 From: soroush.rabiei at gmail.com (Soroush Rabiei) Date: Sun, 5 Feb 2017 13:46:28 +0330 Subject: [Development] Request moving project (noron) to playground area In-Reply-To: References: Message-ID: Greetings Good idea (: it would be great to have RPC integrated into Qt... There was a similar project (Qt Remote Objects was the name if I'm not mistaken). Don't know the details, seems they are planning to provide a transparent remote API around Qt's Signal/Slot mechanism... You may want to have a look at it, or contact its developers: http://lists.qt-project.org/pipermail/development/2017-January/028282.html Cheers, Soroush From alexander.blasche at qt.io Mon Feb 6 08:34:35 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 6 Feb 2017 07:34:35 +0000 Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business In-Reply-To: <20170203222222.GO12242@troll08> References: <20170203222222.GO12242@troll08> Message-ID: Hi, It would help to actually state the rules the bot is following. This case below is an assumption since you don't really name the rules and I am interpreting in between your lines: How do I stage a change that is not a cherry-pick? Yes, they do exist and I can name a few cases where this makes sense especially since we are talking about 3 minor releases of Qt in between. -- Alex ________________________________________ From: Development on behalf of Oswald Buddenhagen Sent: Friday, 3 February 2017 11:22:22 PM To: development at qt-project.org Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business moin, we finally managed to add a cherry-pick validator to the sanity bot, so i dared to open the 5.6 branch for staging again. caveat: patchsets created before the final forward merge got a positive review while they aren't cherry-picks. i don't suppose anyone would stage such an old patchset as-is anyway, but please check. note that there is an exception to the policy as well: the qt5 super repo continues to operate in forward-merge mode also for the LTS branch. you probably don't care unless you're in the release or CI team. there is also another consideration: these off 5.6 integration runs of course cost CI resources. maybe it would be smart as a matter of policy to have a dedicated team do the staging in batches. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From andre.hartmann at iseg-hv.de Mon Feb 6 09:24:33 2017 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Mon, 6 Feb 2017 09:24:33 +0100 Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business In-Reply-To: References: <20170203222222.GO12242@troll08> Message-ID: Hi, and what about changes already uploaded to Gerrit, containing a cherry-pick line? They cannot be uploaded again without changing at least the commit message. What should happen there? Best regards, André Am 06.02.2017 um 08:34 schrieb Alex Blasche: > Hi, > > It would help to actually state the rules the bot is following. > > This case below is an assumption since you don't really name the rules and I am interpreting in between your lines: > > How do I stage a change that is not a cherry-pick? Yes, they do exist and I can name a few cases where this makes sense especially since we are talking about 3 minor releases of Qt in between. > > -- > Alex > ________________________________________ > From: Development on behalf of Oswald Buddenhagen > Sent: Friday, 3 February 2017 11:22:22 PM > To: development at qt-project.org > Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business > > moin, > > we finally managed to add a cherry-pick validator to the sanity bot, so > i dared to open the 5.6 branch for staging again. > > caveat: patchsets created before the final forward merge got a positive > review while they aren't cherry-picks. i don't suppose anyone would > stage such an old patchset as-is anyway, but please check. > > note that there is an exception to the policy as well: the qt5 super > repo continues to operate in forward-merge mode also for the LTS branch. > you probably don't care unless you're in the release or CI team. > > there is also another consideration: these off 5.6 integration runs of > course cost CI resources. maybe it would be smart as a matter of policy > to have a dedicated team do the staging in batches. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Best regards / Mit freundlichen Grüßen André Hartmann, Dipl.-Ing. (FH) Software Project Manager iseg Spezialelektronik GmbH | phone: ++49 (0)351 26996-43 Bautzner Landstr. 23 | fax: ++49 (0)351 26996-21 D-01454 Radeberg / Rossendorf | web: www.iseg-hv.com Geschäftsführer / Managing director: Dr. F. Gleisberg, Dr. J. Pöthig Amtsgericht / Lower district court: Dresden HRB 16250 Ust.-Id.-Nr. / VAT-ID: DE812508942 Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and delete this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From oswald.buddenhagen at qt.io Mon Feb 6 10:53:30 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 6 Feb 2017 10:53:30 +0100 Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business In-Reply-To: References: <20170203222222.GO12242@troll08> Message-ID: <20170206095330.GP12242@troll08> On Mon, Feb 06, 2017 at 07:34:35AM +0000, Alexander Blasche wrote: > How do I stage a change that is not a cherry-pick? Yes, they do exist > and I can name a few cases where this makes sense especially since we > are talking about 3 minor releases of Qt in between. > you override the bot, clearly stating why you're doing it. this is not a special case, so requires no explicit mention. From annulen at yandex.ru Mon Feb 6 10:56:24 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 06 Feb 2017 12:56:24 +0300 Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business In-Reply-To: <20170203222222.GO12242@troll08> References: <20170203222222.GO12242@troll08> Message-ID: <449311486374984@web26g.yandex.ru> 04.02.2017, 01:23, "Oswald Buddenhagen" : > moin, > > we finally managed to add a cherry-pick validator to the sanity bot, so > i dared to open the 5.6 branch for staging again. > > caveat: patchsets created before the final forward merge got a positive > review while they aren't cherry-picks. i don't suppose anyone would > stage such an old patchset as-is anyway, but please check. > > note that there is an exception to the policy as well: the qt5 super > repo continues to operate in forward-merge mode also for the LTS branch. > you probably don't care unless you're in the release or CI team. Here sanity bot compains that patch for 5.6 for qt5 repo is not a cherry-pick: https://codereview.qt-project.org/#/c/184640/1 > > there is also another consideration: these off 5.6 integration runs of > course cost CI resources. maybe it would be smart as a matter of policy > to have a dedicated team do the staging in batches. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From oswald.buddenhagen at qt.io Mon Feb 6 10:59:19 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 6 Feb 2017 10:59:19 +0100 Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business In-Reply-To: References: <20170203222222.GO12242@troll08> Message-ID: <20170206095919.GQ12242@troll08> On Mon, Feb 06, 2017 at 09:24:33AM +0100, André Hartmann wrote: > and what about changes already uploaded to Gerrit, containing a > cherry-pick line? > look at the changes' review comments? From oswald.buddenhagen at qt.io Mon Feb 6 11:12:29 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 6 Feb 2017 11:12:29 +0100 Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business In-Reply-To: <449311486374984@web26g.yandex.ru> References: <20170203222222.GO12242@troll08> <449311486374984@web26g.yandex.ru> Message-ID: <20170206101229.GR12242@troll08> On Mon, Feb 06, 2017 at 12:56:24PM +0300, Konstantin Tokarev wrote: > 04.02.2017, 01:23, "Oswald Buddenhagen" : > > note that there is an exception to the policy as well: the qt5 super > > repo continues to operate in forward-merge mode also for the LTS branch. > > you probably don't care unless you're in the release or CI team. > > Here sanity bot compains that patch for 5.6 for qt5 repo is not a cherry-pick: > > https://codereview.qt-project.org/#/c/184640/1 > yeah, something is wrong. it works just fine when i test it on the server's command line, but in the hook context it apparently doesn't pick up the repository's configuration. will investigate. From edward.welbourne at qt.io Mon Feb 6 11:33:52 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 6 Feb 2017 10:33:52 +0000 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <13214911.RNMolzDENi@tjmaciei-mobl1> References: <201701311839.44054.marc.mutz@kdab.com> <15525147.Lm1KGjIrF9@tjmaciei-mobl1> <201702031259.19797.marc.mutz@kdab.com>, <13214911.RNMolzDENi@tjmaciei-mobl1> Message-ID: >>> [followed by exception handling code irrelevant for us] >> >> I disagree. The exception code is not irrelevant for our users (and >> not for us, either, e.g. in QtCore). Thiago Macieira (3 February 2017 17:45) > It's irrelevant when the function called is one of ours, in a library > of ours that got compiled with -fno-exceptions. It'll never > throw. Even the few libraries we compile with exceptions will never > throw. *Especially* the functions that would not allocate memory > anyway, just increase a refcount. If the unused code gets loaded into memory, then it's not entirely irrelevant; it is costing run-time memory and making caches miss more often. Smaller code runs faster. Eddy. From andre.hartmann at iseg-hv.de Mon Feb 6 11:46:42 2017 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Mon, 6 Feb 2017 11:46:42 +0100 Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business In-Reply-To: <20170206095919.GQ12242@troll08> References: <20170203222222.GO12242@troll08> <20170206095919.GQ12242@troll08> Message-ID: <7d3182fb-577c-a06f-8ced-314c9b1408ca@iseg-hv.de> Hi Oswald, > look at the changes' review comments? Sorry for the noise. Now I got it :) Thanks, André Am 06.02.2017 um 10:59 schrieb Oswald Buddenhagen: > On Mon, Feb 06, 2017 at 09:24:33AM +0100, André Hartmann wrote: >> and what about changes already uploaded to Gerrit, containing a >> cherry-pick line? >> > look at the changes' review comments? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From sean.harmer at kdab.com Mon Feb 6 13:26:03 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 06 Feb 2017 12:26:03 +0000 Subject: [Development] Nominate Mike Krus as approver Message-ID: <3025657.bWAXI9RxFb@cartman> Hi, I'd like to nominate Mike Krus as an approver. Mike contributed support for Qt on tvOS along with the refactoring that went in as part of this. Mike has done a lot of work within Qt 3D too. Disclaimer: Mike is a colleague at KDAB. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From bogdan.vatra at kdab.com Mon Feb 6 13:29:18 2017 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Mon, 06 Feb 2017 14:29:18 +0200 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <3025657.bWAXI9RxFb@cartman> References: <3025657.bWAXI9RxFb@cartman> Message-ID: <30345374.vbkjoXEbWa@zmeu> On luni, 6 februarie 2017 12:26:03 EET Sean Harmer wrote: > Hi, > > I'd like to nominate Mike Krus as an approver. Mike contributed support for > Qt on tvOS along with the refactoring that went in as part of this. Mike > has done a lot of work within Qt 3D too. > > Disclaimer: Mike is a colleague at KDAB. > > Cheers, > > Sean +1 BogDan. Same disclaimer. From sean.harmer at kdab.com Mon Feb 6 14:20:58 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 06 Feb 2017 13:20:58 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <3025657.bWAXI9RxFb@cartman> References: <3025657.bWAXI9RxFb@cartman> Message-ID: <5153888.NmrKWlxPQI@cartman> Hi, in fact, I've just been reminded we already proposed and voted for Mike as maintainer of the tvOS system last year: http://lists.qt-project.org/pipermail/development/2016-August/026903.html There were no objections and maintainer of a module implies approver, so could somebody do the honours and grant Mike the rights please? The necessary period has long since passed. Thanks, Sean On Monday 06 February 2017 12:26:03 Sean Harmer wrote: > Hi, > > I'd like to nominate Mike Krus as an approver. Mike contributed support for > Qt on tvOS along with the refactoring that went in as part of this. Mike > has done a lot of work within Qt 3D too. > > Disclaimer: Mike is a colleague at KDAB. > > Cheers, > > Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From alexander.blasche at qt.io Mon Feb 6 15:54:53 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 6 Feb 2017 14:54:53 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <5153888.NmrKWlxPQI@cartman> References: <3025657.bWAXI9RxFb@cartman>,<5153888.NmrKWlxPQI@cartman> Message-ID: >There were no objections and maintainer of a module implies approver, so could >somebody do the honours and grant Mike the rights please? The necessary period >has long since passed. I am sorry but being the maintainer does not imply approver rights. At most it implies approver rights for the component he is maintainer for. I agree that when you maintain a cross module component that this is somewhat harder to manage. In any case I am sure that waiting for the required time does not make much of a difference. Then this discussion is over anyway. -- Alex From milian.wolff at kdab.com Mon Feb 6 16:13:23 2017 From: milian.wolff at kdab.com (Milian Wolff) Date: Mon, 06 Feb 2017 16:13:23 +0100 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <30345374.vbkjoXEbWa@zmeu> References: <3025657.bWAXI9RxFb@cartman> <30345374.vbkjoXEbWa@zmeu> Message-ID: <7769529.isUTnznbmr@milian-kdab2> On Monday, February 6, 2017 1:29:18 PM CET Bogdan Vatra wrote: > On luni, 6 februarie 2017 12:26:03 EET Sean Harmer wrote: > > Hi, > > > > I'd like to nominate Mike Krus as an approver. Mike contributed support > > for > > Qt on tvOS along with the refactoring that went in as part of this. Mike > > has done a lot of work within Qt 3D too. > > > > Disclaimer: Mike is a colleague at KDAB. > > > > Cheers, > > > > Sean > > +1 > > BogDan. > > Same disclaimer. ^- +1 to both of the above -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From sean.harmer at kdab.com Mon Feb 6 16:19:38 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 06 Feb 2017 15:19:38 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: References: <3025657.bWAXI9RxFb@cartman> <5153888.NmrKWlxPQI@cartman> Message-ID: <1870998.ouyocvDNR3@cartman> On Monday 06 February 2017 14:54:53 Alex Blasche wrote: > >There were no objections and maintainer of a module implies approver, so > >could somebody do the honours and grant Mike the rights please? The > >necessary period has long since passed. > > I am sorry but being the maintainer does not imply approver rights. At most > it implies approver rights for the component he is maintainer for. I agree > that when you maintain a cross module component that this is somewhat > harder to manage. > > In any case I am sure that waiting for the required time does not make much > of a difference. Then this discussion is over anyway. My misunderstanding then. No problem to wait now of course. Cheers, Sean > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From sergio.martins at kdab.com Mon Feb 6 17:11:16 2017 From: sergio.martins at kdab.com (Sergio Martins) Date: Mon, 06 Feb 2017 16:11:16 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: References: <3025657.bWAXI9RxFb@cartman>,<5153888.NmrKWlxPQI@cartman> Message-ID: <0cc37cb85f80c242d8b32100f9a6b3e5@kdab.com> On 2017-02-06 14:54, Alex Blasche wrote: >> There were no objections and maintainer of a module implies approver, >> so could >> somebody do the honours and grant Mike the rights please? The >> necessary period >> has long since passed. > > I am sorry but being the maintainer does not imply approver rights. https://wiki.qt.io/The_Qt_Governance_Model kind of implies you can't be a maintainer if you're not an approver. "How to become a Maintainer: An Approver who (...), may be nomiated (...)" What failed here is that he wasn't nominated for approver, so we need to wait in any case :) +1 for approver, from me. Btw, the "maintainers" group in gerrit (https://codereview.qt-project.org/#/admin/groups/13,members) seems out of date, it's missing Sean, Bogdan, Giulio, Milian and possibly more. 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 annulen at yandex.ru Mon Feb 6 17:35:05 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 06 Feb 2017 19:35:05 +0300 Subject: [Development] [Announcement] QtWebKit Technology Preview 5 Message-ID: <1510551486398905@web12j.yandex.ru> Hi all, QtWebKit Technology Preview 5 is out. Highlights of these release are: * WebGL, accelerated compositing and accelerated 2D canvas are supported now. Accelerated compositing is disabled by default for now, it is known to cause minor artifacts on some sites. * MinGW compiler is now fully supported on Windows This improves feature parity with previous releases of QtWebKit [1]. The only major remining thing is QML API (based on WebKit2) which is being worked on right now [2] You can find more detailed release changelog and binary builds compatible with official Qt 5.8 SDK at https://github.com/annulen/webkit/releases/tag/qtwebkit-tp5 Big thanks to all contributors! [1] https://github.com/annulen/webkit/wiki/Comparison-with-QtWebKit-5.6 [2] https://github.com/annulen/webkit/tree/wk2 https://github.com/annulen/webkit/wiki/Building-WebKit2-%28WIP%29 -- Regards, Konstantin From thiago.macieira at intel.com Mon Feb 6 17:38:12 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 06 Feb 2017 08:38:12 -0800 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: References: <201701311839.44054.marc.mutz@kdab.com> <13214911.RNMolzDENi@tjmaciei-mobl1> Message-ID: <2382102.Fquryj8u36@tjmaciei-mobl1> On segunda-feira, 6 de fevereiro de 2017 10:33:52 PST Edward Welbourne wrote: > Thiago Macieira (3 February 2017 17:45) > > > It's irrelevant when the function called is one of ours, in a library > > of ours that got compiled with -fno-exceptions. It'll never > > throw. Even the few libraries we compile with exceptions will never > > throw. *Especially* the functions that would not allocate memory > > anyway, just increase a refcount. > > If the unused code gets loaded into memory, then it's not entirely > irrelevant; it is costing run-time memory and making caches miss > more often. Smaller code runs faster. Yes, but it's very hard to measure. I do agree in shrinking our code however much we can (which is why I'd like to suppress the unwind tables completely). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Feb 6 17:39:21 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 06 Feb 2017 08:39:21 -0800 Subject: [Development] HEADS-UP: 5.6 / LTS is now open for business In-Reply-To: References: <20170203222222.GO12242@troll08> Message-ID: <2418851.lCJp4caaQQ@tjmaciei-mobl1> On segunda-feira, 6 de fevereiro de 2017 07:34:35 PST Alex Blasche wrote: > Hi, > > It would help to actually state the rules the bot is following. > > This case below is an assumption since you don't really name the rules and I > am interpreting in between your lines: > > How do I stage a change that is not a cherry-pick? Yes, they do exist and I > can name a few cases where this makes sense especially since we are talking > about 3 minor releases of Qt in between. I assume that writing "This does not apply to Qt 5.8" somewhere and the bot will be smart enough to either not give you -2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Jake.Petroules at qt.io Mon Feb 6 17:51:53 2017 From: Jake.Petroules at qt.io (Jake Petroules) Date: Mon, 6 Feb 2017 16:51:53 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <0cc37cb85f80c242d8b32100f9a6b3e5@kdab.com> References: <3025657.bWAXI9RxFb@cartman> <5153888.NmrKWlxPQI@cartman> <0cc37cb85f80c242d8b32100f9a6b3e5@kdab.com> Message-ID: +1 for Mike Krus as Approver. > On Feb 6, 2017, at 8:11 AM, Sergio Martins wrote: > > On 2017-02-06 14:54, Alex Blasche wrote: >>> There were no objections and maintainer of a module implies approver, so could >>> somebody do the honours and grant Mike the rights please? The necessary period >>> has long since passed. >> I am sorry but being the maintainer does not imply approver rights. > > https://wiki.qt.io/The_Qt_Governance_Model kind of implies you can't be a maintainer if you're not an approver. > "How to become a Maintainer: An Approver who (...), may be nomiated (...)" > > What failed here is that he wasn't nominated for approver, so we need to wait in any case :) > > +1 for approver, from me. > > > Btw, the "maintainers" group in gerrit (https://codereview.qt-project.org/#/admin/groups/13,members) seems out of date, it's missing Sean, Bogdan, Giulio, Milian and possibly more. > > > > 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 -- Jake Petroules - jake.petroules at qt.io The Qt Company - Silicon Valley Qbs build tool evangelist - qbs.io From oswald.buddenhagen at qt.io Mon Feb 6 18:39:19 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 6 Feb 2017 18:39:19 +0100 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: References: <3025657.bWAXI9RxFb@cartman> <5153888.NmrKWlxPQI@cartman> Message-ID: <20170206173919.GT12242@troll08> On Mon, Feb 06, 2017 at 02:54:53PM +0000, Alexander Blasche wrote: > >There were no objections and maintainer of a module implies approver, so could > >somebody do the honours and grant Mike the rights please? The necessary period > >has long since passed. > > I am sorry but being the maintainer does not imply approver rights. At most it implies approver rights for the component he is maintainer for. I agree that when you maintain a cross module component that this is somewhat harder to manage. > selective approver rights are not implementable for a horizontal responsibility, so this is kind of moot. > In any case I am sure that waiting for the required time does not make much of a difference. Then this discussion is over anyway. > the previous thread already used the word approver without futher qualification (http://lists.qt-project.org/pipermail/development/2016-August/026909.html) and nobody objected, so i just gave mike the rights. From thiago.macieira at intel.com Mon Feb 6 19:27:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 06 Feb 2017 10:27:01 -0800 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <20170206173919.GT12242@troll08> References: <3025657.bWAXI9RxFb@cartman> <20170206173919.GT12242@troll08> Message-ID: <3308654.Pubholnvlv@tjmaciei-mobl1> On segunda-feira, 6 de fevereiro de 2017 18:39:19 PST Oswald Buddenhagen wrote: > On Mon, Feb 06, 2017 at 02:54:53PM +0000, Alexander Blasche wrote: > > >There were no objections and maintainer of a module implies approver, so > > >could somebody do the honours and grant Mike the rights please? The > > >necessary period has long since passed. > > > > I am sorry but being the maintainer does not imply approver rights. At > > most it implies approver rights for the component he is maintainer for. I > > agree that when you maintain a cross module component that this is > > somewhat harder to manage. > selective approver rights are not implementable for a horizontal > responsibility, so this is kind of moot. > > > In any case I am sure that waiting for the required time does not make > > much of a difference. Then this discussion is over anyway. > the previous thread already used the word approver without futher > qualification > (http://lists.qt-project.org/pipermail/development/2016-August/026909.html) > and nobody objected, so i just gave mike the rights. Let's not quabble over this. Becoming maintainer of anything in a main module implies becoming Approver everywhere, if one is not so yet. Restricted maintainership rights should be used only for playground things. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gna.org Tue Feb 7 01:39:17 2017 From: chgans at gna.org (Ch'Gans) Date: Tue, 7 Feb 2017 13:39:17 +1300 Subject: [Development] Documentation typo fixes Message-ID: Hi there, It's been a while that I notice some typos here and there in Qt5 documentation (mainly qtbase), and i decided that i would start correcting them in the source code. Most of them are really straight forward, eg. in QGraphicsView::setTransform: "To simplify interation with items using a transformed view, ..." should be: "To simplify interaction with items using a transformed view, ..." It's just one example from this morning. Not a big of a deal, but documentation looks always nicer without typos. I would like to know to which branch should i target such "code review" on gerrit. Should it be "Current release", "Next release", "dev" or "master"? My gut feeling tells me "dev", so that from there, maintainers can decide if they want to propagate or not. Could someone confirm this? Thanks, Chris From szehowe.koh at gmail.com Tue Feb 7 04:35:38 2017 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Tue, 7 Feb 2017 11:35:38 +0800 Subject: [Development] Documentation typo fixes In-Reply-To: References: Message-ID: On 7 February 2017 at 08:39, Ch'Gans wrote: > > Hi there, > > It's been a while that I notice some typos here and there in Qt5 > documentation (mainly qtbase), and i decided that i would start > correcting them in the source code. > Most of them are really straight forward, eg. in QGraphicsView::setTransform: > "To simplify interation with items using a transformed view, ..." > should be: > "To simplify interaction with items using a transformed view, ..." > > It's just one example from this morning. Not a big of a deal, but > documentation looks always nicer without typos. > > I would like to know to which branch should i target such "code > review" on gerrit. > Should it be "Current release", "Next release", "dev" or "master"? > My gut feeling tells me "dev", so that from there, maintainers can > decide if they want to propagate or not. > Could someone confirm this? > > Thanks, > Chris Hi Chris, Thank you for helping to fix typos. See http://wiki.qt.io/Branch_Guidelines (Note: Qt module repositories don't have a "master" branch) Right now, the branches that accept documentation fixes are: * 5.8 (stable branch) * 5.9 (next release branch) * dev (development branch) Simply put, patches will merge from the top of the list to the bottom of this list. For example, patches that go into "5.8" will eventually be merged into "5.9", which in turn will eventually be merged into "dev". Typo fixes are not new features or major/risky changes, so they can go into the stable branch ("5.8"). Regards, Sze-Howe From tuukka.turunen at qt.io Tue Feb 7 09:10:28 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Tue, 7 Feb 2017 08:10:28 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <3308654.Pubholnvlv@tjmaciei-mobl1> References: <3025657.bWAXI9RxFb@cartman> <20170206173919.GT12242@troll08> <3308654.Pubholnvlv@tjmaciei-mobl1> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+tuukka.turunen=qt.io at qt-project.org] On Behalf Of Thiago > Macieira > Sent: maanantaina 6. helmikuuta 2017 20.27 > To: development at qt-project.org > Subject: Re: [Development] Nominate Mike Krus as approver > > On segunda-feira, 6 de fevereiro de 2017 18:39:19 PST Oswald Buddenhagen > wrote: > > On Mon, Feb 06, 2017 at 02:54:53PM +0000, Alexander Blasche wrote: > > > >There were no objections and maintainer of a module implies > > > >approver, so could somebody do the honours and grant Mike the > > > >rights please? The necessary period has long since passed. > > > > > > I am sorry but being the maintainer does not imply approver rights. > > > At most it implies approver rights for the component he is > > > maintainer for. I agree that when you maintain a cross module > > > component that this is somewhat harder to manage. > > selective approver rights are not implementable for a horizontal > > responsibility, so this is kind of moot. > > > > > In any case I am sure that waiting for the required time does not > > > make much of a difference. Then this discussion is over anyway. > > the previous thread already used the word approver without futher > > qualification > > (http://lists.qt-project.org/pipermail/development/2016-August/026909. > > html) and nobody objected, so i just gave mike the rights. > > Let's not quabble over this. > > Becoming maintainer of anything in a main module implies becoming > Approver everywhere, if one is not so yet. > +1 (to me this has mostly already been the case, but as it seems to be unclear it is good to document it clearly) > Restricted maintainership rights should be used only for playground things. > +1 (barrier to have playground repo should be low, thus these could be maintained by persons who are not approvers yet) Yours, Tuukka > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From lars.knoll at qt.io Tue Feb 7 10:23:27 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 7 Feb 2017 09:23:27 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <3308654.Pubholnvlv@tjmaciei-mobl1> References: <3025657.bWAXI9RxFb@cartman> <20170206173919.GT12242@troll08> <3308654.Pubholnvlv@tjmaciei-mobl1> Message-ID: <7E0506E0-DBE6-42C3-91F2-9F0DC67BD9E0@qt.io> On 06 Feb 2017, at 19:27, Thiago Macieira > wrote: On segunda-feira, 6 de fevereiro de 2017 18:39:19 PST Oswald Buddenhagen wrote: On Mon, Feb 06, 2017 at 02:54:53PM +0000, Alexander Blasche wrote: There were no objections and maintainer of a module implies approver, so could somebody do the honours and grant Mike the rights please? The necessary period has long since passed. I am sorry but being the maintainer does not imply approver rights. At most it implies approver rights for the component he is maintainer for. I agree that when you maintain a cross module component that this is somewhat harder to manage. selective approver rights are not implementable for a horizontal responsibility, so this is kind of moot. In any case I am sure that waiting for the required time does not make much of a difference. Then this discussion is over anyway. the previous thread already used the word approver without futher qualification (http://lists.qt-project.org/pipermail/development/2016-August/026909.html) and nobody objected, so i just gave mike the rights. Let's not quabble over this. Becoming maintainer of anything in a main module implies becoming Approver everywhere, if one is not so yet. Restricted maintainership rights should be used only for playground things. +1. Being maintainer of something that is part of Qt does of course imply approver rights. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Tue Feb 7 11:18:56 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 7 Feb 2017 10:18:56 +0000 Subject: [Development] Documentation typo fixes In-Reply-To: References: , Message-ID: On 7 February 2017 at 08:39, Ch'Gans wrote: >> It's been a while that I notice some typos here and there in Qt5 >> documentation (mainly qtbase), and i decided that i would start >> correcting them in the source code. Thank you :-) [snip] >> documentation looks always nicer without typos. Indeed it does. >> I would like to know to which branch should i target such "code >> review" on gerrit. >> Should it be "Current release", "Next release", "dev" or "master"? >> My gut feeling tells me "dev", so that from there, maintainers can >> decide if they want to propagate or not. >> Could someone confirm this? Sze Howe Koh (7 February 2017 04:35) replied: > See http://wiki.qt.io/Branch_Guidelines (Note: Qt module repositories > don't have a "master" branch) > > Right now, the branches that accept documentation fixes are: > > * 5.8 (stable branch) > * 5.9 (next release branch) > * dev (development branch) > > Simply put, patches will merge from the top of the list to the bottom > of this list. For example, patches that go into "5.8" will eventually > be merged into "5.9", which in turn will eventually be merged into > "dev". > > Typo fixes are not new features or major/risky changes, so they can go > into the stable branch ("5.8"). Indeed. This is all being formalised in QUIP 5: https://codereview.qt-project.org/178906 where you can find out all you wish to know about which changes should go to which branches, Eddy. From edward.welbourne at qt.io Tue Feb 7 11:29:03 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 7 Feb 2017 10:29:03 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <0cc37cb85f80c242d8b32100f9a6b3e5@kdab.com> References: <3025657.bWAXI9RxFb@cartman>,<5153888.NmrKWlxPQI@cartman> , <0cc37cb85f80c242d8b32100f9a6b3e5@kdab.com> Message-ID: Sergio Martins (6 February 2017 17:11) quoted > https://wiki.qt.io/The_Qt_Governance_Model kind of implies you can't > be a maintainer if you're not an approver. > "How to become a Maintainer: An Approver who (...), may be nomiated > (...)" However, the next paragraph adds "A Maintainer may also nominate a new Maintainer to take ownership of a subset of his / her component" without any mention of the new Maintainer being an Approver. Subsequent discussion appears to have concluded (quoting Thiago): Becoming maintainer of anything in a main module implies becoming Approver everywhere, if one is not so yet. Should I update that wiki page ? Should we, in fact, turn it into a QUIP ? Eddy. From lars.knoll at qt.io Tue Feb 7 12:45:44 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 7 Feb 2017 11:45:44 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: References: <3025657.bWAXI9RxFb@cartman> <5153888.NmrKWlxPQI@cartman> <0cc37cb85f80c242d8b32100f9a6b3e5@kdab.com> Message-ID: > On 07 Feb 2017, at 11:29, Edward Welbourne wrote: > > Sergio Martins (6 February 2017 17:11) quoted >> https://wiki.qt.io/The_Qt_Governance_Model kind of implies you can't >> be a maintainer if you're not an approver. >> "How to become a Maintainer: An Approver who (...), may be nomiated >> (...)" > > However, the next paragraph adds "A Maintainer may also nominate a new > Maintainer to take ownership of a subset of his / her component" without > any mention of the new Maintainer being an Approver. > > Subsequent discussion appears to have concluded (quoting Thiago): > > Becoming maintainer of anything in a main module implies becoming > Approver everywhere, if one is not so yet. > > Should I update that wiki page ? > Should we, in fact, turn it into a QUIP ? The way we have been drawing our governance model as a pyramid had always implied this for me. But I can see that it’s not explicitly mentioned in the wiki page. Let's add a sentence to the wiki page for the maintainers section. And yes, it would be good to turn the governance model into a QUIP :) Cheers, Lars From edward.welbourne at qt.io Tue Feb 7 13:03:47 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 7 Feb 2017 12:03:47 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: References: <3025657.bWAXI9RxFb@cartman> <5153888.NmrKWlxPQI@cartman> <0cc37cb85f80c242d8b32100f9a6b3e5@kdab.com> , Message-ID: Lars Knoll (7 February 2017 12:45) wrote: > The way we have been drawing our governance model as a pyramid had > always implied this for me. But I can see that it’s not explicitly > mentioned in the wiki page. Indeed, the "Becoming a Maintainer" section did in fact only permit us to nominate existing Approvers as Maintainers; which we have violated repeatedly. > Let's add a sentence to the wiki page for the maintainers section. And > yes, it would be good to turn the governance model into a QUIP :) Here's my change to the Wiki page: https://wiki.qt.io/index.php?title=The_Qt_Governance_Model&diff=29866&oldid=29555 I doubt I'll get round to QUIPping it any time soon - any volunteers ? Eddy. From lars.knoll at qt.io Tue Feb 7 13:17:26 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 7 Feb 2017 12:17:26 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: References: <3025657.bWAXI9RxFb@cartman> <5153888.NmrKWlxPQI@cartman> <0cc37cb85f80c242d8b32100f9a6b3e5@kdab.com> Message-ID: <2B7F899C-D878-48E6-A573-A3D40E002CF1@qt.io> > On 07 Feb 2017, at 13:03, Edward Welbourne wrote: > > Lars Knoll (7 February 2017 12:45) wrote: >> The way we have been drawing our governance model as a pyramid had >> always implied this for me. But I can see that it’s not explicitly >> mentioned in the wiki page. > > Indeed, the "Becoming a Maintainer" section did in fact only permit us > to nominate existing Approvers as Maintainers; which we have violated > repeatedly. > >> Let's add a sentence to the wiki page for the maintainers section. And >> yes, it would be good to turn the governance model into a QUIP :) > > Here's my change to the Wiki page: > https://wiki.qt.io/index.php?title=The_Qt_Governance_Model&diff=29866&oldid=29555 Thanks Eddy! Looks good to me :) Lars > > I doubt I'll get round to QUIPping it any time soon - any volunteers ? > > Eddy. From thiago.macieira at intel.com Tue Feb 7 16:54:04 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Feb 2017 07:54:04 -0800 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: References: <3025657.bWAXI9RxFb@cartman> Message-ID: <31699173.y30tuQOZWR@tjmaciei-mobl1> On terça-feira, 7 de fevereiro de 2017 12:03:47 PST Edward Welbourne wrote: > Lars Knoll (7 February 2017 12:45) wrote: > > The way we have been drawing our governance model as a pyramid had > > always implied this for me. But I can see that it’s not explicitly > > mentioned in the wiki page. > > Indeed, the "Becoming a Maintainer" section did in fact only permit us > to nominate existing Approvers as Maintainers; which we have violated > repeatedly. I read that as nominating for maintainership and approvership at the same time. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Feb 7 17:25:57 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 07 Feb 2017 17:25:57 +0100 Subject: [Development] standalone building of sql plugins Message-ID: <1803710.uzhPaLupVr@portia.local> Hello, MacPorts has always shipped the Qt sql plugins as separate packages, so the main (QtBase) component could be built without unnecessary libraries installed. That is, qtbase is configured with -no-sql-$driver This was implemented quite simply: to build say the PostGresql plugin we'd unpack the qtbase component (except for the mkspecs directory), and invoke the installed qmake in /path/to/source/qtbase/src/plugins/sqldrivers/psql . Run make and make install, and the libqsqlpsql.dylib binary would be installed in the appropriate location. This approach is broken in Qt 5.8.0; is it still possible to build these plugins separately? Would this work by calling qmake in qtbase/src/sql for instance, with the appropriate arguments? Thanks! R. From samuel.gaist at edeltech.ch Tue Feb 7 17:35:37 2017 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Tue, 7 Feb 2017 17:35:37 +0100 Subject: [Development] standalone building of sql plugins In-Reply-To: <1803710.uzhPaLupVr@portia.local> References: <1803710.uzhPaLupVr@portia.local> Message-ID: <878C59C9-927B-491D-B971-B2904862D274@edeltech.ch> > On 7 Feb 2017, at 17:25, René J.V. Bertin wrote: > > Hello, > > MacPorts has always shipped the Qt sql plugins as separate packages, so the main (QtBase) component could be built without unnecessary libraries installed. That is, qtbase is configured with -no-sql-$driver > > This was implemented quite simply: to build say the PostGresql plugin we'd unpack the qtbase component (except for the mkspecs directory), and invoke the installed qmake in /path/to/source/qtbase/src/plugins/sqldrivers/psql . Run make and make install, and the libqsqlpsql.dylib binary would be installed in the appropriate location. > > This approach is broken in Qt 5.8.0; is it still possible to build these plugins separately? Would this work by calling qmake in qtbase/src/sql for instance, with the appropriate arguments? > > Thanks! > > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Hi, https://bugreports.qt.io/browse/QTBUG-58372 might be of help. Regards, Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP URL: From vindrg at gmail.com Tue Feb 7 18:03:04 2017 From: vindrg at gmail.com (Vincas Dargis) Date: Tue, 7 Feb 2017 19:03:04 +0200 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <2382102.Fquryj8u36@tjmaciei-mobl1> References: <201701311839.44054.marc.mutz@kdab.com> <13214911.RNMolzDENi@tjmaciei-mobl1> <2382102.Fquryj8u36@tjmaciei-mobl1> Message-ID: <3835762c-603f-4652-e20d-908fab44c78d@gmail.com> 2017.02.06 18:38, Thiago Macieira rašė: > Yes, but it's very hard to measure. I do agree in shrinking our code however > much we can (which is why I'd like to suppress the unwind tables completely). Sorry for off-topic, but I wonder, have anyone measured how Qt modules sizes differs with and without `noexcept` being in effect? From annulen at yandex.ru Tue Feb 7 18:06:38 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 07 Feb 2017 20:06:38 +0300 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <3835762c-603f-4652-e20d-908fab44c78d@gmail.com> References: <201701311839.44054.marc.mutz@kdab.com> <13214911.RNMolzDENi@tjmaciei-mobl1> <2382102.Fquryj8u36@tjmaciei-mobl1> <3835762c-603f-4652-e20d-908fab44c78d@gmail.com> Message-ID: <7880271486487198@web10g.yandex.ru> 07.02.2017, 20:03, "Vincas Dargis" : > 2017.02.06 18:38, Thiago Macieira rašė: >>  Yes, but it's very hard to measure. I do agree in shrinking our code however >>  much we can (which is why I'd like to suppress the unwind tables completely). > > Sorry for off-topic, but I wonder, have anyone measured how Qt modules > sizes differs with and without `noexcept` being in effect? It's not about size only, having exceptions enabled makes some compiler optimizations impossible, because new paths of execution flow become possible. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From rjvbertin at gmail.com Tue Feb 7 19:05:19 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 07 Feb 2017 19:05:19 +0100 Subject: [Development] standalone building of sql plugins In-Reply-To: <878C59C9-927B-491D-B971-B2904862D274@edeltech.ch> References: <1803710.uzhPaLupVr@portia.local> <878C59C9-927B-491D-B971-B2904862D274@edeltech.ch> Message-ID: <1670187.W3oPnEEFUL@portia.local> On Tuesday February 07 2017 17:35:37 Samuel Gaist wrote: > https://bugreports.qt.io/browse/QTBUG-58372 Indeed, thanks. Removing the QMAKE_USE+=psql line also worked here (plus moving .qmake.conf into the psql directory). R. From thiago.macieira at intel.com Tue Feb 7 20:15:45 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Feb 2017 11:15:45 -0800 Subject: [Development] standalone building of sql plugins In-Reply-To: <1803710.uzhPaLupVr@portia.local> References: <1803710.uzhPaLupVr@portia.local> Message-ID: <2173130.YG2P4Fok3e@tjmaciei-mobl1> Em terça-feira, 7 de fevereiro de 2017, às 17:25:57 PST, René J.V. Bertin escreveu: > This approach is broken in Qt 5.8.0; is it still possible to build these > plugins separately? Would this work by calling qmake in qtbase/src/sql for > instance, with the appropriate arguments? It needs to work, because we can't ship all plugins. It does not need to be exactly the same way that it was before, but there needs to be a way. Seeing there's a bug report already, let's discuss ther on how to solve this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Feb 7 20:21:30 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Feb 2017 11:21:30 -0800 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <7880271486487198@web10g.yandex.ru> References: <201701311839.44054.marc.mutz@kdab.com> <3835762c-603f-4652-e20d-908fab44c78d@gmail.com> <7880271486487198@web10g.yandex.ru> Message-ID: <78239659.1uqUhjt3T5@tjmaciei-mobl1> Em terça-feira, 7 de fevereiro de 2017, às 20:06:38 PST, Konstantin Tokarev escreveu: > 07.02.2017, 20:03, "Vincas Dargis" : > > 2017.02.06 18:38, Thiago Macieira rašė: > >> Yes, but it's very hard to measure. I do agree in shrinking our code > >> however much we can (which is why I'd like to suppress the unwind tables > >> completely).> > > Sorry for off-topic, but I wonder, have anyone measured how Qt modules > > sizes differs with and without `noexcept` being in effect? > > It's not about size only, having exceptions enabled makes some compiler > optimizations impossible, because new paths of execution flow become > possible. Right. The difference is in the calling code, mostly. But note we do *not* mark our methods in libraries outside of QtCore as noexcept. They will never throw, but we don't mark them as such. There's also a policy in place that we don't mark nothrow any narrow-contract function. The difference, as we discussed before, is in having smaller code because of the absence of the exceptional code paths. Since we know we won't throw, we can suppress that code and gain in memory pressure and cache utilisation, both of which are very hard to measure an effect on. I've toyed with the idea of suppressing the unwind tables completely (see review I2bc52f3c7a574209b213fffd149b5028b27b0395). That change applies it only to bootstrapped tools, since we control the execution, but not for libraries. The unwind tables may be used by other things besides exceptions, like POSIX asynchronous thread cancellations and backtrace dumps. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Feb 7 21:40:53 2017 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 07 Feb 2017 21:40:53 +0100 Subject: [Development] standalone building of sql plugins References: <1803710.uzhPaLupVr@portia.local> <2173130.YG2P4Fok3e@tjmaciei-mobl1> Message-ID: <3060179.yGk8BGJPcQ@portia.local> Thiago Macieira wrote: > It needs to work, because we can't ship all plugins. It does not need to be > exactly the same way that it was before, but there needs to be a way. > > Seeing there's a bug report already, let's discuss ther on how to solve this. Agreed and agreed. R. From chgans at gna.org Tue Feb 7 23:03:29 2017 From: chgans at gna.org (Ch'Gans) Date: Wed, 8 Feb 2017 11:03:29 +1300 Subject: [Development] Documentation typo fixes In-Reply-To: References: Message-ID: On 7 February 2017 at 23:18, Edward Welbourne wrote: [...] > > Sze Howe Koh (7 February 2017 04:35) replied: >> See http://wiki.qt.io/Branch_Guidelines (Note: Qt module repositories >> don't have a "master" branch) >> >> Right now, the branches that accept documentation fixes are: >> >> * 5.8 (stable branch) >> * 5.9 (next release branch) >> * dev (development branch) >> >> Simply put, patches will merge from the top of the list to the bottom >> of this list. For example, patches that go into "5.8" will eventually >> be merged into "5.9", which in turn will eventually be merged into >> "dev". >> >> Typo fixes are not new features or major/risky changes, so they can go >> into the stable branch ("5.8"). > > Indeed. This is all being formalised in QUIP 5: > https://codereview.qt-project.org/178906 > where you can find out all you wish to know about which changes should > go to which branches, Thanks both of you for the information. Chris > > Eddy. From lars.knoll at qt.io Wed Feb 8 10:46:36 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 8 Feb 2017 09:46:36 +0000 Subject: [Development] CI stability Message-ID: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> Hi everybody, I guess all of you know the frustration about not getting your change in because an unrelated autotest failed, or due to changes in other modules breaking things for you. After quite a few discussions, we’ve now decided that we will try to tackle this and hopefully make the whole process smoother in the longer term. The most important item is that our CI system is never blocked, so that we all can get our patches and bug fixes in as smoothly and quickly as possible. We need to put a very high priority on any issue that prevents us from getting (valid) changes in. As a first item, I’d like to make it clear that reverting changes is something we should do more often. If a change is found to cause problems in other modules (like auto test failures), and the author of the change can’t fix it immediately (for whatever reason), it’s ok for anybody to revert those changes. In that case, simply re-open the corresponding bug and send the author of the problematic change an email explaining what you reverted and why. The second larger issue are flaky tests, ie. tests that fail randomly from time to time. These tests are causing huge issues in CI, and especially make qt5.git integrations that are required for releasing and to get updated packages very painful. The flakiness of the tests and also the flakiness in the CI system itself (which is a separate item for the team working on the CI) is one of the main reasons why releases are getting delayed. So we will try a new policy for those flaky tests from now on: Anybody who identifies a flaky test (ie. a test that is randomly failing in CI), can blacklist that test; under one condition. He needs to at the same time create a P0 bug report about it. Please also add the labels ‘autotest’ and ‘flaky’ to the bug report, so that we can follow up on those. Flaky tests might be badly written tests, but they can also hide real problems in Qt. So we need to have a very high priority for looking at them and keeping our blacklist minimal. Making them a P0 ensures that the issue will be looked quickly (as they will block the next release). Anybody who get’s one of those bug reports assigned please look at them immediately and try to see what’s going wrong. This is not always easy or straightforward, as they aren’t always reproducible outside the CI system. Here are a few pointers to help: Have a look at https://wiki.qt.io/Writing_good_tests , and check that the test is following the rules there. Often tests fail more easily under high load, so this is something to check as well. If you’re working for The Qt Company, you have the additional option of creating a VM inside the CI system or running test builds of a pushed change in the CI system. If you’re not working for TQtC, ask someone who does and we can schedule a build of any patch you push to gerrit inside the CI on the platform of your choice (with results being reported back to the gerrit change). If the test is flaky due to some external dependency (e.g. the network test server), you might want to file them as a subtask for getting a better test server in place and keep it blacklisted. In almost all other cases, you should try to fix the test (or the bug in Qt). If it's not possible to fix the test, think about how it could be rewritten. If the test is worthless (for example because it doesn’t test anything we haven’t covered in other ways), remove it. In any case, please handle those bug reports quickly, as said above they will block the release until handled. Please don’t down-prioritize these bugs reports without very good reasons (and talking to the module maintainer). I hope that as many people as possible will help in the effort. Fixing those flaky tests is quite some work right now, but in the longer term we will benefit us all when integrations go in more smoothly and we can more easily update qt5.git and get releases out. Cheers, Lars From edward.welbourne at qt.io Wed Feb 8 11:52:10 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Feb 2017 10:52:10 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <31699173.y30tuQOZWR@tjmaciei-mobl1> References: <3025657.bWAXI9RxFb@cartman> , <31699173.y30tuQOZWR@tjmaciei-mobl1> Message-ID: On terça-feira, 7 de fevereiro de 2017 12:03:47 PST Edward Welbourne wrote: >> Indeed, the "Becoming a Maintainer" section did in fact only permit >> us to nominate existing Approvers as Maintainers; which we have >> violated repeatedly. Thiago Macieira (7 February 2017 16:54) > I read that as nominating for maintainership and approvership at the > same time. ... which may well have been the intent, but the thing about Rules, Policies, Laws and Constitutions is that they have to actually *say* what they mean, else the wilful interpretations (usually with ulterior motives) get to make a mess (as The Real World never tires of demonstrating, usually in courts). Hence my fix to the page and the check that none here disagree (I guess any who *do* have about a fortnight to raise their objections, according to our Lazy Consensus model), Eddy. From olivier at woboq.com Wed Feb 8 12:18:31 2017 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 08 Feb 2017 12:18:31 +0100 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: References: <3025657.bWAXI9RxFb@cartman> <31699173.y30tuQOZWR@tjmaciei-mobl1> Message-ID: <11725134.zOMsPWvBVC@maurice> On Mittwoch, 8. Februar 2017 10:52:10 CET Edward Welbourne wrote: > ... which may well have been the intent, but the thing about Rules, > Policies, Laws and Constitutions is that they have to actually *say* > what they mean, And you can say the same about the code in any programming language. > else the wilful interpretations (usually with ulterior > motives) get to make a mess (as The Real World never tires of > demonstrating, usually in courts). ... or the wilful interpretation by the compiler get to make a mess. (Don't trigger undefined behavior.) :-) From robert.loehning at qt.io Wed Feb 8 14:20:39 2017 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Wed, 8 Feb 2017 14:20:39 +0100 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: References: <3025657.bWAXI9RxFb@cartman> <5153888.NmrKWlxPQI@cartman> <0cc37cb85f80c242d8b32100f9a6b3e5@kdab.com> Message-ID: <13b76e6b-5e66-aff7-97bd-00ae872a204c@qt.io> Am 07.02.2017 um 13:03 schrieb Edward Welbourne: > Lars Knoll (7 February 2017 12:45) wrote: >> The way we have been drawing our governance model as a pyramid had >> always implied this for me. But I can see that it’s not explicitly >> mentioned in the wiki page. > > Indeed, the "Becoming a Maintainer" section did in fact only permit us > to nominate existing Approvers as Maintainers; which we have violated > repeatedly. > >> Let's add a sentence to the wiki page for the maintainers section. And >> yes, it would be good to turn the governance model into a QUIP :) > > Here's my change to the Wiki page: > https://wiki.qt.io/index.php?title=The_Qt_Governance_Model&diff=29866&oldid=29555 > > I doubt I'll get round to QUIPping it any time soon - any volunteers ? > > Eddy. Hi Eddy, isn't https://codereview.qt-project.org/176903 what you're looking for? Cheers, Robert From edward.welbourne at qt.io Wed Feb 8 14:30:54 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Feb 2017 13:30:54 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <13b76e6b-5e66-aff7-97bd-00ae872a204c@qt.io> References: <3025657.bWAXI9RxFb@cartman> <5153888.NmrKWlxPQI@cartman> <0cc37cb85f80c242d8b32100f9a6b3e5@kdab.com> , <13b76e6b-5e66-aff7-97bd-00ae872a204c@qt.io> Message-ID: Am 07.02.2017 um 13:03 schrieb Edward Welbourne: [snip] >> Here's my change to the Wiki page: >> https://wiki.qt.io/index.php?title=The_Qt_Governance_Model&diff=29866&oldid=29555 >> >> I doubt I'll get round to QUIPping it any time soon - any volunteers ? Robert Löhning (8 February 2017 14:20) replied: > isn't > https://codereview.qt-project.org/176903 > what you're looking for? Indeed it is - and with all the recent flood of reviews, I'd quite forgotten all about it - thanks for the reminder ;-) Which seems like a good moment to encourage all on this list to take a look at QUIP 2 and exercise your Lazy Consensus powers ... by saying nothing if you're happy with it and suggesting improvements otherwise, Eddy. From edward.welbourne at qt.io Wed Feb 8 15:50:07 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Feb 2017 14:50:07 +0000 Subject: [Development] Calendar Systems proposal In-Reply-To: <1485810203.2838450.864653776.00F11FBC@webmail.messagingengine.com> References: <1485771647.2693050.863925144.679BECDA@webmail.messagingengine.com> , <1485810203.2838450.864653776.00F11FBC@webmail.messagingengine.com> Message-ID: Sorry to have left this thread dangling for so long. A vast flood of code-review came my way ... Now to work my way back through the thread, staring at the end, so all in JavaScript land: On Mon, Jan 30, 2017, at 09:07 PM, Hamed Masafi wrote: >> My prefer option is form (3) >> We can add an enumeration to global space. >> var date = new Date; >> var out = date.toString(Qt.JalaliCalendar, "yyyy-MM-dd"); Robin Burchell (30 January 2017 22:03) replied: > I would prefer to not modify standard APIs if we can avoid it (unless we > have a good reason to do so and such a change is pretty low risk). > Keeping close to the rest of the JS ecosystem means that skills learned > in one place are easily translated to another (meaning less > QJSEngine-specific knowledge and docs are required). In the particular > case of Date.prototype.toString(), it also means that should any future > specification start supporting additional arguments there, we aren't > going to open ourselves up to future unexpected problems. Indeed; we should keep our ECMAScript (i.e. JavaScript) implementation as clean as we can. If we *do* want to extend, we should do it via properties of the Qt object, not the global object. So var date = new Date; var out = Qt.Calendar('Jalali').dateToString(date, 'yyyy-MM-dd') would be a more apt model for what to aim for. >> > Have you considered whether Date.prototype.toLocaleDateString could be >> > of use for this? See: >> > >> http://ecma-international.org/ecma-402/3.0/index.html#sup-date.prototype.tolocaledatestring >> Date.prototype.toLocaleDateString is used to converting date to a string >> bases on a Locale. and, just to be clear here, a Locale is a string or list of strings, not to be confused with one of Qt's locale objects, although V4 does in fact accept one of *those* - in violation of the ECMA spec (see below). >> we can use this function for accepting an CalendarType >> (CalendarType is a QEnum that contains list of calendar types like; >> gregorian, jalali, hindi or etc) >> date.toLocaleString(format); >> date.toLocaleString(CalendarType, format); >> date.toLocaleString(locale, format); >> date.toLocaleString(CalendarType, locale, format); > Right, if you look at the spec I linked you to, that's what it > specifies- converting a date to a string in a locale-specific way. They > don't use an enum, but a string to describe the calendar system (plus > some additional options to control the formatting result in an > additional optional parameter). I can admit the spec is a bit hard to > read. Here's a slightly less formal description, with some examples: > > https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString Thanks for that. I'd read the spec and been left none the wiser. So we should expect the locale argument to be a string (or an array of strings, each of) which looks like a language code (hyphen-joined sequence of tokens) and may include -u-ca-... tokens indicating a selection of calendar. So var out = date.toLocaleDateString('ar-EG-u-ca-persian') should also be suitable. > If you want to see it in action, in a browser, try something like this > in a web browser JS console: > > console.log(new Date().toLocaleDateString("ar-EG")) > > I see: > > ٣٠‏/١‏/٢٠١٧ > > Which I hope is something useful/meaningful, I'm unfortunately not > familiar enough with that locale to tell. I've confirmed this to work in > recent releases of Safari, Firefox and Chrome on OS X. Outside of > browsers, YMMV. I didn't get Nodejs to respect the locale options, for > instance. > > What we implement now is nothing close to this (in fact, we simply > ignore all arguments and return the argument using local formatting) - > my guess is that it is down to most of this being added after ES5. ECMA-262 explicitly forbids [*] extending toLocaleString(), toLocaleTimeString() and toLocaleDateString() in any way other than as described in ECMA-402, which adds the locale and options. So we conform to the old spec in so far as we ignore the parameters (but see QTBUG-56923; for whose worst deviations I have a partial fix awaiting review). [*] http://www.ecma-international.org/ecma-262/7.0/index.html#sec-forbidden-extensions >> But there are some bugs related to this prototype, We have to solve that >> within this process. > As I said, as it stands, our implementation is currently not doing what > you need - it would need to be fleshed out to actually use the provided > arguments. However, I think that extending this seems to be a pretty > good match for the functionality you are wanting to add? That's also my impression; if we implement ECMA-402's locale extensions, including calendar support, I think we get most of the way to what Soroush and Hamed are after. We just need the infrastructure in Qt on which to build the V4 extensions (conformant to ECMA-402). For which I need to answer earlier mails ... Eddy. From edward.welbourne at qt.io Wed Feb 8 16:42:47 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Feb 2017 15:42:47 +0000 Subject: [Development] Calendar Systems proposal In-Reply-To: References: , Message-ID: Soroush Rabiei (30 January 2017 11:04) wrote: > Speaking of the API, I wish to share an idea about not to put calendar > implementations in a plugin subsystem. I should clarify: when I spoke of calendar systems in plugins, I wasn't suggesting we should do that as the normal mode for commonly-used calendars. I prefer an instance-based system (over an enum-based one) because it allows third parties to define a mechanism to support calendar customisation, which might for example use a plugin. However, the usual way of using the API would indeed be to instantiate a calendar system provided either by Qt or by the application built on Qt. > There are differences between those concepts that are implemented as > plugins and calendars. A calendar system is not an image format nor a > database implementation. It is, however, something that each user typically only wants one or a few of, despite there being many more for which they have no use. That, to me, is the decisive place where a plugin architecture is a win; spare users the bloat of the ones they don't need, while supporting those most users do need and making it easy to have others as needed. > There will be no new calendar (at least, it's unlikely to have a brand > new calendar) and there will be no newer versions of existing > calendars. What is the point of having calendars as plugins? There are, however, existing calendars with more variations than we shall be happy to support: for example, the Islamic calendar, when implemented strictly by astronomic observation, has a different variant for each location, albeit with only minor variations. We can *allow* for those who want (for whatever reason) to follow this for their location, without having to actually support them ourselves. They can subclass our Islamic calendar class (which shall provide the relevant locale-specific details and generic structure), apply their tweaks and have the calendar they want. This does also mean that we can initially support a small sub-set of calendar systems and wait for contributors to supply the rest, rather than feeling obliged to implement a dozen or more different calendar systems ourselves at the outset - for each of which we'd need to do significant research (and we'd probably get some of them wrong). > And we have to keep QGregorianCalendar everywhere after > all... And we will have the problem of instantiation. While plugins > have no public header, then how we are supposed to use them in code? > Like this: > > QDate d; > d.setDate(y,m,d,QCalendar::fromName("jalali")); > > Or maybe: > > d.setDate(y,m,d,"jalali"); > > Let's add all calendar systems that do have locale information in > CLDR, That's probably more work than we want to do - how familiar are you with the algorithms for computation of the different calendar systems ? I'm sure we can look each up on Wikipedia - and *most* of them shall have sufficiently well-established algorithms for mapping to and from Julian day number that we can implement them; but, even so, it's going to take a pile of work to do that; and lack of someone familiar with a calendar is apt to leave us innocently making embarrassing mistakes. Better to make it easy for others to contribute the ones they care about, while we implement the ones we know. > and make all of them configurable as to be built or not, except > QGregorianCalendar. Then decide on a default subset of calendars to be > compiled into qtbase. That will be something like: > > +----+-----------------+--------------------+------------+--------+ > |No. |Name |Variant |Configurable|Default | > +----+-----------------+--------------------+------------+--------+ > |1 |Gregorian | |No |Yes | > +----+-----------------+--------------------+------------+--------+ > |2 |Islamic |Astronomical |Yes |No | > +----+-----------------+--------------------+------------+--------+ > |3 |Islamic |Civil (Algorithmic) |Yes |Yes | > +----+-----------------+--------------------+------------+--------+ > |4 |Persian | |Yes |Yes | > +----+-----------------+--------------------+------------+--------+ > |5 |Hebrew | |Yes |Yes | > +----+-----------------+--------------------+------------+--------+ > |6 |Chinese | |Yes |Yes | > +----+-----------------+--------------------+------------+--------+ > |7 |Japanese | |Yes |No | > +----+-----------------+--------------------+------------+--------+ > |8 |Buddhist | |Yes |No | > +----+-----------------+--------------------+------------+--------+ > |9 |Republic of China| |Yes |No | > +----+-----------------+--------------------+------------+--------+ > |10 |Coptic | |Yes |No | > +----+-----------------+--------------------+------------+--------+ > |11 |Ethiopic |Amete Alem |Yes |No | > +----+-----------------+--------------------+------------+--------+ > |12 |Ethiopic |Amete Mihret |Yes |No | > +----+-----------------+--------------------+------------+--------+ > |13 |Indian | |Yes |No | > +----+-----------------+--------------------+------------+--------+ For reference, the Mozilla documentation Robin helpfully linked lists these fourteen calendars: "buddhist", "chinese", "coptic", "ethioaa", "ethiopic", "gregory", "hebrew", "indian", "islamic", "islamicc", "iso8601", "japanese", "persian", "roc". https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleDateString Once you've got five added, it's within a factor of three more to get all of those listed; if adding five is affordable, adding all probably is, too. I'd be inclined to make Gregorian-only the default, but we should definitely make it easy to select, at configure-time, any subset of those available, including "all". As Gregorian is needed for basic QDate, it's not optional or configurable. > For historical calendars, Qt users are unlikely to add marginal > calendar systems -> A reason to avoid plugin system. Though having > current schema, they can subclass QAbstractCalendar and add their > calendar (not as a loadable plugin) in their own code. The thing about "unlikely" is that *each* user being unlikely to need a marginal calendar doesn't get us away from there being many users, hence *some* who do that unlikely thing - or who *wish they could* but, since none of the software at their disposal lets them, suffer without. Historians, for example, may find it very useful to be able to view a calendar that faithfully represents what the era and folk they study used; there shall be few such users of each obsolete calendar, to be sure, but the thing about long tails is that, when you sum up the tiny group-sizes of many small constituencies with eccentric needs, you may be surprised by how many they come to in total. The other issue with a long tail is making the call about where to make the cut - do we really want to include all three Ethiopian calendars (Coptic being also from Ethiopia) when we probably don't have large numbers of Ethiopian users ? I note that you leave out the Julian calendar: yet Eastern Orthodox Christians still use it - shouldn't we include it ? If we support a few while making it easy for applications to support more, and easy for users to contribute ones we lack, we don't impose our culturally-biased decisions about "who matters more" on our users. We just support the calendars for which we have active contributors willing to serve as maintainers, while leaving the door open to the rest. So, to reiterate: we don't need to invent a plugin architecture; we just need to use an instance-based model - then a third party who *wants to* has the option of (defining their own plugin API and) accepting plugins; while applications that want to build in a calendar we don't support can do so; and *we* only need to support as many as we actually have a maintainer familiar with. Eddy. From edward.welbourne at qt.io Wed Feb 8 17:04:37 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 8 Feb 2017 16:04:37 +0000 Subject: [Development] Calendar Systems proposal In-Reply-To: References: <1485771647.2693050.863925144.679BECDA@webmail.messagingengine.com>, Message-ID: I had remarked: >> That shall complement Soroush Rabiei's work on the C++ side: Hamed Masafi (30 January 2017 21:07) replied: > Yes, that's right. I'm trying to port Soroush's calendar mechanism to > qml side of Qt. Good. >> If I understand Lars correctly, he prefers an API where the calendar >> object carries methods that act on a date and any further arguments >> it may need (similar to QLocale), so cal.toString(date, "yyyy-MM-dd") >> is more likely (although I personally like the style of API you give >> above, where the date object has the calendar-aware methods; too many >> of the details are the same between calendar systems). Aside from >> that, this is roughly the shape the C++ API shall have, making it a >> natural model for the QML to follow. > I'm not sure we can add an global type to script engine that are not > in ecma script. >From what I've now understood of ECMA-402, we can do much of this via the Date.toLocaleString() family of APIs, without non-ECMA types in our engine. It remains that we have a Qt object to which we can reasonably add things for use by QML - if we feel the need for it. >> Not sure what you're proposing here - you don't mention Qt.calendar >> in the code example, which looks more like 1) with JalaliCalendar >> moved to the Qt object - which may indeed be a better place for it >> than as a naked global object. > No; in this case Qt.JalaliCalendar is a QEnum and not an object (my > suggestion explained below) As explained elsewhere, I prefer an instance-based calendar system over an enum-based one *in C++*. However, from V4's perspective, that shall all be hidden inside QML's implementation and we'll most likely access it via names. An instance-based model can handle that by providing some way for the classes defining the instances we use in C++ to also tell the QML engine to associate them with a suitable name, e.g. 'Jalali', possibly with an alias mechanism - since Date.toLocaleString needs us to also recognise 'Persian' as referring to that. >> I don't know what rules QML might impose. Each of these would, in >> one way or another, require the calendar system code to register >> itself in some way with QML, associated with the name by which QML is >> to refer to it. The details of whether that name is in the namespace >> of some visible object (the ECMAScript global object or the Qt >> object) or in some internal mapping (for 2) are a matter of what's >> practical or convenient - someone with more QML fu than I can claim >> can advise you better there. > My prefer option is form (3) > We can add an enumeration to global space. > var date = new Date; > var out = date.toString(Qt.JalaliCalendar, "yyyy-MM-dd"); At the level of QML, this works fine; it's just another binding of a string to the underlying implementation of the calendar system. We shall need toLocale(|Date|Time)String(locale, options) to also know a binding to the u-ca-* fragments in locale. However, adapting the ECMA-262 Date.toString() to take such an enum would present compatibility problems; better to handle this within the ECMA-402 locale framework, as discussed earlier. > I think to continue we must conclusion on that calendar types must be > plugin or not? As discussed in my last mail, we don't need to actually do a plugin approach; the instance-based approach of Souroush's present work is just fine. Because third parties can sub-class QAbstractCalendar, they can do their own crazy things with plugins if they want, but we don't need to care about that. In QML, we can provide enum-like access to the calendar systems where we see a use for it; and we'll definitely need a string-based access in order to support date.toLocaleString() and its peers properly. Eddy. From marc.mutz at kdab.com Wed Feb 8 20:40:04 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 08 Feb 2017 20:40:04 +0100 Subject: [Development] =?utf-8?q?=5F=5Fhas=5Finclude_vs_GCC?= Message-ID: Hi, I just filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 complaining that __has_include returns true for headers which then, when included, #error out about the wrong C++ standard used. We use this mechanism for at least , and are either about to ship it or already do. That's fine since we compile at least in C++11 mode these days. I, however, intended to use the same feature for and , which don't seem to have SD-6 feature test macros (or else define them in the header which you're not allowed to include to check), but since we compile qmake only in C++11, not higher, this was greeted with an #error. How do other compilers/platforms behave? Thanks, Marc From thiago.macieira at intel.com Wed Feb 8 21:37:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Feb 2017 12:37:50 -0800 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: References: <3025657.bWAXI9RxFb@cartman> <31699173.y30tuQOZWR@tjmaciei-mobl1> Message-ID: <1753789.4Ziz7SGnSF@tjmaciei-mobl1> On quarta-feira, 8 de fevereiro de 2017 10:52:10 PST Edward Welbourne wrote: > ... which may well have been the intent, but the thing about Rules, > Policies, Laws and Constitutions is that they have to actually *say* > what they mean That's the difference between the Roman Civil Code / BGB-style laws and the Anglo-Saxon jurisprudence laws work. On one, you have to specifically say what you mean, otherwise it's outside the law; on the latter, the intent of the lawmarker is valid. :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Wed Feb 8 22:33:25 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 8 Feb 2017 22:33:25 +0100 Subject: [Development] __has_include vs GCC In-Reply-To: References: Message-ID: <829764e8-3711-c007-a630-afb8fc2806c6@kdab.com> Il 08/02/2017 20:40, Marc Mutz ha scritto: > I, however, intended to use the same feature for and > , which don't seem to have SD-6 feature test > macros (or else define them in the header which you're not allowed to > include to check), but since we compile qmake only in C++11, not higher, > this was greeted with an #error. Well, it smells that at least under GCC this would be the idiomatic way: #if __cplusplus > 201103L && __has_include() #include #endif (And > 201402L, i.e. post C++14, for string_view). Then again, you may argue that the presence of the header, even in the right C++ version, will not tell you if there's a #error "unimplemented" in there; this sounds like a silly game to play against the toolchain. Of course, MSVC does not bump __cplusplus (still 199711L). So perhaps those version checks need to become Qt macros? My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - 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 Wed Feb 8 23:43:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Feb 2017 14:43:50 -0800 Subject: [Development] __has_include vs GCC In-Reply-To: <829764e8-3711-c007-a630-afb8fc2806c6@kdab.com> References: <829764e8-3711-c007-a630-afb8fc2806c6@kdab.com> Message-ID: <3860477.OHS0D1QTSf@tjmaciei-mobl1> On quarta-feira, 8 de fevereiro de 2017 22:33:25 PST Giuseppe D'Angelo wrote: > Of course, MSVC does not bump __cplusplus (still 199711L). So perhaps > those version checks need to become Qt macros? I'd rather not and just suppress functionality until the compiler gets their act together. Our users should file bugs with their vendors instead to pressure them to change their way. I filed the __cplusplus one yesterday with ICC, when I noticed when running configure that it sayd "C++14..... no". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Feb 8 23:49:32 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Feb 2017 14:49:32 -0800 Subject: [Development] __has_include vs GCC In-Reply-To: References: Message-ID: <1925039.6XbXj7tfcE@tjmaciei-mobl1> On quarta-feira, 8 de fevereiro de 2017 20:40:04 PST Marc Mutz wrote: > Hi, > > I just filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 > complaining that __has_include returns true for headers which then, when > included, #error out about the wrong C++ standard used. I'm with you. SD-6 says that we should use __has_include to check if it exists, so I'd argue it shouldn't complain when we do it. > We use this mechanism for at least , and are either about to > ship it or already do. That's fine since we compile at least in C++11 > mode these days. > > I, however, intended to use the same feature for and > , which don't seem to have SD-6 feature test > macros (or else define them in the header which you're not allowed to > include to check), but since we compile qmake only in C++11, not higher, > this was greeted with an #error. > > How do other compilers/platforms behave? I don't think any of them check if the included file #errors out. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From steveire at gmail.com Thu Feb 9 00:52:03 2017 From: steveire at gmail.com (Stephen Kelly) Date: Wed, 08 Feb 2017 23:52:03 +0000 Subject: [Development] __has_include vs GCC References: Message-ID: Marc Mutz wrote: > Hi, > > I just filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 > complaining that __has_include returns true for headers which then, when > included, #error out about the wrong C++ standard used. In my opinion, the problem is sd-6 defining feature macros in the header that contains the implementation, instead of in a single header. There are many reasons not to do that, but the opinion of the chair is bonkers and no one else has an opinion: https://www.mail-archive.com/features at isocpp.open-std.org/msg00018.html https://www.mail-archive.com/features at isocpp.open-std.org/msg00162.html Thanks, Steve. From giuseppe.dangelo at kdab.com Thu Feb 9 01:11:18 2017 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 9 Feb 2017 01:11:18 +0100 Subject: [Development] __has_include vs GCC In-Reply-To: <3860477.OHS0D1QTSf@tjmaciei-mobl1> References: <829764e8-3711-c007-a630-afb8fc2806c6@kdab.com> <3860477.OHS0D1QTSf@tjmaciei-mobl1> Message-ID: <24372b57-daa7-1968-4469-2305af02e2d5@kdab.com> Il 08/02/2017 23:43, Thiago Macieira ha scritto: > I'd rather not and just suppress functionality until the compiler gets their > act together. Our users should file bugs with their vendors instead to pressure > them to change their way. They did and the result was a WONTFIX: > https://connect.microsoft.com/VisualStudio/feedback/details/763051/a-value-of-predefined-macro-cplusplus-is-still-199711l My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - 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 Thu Feb 9 02:16:50 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Feb 2017 17:16:50 -0800 Subject: [Development] __has_include vs GCC In-Reply-To: <24372b57-daa7-1968-4469-2305af02e2d5@kdab.com> References: <3860477.OHS0D1QTSf@tjmaciei-mobl1> <24372b57-daa7-1968-4469-2305af02e2d5@kdab.com> Message-ID: <2044494.NVjurlY3mE@tjmaciei-mobl1> On quinta-feira, 9 de fevereiro de 2017 01:11:18 PST Giuseppe D'Angelo wrote: > Il 08/02/2017 23:43, Thiago Macieira ha scritto: > > I'd rather not and just suppress functionality until the compiler gets > > their act together. Our users should file bugs with their vendors instead > > to pressure them to change their way. > > They did and the result was a WONTFIX: > > https://connect.microsoft.com/VisualStudio/feedback/details/763051/a-value > > -of-predefined-macro-cplusplus-is-still-199711l > My 2 c, That wasn't WONTFIX. That was "we'll fix it when we get the rest of C++11 done". I meant the SD-6 predefined macros: we want the compiler vendors to support them. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Feb 9 02:21:44 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 08 Feb 2017 17:21:44 -0800 Subject: [Development] __has_include vs GCC In-Reply-To: References: Message-ID: <10488187.CLAYKEkng1@tjmaciei-mobl1> On quarta-feira, 8 de fevereiro de 2017 23:52:03 PST Stephen Kelly wrote: > Marc Mutz wrote: > > Hi, > > > > I just filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79433 > > complaining that __has_include returns true for headers which then, when > > included, #error out about the wrong C++ standard used. > > In my opinion, the problem is sd-6 defining feature macros in the header > that contains the implementation, instead of in a single header. > > There are many reasons not to do that, but the opinion of the chair is > bonkers and no one else has an opinion: > > https://www.mail-archive.com/features at isocpp.open-std.org/msg00018.html > > https://www.mail-archive.com/features at isocpp.open-std.org/msg00162.html I don't agree with you, mostly because I don't understand what the issue is. And it's not the issue Marc is having. The way I see it, macros defined inside a file are not an issue, if the file has been there for 20 years. There's no harm in #include'ing it. Some features are the entire new file, so that's what #if __has_include is for. The issue Marc has is that the way to tell that a feature exist *is* the __has_include, but once you do that, you get an #error. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Feb 9 09:04:51 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Feb 2017 09:04:51 +0100 Subject: [Development] __has_include vs GCC In-Reply-To: References: Message-ID: <201702090904.51601.marc.mutz@kdab.com> Hi Steve, On Thursday 09 February 2017 00:52:03 Stephen Kelly wrote: > In my opinion, the problem is sd-6 defining feature macros in the header > that contains the implementation, instead of in a single header. Indeed, this would have been a valid _other_ way to do things: #include // contains all the __cpp_* macros, too #ifdef __cpp_lib_string_view # include // ... #endif #ifdef __cpp_lib_experimetal_string_view # include // ... #endif But the current version of SD-6 chose to use __has_include to check for headers (implying that they work, cf. example in https://isocpp.org/std/standing-documents/sd-6-sg10-feature-test- recommendations), and the __cpp_lib macros only for versioning of headers. These things are somewhat orthogonal, and I think the ship has sailed for central macro header approach. The issue at hand is that GCC squarely fails to conform to SD-6 re: __has_include. If it was conformant, I couldn't care less about in which header a __cpp_* macro was defined. I'd just conditionally include all of them and check macros at the end. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From lars.knoll at qt.io Thu Feb 9 10:05:23 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 9 Feb 2017 09:05:23 +0000 Subject: [Development] Request moving project (noron) to playground area In-Reply-To: References: Message-ID: <9C905C2E-95CA-4662-B47D-7248D06FFE5C@qt.io> Yes, please have a look at Qt Remote Objects, which has been a playground project for a while. Brett is currently working on upgrading this to a Technology Preview module for Qt. Before doing anything else with this module it’ll be good to understand what the overlap and differences between those modules are. Cheers, Lars > On 05 Feb 2017, at 11:16, Soroush Rabiei wrote: > > Greetings > > Good idea (: it would be great to have RPC integrated into Qt... > > There was a similar project (Qt Remote Objects was the name if I'm not > mistaken). Don't know the details, seems they are planning to provide > a transparent remote API around Qt's Signal/Slot mechanism... You may > want to have a look at it, or contact its developers: > > http://lists.qt-project.org/pipermail/development/2017-January/028282.html > > Cheers, > Soroush > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Thu Feb 9 10:41:05 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Feb 2017 10:41:05 +0100 Subject: [Development] Removing fromUtf8() fallback in QStringLiteral Message-ID: <201702091041.05516.marc.mutz@kdab.com> Hi, https://codereview.qt-project.org/185059 proposes to remove support for the fromUtf8() fallback of QStringLiteral, so we can finally guarantee that QStringLiteral use will not allocate memory and will not throw. I believe we can get away with it (see comment in change set for details) since 5.7 already, so I'd like to propose 1. To have this patch merged for 5.8 instead of dev 2. Failing that, to drop any platform (version) that does not provide Q_COMPILER_UNICODE_STRINGS from the supported list of compilers for 5.10. AFAICT, (2) could only possibly affect ICC and VxWorks. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From edward.welbourne at qt.io Thu Feb 9 10:48:28 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 9 Feb 2017 09:48:28 +0000 Subject: [Development] Nominate Mike Krus as approver In-Reply-To: <1753789.4Ziz7SGnSF@tjmaciei-mobl1> References: <3025657.bWAXI9RxFb@cartman> <31699173.y30tuQOZWR@tjmaciei-mobl1> , <1753789.4Ziz7SGnSF@tjmaciei-mobl1> Message-ID: On quarta-feira, 8 de fevereiro de 2017 10:52:10 PST Edward Welbourne wrote: >> ... which may well have been the intent, but the thing about Rules, >> Policies, Laws and Constitutions is that they have to actually *say* >> what they mean Thiago Macieira (8 February 2017 21:37) > That's the difference between the Roman Civil Code / BGB-style laws > and the Anglo-Saxon jurisprudence laws work. On one, you have to > specifically say what you mean, otherwise it's outside the law; on the > latter, the intent of the lawmarker is valid. :-) Only for as long as the lawmaker is available to consult, as to intent, and is a single person - if there's more than one, sooner or later, their differences of intent shall surface. Even then, if the intent of the lawmaker doesn't match the explicit wording of the law, a suspicion is apt to arise of partiality (i.e. the opposite of impartiality) whenever an appeal to the lawmaker's intent arises. It is better, thus, to refine the wording of the law, each time that intent is consulted, so that it more faithfully reflects the intent. Which we have just done. Furthermore, having the intent plainly stated in the law makes it easier for those who must follow it to be confident of which actions they may take within it and which would violate it. This is far better than leaving them to be surprised when they discover what they have done violates (the unstated intent of) a law they thought they had followed. Eddy. From marc.mutz at kdab.com Thu Feb 9 11:52:22 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Feb 2017 11:52:22 +0100 Subject: [Development] CI stability In-Reply-To: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> References: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> Message-ID: <201702091152.22510.marc.mutz@kdab.com> Hi Lars, On Wednesday 08 February 2017 10:46:36 Lars Knoll wrote: > Anybody who identifies a flaky test (ie. a test that is randomly failing in > CI), can blacklist that test; under one condition. He needs to at the same > time create a P0 bug report about it. Please also add the labels > ‘autotest’ and ‘flaky’ to the bug report, so that we can follow up on > those. A request for clarification: If a test fails on 5.8, it's clear: blacklist it in 5.8, too, backport to 5.6 as needed. What about 5.9 and dev? I'd push the blacklist to 5.8 if the test in question didn't change since 5.8, but maybe the implementation of the functionality did change and made the test flaky? Still submit to 5.8 or to the branch it was seen failing on, even if that means multiple identical commits to different branches down the line? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From a.volkov at rusbitech.ru Thu Feb 9 11:57:56 2017 From: a.volkov at rusbitech.ru (Alexander Volkov) Date: Thu, 9 Feb 2017 13:57:56 +0300 Subject: [Development] include/QtGui/QList header Message-ID: <17767e4e-18af-49f4-890c-145f7f077d14@rusbitech.ru> Hi all, The header include/QtGui/QList is created since Qt 5.8. It includes qevent.h and I guess this is because of https://codereview.qt-project.org/#/c/170513/ Who knows how to fix it? From marc.mutz at kdab.com Thu Feb 9 12:03:44 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Feb 2017 12:03:44 +0100 Subject: [Development] include/QtGui/QList header In-Reply-To: <17767e4e-18af-49f4-890c-145f7f077d14@rusbitech.ru> References: <17767e4e-18af-49f4-890c-145f7f077d14@rusbitech.ru> Message-ID: <201702091203.44250.marc.mutz@kdab.com> On Thursday 09 February 2017 11:57:56 Alexander Volkov wrote: > Hi all, > > The header include/QtGui/QList is created since Qt 5.8. > It includes qevent.h and I guess this is because of > https://codereview.qt-project.org/#/c/170513/ > Who knows how to fix it? - template <> class QList... + #define QT_HIDE_CLASS_FROM_SYNCQT_PL class + template <> QT_HIDE_CLASS_FROM_SYNCQT_PL QList... + #undef QT_HIDE_CLASS_FROM_SYNCQT_PL But I'd prefer if syncqt.pl was fixed instead. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From oswald.buddenhagen at qt.io Thu Feb 9 12:04:03 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 9 Feb 2017 12:04:03 +0100 Subject: [Development] include/QtGui/QList header In-Reply-To: <17767e4e-18af-49f4-890c-145f7f077d14@rusbitech.ru> References: <17767e4e-18af-49f4-890c-145f7f077d14@rusbitech.ru> Message-ID: <20170209110403.GC23393@troll08> On Thu, Feb 09, 2017 at 01:57:56PM +0300, Alexander Volkov wrote: > The header include/QtGui/QList is created since Qt 5.8. > It includes qevent.h and I guess this is because of > https://codereview.qt-project.org/#/c/170513/ > Who knows how to fix it? > failing to fix the parser (which may be tricky, but give it a shot), declare an explicit override in sync.profile. From lars.knoll at qt.io Thu Feb 9 12:40:35 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 9 Feb 2017 11:40:35 +0000 Subject: [Development] CI stability In-Reply-To: <201702091152.22510.marc.mutz@kdab.com> References: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> <201702091152.22510.marc.mutz@kdab.com> Message-ID: <31266087-FA00-4381-9627-AD75AA186CCA@qt.io> > On 09 Feb 2017, at 11:52, Marc Mutz wrote: > > Hi Lars, > > On Wednesday 08 February 2017 10:46:36 Lars Knoll wrote: >> Anybody who identifies a flaky test (ie. a test that is randomly failing in >> CI), can blacklist that test; under one condition. He needs to at the same >> time create a P0 bug report about it. Please also add the labels >> ‘autotest’ and ‘flaky’ to the bug report, so that we can follow up on >> those. > > A request for clarification: > > If a test fails on 5.8, it's clear: blacklist it in 5.8, too, backport to 5.6 > as needed. > > What about 5.9 and dev? I'd push the blacklist to 5.8 if the test in question > didn't change since 5.8, but maybe the implementation of the functionality did > change and made the test flaky? > > Still submit to 5.8 or to the branch it was seen failing on, even if that > means multiple identical commits to different branches down the line? I’d say we push the branch we saw it failing on (but please feel free to do a quick check whether you can find it failing in 5.8 as well before pushing). That might imply that we get multiple changes, but we won’t lower our test coverage more than strictly required. Cheers, Lars From marc.mutz at kdab.com Thu Feb 9 13:04:41 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Feb 2017 13:04:41 +0100 Subject: [Development] CI stability In-Reply-To: <31266087-FA00-4381-9627-AD75AA186CCA@qt.io> References: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> <201702091152.22510.marc.mutz@kdab.com> <31266087-FA00-4381-9627-AD75AA186CCA@qt.io> Message-ID: <201702091304.41718.marc.mutz@kdab.com> On Thursday 09 February 2017 12:40:35 Lars Knoll wrote: [...] > I’d say we push the branch we saw it failing on (but please feel free to do > a quick check whether you can find it failing in 5.8 as well before > pushing). That might imply that we get multiple changes, but we won’t > lower our test coverage more than strictly required. Ok, case in point: tst_QSemaphore. Blacklisted already in 5.8, but apparently not yet merged up to 5.9 and dev, causing at least eight integrations to fail there since Jan 10th. Submit to 5.9 and dev, too, separately, or wait for 5.8 to be merged into 5.9 and then dev? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From Simon.Hausmann at qt.io Thu Feb 9 13:05:21 2017 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Thu, 9 Feb 2017 12:05:21 +0000 Subject: [Development] CI stability In-Reply-To: <201702091304.41718.marc.mutz@kdab.com> References: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> <201702091152.22510.marc.mutz@kdab.com> <31266087-FA00-4381-9627-AD75AA186CCA@qt.io>, <201702091304.41718.marc.mutz@kdab.com> Message-ID: Hi, I don't see any modification to the test exclusion list of tst_QSempaphore (in tests/auto/corelib/thread/qsemaphore) that isn't merged all the way up to dev. The last one was from me back in June last year. The merge of qtbase from 5.8 to 5.9 went through this morning. Did you mean another class perhaps? Simon ________________________________ From: Development on behalf of Marc Mutz Sent: Thursday, February 9, 2017 1:04:41 PM To: Qt development mailing list Subject: Re: [Development] CI stability On Thursday 09 February 2017 12:40:35 Lars Knoll wrote: [...] > I’d say we push the branch we saw it failing on (but please feel free to do > a quick check whether you can find it failing in 5.8 as well before > pushing). That might imply that we get multiple changes, but we won’t > lower our test coverage more than strictly required. Ok, case in point: tst_QSemaphore. Blacklisted already in 5.8, but apparently not yet merged up to 5.9 and dev, causing at least eight integrations to fail there since Jan 10th. Submit to 5.9 and dev, too, separately, or wait for 5.8 to be merged into 5.9 and then dev? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Thu Feb 9 13:11:14 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Feb 2017 13:11:14 +0100 Subject: [Development] CI stability In-Reply-To: <201702091304.41718.marc.mutz@kdab.com> References: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> <31266087-FA00-4381-9627-AD75AA186CCA@qt.io> <201702091304.41718.marc.mutz@kdab.com> Message-ID: <201702091311.14919.marc.mutz@kdab.com> On Thursday 09 February 2017 13:04:41 Marc Mutz wrote: > On Thursday 09 February 2017 12:40:35 Lars Knoll wrote: > [...] > > > I’d say we push the branch we saw it failing on (but please feel free to > > do a quick check whether you can find it failing in 5.8 as well before > > pushing). That might imply that we get multiple changes, but we won’t > > lower our test coverage more than strictly required. > > Ok, case in point: tst_QSemaphore. Blacklisted already in 5.8, but > apparently not yet merged up to 5.9 and dev, causing at least eight > integrations to fail there since Jan 10th. > > Submit to 5.9 and dev, too, separately, or wait for 5.8 to be merged into > 5.9 and then dev? Ok, https://codereview.qt-project.org/179427 attempted a fix, but it's incomplete. Will add a reduced blacklist to 5.9. Still: add to dev, too? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From oswald.buddenhagen at qt.io Thu Feb 9 13:11:45 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 9 Feb 2017 13:11:45 +0100 Subject: [Development] CI stability In-Reply-To: <201702091311.14919.marc.mutz@kdab.com> References: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> <31266087-FA00-4381-9627-AD75AA186CCA@qt.io> <201702091304.41718.marc.mutz@kdab.com> <201702091311.14919.marc.mutz@kdab.com> Message-ID: <20170209121145.GD23393@troll08> On Thu, Feb 09, 2017 at 01:11:14PM +0100, Marc Mutz wrote: > Still: add to dev, too? > no. that's an equivalent of a cherry-pick, and we don't do that. From lars.knoll at qt.io Thu Feb 9 13:19:21 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Thu, 9 Feb 2017 12:19:21 +0000 Subject: [Development] CI stability In-Reply-To: <20170209121145.GD23393@troll08> References: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> <31266087-FA00-4381-9627-AD75AA186CCA@qt.io> <201702091304.41718.marc.mutz@kdab.com> <201702091311.14919.marc.mutz@kdab.com> <20170209121145.GD23393@troll08> Message-ID: <8804F7C5-AB30-441B-B547-A30E390A947C@qt.io> > On 09 Feb 2017, at 13:11, Oswald Buddenhagen wrote: > > On Thu, Feb 09, 2017 at 01:11:14PM +0100, Marc Mutz wrote: >> Still: add to dev, too? >> > no. that's an equivalent of a cherry-pick, and we don't do that. Agree. If you need it in dev as well, we should simply do the required merge. Lars From rjvbertin at gmail.com Thu Feb 9 16:46:12 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2E__V=2E?= Bertin) Date: Thu, 09 Feb 2017 16:46:12 +0100 Subject: [Development] QtWE 5.8/linux: "Exception: Variants not supported in JavaScript bindings." Message-ID: <2976658.1hTikaWBlU@patux.local> Hello, Building QtWebEngine 5.8.0 against Qt 5.8.0 installed in /opt/local, where can the error below come from? An earlier build with the same configuration got further but failed on what looks like a confusion between a headerfile from the source tree and the installed QtWE 5.7.1 headers, so I removed the 5.7.1 install and started a clean QtWE build. Apologies for asking here, I have a DSL bandwidth problem that makes it impossible to use Google or even IMAP over SSL ... even KNode barely manages to connect. QtWE doesn't require full internet access while building, does it? That would explain why my earlier build got further. [22/7804] RULE Generating Mojo bindings from public/interfaces/chooser_service.mojom FAILED: gen/device/usb/public/interfaces/chooser_service.mojom-blink.cc gen/device/usb/public/interfaces/chooser_service.mojom-blink.h gen/device/usb/public/interfaces/chooser_service.mojom-blink-internal.h cd /path/to/work/qt-everywhere-opensource- src-5.8.0/qtwebengine/src/3rdparty/chromium/device/usb; python ../../mojo/public/tools/bindings/mojom_bindings_generator.py -- use_bundled_pylibs generate "./public/interfaces/chooser_service.mojom" -d ../.. -I../.. -I../../mojo/services -o /path/to/work/build/src/core/Release/gen "-- java_output_directory=/path/to/work/build/src/core/Release/java_mojo/device_usb_mojo_bindings_for_blink/src" --variant blink c++ --typemap /path/to/work/build/src/core/Release/gen/device/usb/device_usb_mojo_bindings_for_blink_type_mappings --for_blink --bytecode_path /path/to/work/build/src/core/Release/gen/mojo/public/tools/bindings Traceback (most recent call last): File "../../mojo/public/tools/bindings/mojom_bindings_generator.py", line 273, in sys.exit(main()) File "../../mojo/public/tools/bindings/mojom_bindings_generator.py", line 269, in main return args.func(args, remaining_args) File "../../mojo/public/tools/bindings/mojom_bindings_generator.py", line 206, in _Generate processor.ProcessFile(args, remaining_args, generator_modules, filename) File "../../mojo/public/tools/bindings/mojom_bindings_generator.py", line 111, in ProcessFile filename) File "../../mojo/public/tools/bindings/mojom_bindings_generator.py", line 153, in _GenerateModule generator.GenerateFiles(filtered_args) File "/path/to/work/qt-everywhere-opensource- src-5.8.0/qtwebengine/src/3rdparty/chromium/mojo/public/tools/bindings/generators/mojom_js_generator.py", line 397, in GenerateFiles raise Exception("Variants not supported in JavaScript bindings.") Exception: Variants not supported in JavaScript bindings. ninja: build stopped: subcommand failed. From marc.mutz at kdab.com Thu Feb 9 17:32:42 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Feb 2017 17:32:42 +0100 Subject: [Development] Removing fromUtf8() fallback in QStringLiteral In-Reply-To: <201702091041.05516.marc.mutz@kdab.com> References: <201702091041.05516.marc.mutz@kdab.com> Message-ID: <201702091732.42832.marc.mutz@kdab.com> On Thursday 09 February 2017 10:41:05 Marc Mutz wrote: > AFAICT, (2) could only possibly affect ICC and VxWorks. From the change set: - VxWorks uses GCC 4.8, that's enough. - The ICC minimum version since Qt 5.7 (cf. dist/changes-5._6_.0) is v14 (Unicode string literals were added for 12.1), so enough, too. For MSVC 2013, we have the wchar_t workaround (assuming all MSVC have sizeof(wchar_t) == 2? The ifdefs seem to suggest otherwise...). So, I'd like to propose this patch for 5.8, then (5.7 being closed and 5.6 not requiring enough compiler support). Thanks, Mard -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From olivier at woboq.com Thu Feb 9 18:14:47 2017 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 09 Feb 2017 18:14:47 +0100 Subject: [Development] Removing fromUtf8() fallback in QStringLiteral In-Reply-To: <201702091732.42832.marc.mutz@kdab.com> References: <201702091041.05516.marc.mutz@kdab.com> <201702091732.42832.marc.mutz@kdab.com> Message-ID: <2083442.QCySnYzGT4@maurice> On Donnerstag, 9. Februar 2017 17:32:42 CET Marc Mutz wrote: > On Thursday 09 February 2017 10:41:05 Marc Mutz wrote: > > AFAICT, (2) could only possibly affect ICC and VxWorks. > > From the change set: > > - VxWorks uses GCC 4.8, that's enough. > - The ICC minimum version since Qt 5.7 (cf. dist/changes-5._6_.0) is v14 > (Unicode string literals were added for 12.1), so enough, too. > > For MSVC 2013, we have the wchar_t workaround (assuming all MSVC have > sizeof(wchar_t) == 2? The ifdefs seem to suggest otherwise...). > > So, I'd like to propose this patch for 5.8, then (5.7 being closed and 5.6 > not requiring enough compiler support). If I look at the table from https://codereview.qt-project.org/178906 , it could be classified as "Using new C++ features" or "Enabling new compiler features" or "Refactoring: non-test code". Maybe to "Performance: Issue related to best practices", all of them point to "dev". Why do you think this change should go in another branch? Maybe it could be classified under "Bugs: Other", but i don't think it fixes a bug. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Thu Feb 9 18:38:32 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 09 Feb 2017 09:38:32 -0800 Subject: [Development] Removing fromUtf8() fallback in QStringLiteral In-Reply-To: <201702091041.05516.marc.mutz@kdab.com> References: <201702091041.05516.marc.mutz@kdab.com> Message-ID: <2651276.aeT55i6SsR@tjmaciei-mobl1> On quinta-feira, 9 de fevereiro de 2017 10:41:05 PST Marc Mutz wrote: > 1. To have this patch merged for 5.8 instead of dev I agree, because I consider that you're not changing behaviour. There should be no one left using the fromUtf8 branch. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Feb 9 18:40:45 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 09 Feb 2017 09:40:45 -0800 Subject: [Development] include/QtGui/QList header In-Reply-To: <20170209110403.GC23393@troll08> References: <17767e4e-18af-49f4-890c-145f7f077d14@rusbitech.ru> <20170209110403.GC23393@troll08> Message-ID: <2503428.xlGpeqah0l@tjmaciei-mobl1> On quinta-feira, 9 de fevereiro de 2017 12:04:03 PST Oswald Buddenhagen wrote: > > The header include/QtGui/QList is created since Qt 5.8. > > It includes qevent.h and I guess this is because of > > https://codereview.qt-project.org/#/c/170513/ > > Who knows how to fix it? > > failing to fix the parser (which may be tricky, but give it a shot), Shouldn't be too difficult to confirm that there's no < after the class name, which indicates a partial or full template specialisation. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Feb 9 18:42:34 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 09 Feb 2017 09:42:34 -0800 Subject: [Development] CI stability In-Reply-To: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> References: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> Message-ID: <2346930.SohvgVAlx7@tjmaciei-mobl1> On quarta-feira, 8 de fevereiro de 2017 09:46:36 PST Lars Knoll wrote: > The second larger issue are flaky tests, ie. tests that fail randomly from > time to time. These tests are causing huge issues in CI, and especially > make qt5.git integrations that are required for releasing and to get > updated packages very painful. The flakiness of the tests and also the > flakiness in the CI system itself (which is a separate item for the team > working on the CI) is one of the main reasons why releases are getting > delayed. Could we somehow fix the CI so that operations that take a couple of microseconds on a developer machines don't take 10000x more in the CI? I understand slow machines, but 4 or 5 orders of magnitude is not something we can account for. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Feb 9 20:06:06 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Feb 2017 20:06:06 +0100 Subject: [Development] Removing fromUtf8() fallback in QStringLiteral In-Reply-To: <2083442.QCySnYzGT4@maurice> References: <201702091041.05516.marc.mutz@kdab.com> <201702091732.42832.marc.mutz@kdab.com> <2083442.QCySnYzGT4@maurice> Message-ID: <201702092006.07030.marc.mutz@kdab.com> On Thursday 09 February 2017 18:14:47 Olivier Goffart wrote: > On Donnerstag, 9. Februar 2017 17:32:42 CET Marc Mutz wrote: > > On Thursday 09 February 2017 10:41:05 Marc Mutz wrote: > > > AFAICT, (2) could only possibly affect ICC and VxWorks. > > > > From the change set: > > > > - VxWorks uses GCC 4.8, that's enough. > > - The ICC minimum version since Qt 5.7 (cf. dist/changes-5._6_.0) is v14 > > > > (Unicode string literals were added for 12.1), so enough, too. > > > > For MSVC 2013, we have the wchar_t workaround (assuming all MSVC have > > sizeof(wchar_t) == 2? The ifdefs seem to suggest otherwise...). > > > > So, I'd like to propose this patch for 5.8, then (5.7 being closed and > > 5.6 not requiring enough compiler support). > > If I look at the table from https://codereview.qt-project.org/178906 , it > could be classified as "Using new C++ features" or "Enabling new compiler > features" or "Refactoring: non-test code". Maybe to "Performance: Issue > related to best practices", all of them point to "dev". > Why do you think this change should go in another branch? > > Maybe it could be classified under "Bugs: Other", but i don't think it > fixes a bug. For the vast majority of configurations, nothing will change. The only platform I'm aware of that that patch would change is QNX < 7. This platform has a compiler (GCC) capable of char16_t, but lacks stdlib support for it, presumably std::u16string etc. But QStringLiteral only needs the u"string" feature, which is a core language feature. So one could say that it's a fix for a serious performance bug for QStringLiteral on QNX. Fixing that allows us to up the guarantees for QStringLiteral: it will be non-allocating and nothrow on all supported platforms. I can rephrase the commit message to degrade this into a QNX-only fix, so it becomes acceptable for 5.8, but the fact that fixing the last platform to still use the fromUtf8() to not do so is, imho, better expressed as "drop the fromUtf8() fallback", because it has ramifications outside QNX code: QStringLiteral(...).constData() is now stable, e.g. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From kevin.kofler at chello.at Fri Feb 10 00:16:01 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 10 Feb 2017 00:16:01 +0100 Subject: [Development] Calendar Systems proposal References: Message-ID: Edward Welbourne wrote: > (Coptic being also from Ethiopia) Uh, no. Coptic is from Egypt. According to Wikipedia, "Its years and months coincide with those of the Ethiopian calendar but have different numbers and names." Kevin Kofler From lars.knoll at qt.io Fri Feb 10 10:47:20 2017 From: lars.knoll at qt.io (Lars Knoll) Date: Fri, 10 Feb 2017 09:47:20 +0000 Subject: [Development] CI stability In-Reply-To: <2346930.SohvgVAlx7@tjmaciei-mobl1> References: <9D28170D-900A-4D33-84C8-8C684A82E689@qt.io> <2346930.SohvgVAlx7@tjmaciei-mobl1> Message-ID: <5F6846A8-C25D-439A-ABF7-C10436AD3F87@qt.io> > On 09 Feb 2017, at 18:42, Thiago Macieira wrote: > > On quarta-feira, 8 de fevereiro de 2017 09:46:36 PST Lars Knoll wrote: >> The second larger issue are flaky tests, ie. tests that fail randomly from >> time to time. These tests are causing huge issues in CI, and especially >> make qt5.git integrations that are required for releasing and to get >> updated packages very painful. The flakiness of the tests and also the >> flakiness in the CI system itself (which is a separate item for the team >> working on the CI) is one of the main reasons why releases are getting >> delayed. > > Could we somehow fix the CI so that operations that take a couple of > microseconds on a developer machines don't take 10000x more in the CI? I > understand slow machines, but 4 or 5 orders of magnitude is not something we > can account for. We’ve tried. The main issue we’re seeing is that Windows machines are sometimes randomly hanging for extended time periods. So far we haven’t been able to figure out why. I hope that the scheduled changes in CI (moving to running on local disks instead of a SAN, and changing the virtualisation platform) will help, but we don’t yet know for sure. Cheers, Lars From edward.welbourne at qt.io Fri Feb 10 10:51:55 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 10 Feb 2017 09:51:55 +0000 Subject: [Development] Calendar Systems proposal In-Reply-To: References: <8680F22F-7B32-4DDD-9380-8EE517C10830@qt.io> <29088300.rDUCxivhrG@port-fma>, Message-ID: On Monday 02 January 2017 09:21:25 Lars Knoll wrote: >>> I wonder whether we can't keep handling of different calendars >>> completely outside of QDate. Something similar to what we've done >>> with QString/QLocale. So QDate would continue unchanged and only >>> support the standard Gregorian calendar. In addition, we have a >>> QCalendar class, that can be constructed with a different calendar >>> system, and can then return 'localized' date strings, days, months >>> and years for this calendar system. >>> >>> Something like: >>> >>> QDate date; >>> QCalendar c(QCalendar::Hebrew); >>> QString hebrewDateString = c.toString(date); >>> int hebrewYear = c.year(date); >>> >>> Maybe one could even integrate this into QLocale, that already provides >>> support for localized month and day names? The current work actually moves QLocale's calendar-related data *out* to the calendar system classes - a step towards the dismembering of QLocle that was contemplated some years ago, but on which no progress appears to have been made. This separation is one of the particularly satisfying results of Soroush's work. Choice of calendar system is (kinda) orthogonal to choice of locale, anyway, so the calendar data doesn't belong in the QLocale (which only knows about language, script and country, although we *could* teach QLocale(const QString &) to parse more complications out of a string - I doubt that'd be a win). Note, by the way, that the locale data is the *only* data in most calendar system classes, handled as globals (as in QLocale) of the class's compilation unit. Calendar objects themselves are usually entirely algorithmic - they have no data members, just a vtable - although one can conceive of eccentric ones (that we aren't about to implement, but client code might) that could conceivably have member data (e.g. a historian might use a hybrid Julian/Gregorian calendar with one datum, the Julian day number at which to make the transition between the two; the class for that could be instantiated with different transition dates for the various jurisdictions that switched at different dates). On 02/01/17 12:01, "Frédéric Marchal" wrote: >> There is more to it than converting a date to a string: >> >> * Add N days to a date. >> * Find the number of days in a month. >> * Compare two dates. >> * Count the number of days between two dates. >> >> For instance a program wishing a happy new year to its users should >> do it with as little modifications as possible. >> >> Using a plain QDate would have been the easiest way to reach more >> users because it doesn't require to replace lots of QDate with a new, >> very similar, class. As it is not possible to change QDate for now, >> Soroush is looking for a temporary solution that would bridge the gap >> until Qt6 is out. Lars Knoll (2 January 2017 12:39) followed up with: > Sure, that there’s more to do than just the examples I listed. Still, > design wise it might be a good idea to have this functionality in a > class separate from QDate. We’ve done the same design decision for > QString (having no locale specific functionality in QString), and this > worked out rather nicely. So I would encourage you to have a look > whether and how a similar design could be done for calendar system > support. Actually, I do indeed want to move calendaring information - notably that of the Gregorian calendar - out of QDate; even though QDate must surely use Gregorian by default, moving the Gregorian logic (already largely separated into static functions) out makes the QDate class more straightforward. That actually leaves little in QDate itself; and what it does leave can readily be made calendar-system agnostic, although it manipulates a calendar-system object to do the work. So making Gregorian the default in APIs that take a calendar system is in fact a simplification of QDate, where I suppose locale-support complicated QString and its removal simplified. One big reason for wanting to integrate calendar into QDate is that, without it, the overhead of supporting alternate calendars in any app involves re-writing the app, reducing all use of QDate to a mere carrier for its ->toJulianDay(). With QDate taking a calendar object (that defaults Gregorian), it's fairly easy and painless to integrate calendar support into an app. This is rather well illustrated by Soroush's most recent patch-set (11), which extends QCalendarWidget to have QAbstractCalendar member (that, of course, shall default Gregorian), which it duly passes to each QDate method: https://codereview.qt-project.org#/c/182341/11/src/widgets/widgets/qcalendarwidget.cpp,unified This is easy, straightforward and natural; one can readily see that it's correct. (The one wrinkle, QCalendarModel::referenceDate(), being due to the existing comment looking suspiciously bogus, see my comments in Gerrit; search for "Oct 1582" on PS 11.) Now contrast this with what happens if we keep calendar systems out of QDate. There's a basic level of conversion that would go just as straightforwardly - transforming date->method(args) into cal->method(date, args) in most cases - but then there are places where the code needs to add days or jump to the start of the week, month or year, e.g. QCalendarView::moveCursor(). The calendar API can surely have the methods to do that - but, if it does so, the calendar systems would all be doing the same thing as QDate, so we'd end up with concrete methods of QAbstractCalendar (to avoid duplicating *between* systems), each of which duplicates code in a matching QDate method. We could eliminate this duplication by rewriting each QDate method as ret QDate::method(args) { return QGregorianCalendar().method(this, args); } or, indeed, for get-ish things ret QDate::method(args) { return QGregorianCalendar().method(this->toJulianDay(), args); } and, for set-ish things, void QDate::setThing(args) { this->fromJulianDay(QGregorianCalendar()->julianDayFromThing(args)); } possibly with a this->toJulianDay() added to the args, as needed. What bothers me about this is that, at this point, I see no value left in QDate. It would just be a cumbersome way to package a Julian day number - as the last two illustrate - that code using calendar systems other than Gregorian would be obliged to go via in order to interact with the rest of Qt. That's actually worse than no value: it's an obstacle to adding support for other calendars in apps using Qt. QDate is the natural place for the algorithms that would, in this scenario, be carried by QAbstractCalendar's non-abstract methods - they are *date* manipulations, though they need to consult a calendar to work out what to do, not *calendar* manipulations or conversions. Now, as it happens, QDate's relevant methods at present mostly call out to local static functions that would inevitably become methods of QGregorianCalendar (and the exceptions inline relevant code in a QDate method, duplicating what would be in QGregorianCalendar), making it natural to implement them by having a local instance of that calendar class in each method, so as to call its methods. Once we do that, though, the stop to having that instance come in as a parameter (that defaults to a QGregorianCalendar instance) is very low indeed. As a result, integrating calendar support into QDate would actually be more natural than separating it - it would intrude scarcely at all into the implementations (once re-written to use a QGregorianCalendar, to save duplication) while being the natural way to share date-manipulation code that would otherwise have to live in QAbstractCalendar, either as a duplicate of QDate's code or as what QDate code ends up calling to do a job that more naturally belongs to QDate, Eddy. From schnitzeltony at googlemail.com Fri Feb 10 11:19:14 2017 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Fri, 10 Feb 2017 11:19:14 +0100 Subject: [Development] Qt5.8 qdbuscpp2xml broken for kde baloo? Message-ID: Hi, I am cross building Qt and KDE with yocto environment. After Update to Qt 5.8 the package baloo from KDE KF5 is broken. After investigation I found that qdbuscpp2xml 5.8 build misses some public slots. I get for Qt5.8 build by yocto: qdbuscpp2xml -a filecontentindexer.h Unregistered input type in parameter list: QDBusMessage Unregistered input type in parameter list: QDBusMessage On my local fedora Qt5.7.1 qdbuscpp2xml -a filecontentindexer.h You can see that qdbuscpp2xml complains for unregistered QDBusMessage and the slots 'registerMonitor' and 'unregisterMonitor' having QDBusMessage in parameter are missing. Since yocto builds also native qdbuscpp2xml it might be possible that there is something missing for qdbuscpp2xml. Pointers how to get around or even confirmation of a bug are welcome - baloo's filecontentindexer.h is attached Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: filecontentindexer.h Type: text/x-chdr Size: 2417 bytes Desc: not available URL: From tuukka.turunen at qt.io Fri Feb 10 11:59:56 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 10 Feb 2017 10:59:56 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 Message-ID: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> Hi, Short summary: The Qt Company has decided to focus development effort to 5.9 and dev branches in order to reach the planned timeline for Qt 5.9 release and make improvements in the CI system. Next scheduled patch level release would be Qt 5.6.3 straight after Qt 5.9 is out. In case of severe security vulnerability we would make Qt 5.8.1 directly based on 5.8.0 with just the security fix(es) added. Qt 5.8.0 looks to be a good and successful release. It has already been downloaded 150.000 times even though it was released just two weeks ago. The reception has been good overall and there are no blockers reported based on the release. Qt 5.9 and subsequent releases will leverage the new configuration system and other major improvements introduced with it, as well as add new functionality to make Qt even better. It took us a more time than planned to get Qt 5.8 out and because of that we are already past Qt 5.9 feature freeze and approaching the alpha release soon. Looking into the reasons why Qt 5.8.0 was delayed there are 3 items that had a significant effect: 1. We did not keep the feature freeze properly as there were some items we wanted to get in – doing so we should have replanned the whole release time, but we tried to keep schedule and failed. 2. We were not able to focus enough to Qt 5.8 finalization as there was quite a lot of effort going still to Qt 5.6.x and 5.7.x patch releases in parallel – and our systems and processes are not yet good enough for this. 3. We have had some issues in the CI system that cause integrations to fail and thus increase system load – these are now being addressed (getting new HW in place, change to a better virtualization platform, use local disks instead of central disk, reduce number of flaky tests, etc). We believe it will be possible to significantly reduce the time from feature freeze to release. To reach this we need to improve the items that have been problematic with Qt 5.8 and other releases. After we have done the improvements, it will be easier to keep the timelines and also be more productive. We absolutely do not want to rush a new release out with severe bugs in it – not now and not in the future – for this reason we want to focus into the processes and systems part and allow more efficient release creation. First we want to be able to reach the current 17 weeks timeline from FF to release with Qt 5.9. After that we want to reduce it gradually to 10-12 weeks (for a new minor release of Qt). Increased productivity will allow us to make more patch releases than before. In the CI system side we have major improvements happening during this year. We will be purchasing more blades and other HW during H1/17, which will add capacity, so we will be able to run more parallel integrations. We are also looking into changing the system architecture away from central disk into using local ssd for build machines. This is expected to bring improvements to both performance and reliability (especially now as we have had issues with disks failing despite the disk system still being in the mid of its life-cycle). Third item we are looking into is change of the virtualization platform, which we hope will bring improvements in stability as well as new capabilities. Arranging enough time to implement the improvements in our systems as well as keeping the timeline of Qt 5.9 despite delayed 5.8 release unfortunately means that we can’t make any scheduled patch releases until June, after Qt 5.9 is out. We will keep the ability to release patch release for urgent security vulnerabilities, as always. Such release would be on top of the previous patch release and not include all other changes in the corresponding branch. Even with a lot more help from community than before, making a scheduled Qt 5.8.1 release parallel with Qt 5.9 has impact to the system load as well as to the work needed from the release team and others. I am well aware that a Qt 5.8.1 release would be beneficial, but making one now would impact Qt 5.9 schedule and our capability to improve CI system stability. Qt 5.6.3 LTS patch release is done straight after Qt 5.9 release, but not before. After the Qt 5.9.0 in May we should then focus into making Qt 5.9.1 release instead of making Qt 5.8.1 any more as Qt 5.9.0 is already out. With the CI improvements in place, we should definitely be able to make more than one patch release for Qt 5.9. As a scheduled Qt 5.8.1 release is not planned, should we start pushing fixes directly to 5.9 branch now? It would reduce the workload as we do not need to first integrate changes into 5.8 and then merge upwards to 5.9. It would also reduce the time it takes to get fixes into to 5.9 and dev as well as reduce the load to the CI system as less integrations are needed. We can keep 5.8 branch open for a while still similarly as 5.6 is in case there is some fix that must be in the 5.8 branch. Let’s discuss in the next release team meeting (Tuesday 14th Feb 16.00 CET) if pushing fixes to 5.9 branch directly would be good approach. Yours, Tuukka -------------- next part -------------- An HTML attachment was scrubbed... URL: From schnitzeltony at googlemail.com Fri Feb 10 12:57:58 2017 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Fri, 10 Feb 2017 12:57:58 +0100 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? Message-ID: On Fri, Feb 10, 2017 at 11:19 AM, Andreas Müller wrote: > Hi, > > I am cross building Qt and KDE with yocto environment. After Update to > Qt 5.8 the package baloo from KDE KF5 is broken. After investigation I > found that qdbuscpp2xml 5.8 build misses some public slots. > > I get for Qt5.8 build by yocto: > > qdbuscpp2xml -a filecontentindexer.h > Unregistered input type in parameter list: QDBusMessage > Unregistered input type in parameter list: QDBusMessage > 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> > > > > > > > > > > > > > On my local fedora Qt5.7.1 > qdbuscpp2xml -a filecontentindexer.h > 1.0//EN" "http://www.freedesktop.org/standards/dbus/1.0/introspect.dtd"> > > > > > > > > > > > > > > > > > You can see that qdbuscpp2xml complains for unregistered QDBusMessage > and the slots 'registerMonitor' and 'unregisterMonitor' having > QDBusMessage in parameter are missing. > > Since yocto builds also native qdbuscpp2xml it might be possible that > there is something missing for qdbuscpp2xml. > > Pointers how to get around or even confirmation of a bug are welcome - > baloo's filecontentindexer.h is attached > I have straced qdbuscpp2xml build with Qt 5.7/5.8 My 5.8 qdbuscpp2xml does not try to load a single Qt library. 5.7 qdbuscpp2xml loads libQt5DBus.so.5 right after start. This let's me assume there's something wrong with our build of qdbuscpp2xml. Andreas From oswald.buddenhagen at qt.io Fri Feb 10 14:07:06 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 10 Feb 2017 14:07:06 +0100 Subject: [Development] [HEADS UP] please clean up your "in progress" jira tasks Message-ID: <20170210130706.GI23393@troll08> moin, running the query https://bugreports.qt.io/issues/?jql=status%20%3D%20%22In%20Progress%22%20AND%20updated%20%3C%20-3weeks produces an astonishing number of tasks. i suspect in most cases the assignee just failed to close the task after integration, while in some cases the task was in reality deferred, and yet in other cases it was more of an "intent to start work" in the first place. so please go through your tasks and those of the components you feel responsible for and check their status. when you mark tasks as done, don't forget to set the "changes" and "fixed in" fields. on a somewhat related note, it makes sense to re-triage old tasks from time to time to weed out stuff that got fixed "asynchronously". a task for slow friday afternoons. ^^ From mitch.curtis at qt.io Fri Feb 10 15:06:13 2017 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 10 Feb 2017 14:06:13 +0000 Subject: [Development] [HEADS UP] please clean up your "in progress" jira tasks In-Reply-To: <20170210130706.GI23393@troll08> References: <20170210130706.GI23393@troll08> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Oswald Buddenhagen > Sent: Friday, 10 February 2017 2:07 PM > To: development at qt-project.org; qt-creator at qt-project.org > Subject: [Development] [HEADS UP] please clean up your "in progress" jira > tasks > > moin, > > running the query > https://bugreports.qt.io/issues/?jql=status%20%3D%20%22In%20Progress% > 22%20AND%20updated%20%3C%20-3weeks > produces an astonishing number of tasks. i suspect in most cases the > assignee just failed to close the task after integration, while in some cases > the task was in reality deferred, and yet in other cases it was more of an > "intent to start work" in the first place. > > so please go through your tasks and those of the components you feel > responsible for and check their status. > when you mark tasks as done, don't forget to set the "changes" and "fixed > in" fields. If you're lazy and don't want to go through Jira's interface, here's that same filter with your "In Progress" tasks: https://bugreports.qt.io/issues/?jql=status%20%3D%20%22In%20Progress%22%20AND%20assignee%20%3D%20currentUser()%20AND%20updated%20%3C%20-3weeks > on a somewhat related note, it makes sense to re-triage old tasks from time > to time to weed out stuff that got fixed "asynchronously". a task for slow > friday afternoons. ^^ > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at qt.io Fri Feb 10 16:21:26 2017 From: Kai.Koehne at qt.io (Kai Koehne) Date: Fri, 10 Feb 2017 15:21:26 +0000 Subject: [Development] [Releasing] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> <20170125111329.GH20252@troll08> <20170126115151.GD3289@troll08>, Message-ID: Hi, To sum the discussion here and also on gerrit up : There's no consensus on making [ChangeLog] entries mandatory, or making the [ChangeLog] field enabled by default. Anyhow, Ossi had an interesting third suggestion on https://codereview.qt-project.org/#/c/183244/: > how about this for an idea: we add a new gerrit category "ChangeLog" which needs a +1. it would be auto-set by the bot if a changelog file is touched, otherwise a reviewer needs to set it. easy to implement, reliable (well, as much as the reviewers), and adds no noise to the commit messages. I understand that this would not be hard to do. This way nobody is forced to write changelog entries, but it requires a conscious click from the reviewer to say 'Yes, this does _not_ use a ChangeLog'. Any strong opinion against this? Kai > -----Original Message----- > From: Schumann, Spencer [mailto:Spencer.Schumann at echostar.com] > Sent: Thursday, January 26, 2017 5:11 PM > To: Kai Koehne ; Oswald Buddenhagen > ; development at qt-project.org; > releasing at qt-project.org > Subject: Re: [Releasing] [Development] Change file process & improvement > proposal > > > > For the sanity bot, either we decide that _every_ change has a > > [ChangeLog], or we try to make the bot intelligent > > > enough to decide whether a commit needs a change log, or not. Parts of > > the discussion so far makes me think > > > that this will be an uphill battle though. > > > > So, any strong opinion against enforcing a [ChangeLog] line, with > "[ChangeLog] -" for commits that don't need one? > > I doubt the decision on whether a changelog is needed could be adequately > automated. Sometimes, even a one character change might need a detailed > changelog. > > Isn't this something that could and should be enforced via the code review > process? If reviewers see that the changelog is missing or inadequate, they > can reject the change. > > > > > > - Spencer > > > ________________________________ > > From: Releasing project.org> on behalf of Kai Koehne > Sent: Thursday, January 26, 2017 5:28:30 AM > To: Oswald Buddenhagen; development at qt-project.org; releasing at qt- > project.org > Subject: Re: [Releasing] [Development] Change file process & improvement > proposal > > > > > -----Original Message----- > > From: Releasing [mailto:releasing-bounces+kai.koehne=qt.io at qt- > > project.org] On Behalf Of Oswald Buddenhagen > > Sent: Thursday, January 26, 2017 12:52 PM > > To: development at qt-project.org; releasing at qt-project.org > > Subject: Re: [Releasing] [Development] Change file process & > > improvement proposal > > > > On Thu, Jan 26, 2017 at 09:51:24AM +0100, Edward Welbourne wrote: > > > I don't know what you're saying, much less why it's supposed to be > > > the obvious interpretation. A "tagged commit" is presumably v5.7.0 > > > or similar; why should a commit without an amends line be assumed to > > > relate to one of these ? > > > > > i used "tagged commit" as a shorthand for "a commit which is reachable > > from a tag", which should be fairly clear from the context. i.e., "git > > tag --contains " returns something. > > Well, I had a hard time deciphering this, too. > > > > Anyway, this all feels like we get side-tracked in details. To reiterate: > > - We do (still) have a problem with our ChangeLog files > * The quality of the entries, and the scope, greatly differs (between > modules) > * We do have a problem getting them in place on time for a release > > Jani's proposal is to fix parts of this is to encourage committers and reviewers > to write [ChangeLog] entries as part of the commit. This could be encouraged > by > * Enabling the [ChangeLog] line by default in the commit template > * Enforcing a [ChangeLog] entry by the Sanity Bot (under conditions xxx) > > For the sanity bot, either we decide that _every_ change has a [ChangeLog], > or we try to make the bot intelligent enough to decide whether a commit > needs a change log, or not. Parts of the discussion so far makes me think that > this will be an uphill battle though. > > So, any strong opinion against enforcing a [ChangeLog] line, with > "[ChangeLog] -" for commits that don't need one? > > Regards > > Kai > > > _______________________________________________ > > Releasing mailing list > > Releasing at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/releasing > _______________________________________________ > Releasing mailing list > Releasing at qt-project.org > http://lists.qt-project.org/mailman/listinfo/releasing > From rafael.roquetto at kdab.com Fri Feb 10 19:52:22 2017 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Fri, 10 Feb 2017 18:52:22 +0000 Subject: [Development] Adding Tracepoints to Qt Message-ID: <20170210185221.GA572@sirius> Hello, I have been working lately on trying to bring tracing support to Qt, internally. The idea is to support LTTNG on Linux and ETW on Windows, at first. Eventually, we would like to add DTrace support as well, if feasible. LTTNG and ETW offer very distinct APIs, which are very difficult to abstract together using only C++ and macros. After a few failed attempts, I decided to go for a code generation. The most relevant reason for this is that both rely a lot on macros, leaving a very small amount of things that can be done after the preprocessor has run. Eventually, we decided to go for a code generator, which is unsurprisingly called 'tracegen', and is written in Perl,usince Qt already depends on it during build time (not to metion that Perl makes it very easy to process textual data). A very *RAW* WIP version can be found here: https://codereview.qt-project.org/#/c/185287/2 The commit message sums it up. The idea is that, for each Qt module, one can define a tracepoint provider. Each tracepoint provider is defined on its own file. See qtcore.provider on the review above for details (the contents of that file are merely illustrative for now). Here are the highlights, though, on how to create a tracepoint: 1. you add a new entry to the provider file, i.e. qwidget_geometry(const QRect &, rect) 2. On the trace location, you do: #include . . Q_TRACE(qwidget_geometry, geometry()); And that's it. There are other two macros, Q_DO_TRACE() and Q_TRACE_ENABLED(). Those are mostly relevant for LTTNG. See the commit message for further info. At this time, this is just a prototype. I would appreciate any kind of constructive feedback, and hope that we can eventually have the results of this merged upstream. If anyone has any questions, please don't think twice before asking :) Also, bear in mind that I did not put a lot of thought yet on the build process. I was just trying to make it work. To get started, I have a couple of questions: 1. is corelib/global the appropriate place for this? 2. is utils/tracegen the appropriate location for the code generator? 3. could someone with qmake knowledge give some feedback on the changes I made to the .pri files? I suppose there might be better ways to achieve what I want. 4. specially, what would be the best way to make this work accross modules? 5. For the configure switches, I would prefer -trace [lttng|etw], but similar options hint to -lttng and -etw instead (which is what I currently have). What would be the best approach? 6. What subset of Qt types should we support out of the box? I am thinking of QString, QByteArray, QRect[F], QSize[F], i.e. geometry types, QUrl, etc... ? Thanks for reading! Rafael -- Rafael Roquetto | rafael.roquetto at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts From jhihn at gmx.com Fri Feb 10 20:21:15 2017 From: jhihn at gmx.com (Jason H) Date: Fri, 10 Feb 2017 20:21:15 +0100 Subject: [Development] QtQuick2 Backend: WebGL? Message-ID: I was watching the recently posted videos on youtube. One went into the GL support for QtQuick, and I got to thinking that WebGL might not be terrible. If we can send the draw commands to a browser we can web-enable any Qt app. And a lot of embedded apps want to be web-enabled. Does anyone have an idea how hard this would be or if it is even doable? From thiago.macieira at intel.com Sat Feb 11 05:54:36 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 10 Feb 2017 20:54:36 -0800 Subject: [Development] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: References: Message-ID: <4362615.CxcfA5gnds@tjmaciei-mobl1> Em sexta-feira, 10 de fevereiro de 2017, às 11:19:14 PST, Andreas Müller via Development escreveu: > qdbuscpp2xml -a filecontentindexer.h > Unregistered input type in parameter list: QDBusMessage > Unregistered input type in parameter list: QDBusMessage Hmm... unregistered types. Can you check if you're applying these patches: https://codereview.qt-project.org/180231 https://codereview.qt-project.org/180232 I can't support any QtDBus unless those two patches are applied. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From charleyb123 at gmail.com Sat Feb 11 15:08:18 2017 From: charleyb123 at gmail.com (charleyb123 .) Date: Sat, 11 Feb 2017 07:08:18 -0700 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> Message-ID: On Fri, Feb 10, 2017 at 3:59 AM, Tuukka Turunen wrote: > Short summary: The Qt Company has decided to focus development effort to 5.9 > and dev branches in order to reach the planned timeline for Qt 5.9 release > and make improvements in the CI system. , > In the CI system side we have major improvements happening during this year. > We will be purchasing more blades and other HW during H1/17, which will add > capacity, so we will be able to run more parallel integrations. Perhaps related, I think it might be a good idea to target more closely new compiler releases from Microsoft. In the past several years they have shifted to an early-and-frequent update model, and organizations are adapting to more aggressively take advantage of new C++ language features, and to target platform technology changes. For example MSVC++2017 (version 15) was previewed in March-2016; has had three major updates; went to RC in Nov-2016; and is announced for launch in March-2017 (see: http://www.zdnet.com/article/microsoft-to-release-visual-studio-2017-on-march-7/). That tool chain was actually at very high quality since its launch a year ago (this is their new release model), and I'm aware of companies that have relied on that version for commercial development since its preview access. IMHO, not providing binaries for that platform is a hindrance to Qt adoption. Intel provides chips to OEMs before launch, and companies regularly provide pre-release technology access to allow OEMs time to integrate with their products, and I'm suggesting Qt should similarly support this type of early-access (we can call it "pre-release" access if we want). Yes, developers can build their own Qt binaries; but this is a non-trivial point of friction, and you need to install Python, and become familiar with config, etc. The "experts" have success here, but we continue to see email threads on stumped non-experts unable to get working Qt binaries. If we want friction-less Qt adoption (perhaps even for casual and accidental developer exposure), we should just provide the binaries. Yes, I'm very aware that some companies are on the slow-stable upgrade model and need long support for older compilers. I'm talking about another market where requirements and competitive advantage demand access to new tooling, (consistent with the fast pace of web technology advances and the need for security patches and updates). Under this proposal, Qt binaries would be available for MSVC++2018 when it is previewed, or at least most certainly when it goes to RC. Waiting for it to deploy is *way* too late, as the new Microsoft release model suggests that developers have been integrating the compiler into their tooling for a year before Qt "shows up". --charley From thiago.macieira at intel.com Sat Feb 11 21:26:10 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 11 Feb 2017 12:26:10 -0800 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> Message-ID: <11923625.iOlAjAdnsg@tjmaciei-mobl1> On sábado, 11 de fevereiro de 2017 07:08:18 PST charleyb123 . wrote: > That tool chain was actually at very high quality since its launch a > year ago (this is their new release model), and I'm aware of companies > that have relied on that version for commercial development since its > preview access. It was, except for the part where they used their new optimiser (the same as MSVC 2015 Update 3) that generated broken code... > IMHO, not providing binaries for that platform is a hindrance to Qt > adoption. Intel provides chips to OEMs before launch, and companies > regularly provide pre-release technology access to allow OEMs time to > integrate with their products, and I'm suggesting Qt should similarly > support this type of early-access (we can call it "pre-release" access > if we want). We can't provide binaries because, with Visual Studio, the different releases are not binary-compatible with each other. If we built our releases with the RC, it may not run with your application that you compiled with the final. And since we promise to keep our compatibility forwards and backwards inside a minor series, we don't like to update the MSVC version so you can just drop in the new release and not have to rebuild everything. Maybe we ought to revisit that. The next problem is the load on the build servers and on the people doing the testing that the generated binaries actually work. See the discussion we had a couple of months ago on what we'd release for 5.8 and 5.9. We need to keep the number of binaries to a constant number. So adding MSVC 2017 would mean dropping something. But we did make MSVC 2017 work with 5.8. We solved all build issues we could find. > Under this proposal, Qt binaries would be available for MSVC++2018 > when it is previewed, or at least most certainly when it goes to RC. > Waiting for it to deploy is *way* too late, as the new Microsoft > release model suggests that developers have been integrating the > compiler into their tooling for a year before Qt "shows up". That's unlikely to happen. How about asking Microsoft to follow up on their promise of keeping binary compatibility instead? That way, the binaries built with MSVC 2017 will work with 2018 and we don't have to rebuild. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From gunnar.roth at gmx.de Sun Feb 12 21:41:16 2017 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Sun, 12 Feb 2017 21:41:16 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <11923625.iOlAjAdnsg@tjmaciei-mobl1> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <11923625.iOlAjAdnsg@tjmaciei-mobl1> Message-ID: > > We can't provide binaries because, with Visual Studio, the different releases > are not binary-compatible with each other. If we built our releases with the > RC, it may not run with your application that you compiled with the final. And > since we promise to keep our compatibility forwards and backwards inside a > minor series, we don't like to update the MSVC version so you can just drop in > the new release and not have to rebuild everything. vcblog says: " Specifically, VS 2015 and VS “15” will have the same major compiler version (19) and their STLs will be binary-compatible, and this compatible compiler and STL will remain available throughout the lifecycle of VS “15”. This implies that the STL’s DLL will continue to be named msvcp140.dll. (At some point in the future, we expect to have a compiler version 20 and a binary-incompatible STL again.)" > > Maybe we ought to revisit that. > yes. > The next problem is the load on the build servers and on the people doing the > testing that the generated binaries actually work. See the discussion we had a > couple of months ago on what we'd release for 5.8 and 5.9. We need to keep the > number of binaries to a constant number. So adding MSVC 2017 would mean > dropping something. yes dropping vs2015 build as using the latest 19.xx compiler will be binary compatible to vs2015 code. > But we did make MSVC 2017 work with 5.8. We solved all build issues we could > find. Well sadly that does not include 5.8.0, so now users have to wait at least until may to get a vs2017 ( which will be released on March 9th). > >> Under this proposal, Qt binaries would be available for MSVC++2018 >> when it is previewed, or at least most certainly when it goes to RC. >> Waiting for it to deploy is *way* too late, as the new Microsoft >> release model suggests that developers have been integrating the >> compiler into their tooling for a year before Qt "shows up". > > That's unlikely to happen. > > How about asking Microsoft to follow up on their promise of keeping binary > compatibility instead? That way, the binaries built with MSVC 2017 will work > with 2018 and we don't have to rebuild. How about Qt supports the binary compatibility bewegen cl19.00 and cl cl19.xx instead on making a win32-msvc2017? mkspec should be based on the cl major version , instead of the IDE year. QtCreator complains when you try to use a qt with 2017 mkspec and a 2015 compiler set. Regards, Gunnar Roth -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Feb 13 00:38:02 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 12 Feb 2017 15:38:02 -0800 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <11923625.iOlAjAdnsg@tjmaciei-mobl1> Message-ID: <1722423.mXEIWrKKf1@tjmaciei-mobl1> On domingo, 12 de fevereiro de 2017 21:41:16 PST Gunnar Roth wrote: > vcblog says: " Specifically, VS 2015 and VS “15” will have the same major > compiler version (19) and their STLs will be binary-compatible, and this > compatible compiler and STL will remain available throughout the lifecycle > of VS “15”. This implies that the STL’s DLL will continue to be named > msvcp140.dll. (At some point in the future, we expect to have a compiler > version 20 and a binary-incompatible STL again.)" This needs to be tested. It's not only binary compatibility, it's also the way that Windows does DLLs -- especially the VC runtime ones. It's possible to load more than one with different manifest information, which by itself is problematic. But then you can't delete in one pointers new'ed by another, which is a much bigger problem. Maybe that's fixed. Maybe it isn't. Someone who knows more about DLLs, manifests, and VC needs to check this > > Maybe we ought to revisit that. > > yes. Let's discuss that when we're approaching 5.8.1 and 5.9.1. > > The next problem is the load on the build servers and on the people doing > > the testing that the generated binaries actually work. See the discussion > > we had a couple of months ago on what we'd release for 5.8 and 5.9. We > > need to keep the number of binaries to a constant number. So adding MSVC > > 2017 would mean dropping something. > > yes dropping vs2015 build as using the latest 19.xx compiler will be binary > compatible to vs2015 code. We can't drop it from the CI. I don't think we can drop it from the build packages either, since usually you compile with the oldest you plan to use. So if you're correct and VS2017 is binary-compatible, then we are already providing the packages for VS2017. > > But we did make MSVC 2017 work with 5.8. We solved all build issues we > > could find. > > Well sadly that does not include 5.8.0, so now users have to wait at least > until may to get a vs2017 ( which will be released on March 9th). We had planned on having 5.8.1 before that release. Unfortunately, it's not going to happen, due to lack of resources. 5.8.1 is postponed indefinitely and will most likely not happen. 5.9.0 will have support and binaries. > > How about asking Microsoft to follow up on their promise of keeping binary > > compatibility instead? That way, the binaries built with MSVC 2017 will > > work with 2018 and we don't have to rebuild. > > How about Qt supports the binary compatibility bewegen cl19.00 and cl > cl19.xx instead on making a win32-msvc2017? mkspec should be based on the > cl major version , instead of the IDE year. QtCreator complains when you > try to use a qt with 2017 mkspec and a 2015 compiler set. The win32-msvcXXXX mkspecs have been dropped as of Qt 5.8.0. They're all now called "win32-msvc" and the actual versions are extracted from the compiler itself, to enable command-line options as needed. The plan was for 2017 to not get an mkspec of its own, but we had to add it for compatibility with Qt 5.6.3, which apparently needed to get one of its own. Though if you're right, we wouldn't have needed win32-msvc2017 and could have told people to use win32-msvc2015 instead. Except that users not as knowledgeable as you would have complained that the support wasn't final. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From schnitzeltony at googlemail.com Mon Feb 13 09:29:55 2017 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Mon, 13 Feb 2017 09:29:55 +0100 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? Message-ID: On Sat, Feb 11, 2017 at 5:54 AM, Thiago Macieira wrote: > Em sexta-feira, 10 de fevereiro de 2017, às 11:19:14 PST, Andreas Müller via > Development escreveu: >> qdbuscpp2xml -a filecontentindexer.h >> Unregistered input type in parameter list: QDBusMessage >> Unregistered input type in parameter list: QDBusMessage > > Hmm... unregistered types. Can you check if you're applying these patches: > > https://codereview.qt-project.org/180231 > https://codereview.qt-project.org/180232 > > I can't support any QtDBus unless those two patches are applied. > Bad news: qdbuscpp2xml build with these patches does not output a single character, the application does not return (no significant CPU load) and has to be terminated by Ctrl+C. Andreas From oswald.buddenhagen at qt.io Mon Feb 13 10:03:54 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 13 Feb 2017 10:03:54 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <1722423.mXEIWrKKf1@tjmaciei-mobl1> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <11923625.iOlAjAdnsg@tjmaciei-mobl1> <1722423.mXEIWrKKf1@tjmaciei-mobl1> Message-ID: <20170213090354.GJ23393@troll08> On Sun, Feb 12, 2017 at 03:38:02PM -0800, Thiago Macieira wrote: > The win32-msvcXXXX mkspecs have been dropped as of Qt 5.8.0. > 5.8.1 (so 5.9.0, by all appearances). From edward.welbourne at qt.io Mon Feb 13 11:02:36 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 13 Feb 2017 10:02:36 +0000 Subject: [Development] [Releasing] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> <20170125111329.GH20252@troll08> <20170126115151.GD3289@troll08>, , Message-ID: Kai Koehne (10 February 2017 16:21) wrote: > To sum the discussion here and also on gerrit up : There's no > consensus on making [ChangeLog] entries mandatory, or making the > [ChangeLog] field enabled by default. Indeed. > Anyhow, Ossi had an interesting third suggestion on > https://codereview.qt-project.org/#/c/183244/: >> how about this for an idea: we add a new gerrit category "ChangeLog" >> which needs a +1. it would be auto-set by the bot if a changelog file >> is touched, otherwise a reviewer needs to set it. easy to implement, >> reliable (well, as much as the reviewers), and adds no noise to the >> commit messages. Note that this speaks of "a changelog file" rather than tags in commits; I do think this is a better approach, although I do also exhort everyone to keep your changelog files organised on some *other* model than "make each addition at the end" - e.g. sort by category, like the existing ChangeLog tags, and put related changes near each other - since any model that makes all additions at the same place *will* get conflicts all the time. Anything to ensure contemporary changes happen in different places is better than always conflicting. > I understand that this would not be hard to do. This way nobody is > forced to write changelog entries, but it requires a conscious click > from the reviewer to say 'Yes, this does _not_ use a ChangeLog'. > > Any strong opinion against this? Not from this quarter; if Ossi can teach Gerrit to remind me to think about whether each change, that lacks one, wants a change log; that sounds like a good solution to me. Be sure to include a link to the wiki page that says what tags to use and what should be in the change log. Eddy. From tor.arne.vestbo at qt.io Mon Feb 13 12:11:56 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Mon, 13 Feb 2017 12:11:56 +0100 Subject: [Development] [Releasing] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> <20170125111329.GH20252@troll08> <20170126115151.GD3289@troll08> Message-ID: <8f82f129-7b07-aa03-2739-7459272c48c1@qt.io> On 13/02/2017 11:02, Edward Welbourne wrote: > Note that this speaks of "a changelog file" rather than tags in commits; > I do think this is a better approach, although I do also exhort everyone > to keep your changelog files organised on some *other* model than "make > each addition at the end" - e.g. sort by category, like the existing > ChangeLog tags, and put related changes near each other - since any > model that makes all additions at the same place *will* get conflicts > all the time. Anything to ensure contemporary changes happen in > different places is better than always conflicting. Git merge-drivers can be specified on a per file (pattern) basis, so a custom changelog driver could be used. We had something similar in WebKit for ChangeLog files. tor arne From tor.arne.vestbo at qt.io Mon Feb 13 12:11:56 2017 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Mon, 13 Feb 2017 12:11:56 +0100 Subject: [Development] [Releasing] Change file process & improvement proposal In-Reply-To: References: <20161110142306.GC9877@troll08> <20170124152033.GE20252@troll08> <20170125111329.GH20252@troll08> <20170126115151.GD3289@troll08> Message-ID: <8f82f129-7b07-aa03-2739-7459272c48c1@qt.io> On 13/02/2017 11:02, Edward Welbourne wrote: > Note that this speaks of "a changelog file" rather than tags in commits; > I do think this is a better approach, although I do also exhort everyone > to keep your changelog files organised on some *other* model than "make > each addition at the end" - e.g. sort by category, like the existing > ChangeLog tags, and put related changes near each other - since any > model that makes all additions at the same place *will* get conflicts > all the time. Anything to ensure contemporary changes happen in > different places is better than always conflicting. Git merge-drivers can be specified on a per file (pattern) basis, so a custom changelog driver could be used. We had something similar in WebKit for ChangeLog files. tor arne From meskobalazs at fedoraproject.org Mon Feb 13 13:25:32 2017 From: meskobalazs at fedoraproject.org (=?UTF-8?B?QmFsw6F6cyBNZXNrw7M=?=) Date: Mon, 13 Feb 2017 13:25:32 +0100 Subject: [Development] Gerrit issue Message-ID: Hi! Sorry for sending this mail to this list, but the localization list seems quite dead, and the actual problem *is* a development issue. I am trying to push the Hungarian localization for Qt 5.6. I am running *git push gerrit HEAD:refs/for/5.6 *which results in *Permission denied (publickey).* What should I do to set up the SSH auth?I have already generated an SSH key, and uploaded the public key to my gerrit account. I am stuck, and the documentation is of no help. I am assuming, that I must config something on my end, but what? Thanks for the help in advance, Balázs -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Mon Feb 13 13:27:25 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 13 Feb 2017 15:27:25 +0300 Subject: [Development] Gerrit issue In-Reply-To: References: Message-ID: <2928911486988845@web33j.yandex.ru> 13.02.2017, 15:26, "Balázs Meskó" : > Hi! > > Sorry for sending this mail to this list, but the localization list seems quite dead, and the actual problem *is* a development issue. > > I am trying to push the Hungarian localization for Qt 5.6. I am running git push gerrit HEAD:refs/for/5.6 which results in Permission denied (publickey). > > What should I do to set up the SSH auth?I have already generated an SSH key, and uploaded the public key to my gerrit account. I am stuck, and the documentation is of no help. Check if email in commit you are pushing matches email that you specified in gerrit account > > I am assuming, that I must config something on my end, but what? > > Thanks for the help in advance, > Balázs > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From gunnar.roth at gmx.de Mon Feb 13 14:13:59 2017 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Mon, 13 Feb 2017 14:13:59 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <1722423.mXEIWrKKf1@tjmaciei-mobl1> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <11923625.iOlAjAdnsg@tjmaciei-mobl1> , <1722423.mXEIWrKKf1@tjmaciei-mobl1> Message-ID:     >> vcblog says: " Specifically, VS 2015 and VS “15” will have the same major> >> compiler version (19) and their STLs will be binary-compatible, and this >> compatible compiler and STL will remain available throughout the lifecycle >> of VS “15”. This implies that the STL’s DLL will continue to be named >> msvcp140.dll. (At some point in the future, we expect to have a compiler >> version 20 and a binary-incompatible STL again.)" > >This needs to be tested. It's not only binary compatibility, it's also the way >that Windows does DLLs -- especially the VC runtime ones. It's possible to >load more than one with different manifest information, which by itself is >problematic. But then you can't delete in one pointers new'ed by another, >which is a much bigger problem. >Maybe that's fixed. Maybe it isn't. Someone who knows more about DLLs, >manifests, and VC needs to check this well as the vcruntime is still called 140, a vs2017 runtime will supersede your 2015 runtime, if your manifest says use the latest. So there is no difference between the different vs2015 update versions. Ms needs to keep them compatible, especially the allocator. >> yes dropping vs2015 build as using the latest 19.xx compiler will be binary >> compatible to vs2015 code. >We can't drop it from the CI. I don't think we can drop it from the build >packages either, since usually you compile with the oldest you plan to use. So >if you're correct and VS2017 is binary-compatible, then we are already >providing the packages for VS2017. Yes but then you do not have the many performancee optmisations ( better constexpr, better vector preformance, compiler optimisations) in the qt build. >> > But we did make MSVC 2017 work with 5.8. We solved all build issues we >> > could find. >> >> Well sadly that does not include 5.8.0, so now users have to wait at least >> until may to get a vs2017 ( which will be released on March 9th). > >We had planned on having 5.8.1 before that release. Unfortunately, it's not >going to happen, due to lack of resources. 5.8.1 is postponed indefinitely and >will most likely not happen. Actually I expected that, because that's Murphy's Law ;-) But as I always build Qt myself to be able to add patches and to have release pdbs, I myself do not care so much, I just think it would give Qt a better look for other users, to support 2017rc. >The win32-msvcXXXX mkspecs have been dropped as of Qt 5.8.0. They're all now >called "win32-msvc" and the actual versions are extracted from the compiler >itself, to enable command-line options as needed. The plan was for 2017 to not >get an mkspec of its own, but we had to add it for compatibility with Qt >5.6.3, which apparently needed to get one of its own. Hmm what do you mean? If i do a dir win32* in the mkspec folder of qtbase of Qt 5.8.0, I get this: 24.01.2017 17:37 win32-clang-msvc2015 24.01.2017 17:37 win32-g++ 24.01.2017 17:37 win32-icc 24.01.2017 17:37 win32-msvc2005 24.01.2017 17:37 win32-msvc2008 24.01.2017 17:37 win32-msvc2010 24.01.2017 17:37 win32-msvc2012 24.01.2017 17:37 win32-msvc2013 24.01.2017 17:37 win32-msvc2015 24.01.2017 17:37 win32-msvc2017 So there is lot of unsupported msvc versions (2005,2008,2010,2012), but no win32-msvc mkspec. Regards, Gunnar Roth. From oswald.buddenhagen at qt.io Mon Feb 13 14:37:35 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 13 Feb 2017 14:37:35 +0100 Subject: [Development] Gerrit issue In-Reply-To: References: Message-ID: <20170213133735.GN23393@troll08> On Mon, Feb 13, 2017 at 01:25:32PM +0100, Balázs Meskó wrote: > I am trying to push the Hungarian localization for Qt 5.6. I am running > git push gerrit HEAD:refs/for/5.6 which results in Permission denied > (publickey). > that usually means that you're using the wrong port. From oswald.buddenhagen at qt.io Mon Feb 13 14:46:10 2017 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Mon, 13 Feb 2017 14:46:10 +0100 Subject: [Development] Gerrit issue In-Reply-To: <20170213133735.GN23393@troll08> References: <20170213133735.GN23393@troll08> Message-ID: <20170213134610.GO23393@troll08> On Mon, Feb 13, 2017 at 02:37:35PM +0100, Oswald Buddenhagen wrote: > On Mon, Feb 13, 2017 at 01:25:32PM +0100, Balázs Meskó wrote: > > I am trying to push the Hungarian localization for Qt 5.6. I am running > > git push gerrit HEAD:refs/for/5.6 which results in Permission denied > > (publickey). > > > that usually means that you're using the wrong port. > ... or actually, username. but it's configured in the same place pretty much (the git remote or the ssh configuration). From thiago.macieira at intel.com Mon Feb 13 17:22:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 13 Feb 2017 08:22:40 -0800 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: References: Message-ID: <1829262.BzjvJY2XhL@tjmaciei-mobl1> Em segunda-feira, 13 de fevereiro de 2017, às 09:29:55 PST, Andreas Müller via Development escreveu: > On Sat, Feb 11, 2017 at 5:54 AM, Thiago Macieira > > wrote: > > Em sexta-feira, 10 de fevereiro de 2017, às 11:19:14 PST, Andreas Müller > > via> > > Development escreveu: > >> qdbuscpp2xml -a filecontentindexer.h > >> Unregistered input type in parameter list: QDBusMessage > >> Unregistered input type in parameter list: QDBusMessage > > > > Hmm... unregistered types. Can you check if you're applying these patches: > > > > https://codereview.qt-project.org/180231 > > https://codereview.qt-project.org/180232 > > > > I can't support any QtDBus unless those two patches are applied. > > Bad news: qdbuscpp2xml build with these patches does not output a > single character, the application does not return (no significant CPU > load) and has to be terminated by Ctrl+C. That's probably the same cause that has so far prevented those patches from being applied: the CI shows in 5.8 a freeze and in 5.6, a regression in a unit test. Anyway, I require them to be applied, so I need to know what's happening. I can't reproduce the issue locally. Can you provide the backtrace? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From schnitzeltony at googlemail.com Mon Feb 13 22:48:07 2017 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Mon, 13 Feb 2017 22:48:07 +0100 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: <1829262.BzjvJY2XhL@tjmaciei-mobl1> References: <1829262.BzjvJY2XhL@tjmaciei-mobl1> Message-ID: On Mon, Feb 13, 2017 at 5:22 PM, Thiago Macieira wrote: > Em segunda-feira, 13 de fevereiro de 2017, às 09:29:55 PST, Andreas Müller via > Development escreveu: >> On Sat, Feb 11, 2017 at 5:54 AM, Thiago Macieira >> >> wrote: >> > Em sexta-feira, 10 de fevereiro de 2017, às 11:19:14 PST, Andreas Müller >> > via> >> > Development escreveu: >> >> qdbuscpp2xml -a filecontentindexer.h >> >> Unregistered input type in parameter list: QDBusMessage >> >> Unregistered input type in parameter list: QDBusMessage >> > >> > Hmm... unregistered types. Can you check if you're applying these patches: >> > >> > https://codereview.qt-project.org/180231 >> > https://codereview.qt-project.org/180232 >> > >> > I can't support any QtDBus unless those two patches are applied. >> >> Bad news: qdbuscpp2xml build with these patches does not output a >> single character, the application does not return (no significant CPU >> load) and has to be terminated by Ctrl+C. > > That's probably the same cause that has so far prevented those patches from > being applied: the CI shows in 5.8 a freeze and in 5.6, a regression in a unit > test. > > Anyway, I require them to be applied, so I need to know what's happening. I > can't reproduce the issue locally. Can you provide the backtrace? Sorry but - how do I create a backtrace? Some gdb session and break or? You are aware qdbuscpp2xml does not crash - it is simply idle until I press Ctrl+C. Andreas From annulen at yandex.ru Mon Feb 13 23:42:30 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 14 Feb 2017 01:42:30 +0300 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: References: <1829262.BzjvJY2XhL@tjmaciei-mobl1> Message-ID: <1592201487025750@web33j.yandex.ru> 14.02.2017, 00:48, "Andreas Müller via Development" : > On Mon, Feb 13, 2017 at 5:22 PM, Thiago Macieira > wrote: >>  Em segunda-feira, 13 de fevereiro de 2017, às 09:29:55 PST, Andreas Müller via >>  Development escreveu: >>>  On Sat, Feb 11, 2017 at 5:54 AM, Thiago Macieira >>> >>>   wrote: >>>  > Em sexta-feira, 10 de fevereiro de 2017, às 11:19:14 PST, Andreas Müller >>>  > via> >>>  > Development escreveu: >>>  >> qdbuscpp2xml -a filecontentindexer.h >>>  >> Unregistered input type in parameter list: QDBusMessage >>>  >> Unregistered input type in parameter list: QDBusMessage >>>  > >>>  > Hmm... unregistered types. Can you check if you're applying these patches: >>>  > >>>  > https://codereview.qt-project.org/180231 >>>  > https://codereview.qt-project.org/180232 >>>  > >>>  > I can't support any QtDBus unless those two patches are applied. >>> >>>  Bad news: qdbuscpp2xml build with these patches does not output a >>>  single character, the application does not return (no significant CPU >>>  load) and has to be terminated by Ctrl+C. >> >>  That's probably the same cause that has so far prevented those patches from >>  being applied: the CI shows in 5.8 a freeze and in 5.6, a regression in a unit >>  test. >> >>  Anyway, I require them to be applied, so I need to know what's happening. I >>  can't reproduce the issue locally. Can you provide the backtrace? > > Sorry but - how do I create a backtrace? Some gdb session and break or? Or attach to idle process. > > You are aware qdbuscpp2xml does not crash - it is simply idle until I > press Ctrl+C. > > Andreas > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Mon Feb 13 23:50:17 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 13 Feb 2017 14:50:17 -0800 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: References: <1829262.BzjvJY2XhL@tjmaciei-mobl1> Message-ID: <29745442.rIEqy38Z7a@tjmaciei-mobl1> On segunda-feira, 13 de fevereiro de 2017 22:48:07 PST Andreas Müller via Development wrote: > > Anyway, I require them to be applied, so I need to know what's happening. > > I > > can't reproduce the issue locally. Can you provide the backtrace? > > Sorry but - how do I create a backtrace? Some gdb session and break or? > > You are aware qdbuscpp2xml does not crash - it is simply idle until I > press Ctrl+C. Run it inside gdb and Ctrl+C after it freezes. Then "bt". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From schnitzeltony at googlemail.com Tue Feb 14 00:18:06 2017 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Tue, 14 Feb 2017 00:18:06 +0100 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: <29745442.rIEqy38Z7a@tjmaciei-mobl1> References: <1829262.BzjvJY2XhL@tjmaciei-mobl1> <29745442.rIEqy38Z7a@tjmaciei-mobl1> Message-ID: On Mon, Feb 13, 2017 at 11:50 PM, Thiago Macieira wrote: > On segunda-feira, 13 de fevereiro de 2017 22:48:07 PST Andreas Müller via > Development wrote: >> > Anyway, I require them to be applied, so I need to know what's happening. >> > I >> > can't reproduce the issue locally. Can you provide the backtrace? >> >> Sorry but - how do I create a backtrace? Some gdb session and break or? >> >> You are aware qdbuscpp2xml does not crash - it is simply idle until I >> press Ctrl+C. > > Run it inside gdb and Ctrl+C after it freezes. Then "bt". > Aargh things could be so easy... I just ran a gdb session but debug information gets lost somewhere - only see non very helpful disassembler. Need to sort out where debug information gets lost or paths are aligned to break gdb... Andreas From schnitzeltony at googlemail.com Tue Feb 14 10:08:27 2017 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Tue, 14 Feb 2017 10:08:27 +0100 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: References: <1829262.BzjvJY2XhL@tjmaciei-mobl1> <29745442.rIEqy38Z7a@tjmaciei-mobl1> Message-ID: On Tue, Feb 14, 2017 at 12:18 AM, Andreas Müller wrote: > I just ran a gdb session but debug information gets lost somewhere - > only see non very helpful disassembler. Need to sort out where debug > information gets lost or paths are aligned to break gdb... > OK -g option was missing in my build. It is based on commit 49dc9aa409d727824f26b246054a22b5a7dd5980 + 2 Patches mentioned earlier. I started debug session with qtcreator and interrupted on idle several times with same result - see attachment. Hope that helps... Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: qdbuscpp2xml.tasks Type: application/octet-stream Size: 1652 bytes Desc: not available URL: From jani.heikkinen at qt.io Tue Feb 14 14:11:43 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 14 Feb 2017 13:11:43 +0000 Subject: [Development] First Qt 5.9 alpha snapshot available In-Reply-To: References: Message-ID: Hi all, You can find (soon, mirroring still ongoing) first qt 5.9 alpha snapshot (src only) from http://download.qt.io/snapshots/qt/5.9/5.9.0-alpha/latest_src/ Those aren't yet official alpha src packages but quite close so please inform me immediately if you notice something important missing Known issues: https://bugreports.qt.io/issues/?filter=18372 br, Jani From thiago.macieira at intel.com Tue Feb 14 21:34:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Feb 2017 12:34:01 -0800 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: References: Message-ID: <3603499.sEos6eHTZT@tjmaciei-mobl1> Em terça-feira, 14 de fevereiro de 2017, às 10:08:27 PST, Andreas Müller via Development escreveu: > On Tue, Feb 14, 2017 at 12:18 AM, Andreas Müller > > wrote: > > I just ran a gdb session but debug information gets lost somewhere - > > only see non very helpful disassembler. Need to sort out where debug > > information gets lost or paths are aligned to break gdb... > > OK -g option was missing in my build. It is based on commit > 49dc9aa409d727824f26b246054a22b5a7dd5980 + 2 Patches mentioned > earlier. > I started debug session with qtcreator and interrupted on idle several > times with same result - see attachment. Hope that helps... No, sorry, it didn't. Please do as I asked: run it inside gdb, then when it freezes, Ctrl+C and run "bt" from the (gdb) prompt. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From wim.delvaux at adaptiveplanet.com Tue Feb 14 23:46:45 2017 From: wim.delvaux at adaptiveplanet.com (wim delvaux) Date: Tue, 14 Feb 2017 23:46:45 +0100 Subject: [Development] Qt::MatchRecursive on QTreeWidget does not work Message-ID: I have this code on a QTreeWidget in Qt 5.7 on Linux Qt::MatchFlags F = Qt::MatchRecursive | Qt::MatchContains | Qt::MatchWrap | Qt::MatchFixedString; if( ui->Regex_CB->isChecked() ) { F |= Qt::MatchRegExp; } CurrentMatches = ui->Output_TW->findItems( Txt, F ); I would expect the currentMatches to contain all items that contain a Txt snippet. However it only returns the items with the text snippet in column 0 help! Thx W -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Feb 15 01:17:33 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 15 Feb 2017 01:17:33 +0100 Subject: [Development] Qt::MatchRecursive on QTreeWidget does not work In-Reply-To: References: Message-ID: <201702150117.33943.marc.mutz@kdab.com> On Tuesday 14 February 2017 23:46:45 wim delvaux wrote: > I have this code on a QTreeWidget in Qt 5.7 on Linux > > Qt::MatchFlags F = Qt::MatchRecursive | Qt::MatchContains | > Qt::MatchWrap | Qt::MatchFixedString; > > if( ui->Regex_CB->isChecked() ) { > F |= Qt::MatchRegExp; > } > > CurrentMatches = ui->Output_TW->findItems( Txt, F ); > > I would expect the currentMatches to contain all items that contain a Txt > snippet. However it only returns the items with the text snippet in column > 0 Please provide a self-contained example and file an issue at bugreports.qt.io. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From wim.delvaux at adaptiveplanet.com Wed Feb 15 03:01:28 2017 From: wim.delvaux at adaptiveplanet.com (wim delvaux) Date: Wed, 15 Feb 2017 03:01:28 +0100 Subject: [Development] Qt::MatchRecursive on QTreeWidget does not work In-Reply-To: <201702150117.33943.marc.mutz@kdab.com> References: <201702150117.33943.marc.mutz@kdab.com> Message-ID: First let me say that I am no newbie to Qt. In fact I have been using Qt since v 1. I checked the source code and found this in qtreewidget.cpp (near line 3050) method findItems d->model->match(model()->index(0, column, QModelIndex()), Qt::DisplayRole, text, -1, flags ); The model is a QTreeModel (in qtreewidget_p.h) Now QAbstractItemModel says that in order to search in multiple columns, one needs to reimplement the match method. Now QTreeModel does not do this. So how can Qt::MatchRecursive work ? W On Wed, Feb 15, 2017 at 1:17 AM, Marc Mutz wrote: > On Tuesday 14 February 2017 23:46:45 wim delvaux wrote: > > I have this code on a QTreeWidget in Qt 5.7 on Linux > > > > Qt::MatchFlags F = Qt::MatchRecursive | Qt::MatchContains | > > Qt::MatchWrap | Qt::MatchFixedString; > > > > if( ui->Regex_CB->isChecked() ) { > > F |= Qt::MatchRegExp; > > } > > > > CurrentMatches = ui->Output_TW->findItems( Txt, F ); > > > > I would expect the currentMatches to contain all items that contain a Txt > > snippet. However it only returns the items with the text snippet in > column > > 0 > > Please provide a self-contained example and file an issue at > bugreports.qt.io. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt, C++ and OpenGL Experts > -------------- next part -------------- An HTML attachment was scrubbed... URL: From schnitzeltony at googlemail.com Wed Feb 15 09:10:55 2017 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Wed, 15 Feb 2017 09:10:55 +0100 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: <3603499.sEos6eHTZT@tjmaciei-mobl1> References: <3603499.sEos6eHTZT@tjmaciei-mobl1> Message-ID: On Tue, Feb 14, 2017 at 9:34 PM, Thiago Macieira wrote: > Em terça-feira, 14 de fevereiro de 2017, às 10:08:27 PST, Andreas Müller via > Development escreveu: >> On Tue, Feb 14, 2017 at 12:18 AM, Andreas Müller >> >> wrote: >> > I just ran a gdb session but debug information gets lost somewhere - >> > only see non very helpful disassembler. Need to sort out where debug >> > information gets lost or paths are aligned to break gdb... >> >> OK -g option was missing in my build. It is based on commit >> 49dc9aa409d727824f26b246054a22b5a7dd5980 + 2 Patches mentioned >> earlier. >> I started debug session with qtcreator and interrupted on idle several >> times with same result - see attachment. Hope that helps... > > No, sorry, it didn't. > > Please do as I asked: run it inside gdb, then when it freezes, Ctrl+C and run > "bt" from the (gdb) prompt. > Meanwhile I installed glibc debug info packs. You sequence does not work as expected: Type "apropos word" to search for commands related to "word"... Reading symbols from /home/a.mueller/tmp/oe-core-glibc/work/x86_64-linux/qtbase-native/5.8.0+gitAUTOINC+49dc9aa409-r0/image/home/a.mueller/tmp/oe-core-glibc/sysroots/x86_64-linux/usr/bin/qt5/qdbuscpp2xml...done. (gdb) Quit (gdb) bt No stack. If I attach to running qdbuscpp2xml I get what's attached - there is no reaction on Ctrl+C Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: qdbuscpp2xml.btrace Type: application/octet-stream Size: 2766 bytes Desc: not available URL: From sean.harmer at kdab.com Wed Feb 15 10:36:33 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Wed, 15 Feb 2017 09:36:33 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> Message-ID: <1827326.MVTkkocP57@cartman> First of all, apologies for not being able to make the release meeting yesterday. I was in a workshop all day. For the record I think skipping 5.8.1 is a big mistake. I would much rather delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and try for a quick 5.9.0. Why would releasing 5.8.1 take as long as a .0 release if nothing much has changed in the packaging and build system? I think our users, your paying customers, would rather have a .1 release than another .0. In our experience, many customers explicitly do not use .0 releases. So for these we are condemning them to wait 3/4 of a year or so to be able to go from 5.7.1 to 5.9.1. Imho, a bug fix release should take priority over a feature release. Also, the number of downloads is no measure of the quality of a release. There are plenty of fixes available on the 5.8 branch across pretty much all modules ready to go now. I appreciate the packages will still need testing, but surely this is mainly functional testing for 5.8.1 given the packaging should not have changed since 5.8.0. We could branch 5.8.1 now and be generating the first set of test packages before the 5.9 beta. The reason of not wanting to do a bug fix release in conjunction with a feature release due to limited resources is particularly galling when we read yesterday that TQC have decided to release an *old* 5.5.1 release for Vx Works. Those resources could have been used towards a Qt 5.8.1 over the last month. There is still a very real risk that we will be late with the 5.9.0 release given the large changes to the configuration system in 5.9. Having a 5.8.1 release is a way to mitigate that risk too. It wasn't so long ago Tuukka, that you wanted to do a quick 5.8.1 release after there had been such a huge delay between 5.7.0 and 5.7.1. Please do not go back on this and let the users have a bug fix release. Are there really features in 5.9 that customers cannot live without for an extra 4-6 weeks whilst we prepare a 5.8.1 release? I very much doubt it. Kind regards, Sean On Friday 10 February 2017 10:59:56 Tuukka Turunen wrote: > Hi, > > Short summary: The Qt Company has decided to focus development effort to 5.9 > and dev branches in order to reach the planned timeline for Qt 5.9 release > and make improvements in the CI system. Next scheduled patch level release > would be Qt 5.6.3 straight after Qt 5.9 is out. In case of severe security > vulnerability we would make Qt 5.8.1 directly based on 5.8.0 with just the > security fix(es) added. > Qt 5.8.0 looks to be a good and successful release. It has already been > downloaded 150.000 times even though it was released just two weeks ago. > The reception has been good overall and there are no blockers reported > based on the release. Qt 5.9 and subsequent releases will leverage the new > configuration system and other major improvements introduced with it, as > well as add new functionality to make Qt even better. > It took us a more time than planned to get Qt 5.8 out and because of that we > are already past Qt 5.9 feature freeze and approaching the alpha release > soon. Looking into the reasons why Qt 5.8.0 was delayed there are 3 items > that had a significant effect: 1. We did not keep the feature freeze > properly as there were some items we wanted to get in – doing so we should > have replanned the whole release time, but we tried to keep schedule and > failed. 2. We were not able to focus enough to Qt 5.8 finalization as there > was quite a lot of effort going still to Qt 5.6.x and 5.7.x patch releases > in parallel – and our systems and processes are not yet good enough for > this. 3. We have had some issues in the CI system that cause integrations > to fail and thus increase system load – these are now being addressed > (getting new HW in place, change to a better virtualization platform, use > local disks instead of central disk, reduce number of flaky tests, etc). > We believe it will be possible to significantly reduce the time from feature > freeze to release. To reach this we need to improve the items that have > been problematic with Qt 5.8 and other releases. After we have done the > improvements, it will be easier to keep the timelines and also be more > productive. We absolutely do not want to rush a new release out with severe > bugs in it – not now and not in the future – for this reason we want to > focus into the processes and systems part and allow more efficient release > creation. First we want to be able to reach the current 17 weeks timeline > from FF to release with Qt 5.9. After that we want to reduce it gradually > to 10-12 weeks (for a new minor release of Qt). Increased productivity will > allow us to make more patch releases than before. > In the CI system side we have major improvements happening during this year. > We will be purchasing more blades and other HW during H1/17, which will add > capacity, so we will be able to run more parallel integrations. We are also > looking into changing the system architecture away from central disk into > using local ssd for build machines. This is expected to bring improvements > to both performance and reliability (especially now as we have had issues > with disks failing despite the disk system still being in the mid of its > life-cycle). Third item we are looking into is change of the virtualization > platform, which we hope will bring improvements in stability as well as new > capabilities. > Arranging enough time to implement the improvements in our systems as well > as keeping the timeline of Qt 5.9 despite delayed 5.8 release unfortunately > means that we can’t make any scheduled patch releases until June, after Qt > 5.9 is out. We will keep the ability to release patch release for urgent > security vulnerabilities, as always. Such release would be on top of the > previous patch release and not include all other changes in the > corresponding branch. Even with a lot more help from community than before, > making a scheduled Qt 5.8.1 release parallel with Qt 5.9 has impact to the > system load as well as to the work needed from the release team and > others. > I am well aware that a Qt 5.8.1 release would be beneficial, but making one > now would impact Qt 5.9 schedule and our capability to improve CI system > stability. Qt 5.6.3 LTS patch release is done straight after Qt 5.9 > release, but not before. After the Qt 5.9.0 in May we should then focus > into making Qt 5.9.1 release instead of making Qt 5.8.1 any more as Qt > 5.9.0 is already out. With the CI improvements in place, we should > definitely be able to make more than one patch release for Qt 5.9. > As a scheduled Qt 5.8.1 release is not planned, should we start pushing > fixes directly to 5.9 branch now? It would reduce the workload as we do not > need to first integrate changes into 5.8 and then merge upwards to 5.9. It > would also reduce the time it takes to get fixes into to 5.9 and dev as > well as reduce the load to the CI system as less integrations are needed. > We can keep 5.8 branch open for a while still similarly as 5.6 is in case > there is some fix that must be in the 5.8 branch. Let’s discuss in the next > release team meeting (Tuesday 14th Feb 16.00 CET) if pushing fixes to 5.9 > branch directly would be good approach. > Yours, > > Tuukka > > > > > -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From marc.mutz at kdab.com Wed Feb 15 11:11:15 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 15 Feb 2017 11:11:15 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <1827326.MVTkkocP57@cartman> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <1827326.MVTkkocP57@cartman> Message-ID: <201702151111.15825.marc.mutz@kdab.com> On Wednesday 15 February 2017 10:36:33 Sean Harmer wrote: > First of all, apologies for not being able to make the release meeting > yesterday. I was in a workshop all day. > > For the record I think skipping 5.8.1 is a big mistake. I would much rather > delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and try > for a quick 5.9.0. Amen. I would like to add that this decision, made behind closed doors, does not match well with Qt-as-an-open-governance-project. In particular, it feels like we OSS contributors are being held hostage here. If you close the 5.8 CI, anything we can do, incl. following the dictate of TQC to focus on 5.9, will hurt Qt users one way or another. Either we fragment Qt by releasing a 5.8.1 without TQC backing or we leave users hanging in the air for extended periods of time without the ability for bugfixes. Both are unacceptable, IMHO. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From net147 at gmail.com Wed Feb 15 11:15:13 2017 From: net147 at gmail.com (Jonathan Liu) Date: Wed, 15 Feb 2017 21:15:13 +1100 Subject: [Development] QtWebChannel: Upstreaming of Python client In-Reply-To: References: <200afb57-55a0-14f7-c27e-bf9852cca9e4@menlosystems.com> <7602FCC9-32D8-495D-B87D-EB90735D6BDD@qt.io> Message-ID: Hi Arno, On 26 October 2016 at 19:32, Arno Rehn wrote: > On 25.10.2016 13:36, Johannes Lochmann wrote: > >> Hi Arno, >> >> On 24 October 2016 at 00:53, Arno Rehn >>> wrote: >>> >>>> Hey everybody, >>>> >>>> At my company we've developed a Python client for QtWebChannel. >>>> It consists of a more or less direct translation of >>>> qwebchannel.js and an additional layer on top of it, providing >>>> async/await syntax support for Python3.5+. Ideally, we'd like to >>>> push this upstream. Before I post a patch to gerrit, I'd like to >>>> get some feedback on whether this is wanted at all. QtWebChannel >>>> seems to be pretty much focused on HTML and the web, but the >>>> infrastructure behind it can be used for remoting from pretty >>>> much any scripting language. I'd also plan on implementing a C++ >>>> client, maybe also Ruby and Matlab (since we're using this in a >>>> scientific setting). >>>> >>>> What's your take on this? >>>> >>> >>> Seems useful. Would be interested to try it out. >>> >> >> I agree, this sounds pretty useful, especially given that we’re also >> working again on pyside since this spring. >> >> ...especially an implementation in Python and C++ both from the Qt >> Project could be a really nice combo - sign me up! >> > Thanks for all the feedback! Nice to know that people are interested :) > I'll polish the code a little and create a review request. Did this ever get followed up? Regards, Jonathan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at qt.io Wed Feb 15 11:38:45 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 15 Feb 2017 10:38:45 +0000 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: References: , Message-ID: Hi all, As you know we need to optimize our systems to be able to keep our plans in the future. In CI side we are handling at least 4 different branches at same time. Releasing side we should be able to do many releases/snapshots parallel, test those releases/snapshots parallel etc. And all this needs lots of hw capasity (both calculating power & disc space). We are trying to analyze the places where to do optimization and one place is our src package creation and delivery: At the moment we are doing, testing & delivering single src packages + separate submodule src packages, all these with .zip, .7z, .tar.gz & .tar.xz! Huge amount of src packages/snapshot/release. And currently doing these both for enterprise and lgpl! In the future (5.10?) we should be able to use unified ones meaning no separate LGPL & enterprise ones. But I think we could also drop those less used ones(*) as well with quicker schedule so I propose: From 5.9 -> let's start doing & delivering - One set of src packages with ẃindows line endings (.zip, both single one & submodule specific, both enterprise and lgpl) - One set of src packages with unix line endings (.tar.gz, both single one & submodule specific, both enterprise and lgpl) br, Jani *:Download statistic: .7z 7% .tar.gz 44% .tar.xz 12% .zip 37% From annulen at yandex.ru Wed Feb 15 11:46:20 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 15 Feb 2017 13:46:20 +0300 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: References: , Message-ID: <101421487155580@web24o.yandex.ru> 15.02.2017, 13:39, "Jani Heikkinen" : > Hi all, > > As you know we need to optimize our systems to be able to keep our plans in the future. In CI side we are handling at least 4 different branches at same time. Releasing side we should be able to do many releases/snapshots parallel, test those releases/snapshots parallel etc. And all this needs lots of hw capasity (both calculating power & disc space). > > We are trying to analyze the places where to do optimization and one place is our src package creation and delivery: At the moment we are doing, testing & delivering single src packages + separate submodule src packages, all these with .zip, .7z, .tar.gz & .tar.xz! Huge amount of src packages/snapshot/release. And currently doing these both for enterprise and lgpl! In the future (5.10?) we should be able to use unified ones meaning no separate LGPL & enterprise ones. > > But I think we could also drop those less used ones(*) as well with quicker schedule so I propose: > > From 5.9 -> let's start doing & delivering > > - One set of src packages with ẃindows line endings (.zip, both single one & submodule specific, both enterprise and lgpl) > - One set of src packages with unix line endings (.tar.gz, both single one & submodule specific, both enterprise and lgpl) Why not use most efficient compression formats instead, i.e. keep 7z and tar.xz only? > > br, > Jani > > *:Download statistic: > .7z 7% > .tar.gz 44% > .tar.xz 12% > .zip 37% > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From jani.heikkinen at qt.io Wed Feb 15 12:07:39 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 15 Feb 2017 11:07:39 +0000 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <101421487155580@web24o.yandex.ru> References: , , <101421487155580@web24o.yandex.ru> Message-ID: >>Why not use most efficient compression formats instead, i.e. keep 7z and tar.xz only? well, of course this would be possible as well but this would be a change to existing "behavior" : Currently 7z is with unix line endings. And as you can see from statistic tar.gz and .zip are most used ones and so on it would be quite reasonable to continue offering those br, Jani ________________________________________ From: Konstantin Tokarev Sent: Wednesday, February 15, 2017 12:46 PM To: Jani Heikkinen; development at qt-project.org Cc: releasing at qt-project.org Subject: Re: [Development] Decrease amounth of delivered src packages 15.02.2017, 13:39, "Jani Heikkinen" : > Hi all, > > As you know we need to optimize our systems to be able to keep our plans in the future. In CI side we are handling at least 4 different branches at same time. Releasing side we should be able to do many releases/snapshots parallel, test those releases/snapshots parallel etc. And all this needs lots of hw capasity (both calculating power & disc space). > > We are trying to analyze the places where to do optimization and one place is our src package creation and delivery: At the moment we are doing, testing & delivering single src packages + separate submodule src packages, all these with .zip, .7z, .tar.gz & .tar.xz! Huge amount of src packages/snapshot/release. And currently doing these both for enterprise and lgpl! In the future (5.10?) we should be able to use unified ones meaning no separate LGPL & enterprise ones. > > But I think we could also drop those less used ones(*) as well with quicker schedule so I propose: > > From 5.9 -> let's start doing & delivering > > - One set of src packages with ẃindows line endings (.zip, both single one & submodule specific, both enterprise and lgpl) > - One set of src packages with unix line endings (.tar.gz, both single one & submodule specific, both enterprise and lgpl) Why not use most efficient compression formats instead, i.e. keep 7z and tar.xz only? > > br, > Jani > > *:Download statistic: > .7z 7% > .tar.gz 44% > .tar.xz 12% > .zip 37% > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From kevin.kofler at chello.at Wed Feb 15 12:28:11 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 15 Feb 2017 12:28:11 +0100 Subject: [Development] Decrease amounth of delivered src packages References: <101421487155580@web24o.yandex.ru> Message-ID: Jani Heikkinen wrote: > well, of course this would be possible as well but this would be a change > to existing "behavior" : Currently 7z is with unix line endings. And as > you can see from statistic tar.gz and .zip are most used ones and so on it > would be quite reasonable to continue offering those I would kindly request you to at least use tar.xz (rather than tar.gz) for the tarballs. (What you use as the Windows format is something you need to sort out with the Windows people.) The fact that tar.gz is still the most downloaded is probably mostly out of habit, or maybe your download site is directing to them by default (which ought to be fixed anyway, even if you were to keep both). tar.gz has no advantage over tar.xz, it is just a lot larger. Switching to the tar.gz tarballs (from the tar.xz tarballs that are currently used) would increase the size of distributions' source packages (source RPM etc.) significantly. It is sad that the legacy gzip compression is living a renaissance due to automatic tarball exports from GitHub and the like producing only that format. It should finally be retired now that there are algorithms that are just as open and that compress significantly better. At least for projects like Qt that produce their own tarballs and are already able to produce xz- compressed ones, I see no reason whatsoever to switch back to the obsolete gzip. The bzip2 (tar.bz2) compression is also obsoleted by xz nowadays, I see no good reason to pick that one either. Kevin Kofler From Shawn.Rutledge at qt.io Wed Feb 15 12:52:50 2017 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Wed, 15 Feb 2017 11:52:50 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201702151111.15825.marc.mutz@kdab.com> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <1827326.MVTkkocP57@cartman> <201702151111.15825.marc.mutz@kdab.com> Message-ID: <5BD146E6-0AA4-4288-A25B-7237073FF9C2@qt.io> > On 15 Feb 2017, at 11:11, Marc Mutz wrote: > > On Wednesday 15 February 2017 10:36:33 Sean Harmer wrote: >> First of all, apologies for not being able to make the release meeting >> yesterday. I was in a workshop all day. >> >> For the record I think skipping 5.8.1 is a big mistake. I would much rather >> delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and try >> for a quick 5.9.0. > > Amen. > > I would like to add that this decision, made behind closed doors, does not > match well with Qt-as-an-open-governance-project. In particular, it feels like > we OSS contributors are being held hostage here. If you close the 5.8 CI, > anything we can do, incl. following the dictate of TQC to focus on 5.9, will > hurt Qt users one way or another. Either we fragment Qt by releasing a 5.8.1 > without TQC backing or we leave users hanging in the air for extended periods > of time without the ability for bugfixes. Both are unacceptable, IMHO. There are a lot of potential bug fixes. Skipping 5.8.1 might pull some users into upgrading to 5.9 sooner than they might otherwise, which is good from one side, but the ones who are afraid of new features and new regressions will resist. So I think it’s a mistake because of those people… but I always think those people should be less afraid of new releases, too. (Just try it… how bad can it be. Soon enough you will know if there are regressions that affect you. If so, get patches for them and apply them locally. If there’s no patch, write one and contribute. That helps everyone.) Some Linux distros will pull in some newer patches for their custom 5.8.0 builds. FWIW the discussion was on #qt-releases, not exactly behind closed doors. From mitya57.ml at gmail.com Wed Feb 15 13:05:06 2017 From: mitya57.ml at gmail.com (Dmitry Shachnev) Date: Wed, 15 Feb 2017 15:05:06 +0300 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: References: <101421487155580@web24o.yandex.ru> Message-ID: <20170215120506.jyhwmb7yyxn36ife@mitya57.me> On Wed, Feb 15, 2017 at 12:28:11PM +0100, Kevin Kofler wrote: > I would kindly request you to at least use tar.xz (rather than tar.gz) for > the tarballs. (What you use as the Windows format is something you need to > sort out with the Windows people.) The fact that tar.gz is still the most > downloaded is probably mostly out of habit, or maybe your download site is > directing to them by default (which ought to be fixed anyway, even if you > were to keep both). tar.gz has no advantage over tar.xz, it is just a lot > larger. Switching to the tar.gz tarballs (from the tar.xz tarballs that are > currently used) would increase the size of distributions' source packages > (source RPM etc.) significantly. > > It is sad that the legacy gzip compression is living a renaissance due to > automatic tarball exports from GitHub and the like producing only that > format. It should finally be retired now that there are algorithms that are > just as open and that compress significantly better. At least for projects > like Qt that produce their own tarballs and are already able to produce xz- > compressed ones, I see no reason whatsoever to switch back to the obsolete > gzip. +1, please leave tar.xz instead of tar.gz. Users of all modern UNIX-like systems are able to decompress tar.xz, so .gz has really no advantage over .xz. -- Dmitry Shachnev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From roland.m.winklmeier at gmail.com Wed Feb 15 13:14:03 2017 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Wed, 15 Feb 2017 13:14:03 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <5BD146E6-0AA4-4288-A25B-7237073FF9C2@qt.io> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <1827326.MVTkkocP57@cartman> <201702151111.15825.marc.mutz@kdab.com> <5BD146E6-0AA4-4288-A25B-7237073FF9C2@qt.io> Message-ID: 2017-02-15 12:52 GMT+01:00 Shawn Rutledge : > > > On 15 Feb 2017, at 11:11, Marc Mutz wrote: > > > > On Wednesday 15 February 2017 10:36:33 Sean Harmer wrote: > >> First of all, apologies for not being able to make the release meeting > >> yesterday. I was in a workshop all day. > >> > >> For the record I think skipping 5.8.1 is a big mistake. I would much > rather > >> delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and > try > >> for a quick 5.9.0. > > > > Amen. > > > > I would like to add that this decision, made behind closed doors, does > not > > match well with Qt-as-an-open-governance-project. In particular, it > feels like > > we OSS contributors are being held hostage here. If you close the 5.8 CI, > > anything we can do, incl. following the dictate of TQC to focus on 5.9, > will > > hurt Qt users one way or another. Either we fragment Qt by releasing a > 5.8.1 > > without TQC backing or we leave users hanging in the air for extended > periods > > of time without the ability for bugfixes. Both are unacceptable, IMHO. > > There are a lot of potential bug fixes. Skipping 5.8.1 might pull some > users into upgrading to 5.9 sooner than they might otherwise, which is good > from one side, but the ones who are afraid of new features and new > regressions will resist. So I think it’s a mistake because of those > people… > Speaking for myself, I also think, skipping 5.8.1 is a mistake. We just upgraded our project from 5.6 to 5.8 and realized that it had several regressions. For example we are using a QNetworkAccessManager and for random reasons it always switches to NotAccessible after some minutes. No recovery possible except restarting the application. I wonder why nobody else got affected by this. I _think_ the cause was QTBUG-51543, even though I never finally understood whats going on. In any case, the fix for this bug went into 5.8.1, which now won't get released. For me this is very frustrating, since we counted our next milestone on an early 5.8.1 release. Now I would have to wait for 5.9.0 which is planned end of May if everything goes smooth. Even then, there is no guarantee that there is no new regression which would require 5.9.1 release. I also can't produce custom builds, since I never managed to create a custom offline installer for my team members (we are are non profil OSS group without many infrastructure and resources). I do regular builds of Qt itself, but the rest is out of my capabilities. In summary, for me it is very unfortunate that I have to delay our milestone minimum until June if everything goes well. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Feb 15 13:39:36 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 15 Feb 2017 13:39:36 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <5BD146E6-0AA4-4288-A25B-7237073FF9C2@qt.io> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <201702151111.15825.marc.mutz@kdab.com> <5BD146E6-0AA4-4288-A25B-7237073FF9C2@qt.io> Message-ID: <201702151339.37208.marc.mutz@kdab.com> On Wednesday 15 February 2017 12:52:50 Shawn Rutledge wrote: > FWIW the discussion was on #qt-releases, not exactly behind closed doors. Everything that doesn't happen in a QUIP or on this mailing-list, or to a lesser extent, Gerrit, is behind closed doors. All that was posted to this ML was: On Friday 10 February 2017 11:59:56 Tuukka Turunen wrote: > Short summary: The Qt Company has decided to focus development effort to > 5.9 [...] > In case of severe > security vulnerability we would make Qt 5.8.1 directly based on 5.8.0 with > just the security fix(es) added. "The Qt Company has decided", not "discussions on #qt-releases indicated, here's the protocol, what do you think?", as we had with QtCS sessions. I didn't want to, but I took that kind of opening as a frontal — personal — assault on me as a Qt Project contributor as well as Qt user. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From lkorbel at milosolutions.com Wed Feb 15 13:37:11 2017 From: lkorbel at milosolutions.com (=?UTF-8?Q?=C5=81ukasz_Korbel?=) Date: Wed, 15 Feb 2017 13:37:11 +0100 Subject: [Development] Threads and the SQL Module Message-ID: According to http://doc.qt.io/qt-5/threads-modules.html#threads-and-the-sql-module database connection should be used within one thread *only*. I have checked SQLite driver and according to https://www.sqlite.org/threadsafe.html it supports multithreading by default. And it seems that Qt implementation does not restrict it ( http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp#n645). Code I'm working on is creating QSqlQuery for the same connection in different threads and it works. I understand it doesn't mean Qt want or need to support such use case but maybe documentation can be slightly more accurate? Right now it implies that database connection can never be used from different threads but it seem it depends more on particular driver/3rdparty lib. *Łukasz Korbel * Senior Software Developer Email: lkorbel at milosolutions.com Skype: lukasz_korbel *Milo Solutions* www.milosolutions.com | Facebook | Twitter Disclaimer: This e-mail and any attachments contain information that may be privileged or confidential and is the property of Milo Solutions. If you are not the intended recipient, please notify me immediately by replying to this e-mail, and then delete it. Any unauthorised dissemination, distribution, copying or use of this communication is strictly prohibited. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. Although this e-mail and any files attached to it may have been checked with virus detection software before transmission you should carry out your own virus checks before opening the attachment. No liability can be accepted for any damage which you may sustain as a result of software viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Wed Feb 15 14:33:38 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Wed, 15 Feb 2017 13:33:38 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <5BD146E6-0AA4-4288-A25B-7237073FF9C2@qt.io> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <201702151111.15825.marc.mutz@kdab.com> <5BD146E6-0AA4-4288-A25B-7237073FF9C2@qt.io> Message-ID: <2282272.1SWe2ltiUg@cartman> On Wednesday 15 February 2017 11:52:50 Shawn Rutledge wrote: > > On 15 Feb 2017, at 11:11, Marc Mutz wrote: > > > > On Wednesday 15 February 2017 10:36:33 Sean Harmer wrote: > > > >> First of all, apologies for not being able to make the release meeting > >> yesterday. I was in a workshop all day. > >> > >> For the record I think skipping 5.8.1 is a big mistake. I would much > >> rather delay 5.9 by a few weeks and have a 5.8.1 release out than skip > >> it and try for a quick 5.9.0. > > > > > > Amen. > > > > I would like to add that this decision, made behind closed doors, does not > > match well with Qt-as-an-open-governance-project. In particular, it > > feels like we OSS contributors are being held hostage here. If you close > > the 5.8 CI, anything we can do, incl. following the dictate of TQC to > > focus on 5.9, will hurt Qt users one way or another. Either we fragment > > Qt by releasing a 5.8.1 without TQC backing or we leave users hanging in > > the air for extended periods of time without the ability for bugfixes. > > Both are unacceptable, IMHO. > > There are a lot of potential bug fixes. Skipping 5.8.1 might pull some > users into upgrading to 5.9 sooner than they might otherwise, which is good > from one side, but the ones who are afraid of new features and new > regressions will resist. So I think it’s a mistake because of those > people… but I always think those people should be less afraid of new > releases, too. (Just try it… how bad can it be. Soon enough you will know > if there are regressions that affect you. If so, get patches for them and > apply them locally. If there’s no patch, write one and contribute. That > helps everyone.) That assumes users a) have the ability, b) have the time, c) have company permission to create such patches. And regressions like this can prevent users from upgrading to new feature releases. As a case in point, see https://bugreports.qt.io/browse/QTBUG-58679 > Some Linux distros will pull in some newer patches for their custom 5.8.0 > builds. Sure, but what about Windows, macOS, Android, iOS, ... ? > FWIW the discussion was on #qt-releases, not exactly behind closed doors. The initial discussion was announced by Tuukka as the OP of this thread which presented it as pretty much a done deal. And, as Marc says, if the Qt Project disagrees, what can we do about it without fragmenting? Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From schnitzeltony at googlemail.com Wed Feb 15 14:55:03 2017 From: schnitzeltony at googlemail.com (=?UTF-8?Q?Andreas_M=C3=BCller?=) Date: Wed, 15 Feb 2017 14:55:03 +0100 Subject: [Development] [meta-qt5] Qt5.8 qdbuscpp2xml broken for kde baloo? In-Reply-To: References: <3603499.sEos6eHTZT@tjmaciei-mobl1> Message-ID: On Wed, Feb 15, 2017 at 9:10 AM, Andreas Müller wrote: > On Tue, Feb 14, 2017 at 9:34 PM, Thiago Macieira > wrote: >> Em terça-feira, 14 de fevereiro de 2017, às 10:08:27 PST, Andreas Müller via >> Development escreveu: >>> On Tue, Feb 14, 2017 at 12:18 AM, Andreas Müller >>> >>> wrote: >>> > I just ran a gdb session but debug information gets lost somewhere - >>> > only see non very helpful disassembler. Need to sort out where debug >>> > information gets lost or paths are aligned to break gdb... >>> >>> OK -g option was missing in my build. It is based on commit >>> 49dc9aa409d727824f26b246054a22b5a7dd5980 + 2 Patches mentioned >>> earlier. >>> I started debug session with qtcreator and interrupted on idle several >>> times with same result - see attachment. Hope that helps... >> >> No, sorry, it didn't. >> >> Please do as I asked: run it inside gdb, then when it freezes, Ctrl+C and run >> "bt" from the (gdb) prompt. >> > Meanwhile I installed glibc debug info packs. > > You sequence does not work as expected: > > Type "apropos word" to search for commands related to "word"... > Reading symbols from > /home/a.mueller/tmp/oe-core-glibc/work/x86_64-linux/qtbase-native/5.8.0+gitAUTOINC+49dc9aa409-r0/image/home/a.mueller/tmp/oe-core-glibc/sysroots/x86_64-linux/usr/bin/qt5/qdbuscpp2xml...done. > (gdb) Quit > (gdb) bt > No stack. > > If I attach to running qdbuscpp2xml I get what's attached - there is > no reaction on Ctrl+C > I've looked into this: It is strange that we have two occurrences of QDBusMetaTypeId::instance() in the backtrace. It seems that first call of QDBusMetaTypeId::instance() causes another call on itself finally which is blocked by glibc's __cxa_guard_acquire / syscall (SYS_futex, gi, _GLIBCXX_FUTEX_WAIT, expected, 0). I think QDBusMetaTypeId designed as singleton so calling QDBusMetaTypeId::instance() from QDBusMetaTypeId's constructor causes glibc to deadlock the operation. That's the sympthom.. Andreas From olivier at woboq.com Wed Feb 15 15:29:07 2017 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 15 Feb 2017 15:29:07 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <5BD146E6-0AA4-4288-A25B-7237073FF9C2@qt.io> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <201702151111.15825.marc.mutz@kdab.com> <5BD146E6-0AA4-4288-A25B-7237073FF9C2@qt.io> Message-ID: <9424659.CRLrLk4AEG@maurice> On Mittwoch, 15. Februar 2017 12:52:50 CET Shawn Rutledge wrote: > users into upgrading to 5.9 sooner than they might otherwise I don't think that's true. I even think it's the opposite. Users of 5.6.2 or 5.7.1, that did not upgrade to 5.8.0 because it is a .0 release will also have to wait 5.9.1, so it will even take more time with users on a older version. Which is the opposite of what we want. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From jhihn at gmx.com Wed Feb 15 15:50:53 2017 From: jhihn at gmx.com (Jason H) Date: Wed, 15 Feb 2017 15:50:53 +0100 Subject: [Development] Threads and the SQL Module In-Reply-To: References: Message-ID: An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Feb 15 17:50:47 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Feb 2017 08:50:47 -0800 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201702151339.37208.marc.mutz@kdab.com> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <5BD146E6-0AA4-4288-A25B-7237073FF9C2@qt.io> <201702151339.37208.marc.mutz@kdab.com> Message-ID: <18592171.nmaKQCfGbZ@tjmaciei-mobl1> Em quarta-feira, 15 de fevereiro de 2017, às 13:39:36 PST, Marc Mutz escreveu: > On Friday 10 February 2017 11:59:56 Tuukka Turunen wrote: > > Short summary: The Qt Company has decided to focus development effort to > > 5.9 > > [...] > > > In case of severe > > security vulnerability we would make Qt 5.8.1 directly based on 5.8.0 with > > just the security fix(es) added. > > "The Qt Company has decided", not "discussions on #qt-releases indicated, > here's the protocol, what do you think?", as we had with QtCS sessions. > > I didn't want to, but I took that kind of opening as a frontal — personal — > assault on me as a Qt Project contributor as well as Qt user. I choose to read that as "The Qt Company has decided to focus its own development effort to 5.9" which means the 80% of the workforce by volume of patches to Qt are going to 5.9. In addition, I read Tuukka's email as a proposal to the rest of the community to follow suit and make it a Qt Project decision. Until yesterday, there wasn't much a disagreement, so the release team took it as consensus decision from the community. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Feb 15 17:54:40 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Feb 2017 08:54:40 -0800 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <20170215120506.jyhwmb7yyxn36ife@mitya57.me> References: <20170215120506.jyhwmb7yyxn36ife@mitya57.me> Message-ID: <12713373.l1ioPss3yR@tjmaciei-mobl1> Em quarta-feira, 15 de fevereiro de 2017, às 15:05:06 PST, Dmitry Shachnev escreveu: > On Wed, Feb 15, 2017 at 12:28:11PM +0100, Kevin Kofler wrote: > > I would kindly request you to at least use tar.xz (rather than tar.gz) for > > the tarballs. (What you use as the Windows format is something you need to [cut] > +1, please leave tar.xz instead of tar.gz. > > Users of all modern UNIX-like systems are able to decompress tar.xz, so .gz > has really no advantage over .xz. Adding my voice to that. If data volume is an issue, then let's by all means standardise on .tar.xz. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at qt.io Wed Feb 15 18:00:09 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Wed, 15 Feb 2017 17:00:09 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <1827326.MVTkkocP57@cartman> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <1827326.MVTkkocP57@cartman> Message-ID: <216C8A23-4FFA-423A-BFE3-F6818BC6D739@qt.io> Hi Sean et al, First I want to say that I am also very sorry that we need to skip 5.8.1. Unfortunately I do not see any other approach that would allow us to: 1) catch the delay caused by 5.8 being late (and 5.7 being late, and 5.6 being late) and 2) enable implementation the much needed CI changes in good time before Qt 5.10 feature freeze. We tried really hard to keep somehow Qt 5.8 schedule or even get close to it, but the fact that we were maintaining 4 active branches (5.6, 5.7, 5.8 and dev) and feature freeze of 5.8 being late for some items seen critical to be in made it impossible to be faster. What could have been done, is to see this coming and plan 5.9 release for H2/17. But it was decided to keep the 6 month cycle and therefore development of 5.9 features was completed with the original schedule. New platforms to CI missed this due to 5.8 delay, but otherwise features were completed in time. Now that the FF is reached we should be as fast as possible to get the release out. We should hopefully be even faster than the planned 17 weeks. Getting the Alpha out next week would be a great start. As I wrote earlier, we have many much awaited changes coming to CI this year. These will help capacity definitely and stability hopefully. In addition, we are putting more focus into fixing the flaky cases, which has been a constant effort, but still an item that causes failed runs quite frequently. These changes need to go in well before the Qt 5.10 FF and due to summer holidays in June-August timeframe, we prefer June for most to put them into production. So due to these reasons postponing Qt 5.9 to June or July is not feasible. Making the first patch release is expected to take 4-6 weeks effort from release team, machines and also many developers. The tests run in the CI do not catch all issues and there will be multiple rounds needed to verify a new release on all our supported platforms. So, if we would do 5.8.1 now it would mean delay of 4-6 weeks to 5.9 schedule, and thus put the CI changes at risk due to vacation period and Qt 5.10 FF approaching. Even if there would be much higher amount of volunteers from the community to help in making 5.8.1 release, it would still cause delay to 5.9 schedule because of the load to the system and necessity of having The Qt Company developers and release engineers participate. It is a bit work to make even a patch release of Qt and we need to ensure high quality with every release we do. I think making just 1 patch release of 5.7 and none for 5.8 is really bad. Even with the help from our support team and possibility to work around issues. I would like us to use the time we now have to make sure Qt 5.9.0 is a solid release and that it is easy to make Qt 5.9.x patch releases during H2/17 with the CI improvements in place. Yours, Tuukka On 15/02/2017, 11.36, "sean.harmer on behalf of Sean Harmer" wrote: First of all, apologies for not being able to make the release meeting yesterday. I was in a workshop all day. For the record I think skipping 5.8.1 is a big mistake. I would much rather delay 5.9 by a few weeks and have a 5.8.1 release out than skip it and try for a quick 5.9.0. Why would releasing 5.8.1 take as long as a .0 release if nothing much has changed in the packaging and build system? I think our users, your paying customers, would rather have a .1 release than another .0. In our experience, many customers explicitly do not use .0 releases. So for these we are condemning them to wait 3/4 of a year or so to be able to go from 5.7.1 to 5.9.1. Imho, a bug fix release should take priority over a feature release. Also, the number of downloads is no measure of the quality of a release. There are plenty of fixes available on the 5.8 branch across pretty much all modules ready to go now. I appreciate the packages will still need testing, but surely this is mainly functional testing for 5.8.1 given the packaging should not have changed since 5.8.0. We could branch 5.8.1 now and be generating the first set of test packages before the 5.9 beta. The reason of not wanting to do a bug fix release in conjunction with a feature release due to limited resources is particularly galling when we read yesterday that TQC have decided to release an *old* 5.5.1 release for Vx Works. Those resources could have been used towards a Qt 5.8.1 over the last month. There is still a very real risk that we will be late with the 5.9.0 release given the large changes to the configuration system in 5.9. Having a 5.8.1 release is a way to mitigate that risk too. It wasn't so long ago Tuukka, that you wanted to do a quick 5.8.1 release after there had been such a huge delay between 5.7.0 and 5.7.1. Please do not go back on this and let the users have a bug fix release. Are there really features in 5.9 that customers cannot live without for an extra 4-6 weeks whilst we prepare a 5.8.1 release? I very much doubt it. Kind regards, Sean On Friday 10 February 2017 10:59:56 Tuukka Turunen wrote: > Hi, > > Short summary: The Qt Company has decided to focus development effort to 5.9 > and dev branches in order to reach the planned timeline for Qt 5.9 release > and make improvements in the CI system. Next scheduled patch level release > would be Qt 5.6.3 straight after Qt 5.9 is out. In case of severe security > vulnerability we would make Qt 5.8.1 directly based on 5.8.0 with just the > security fix(es) added. > Qt 5.8.0 looks to be a good and successful release. It has already been > downloaded 150.000 times even though it was released just two weeks ago. > The reception has been good overall and there are no blockers reported > based on the release. Qt 5.9 and subsequent releases will leverage the new > configuration system and other major improvements introduced with it, as > well as add new functionality to make Qt even better. > It took us a more time than planned to get Qt 5.8 out and because of that we > are already past Qt 5.9 feature freeze and approaching the alpha release > soon. Looking into the reasons why Qt 5.8.0 was delayed there are 3 items > that had a significant effect: 1. We did not keep the feature freeze > properly as there were some items we wanted to get in – doing so we should > have replanned the whole release time, but we tried to keep schedule and > failed. 2. We were not able to focus enough to Qt 5.8 finalization as there > was quite a lot of effort going still to Qt 5.6.x and 5.7.x patch releases > in parallel – and our systems and processes are not yet good enough for > this. 3. We have had some issues in the CI system that cause integrations > to fail and thus increase system load – these are now being addressed > (getting new HW in place, change to a better virtualization platform, use > local disks instead of central disk, reduce number of flaky tests, etc). > We believe it will be possible to significantly reduce the time from feature > freeze to release. To reach this we need to improve the items that have > been problematic with Qt 5.8 and other releases. After we have done the > improvements, it will be easier to keep the timelines and also be more > productive. We absolutely do not want to rush a new release out with severe > bugs in it – not now and not in the future – for this reason we want to > focus into the processes and systems part and allow more efficient release > creation. First we want to be able to reach the current 17 weeks timeline > from FF to release with Qt 5.9. After that we want to reduce it gradually > to 10-12 weeks (for a new minor release of Qt). Increased productivity will > allow us to make more patch releases than before. > In the CI system side we have major improvements happening during this year. > We will be purchasing more blades and other HW during H1/17, which will add > capacity, so we will be able to run more parallel integrations. We are also > looking into changing the system architecture away from central disk into > using local ssd for build machines. This is expected to bring improvements > to both performance and reliability (especially now as we have had issues > with disks failing despite the disk system still being in the mid of its > life-cycle). Third item we are looking into is change of the virtualization > platform, which we hope will bring improvements in stability as well as new > capabilities. > Arranging enough time to implement the improvements in our systems as well > as keeping the timeline of Qt 5.9 despite delayed 5.8 release unfortunately > means that we can’t make any scheduled patch releases until June, after Qt > 5.9 is out. We will keep the ability to release patch release for urgent > security vulnerabilities, as always. Such release would be on top of the > previous patch release and not include all other changes in the > corresponding branch. Even with a lot more help from community than before, > making a scheduled Qt 5.8.1 release parallel with Qt 5.9 has impact to the > system load as well as to the work needed from the release team and > others. > I am well aware that a Qt 5.8.1 release would be beneficial, but making one > now would impact Qt 5.9 schedule and our capability to improve CI system > stability. Qt 5.6.3 LTS patch release is done straight after Qt 5.9 > release, but not before. After the Qt 5.9.0 in May we should then focus > into making Qt 5.9.1 release instead of making Qt 5.8.1 any more as Qt > 5.9.0 is already out. With the CI improvements in place, we should > definitely be able to make more than one patch release for Qt 5.9. > As a scheduled Qt 5.8.1 release is not planned, should we start pushing > fixes directly to 5.9 branch now? It would reduce the workload as we do not > need to first integrate changes into 5.8 and then merge upwards to 5.9. It > would also reduce the time it takes to get fixes into to 5.9 and dev as > well as reduce the load to the CI system as less integrations are needed. > We can keep 5.8 branch open for a while still similarly as 5.6 is in case > there is some fix that must be in the 5.8 branch. Let’s discuss in the next > release team meeting (Tuesday 14th Feb 16.00 CET) if pushing fixes to 5.9 > branch directly would be good approach. > Yours, > > Tuukka > > > > > -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From konstantin at podsvirov.pro Wed Feb 15 18:04:12 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 15 Feb 2017 20:04:12 +0300 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <12713373.l1ioPss3yR@tjmaciei-mobl1> References: <20170215120506.jyhwmb7yyxn36ife@mitya57.me> <12713373.l1ioPss3yR@tjmaciei-mobl1> Message-ID: <1633941487178252@web14j.yandex.ru> An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Feb 15 18:07:18 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Feb 2017 09:07:18 -0800 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <1633941487178252@web14j.yandex.ru> References: <12713373.l1ioPss3yR@tjmaciei-mobl1> <1633941487178252@web14j.yandex.ru> Message-ID: <3601860.hXGhjxLTIf@tjmaciei-mobl1> On quarta-feira, 15 de fevereiro de 2017 09:04:12 PST Konstantin Podsvirov wrote: > This can be not quite on this topic, but I have a suggestion and MVP > implementation for QtIFW. > > > This may affect the development process, testing and create offline > installers. Most Valuable Player? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Wed Feb 15 18:08:31 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 15 Feb 2017 20:08:31 +0300 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <3601860.hXGhjxLTIf@tjmaciei-mobl1> References: <12713373.l1ioPss3yR@tjmaciei-mobl1> <1633941487178252@web14j.yandex.ru> <3601860.hXGhjxLTIf@tjmaciei-mobl1> Message-ID: <2055721487178511@web24o.yandex.ru> 15.02.2017, 20:07, "Thiago Macieira" : > On quarta-feira, 15 de fevereiro de 2017 09:04:12 PST Konstantin Podsvirov > wrote: >>  This can be not quite on this topic, but I have a suggestion and MVP >>  implementation for QtIFW. >> >>  This may affect the development process, testing and create offline >>  installers. > > Most Valuable Player? Most Valuable Professional? > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From alexandru.croitor at qt.io Wed Feb 15 18:09:52 2017 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Wed, 15 Feb 2017 17:09:52 +0000 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <2055721487178511@web24o.yandex.ru> References: <12713373.l1ioPss3yR@tjmaciei-mobl1> <1633941487178252@web14j.yandex.ru> <3601860.hXGhjxLTIf@tjmaciei-mobl1> <2055721487178511@web24o.yandex.ru> Message-ID: <6890F14A-CF02-470D-A4D6-B1FB32BE7C5C@qt.io> I think it's minimal viable product. > On 15 Feb 2017, at 18:08, Konstantin Tokarev wrote: > > > > 15.02.2017, 20:07, "Thiago Macieira" : >> On quarta-feira, 15 de fevereiro de 2017 09:04:12 PST Konstantin Podsvirov >> wrote: >>> This can be not quite on this topic, but I have a suggestion and MVP >>> implementation for QtIFW. >>> >>> This may affect the development process, testing and create offline >>> installers. >> >> Most Valuable Player? > > Most Valuable Professional? > >> >> -- >> Thiago Macieira - thiago.macieira (AT) intel.com >> Software Architect - Intel Open Source Technology Center >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Wed Feb 15 18:14:30 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 15 Feb 2017 18:14:30 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <18592171.nmaKQCfGbZ@tjmaciei-mobl1> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <201702151339.37208.marc.mutz@kdab.com> <18592171.nmaKQCfGbZ@tjmaciei-mobl1> Message-ID: <201702151814.30891.marc.mutz@kdab.com> On Wednesday 15 February 2017 17:50:47 Thiago Macieira wrote: > Em quarta-feira, 15 de fevereiro de 2017, às 13:39:36 PST, Marc Mutz escreveu: > > On Friday 10 February 2017 11:59:56 Tuukka Turunen wrote: > > > Short summary: The Qt Company has decided to focus development effort > > > to 5.9 > > > > [...] > > > > > In case of severe > > > security vulnerability we would make Qt 5.8.1 directly based on 5.8.0 > > > with just the security fix(es) added. > > > > "The Qt Company has decided", not "discussions on #qt-releases indicated, > > here's the protocol, what do you think?", as we had with QtCS sessions. > > > > I didn't want to, but I took that kind of opening as a frontal — personal > > — assault on me as a Qt Project contributor as well as Qt user. > > I choose to read that as "The Qt Company has decided to focus its own > development effort to 5.9" which means the 80% of the workforce by volume > of patches to Qt are going to 5.9. In addition, I read Tuukka's email as a > proposal to the rest of the community to follow suit and make it a Qt > Project decision. Yes, you can read the first sentence like that, but not the whole first paragraph, imo. That's why I quoted more than the first sentence. > Until yesterday, there wasn't much a disagreement, so the release team took > it as consensus decision from the community. Sure there was no disagreement. It was _w_e_e_k_e_n_d_. There was no agreement, either. I could also say that no-one came out in support today, so it's community consensus that 5.8.1 happens. Both interpretations are nonsense. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From konstantin at podsvirov.pro Wed Feb 15 18:23:00 2017 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 15 Feb 2017 20:23:00 +0300 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <6890F14A-CF02-470D-A4D6-B1FB32BE7C5C@qt.io> References: <12713373.l1ioPss3yR@tjmaciei-mobl1> <1633941487178252@web14j.yandex.ru> <3601860.hXGhjxLTIf@tjmaciei-mobl1> <2055721487178511@web24o.yandex.ru> <6890F14A-CF02-470D-A4D6-B1FB32BE7C5C@qt.io> Message-ID: <2406881487179380@web30m.yandex.ru> 15.02.2017, 20:10, "Alexandru Croitor" : > I think it's minimal viable product. Yes! It'w work for me now. You can try QtIFW (with --repository option) from my experimental installer for Windows: http://download.podsvirov.pro/installers/dad-0.3.1-windows-mingw64-unstable.exe > >>  On 15 Feb 2017, at 18:08, Konstantin Tokarev wrote: >> >>  15.02.2017, 20:07, "Thiago Macieira" : >>>  On quarta-feira, 15 de fevereiro de 2017 09:04:12 PST Konstantin Podsvirov >>>  wrote: >>>>   This can be not quite on this topic, but I have a suggestion and MVP >>>>   implementation for QtIFW. >>>> >>>>   This may affect the development process, testing and create offline >>>>   installers. >>> >>>  Most Valuable Player? >> >>  Most Valuable Professional? >> >>>  -- >>>  Thiago Macieira - thiago.macieira (AT) intel.com >>>    Software Architect - Intel Open Source Technology Center >>> >>>  _______________________________________________ >>>  Development mailing list >>>  Development at qt-project.org >>>  http://lists.qt-project.org/mailman/listinfo/development >> >>  -- >>  Regards, >>  Konstantin >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin Podsvirov From milian.wolff at kdab.com Wed Feb 15 20:07:36 2017 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 15 Feb 2017 20:07:36 +0100 Subject: [Development] QtWebChannel: Upstreaming of Python client In-Reply-To: References: <200afb57-55a0-14f7-c27e-bf9852cca9e4@menlosystems.com> Message-ID: <1572911.646YAUrLd6@agathebauer> On Mittwoch, 15. Februar 2017 11:15:13 CET Jonathan Liu wrote: > >> I agree, this sounds pretty useful, especially given that we’re also > >> working again on pyside since this spring. > >> > >> ...especially an implementation in Python and C++ both from the Qt > >> Project could be a really nice combo - sign me up! > > > > Thanks for all the feedback! Nice to know that people are interested :) > > I'll polish the code a little and create a review request. > > Did this ever get followed up? No, I never saw any request for review on gerrit. -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From lykurg at gmail.com Wed Feb 15 20:24:05 2017 From: lykurg at gmail.com (Lorenz Haas) Date: Wed, 15 Feb 2017 20:24:05 +0100 Subject: [Development] Threads and the SQL Module In-Reply-To: References: Message-ID: Hi, AFAIS it does not matter if sqlite is thread safe or not. The problem is that QSQLiteDriver itself is not thread safe. For example if two threads call beginTransaction() on the same driver and the "COMMIT" fails, both threads will call QSqlDriver::setLastError() which does "d->error = error;". And here is the first problem. I am not an expert with QSqlQuery, but since it uses the driver, I bet, you'll also find UB and races there. Cheers Lorenz Am 15.02.2017 um 13:37 schrieb Łukasz Korbel: > According to > http://doc.qt.io/qt-5/threads-modules.html#threads-and-the-sql-module > database connection should be used within one thread *only*. > > I have checked SQLite driver and according to > https://www.sqlite.org/threadsafe.html it supports multithreading by > default. And it seems that Qt implementation does not restrict it > (http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp#n645). > Code I'm working on is creating QSqlQuery for the same connection in > different threads and it works. > > I understand it doesn't mean Qt want or need to support such use case > but maybe documentation > can be slightly more accurate? Right now it implies that database > connection can never be used from different threads but it seem it > depends more on particular driver/3rdparty lib. > > > *Łukasz Korbel * > Senior Software Developer > Email: lkorbel at milosolutions.com > Skype: lukasz_korbel > *Milo Solutions* > www.milosolutions.com | Facebook > | Twitter > > Disclaimer: This e-mail and any attachments contain information that may > be privileged or confidential and is the property of Milo Solutions. If > you are not the intended recipient, please notify me immediately by > replying to this e-mail, and then delete it. Any unauthorised > dissemination, distribution, copying or use of this communication is > strictly prohibited. The contents of an attachment to this e-mail may > contain software viruses, which could damage your own computer system. > Although this e-mail and any files attached to it may have been checked > with virus detection software before transmission you should carry out > your own virus checks before opening the attachment. No liability can be > accepted for any damage which you may sustain as a result of software > viruses. > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From apoenitz at t-online.de Wed Feb 15 23:33:12 2017 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 15 Feb 2017 23:33:12 +0100 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <12713373.l1ioPss3yR@tjmaciei-mobl1> References: <20170215120506.jyhwmb7yyxn36ife@mitya57.me> <12713373.l1ioPss3yR@tjmaciei-mobl1> Message-ID: <20170215223312.GB1921@klara.mpi.htwm.de> On Wed, Feb 15, 2017 at 08:54:40AM -0800, Thiago Macieira wrote: > Em quarta-feira, 15 de fevereiro de 2017, às 15:05:06 PST, Dmitry Shachnev > escreveu: > > On Wed, Feb 15, 2017 at 12:28:11PM +0100, Kevin Kofler wrote: > > > I would kindly request you to at least use tar.xz (rather than tar.gz) for > > > the tarballs. (What you use as the Windows format is something you need to > [cut] > > +1, please leave tar.xz instead of tar.gz. > > > > Users of all modern UNIX-like systems are able to decompress tar.xz, so .gz > > has really no advantage over .xz. > > Adding my voice to that. If data volume is an issue, then let's by all means > standardise on .tar.xz. Similarly here. Download statistics are -- as any usage based statistics -- in first approximation independent of user intent and capability as they do not account for cognitive bias like "people take the first feasible option" or "use something with familiar name" etc. If the question is how to reduce server load (a reasonable goal in my book) the question would be "which format is smallest without denying access". Andre' [Not speaking for any company, strictly my own opinion, not having any stake in any of the mentioned formats, etc...] From mathias at taschenorakel.de Thu Feb 16 00:11:49 2017 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 16 Feb 2017 00:11:49 +0100 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <20170215120506.jyhwmb7yyxn36ife@mitya57.me> References: <101421487155580@web24o.yandex.ru> <20170215120506.jyhwmb7yyxn36ife@mitya57.me> Message-ID: <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> Am 15.02.2017 um 13:05 schrieb Dmitry Shachnev: > On Wed, Feb 15, 2017 at 12:28:11PM +0100, Kevin Kofler wrote: >> I would kindly request you to at least use tar.xz (rather than tar.gz) for >> the tarballs. (What you use as the Windows format is something you need to >> sort out with the Windows people.) The fact that tar.gz is still the most >> downloaded is probably mostly out of habit, or maybe your download site is >> directing to them by default (which ought to be fixed anyway, even if you >> were to keep both). tar.gz has no advantage over tar.xz, it is just a lot >> larger. Switching to the tar.gz tarballs (from the tar.xz tarballs that are >> currently used) would increase the size of distributions' source packages >> (source RPM etc.) significantly. If distros care about size they can re-compress. Well, and to my experience they do. >> It is sad that the legacy gzip compression is living a renaissance due to >> automatic tarball exports from GitHub and the like producing only that >> format. It should finally be retired now that there are algorithms that are >> just as open and that compress significantly better. At least for projects >> like Qt that produce their own tarballs and are already able to produce xz- >> compressed ones, I see no reason whatsoever to switch back to the obsolete >> gzip. > > +1, please leave tar.xz instead of tar.gz. > > Users of all modern UNIX-like systems are able to decompress tar.xz, so .gz > has really no advantage over .xz. That's a somewhat limited point of view. Yes, xz archives are slightly smaller, but to be honest: In the days of 4K video streaming saving 100MiB of download size doesn't seem as important as it was. The actual value of gzip and the reason for its return seems to be its significantly lower CPU usage. This is useful to reduce server load on heavily utilized services like github. This is useful to reduce development roundtrip cycles. Just to illustrate this I've collected some numbers on my Thinkpad: Command | Average | Savings | Archive | Savings | CPU time | p. build | size | @100MBit ==================================================== gzip | 00:44.19 | 09:54.58 | 469 MiB | 00:00.00 gzip -9 | 01:55.58 | 08:43.18 | 465 MiB | 00:00.32 xz | 08:46.16 | 01:52.60 | 354 MiB | 00:09.20 xz -9 | 10:38.77 | 00:00.00 | 333 MiB | 00:10.88 Is it worth to spend 10 additional minutes per CI cycle just to save our users a very few seconds of download time? Looking at the problems behind providing an official 5.8.1. Looking at my personal experience with slow CI systems I clearly vote for speeding up the Q/A process and sticking with .zip and .tar.gz. Besides: Does it really make sense to fully test the expensive .xz and .7z builds? In my opinion it would be fully sufficient to only give the inexpensive .zip and .gz archives full test coverage. At least the .xz could be generated on the fly after uploading to the web server by simply decompression: gunzip < qt-sources.tar.gz | xz -9 > qt-sources.tar.xz Ciao, Mathias From mathias at taschenorakel.de Thu Feb 16 00:13:31 2017 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 16 Feb 2017 00:13:31 +0100 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <2055721487178511@web24o.yandex.ru> References: <12713373.l1ioPss3yR@tjmaciei-mobl1> <1633941487178252@web14j.yandex.ru> <3601860.hXGhjxLTIf@tjmaciei-mobl1> <2055721487178511@web24o.yandex.ru> Message-ID: Am 15.02.2017 um 18:08 schrieb Konstantin Tokarev: > > > 15.02.2017, 20:07, "Thiago Macieira" : >> On quarta-feira, 15 de fevereiro de 2017 09:04:12 PST Konstantin Podsvirov >> wrote: >>> This can be not quite on this topic, but I have a suggestion and MVP >>> implementation for QtIFW. >>> >>> This may affect the development process, testing and create offline >>> installers. >> >> Most Valuable Player? > > Most Valuable Professional? Most Verbose Poser? ;-) :-D From kevin.kofler at chello.at Thu Feb 16 01:14:30 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 16 Feb 2017 01:14:30 +0100 Subject: [Development] Decrease amounth of delivered src packages References: <101421487155580@web24o.yandex.ru> <20170215120506.jyhwmb7yyxn36ife@mitya57.me> <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> Message-ID: Mathias Hasselmann wrote: > If distros care about size they can re-compress. > Well, and to my experience they do. I cannot speak for other distributions, but it is Fedora policy to never modify an upstream tarball unless it is required to remove files that cannot be legally redistributed for some reason (e.g. patents). This includes recompression. The reason for that policy is that recompressing makes it harder to compare file checksums. Kevin Kofler From thiago.macieira at intel.com Thu Feb 16 02:28:14 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Feb 2017 17:28:14 -0800 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: References: <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> Message-ID: <2427363.QWWcehDhJt@tjmaciei-mobl1> On quarta-feira, 15 de fevereiro de 2017 16:14:30 PST Kevin Kofler wrote: > Mathias Hasselmann wrote: > > If distros care about size they can re-compress. > > Well, and to my experience they do. > > I cannot speak for other distributions, but it is Fedora policy to never > modify an upstream tarball unless it is required to remove files that cannot > be legally redistributed for some reason (e.g. patents). This includes > recompression. The reason for that policy is that recompressing makes it > harder to compare file checksums. You can compare the checksum of the uncompressed tarball. Two people running git archive on the same commit or tag will produce the same uncompressed stream (including GitHub), but not necessarily the same compressed stream. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Feb 16 02:29:43 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Feb 2017 17:29:43 -0800 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> References: <20170215120506.jyhwmb7yyxn36ife@mitya57.me> <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> Message-ID: <1960522.RHXxxDOTgF@tjmaciei-mobl1> On quarta-feira, 15 de fevereiro de 2017 15:11:49 PST Mathias Hasselmann wrote: > That's a somewhat limited point of view. Yes, xz archives are slightly > smaller, but to be honest: In the days of 4K video streaming saving > 100MiB of download size doesn't seem as important as it was. There are still people with bad or slow connections. > Is it worth to spend 10 additional minutes per CI cycle just to save our > users a very few seconds of download time? Wait, CI cycle? I thought we were talking about releases only, which are final as well as snapshot packages. Why is the CI creating tarballs? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Feb 16 02:36:00 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Feb 2017 17:36:00 -0800 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <201702151814.30891.marc.mutz@kdab.com> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <18592171.nmaKQCfGbZ@tjmaciei-mobl1> <201702151814.30891.marc.mutz@kdab.com> Message-ID: <6482151.TnIeCF2951@tjmaciei-mobl1> On quarta-feira, 15 de fevereiro de 2017 09:14:30 PST Marc Mutz wrote: > > Until yesterday, there wasn't much a disagreement, so the release team > > took > > it as consensus decision from the community. > > Sure there was no disagreement. It was _w_e_e_k_e_n_d_. There was no > agreement, either. I could also say that no-one came out in support today, > so it's community consensus that 5.8.1 happens. Both interpretations are > nonsense. Between Tuukka's email and the RT meeting, there two full workdays, in any timezone. It was not a holiday in any of the major contributing countries. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Feb 16 03:17:32 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Feb 2017 18:17:32 -0800 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <216C8A23-4FFA-423A-BFE3-F6818BC6D739@qt.io> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <1827326.MVTkkocP57@cartman> <216C8A23-4FFA-423A-BFE3-F6818BC6D739@qt.io> Message-ID: <1965478.yendhyjin9@tjmaciei-mobl1> On quarta-feira, 15 de fevereiro de 2017 09:00:09 PST Tuukka Turunen wrote: > First I want to say that I am also very sorry that we need to skip 5.8.1. > Unfortunately I do not see any other approach that would allow us to: 1) > catch the delay caused by 5.8 being late (and 5.7 being late, and 5.6 being > late) and 2) enable implementation the much needed CI changes in good time > before Qt 5.10 feature freeze. Here's a way: Push the 5.9 and 5.10 timelines back. If necessary, unfreeze Qt 5.9. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gna.org Thu Feb 16 05:52:11 2017 From: chgans at gna.org (Ch'Gans) Date: Thu, 16 Feb 2017 17:52:11 +1300 Subject: [Development] Bug (and fix) in QGItem::itemChange() (?) Message-ID: Hi there, Here is my use-case: An item has "handles" child items, when the user moves around an handles, the parent item update it's geometry and position accordingly. Simple concept to let the user change an item geometry by dragging handles. Imagine, you're using a drawing application, you select a circle and 5 handles appear on the screen, one in each corner to resize the circle, and one in the center to move the circle around. The way i implement it is to let the circle item filter an handle item's 'itemChange()' notification. This work nicely for resizing handles, but fails for the 'move handle'. Here is the simplified pseudo code: QVariant HandleItem::itemChange(change, value) { // Move the parent to where the handle wants to go... parentItem()->setPos(parentItem()->mapToParent(value); // ... and leave the handle at parent's origin return QPointF(0, 0); } After banging my head for a while, i finally pin-pointed what I think is the problem: This is related to how items are moved in qt5/qtbase/src/widgets/graphicsview/qgraphicsitem.cpp. When a move begins, the 'initial position' of the item is stored in the scene. This initial position is simply the value of item->pos(), which is in parent's item CS: initialPositions = d_ptr->scene->d_func()->movingItemsInitialPositions; if (initialPositions.isEmpty()) { foreach (QGraphicsItem *item, selectedItems) initialPositions[item] = item->pos(); initialPositions[this] = pos(); } d_ptr->scene->d_func()->movingItemsInitialPositions = initialPositions; As the move goes on, the item's pos is updated based on this 'initial position' (expressed in an outdated parent's CS) and the parent position relative to the item's position: currentParentPos = item->mapToParent(item->mapFromScene(event->scenePos())); buttonDownParentPos = item->mapToParent(item->mapFromScene(event->buttonDownScenePos(Qt::LeftButton))); [...] item->setPos(initialPositions.value(item) + currentParentPos - buttonDownParentPos); Basically the above 3 lines would be correct only and only if the initialPositions were expressed in a dynamic way, that is, if they were independent of the parent's CS since it can change during the move. The following pseudo-code modifications fixes that: // 'Capture' time initialPosition = item->mapToScene(item->mapFromParent(item->pos())); // Independent of parent CS [...] // 'Update' time initialPosition = item->mapToParent(item->mapFromScene(initialPosition)); // up-to-date w/ changed parent's CS item->setPos(initialPosition + currentParentPos - buttonDownParentPos); This modification fixes my use-cases, and doesn't seem to break the "40000 chips" and other demo/example. The scene's private 'movingItemsInitialPositions' is only set/used by QGI::mouseMoveEvent() and cleared by QGI::mouseReleaseEvent(), so this is not an invasive change So my chain of question is: - Is changing the item's parent position in an item's itemChange() a supported feature? - if it is, then isn't there a bug in qgraphicsitem.ccp as i described above? - if positive, is the above fix correct and would you accept this sort of things if i push that to gerrit? Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gna.org Thu Feb 16 06:29:08 2017 From: chgans at gna.org (Ch'Gans) Date: Thu, 16 Feb 2017 18:29:08 +1300 Subject: [Development] Bug (and fix) in QGItem::itemChange() (?) In-Reply-To: References: Message-ID: Please find attached a simple demo: If you try to move the big green rect by dragging the small red rect, the big rect will goes "wild", using my proposed fixed, the big rect follows the mouse as you drag the small rect. Chris On 16 February 2017 at 17:52, Ch'Gans wrote: > Hi there, > > Here is my use-case: > An item has "handles" child items, when the user moves around an handles, > the parent item update it's geometry and position accordingly. Simple > concept to let the user change an item geometry by dragging handles. > Imagine, you're using a drawing application, you select a circle and 5 > handles appear on the screen, one in each corner to resize the circle, and > one in the center to move the circle around. > > The way i implement it is to let the circle item filter an handle item's > 'itemChange()' notification. This work nicely for resizing handles, but > fails for the 'move handle'. Here is the simplified pseudo code: > QVariant HandleItem::itemChange(change, value) > { > // Move the parent to where the handle wants to go... > parentItem()->setPos(parentItem()->mapToParent(value); > // ... and leave the handle at parent's origin > return QPointF(0, 0); > } > > After banging my head for a while, i finally pin-pointed what I think is > the problem: > > This is related to how items are moved in qt5/qtbase/src/widgets/ > graphicsview/qgraphicsitem.cpp. When a move begins, the 'initial > position' of the item is stored in the scene. This initial position is > simply the value of item->pos(), which is in parent's item CS: > > initialPositions = d_ptr->scene->d_func()->movingItemsInitialPositions; > if (initialPositions.isEmpty()) { > foreach (QGraphicsItem *item, selectedItems) > initialPositions[item] = item->pos(); > initialPositions[this] = pos(); > } > d_ptr->scene->d_func()->movingItemsInitialPositions = initialPositions; > > As the move goes on, the item's pos is updated based on this 'initial > position' (expressed in an outdated parent's CS) and the parent position > relative to the item's position: > > currentParentPos = item->mapToParent(item->mapFromScene(event->scenePos() > )); > buttonDownParentPos = item->mapToParent(item->mapFromScene(event-> > buttonDownScenePos(Qt::LeftButton))); > [...] > item->setPos(initialPositions.value(item) + currentParentPos - > buttonDownParentPos); > > Basically the above 3 lines would be correct only and only if the > initialPositions were expressed in a dynamic way, that is, if they were > independent of the parent's CS since it can change during the move. > > The following pseudo-code modifications fixes that: > > // 'Capture' time > initialPosition = item->mapToScene(item->mapFromParent(item->pos())); // > Independent of parent CS > [...] > // 'Update' time > initialPosition = item->mapToParent(item->mapFromScene(initialPosition)); > // up-to-date w/ changed parent's CS > item->setPos(initialPosition + currentParentPos - buttonDownParentPos); > > > This modification fixes my use-cases, and doesn't seem to break the "40000 > chips" and other demo/example. > The scene's private 'movingItemsInitialPositions' is only set/used by > QGI::mouseMoveEvent() and cleared by QGI::mouseReleaseEvent(), so this is > not an invasive change > > > So my chain of question is: > - Is changing the item's parent position in an item's itemChange() a > supported feature? > - if it is, then isn't there a bug in qgraphicsitem.ccp as i described > above? > - if positive, is the above fix correct and would you accept this sort of > things if i push that to gerrit? > > > Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cpp Type: text/x-c++src Size: 1509 bytes Desc: not available URL: From samuel.nevala at intopalo.com Thu Feb 16 07:37:03 2017 From: samuel.nevala at intopalo.com (Samuel Nevala) Date: Thu, 16 Feb 2017 08:37:03 +0200 Subject: [Development] Threads and the SQL Module In-Reply-To: References: Message-ID: Hi, Just recently needed to fix threading issues with SQLite on non-Qt-context. Here here is obsolete information that helped me:). http://www.sqlite.org/cvstrac/wiki?p=MultiThreading. From that doc: "By "threadsafe" we mean that you can use different SQLite database connections in different threads at the same time. It has never been safe to use the same database connection simultaneously in multiple threads." Samuel On 15 February 2017 at 21:24, Lorenz Haas wrote: > Hi, > > AFAIS it does not matter if sqlite is thread safe or not. The problem is > that QSQLiteDriver itself is not thread safe. For example if two threads > call beginTransaction() on the same driver and the "COMMIT" fails, both > threads will call QSqlDriver::setLastError() which does "d->error = > error;". And here is the first problem. > > I am not an expert with QSqlQuery, but since it uses the driver, I bet, > you'll also find UB and races there. > > Cheers > Lorenz > > Am 15.02.2017 um 13:37 schrieb Łukasz Korbel: > > According to > > http://doc.qt.io/qt-5/threads-modules.html#threads-and-the-sql-module > > database connection should be used within one thread *only*. > > > > I have checked SQLite driver and according to > > https://www.sqlite.org/threadsafe.html it supports multithreading by > > default. And it seems that Qt implementation does not restrict it > > (http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/ > sqldrivers/sqlite/qsql_sqlite.cpp#n645). > > Code I'm working on is creating QSqlQuery for the same connection in > > different threads and it works. > > > > I understand it doesn't mean Qt want or need to support such use case > > but maybe documentation > > can be slightly more accurate? Right now it implies that database > > connection can never be used from different threads but it seem it > > depends more on particular driver/3rdparty lib. > > > > > > *Łukasz Korbel * > > Senior Software Developer > > Email: lkorbel at milosolutions.com > > Skype: lukasz_korbel > > *Milo Solutions* > > www.milosolutions.com | Facebook > > | Twitter > > > > Disclaimer: This e-mail and any attachments contain information that may > > be privileged or confidential and is the property of Milo Solutions. If > > you are not the intended recipient, please notify me immediately by > > replying to this e-mail, and then delete it. Any unauthorised > > dissemination, distribution, copying or use of this communication is > > strictly prohibited. The contents of an attachment to this e-mail may > > contain software viruses, which could damage your own computer system. > > Although this e-mail and any files attached to it may have been checked > > with virus detection software before transmission you should carry out > > your own virus checks before opening the attachment. No liability can be > > accepted for any damage which you may sustain as a result of software > > viruses. > > > > > > > > _______________________________________________ > > 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 sean.harmer at kdab.com Thu Feb 16 10:14:30 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Thu, 16 Feb 2017 09:14:30 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <1965478.yendhyjin9@tjmaciei-mobl1> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <216C8A23-4FFA-423A-BFE3-F6818BC6D739@qt.io> <1965478.yendhyjin9@tjmaciei-mobl1> Message-ID: <2073316.YcQn1BNY45@cartman> On Wednesday 15 February 2017 18:17:32 Thiago Macieira wrote: > On quarta-feira, 15 de fevereiro de 2017 09:00:09 PST Tuukka Turunen wrote: > > First I want to say that I am also very sorry that we need to skip 5.8.1. > > Unfortunately I do not see any other approach that would allow us to: 1) > > catch the delay caused by 5.8 being late (and 5.7 being late, and 5.6 > > being > > late) and 2) enable implementation the much needed CI changes in good time > > before Qt 5.10 feature freeze. > > Here's a way: > > Push the 5.9 and 5.10 timelines back. If necessary, unfreeze Qt 5.9. Yes this is what I would vote for too. The 5.9 deadline is somewhat arbitrary/self imposed so does not have to be set in stone. If this has knock- on effects for the CI upgrades, why can't these be done during the summer break by staggering the sysadmin vacations instead of all of them going off at the same time? With this we could have a timeline something like this: 1) Release 5.8.1 asap. Hopefully this would go smoothly given it's a .1 release. 2) Push 5.9.0 deadline to end of June but aim for earlier if the config system doesn't adversely affect the package generation. 3) Perform CI upgrades as soon as 5.9.0 is out (may require some juggling of vacation requests if 5.9.0 goes until end of June. 4) After summer vacation, start release process for 5.9.1 and 5.10. This also helps mitigate the risk of something delaying the 5.9.0 release by getting a .1 release to the users in the interim. Also, to allow others to help with the release process, could you explain where the main bottle neck is with the release process please? Is it the package generation itself? The smoke testing? Something else? KDAB is willing to help where we can if it means we can get a 5.8.1 release in the hands of yours and our customers. But to be able to help, we need to know how we can. Kind regards, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From eric.lemanissier at gmail.com Thu Feb 16 11:34:06 2017 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Thu, 16 Feb 2017 10:34:06 +0000 Subject: [Development] Threads and the SQL Module In-Reply-To: References: Message-ID: Thanks for pointing this out Łukasz, I created a change to disable useless mutexes on sqlite db connection : https://codereview.qt-project.org/#/c/185835/ Unfortunately that would break your usage, but it seems like it is already broken as Lorenz explained. All db intensive usage should see a perfromance win. Eric Le jeu. 16 févr. 2017 à 07:37, Samuel Nevala a écrit : > Hi, > > Just recently needed to fix threading issues with SQLite on > non-Qt-context. Here here is obsolete information that helped me:). > http://www.sqlite.org/cvstrac/wiki?p=MultiThreading. From that doc: "By > "threadsafe" we mean that you can use different SQLite database connections > in different threads at the same time. It has never been safe to use the > same database connection simultaneously in multiple threads." > > Samuel > > On 15 February 2017 at 21:24, Lorenz Haas wrote: > > Hi, > > AFAIS it does not matter if sqlite is thread safe or not. The problem is > that QSQLiteDriver itself is not thread safe. For example if two threads > call beginTransaction() on the same driver and the "COMMIT" fails, both > threads will call QSqlDriver::setLastError() which does "d->error = > error;". And here is the first problem. > > I am not an expert with QSqlQuery, but since it uses the driver, I bet, > you'll also find UB and races there. > > Cheers > Lorenz > > Am 15.02.2017 um 13:37 schrieb Łukasz Korbel: > > According to > > http://doc.qt.io/qt-5/threads-modules.html#threads-and-the-sql-module > > database connection should be used within one thread *only*. > > > > I have checked SQLite driver and according to > > https://www.sqlite.org/threadsafe.html it supports multithreading by > > default. And it seems that Qt implementation does not restrict it > > ( > http://code.qt.io/cgit/qt/qtbase.git/tree/src/plugins/sqldrivers/sqlite/qsql_sqlite.cpp#n645 > ). > > Code I'm working on is creating QSqlQuery for the same connection in > > different threads and it works. > > > > I understand it doesn't mean Qt want or need to support such use case > > but maybe documentation > > can be slightly more accurate? Right now it implies that database > > connection can never be used from different threads but it seem it > > depends more on particular driver/3rdparty lib. > > > > > > *Łukasz Korbel * > > Senior Software Developer > > Email: lkorbel at milosolutions.com > > Skype: lukasz_korbel > > *Milo Solutions* > > www.milosolutions.com | Facebook > > | Twitter > > > > Disclaimer: This e-mail and any attachments contain information that may > > be privileged or confidential and is the property of Milo Solutions. If > > you are not the intended recipient, please notify me immediately by > > replying to this e-mail, and then delete it. Any unauthorised > > dissemination, distribution, copying or use of this communication is > > strictly prohibited. The contents of an attachment to this e-mail may > > contain software viruses, which could damage your own computer system. > > Although this e-mail and any files attached to it may have been checked > > with virus detection software before transmission you should carry out > > your own virus checks before opening the attachment. No liability can be > > accepted for any damage which you may sustain as a result of software > > viruses. > > > > > > > > _______________________________________________ > > 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 kevin.kofler at chello.at Thu Feb 16 16:06:51 2017 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 16 Feb 2017 16:06:51 +0100 Subject: [Development] Decrease amounth of delivered src packages References: <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> <2427363.QWWcehDhJt@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > You can compare the checksum of the uncompressed tarball. But this is not how the Fedora workflow works. And please also note that I did not make the policies, I am just trying to explain why they are the way they are. And I suspect that there are several other distributions that work similarly. > Two people running git archive on the same commit or tag will produce the > same uncompressed stream (including GitHub), but not necessarily the same > compressed stream. It was found that in practice, requesting the same tag from GitHub multiple times gives byte-identical tar.gz output. (Unfortunately, GitHub cannot deliver better compressions.) Of course this might break if they upgrade their gzip, but nothing is perfect. Kevin Kofler From thiago.macieira at intel.com Thu Feb 16 16:51:38 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Feb 2017 07:51:38 -0800 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: References: <2427363.QWWcehDhJt@tjmaciei-mobl1> Message-ID: <6353119.MIOUB0yYHq@tjmaciei-mobl1> On quinta-feira, 16 de fevereiro de 2017 07:06:51 PST Kevin Kofler wrote: > It was found that in practice, requesting the same tag from GitHub multiple > times gives byte-identical tar.gz output. (Unfortunately, GitHub cannot > deliver better compressions.) Of course this might break if they upgrade > their gzip, but nothing is perfect. Right, but my point is that you can get the same uncompressed stream by running it archive in anyone's machine. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Thu Feb 16 16:53:12 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 16 Feb 2017 18:53:12 +0300 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> References: <101421487155580@web24o.yandex.ru> <20170215120506.jyhwmb7yyxn36ife@mitya57.me> <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> Message-ID: <1330981487260392@web27m.yandex.ru> 16.02.2017, 02:12, "Mathias Hasselmann" : > Am 15.02.2017 um 13:05 schrieb Dmitry Shachnev: >>  On Wed, Feb 15, 2017 at 12:28:11PM +0100, Kevin Kofler wrote: >>>  I would kindly request you to at least use tar.xz (rather than tar.gz) for >>>  the tarballs. (What you use as the Windows format is something you need to >>>  sort out with the Windows people.) The fact that tar.gz is still the most >>>  downloaded is probably mostly out of habit, or maybe your download site is >>>  directing to them by default (which ought to be fixed anyway, even if you >>>  were to keep both). tar.gz has no advantage over tar.xz, it is just a lot >>>  larger. Switching to the tar.gz tarballs (from the tar.xz tarballs that are >>>  currently used) would increase the size of distributions' source packages >>>  (source RPM etc.) significantly. > > If distros care about size they can re-compress. > Well, and to my experience they do. > >>>  It is sad that the legacy gzip compression is living a renaissance due to >>>  automatic tarball exports from GitHub and the like producing only that >>>  format. It should finally be retired now that there are algorithms that are >>>  just as open and that compress significantly better. At least for projects >>>  like Qt that produce their own tarballs and are already able to produce xz- >>>  compressed ones, I see no reason whatsoever to switch back to the obsolete >>>  gzip. >> >>  +1, please leave tar.xz instead of tar.gz. >> >>  Users of all modern UNIX-like systems are able to decompress tar.xz, so .gz >>  has really no advantage over .xz. > > That's a somewhat limited point of view. Yes, xz archives are slightly > smaller, but to be honest: In the days of 4K video streaming saving > 100MiB of download size doesn't seem as important as it was. > > The actual value of gzip and the reason for its return seems to be its > significantly lower CPU usage. This is useful to reduce server load on > heavily utilized services like github. This is useful to reduce > development roundtrip cycles. I think nobody here would challenge this statement. But it has nothing to do with src archives that are compressed once and decompressed thousands of times. > > Just to illustrate this I've collected some numbers on my Thinkpad: > >    Command | Average | Savings | Archive | Savings >            | CPU time | p. build | size | @100MBit >   ==================================================== >    gzip | 00:44.19 | 09:54.58 | 469 MiB | 00:00.00 >    gzip -9 | 01:55.58 | 08:43.18 | 465 MiB | 00:00.32 >    xz | 08:46.16 | 01:52.60 | 354 MiB | 00:09.20 >    xz -9 | 10:38.77 | 00:00.00 | 333 MiB | 00:10.88 You should use pxz instead of xz for fair results. > > Is it worth to spend 10 additional minutes per CI cycle just to save our > users a very few seconds of download time? > > Looking at the problems behind providing an official 5.8.1. Looking at > my personal experience with slow CI systems I clearly vote for speeding > up the Q/A process and sticking with .zip and .tar.gz. > > Besides: Does it really make sense to fully test the expensive .xz and > .7z builds? In my opinion it would be fully sufficient to only give the > inexpensive .zip and .gz archives full test coverage. At least the .xz > could be generated on the fly after uploading to the web server by > simply decompression: > >    gunzip < qt-sources.tar.gz | xz -9 > qt-sources.tar.xz > > Ciao, > Mathias > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From tuukka.turunen at qt.io Thu Feb 16 17:13:57 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Thu, 16 Feb 2017 16:13:57 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <2073316.YcQn1BNY45@cartman> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <216C8A23-4FFA-423A-BFE3-F6818BC6D739@qt.io> <1965478.yendhyjin9@tjmaciei-mobl1> <2073316.YcQn1BNY45@cartman> Message-ID: Hi Sean, I do appreciate the offer to help with Qt 5.8.1 creation, but as I explained in my email to the ml yesterday, I do not think it is feasible plan to make a release without involving several people from The Qt Company for it and also causing a load to CI hindering development of 5.9 in parallel. Unfortunately making a new Qt release is so complicated due to large amount of platforms and packages involved, that it mandates effort of releasing team of The Qt Company as well as many developers. As I explained yesterday, even with a lot of help it would mean that 5.9.0 happens probably end of June or beginning of July. This would mean we lose the opportunity window to catch up with releasing and improve the CI system (because Finland and Norway mostly are off in July and Germany in August). Doing the CI change after August means we are already close to 5.10 release. As multiple people and teams have planned their development according to initially agreed feature freeze time of Qt 5.9, it would be very inefficient to reopen 5.9 now or postpone getting the release out. If we can get KDAB and others helping with Qt 5.9 with even remotely similar effort than it would be to create Qt 5.8.1 release I am sure we can make an awesome Qt 5.9.0 ahead of the planned schedule. This means we can make the CI system improvements earlier and thus also have Qt 5.9.1 earlier. Yours, Tuukka On 16/02/2017, 11.14, "Development on behalf of Sean Harmer" wrote: On Wednesday 15 February 2017 18:17:32 Thiago Macieira wrote: > On quarta-feira, 15 de fevereiro de 2017 09:00:09 PST Tuukka Turunen wrote: > > First I want to say that I am also very sorry that we need to skip 5.8.1. > > Unfortunately I do not see any other approach that would allow us to: 1) > > catch the delay caused by 5.8 being late (and 5.7 being late, and 5.6 > > being > > late) and 2) enable implementation the much needed CI changes in good time > > before Qt 5.10 feature freeze. > > Here's a way: > > Push the 5.9 and 5.10 timelines back. If necessary, unfreeze Qt 5.9. Yes this is what I would vote for too. The 5.9 deadline is somewhat arbitrary/self imposed so does not have to be set in stone. If this has knock- on effects for the CI upgrades, why can't these be done during the summer break by staggering the sysadmin vacations instead of all of them going off at the same time? With this we could have a timeline something like this: 1) Release 5.8.1 asap. Hopefully this would go smoothly given it's a .1 release. 2) Push 5.9.0 deadline to end of June but aim for earlier if the config system doesn't adversely affect the package generation. 3) Perform CI upgrades as soon as 5.9.0 is out (may require some juggling of vacation requests if 5.9.0 goes until end of June. 4) After summer vacation, start release process for 5.9.1 and 5.10. This also helps mitigate the risk of something delaying the 5.9.0 release by getting a .1 release to the users in the interim. Also, to allow others to help with the release process, could you explain where the main bottle neck is with the release process please? Is it the package generation itself? The smoke testing? Something else? KDAB is willing to help where we can if it means we can get a 5.8.1 release in the hands of yours and our customers. But to be able to help, we need to know how we can. Kind regards, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From chgans at gna.org Thu Feb 16 22:26:59 2017 From: chgans at gna.org (Ch'Gans) Date: Fri, 17 Feb 2017 10:26:59 +1300 Subject: [Development] Bug (and fix) in QGItem::itemChange() (?) In-Reply-To: References: Message-ID: FYI, I've just created https://bugreports.qt.io/browse/QTBUG-58988. Regards, Chris On 16 February 2017 at 17:52, Ch'Gans wrote: > Hi there, > > Here is my use-case: > An item has "handles" child items, when the user moves around an handles, > the parent item update it's geometry and position accordingly. Simple > concept to let the user change an item geometry by dragging handles. > Imagine, you're using a drawing application, you select a circle and 5 > handles appear on the screen, one in each corner to resize the circle, and > one in the center to move the circle around. > > The way i implement it is to let the circle item filter an handle item's > 'itemChange()' notification. This work nicely for resizing handles, but > fails for the 'move handle'. Here is the simplified pseudo code: > QVariant HandleItem::itemChange(change, value) > { > // Move the parent to where the handle wants to go... > parentItem()->setPos(parentItem()->mapToParent(value); > // ... and leave the handle at parent's origin > return QPointF(0, 0); > } > > After banging my head for a while, i finally pin-pointed what I think is > the problem: > > This is related to how items are moved in qt5/qtbase/src/widgets/ > graphicsview/qgraphicsitem.cpp. When a move begins, the 'initial > position' of the item is stored in the scene. This initial position is > simply the value of item->pos(), which is in parent's item CS: > > initialPositions = d_ptr->scene->d_func()->movingItemsInitialPositions; > if (initialPositions.isEmpty()) { > foreach (QGraphicsItem *item, selectedItems) > initialPositions[item] = item->pos(); > initialPositions[this] = pos(); > } > d_ptr->scene->d_func()->movingItemsInitialPositions = initialPositions; > > As the move goes on, the item's pos is updated based on this 'initial > position' (expressed in an outdated parent's CS) and the parent position > relative to the item's position: > > currentParentPos = item->mapToParent(item->mapFromScene(event->scenePos() > )); > buttonDownParentPos = item->mapToParent(item->mapFromScene(event-> > buttonDownScenePos(Qt::LeftButton))); > [...] > item->setPos(initialPositions.value(item) + currentParentPos - > buttonDownParentPos); > > Basically the above 3 lines would be correct only and only if the > initialPositions were expressed in a dynamic way, that is, if they were > independent of the parent's CS since it can change during the move. > > The following pseudo-code modifications fixes that: > > // 'Capture' time > initialPosition = item->mapToScene(item->mapFromParent(item->pos())); // > Independent of parent CS > [...] > // 'Update' time > initialPosition = item->mapToParent(item->mapFromScene(initialPosition)); > // up-to-date w/ changed parent's CS > item->setPos(initialPosition + currentParentPos - buttonDownParentPos); > > > This modification fixes my use-cases, and doesn't seem to break the "40000 > chips" and other demo/example. > The scene's private 'movingItemsInitialPositions' is only set/used by > QGI::mouseMoveEvent() and cleared by QGI::mouseReleaseEvent(), so this is > not an invasive change > > > So my chain of question is: > - Is changing the item's parent position in an item's itemChange() a > supported feature? > - if it is, then isn't there a bug in qgraphicsitem.ccp as i described > above? > - if positive, is the above fix correct and would you accept this sort of > things if i push that to gerrit? > > > Chris > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Thu Feb 16 23:21:52 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 16 Feb 2017 23:21:52 +0100 Subject: [Development] QMacCocoaViewContainer changes? Message-ID: <3486735.iQvbknHaF3@portia.local> Hello, Has anything changed in Qt 5.8.0 with the way the QMacCocoaViewContainer class has to be used? I observe the following after updating from 5.7.1 to 5.8.0 : - Qt Designer crashes when I have Phonon 4.9.x installed with the phonon-backend-vlc git/master backend (https://cgit.kde.org/phonon-vlc.git/). - the QMacCocoaViewContainer ctor now also calls QMacCocoaViewContainer::setCocoaView() when a NULL NSView pointer is given. - the QMacCocoaViewContainer example no longer releases the native view after passing it to setCocoaView(), despite what the documentation says, and despite the fact that setCocoaView indeed does a retain. Not releasing the VideoView instance in phonon-vlc's VlcMacWidget ctor also prevents the Designer crash but theoretically means the instance is being leaked. The Designer crash is preceded by the terminal output below and occurs in ~QMacCocoaViewContainer(), when doing [nsview release]. This means it's doing one release too many, as confirmed by the malloc error. qt.qpa.cocoa.window: NSView is not QNSView, consider checking for Qt::ForeignWindow qt.qpa.cocoa.window: NSView is not QNSView, consider checking for Qt::ForeignWindow Designer(97879,0x7fff721fd310) malloc: *** error for object 0x7fc7cf2a3300: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Thanks, R. From marc.mutz at kdab.com Thu Feb 16 23:38:58 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 16 Feb 2017 23:38:58 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <2073316.YcQn1BNY45@cartman> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <216C8A23-4FFA-423A-BFE3-F6818BC6D739@qt.io> <1965478.yendhyjin9@tjmaciei-mobl1> <2073316.YcQn1BNY45@cartman> Message-ID: <8a0d4dcb2c1cf18de8bcfc33e789e2de@kdab.com> On 2017-02-16 10:14, Sean Harmer wrote: [...] > Also, to allow others to help with the release process, could you > explain > where the main bottle neck is with the release process please? Is it > the > package generation itself? The smoke testing? Something else? [...] I note that an answer on this is still pending, but as an aside: CI on 5.8 (and 5.6) appears to be smooth sailing the last two days. Hardly any false failures anymore. I don't know whether something changed in the CI, or we successfully implemented Lars' plan to blacklist flakiness, but the result is very pleasant. I do realise that the main load probably comes from qt5.git integrations, but even so, if 5.8 (qtbase) integrations run through the first time instead of requiring half a dozen restages, either the CI load is lowered significantly, helping to avoid flakiness in other tests, or allowing more stuff to be merged per unit time. Shutting down 5.8 because of load problems in the CI now makes even less sense than before. Thanks, Marc From timur.pocheptsov at qt.io Fri Feb 17 06:39:44 2017 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Fri, 17 Feb 2017 05:39:44 +0000 Subject: [Development] QMacCocoaViewContainer changes? In-Reply-To: <3486735.iQvbknHaF3@portia.local> References: <3486735.iQvbknHaF3@portia.local> Message-ID: Hello, could you, please, create a JIRA ticket for this (if not done yet)? I remember some changes - but it was 5.6, so 5.7.1 would be also broken then ... Best regards, Timur. ________________________________ From: Development on behalf of René J.V. Bertin Sent: Thursday, February 16, 2017 11:21:52 PM To: development at qt-project.org Cc: Harald Sitter Subject: [Development] QMacCocoaViewContainer changes? Hello, Has anything changed in Qt 5.8.0 with the way the QMacCocoaViewContainer class has to be used? I observe the following after updating from 5.7.1 to 5.8.0 : - Qt Designer crashes when I have Phonon 4.9.x installed with the phonon-backend-vlc git/master backend (https://cgit.kde.org/phonon-vlc.git/). - the QMacCocoaViewContainer ctor now also calls QMacCocoaViewContainer::setCocoaView() when a NULL NSView pointer is given. - the QMacCocoaViewContainer example no longer releases the native view after passing it to setCocoaView(), despite what the documentation says, and despite the fact that setCocoaView indeed does a retain. Not releasing the VideoView instance in phonon-vlc's VlcMacWidget ctor also prevents the Designer crash but theoretically means the instance is being leaked. The Designer crash is preceded by the terminal output below and occurs in ~QMacCocoaViewContainer(), when doing [nsview release]. This means it's doing one release too many, as confirmed by the malloc error. qt.qpa.cocoa.window: NSView is not QNSView, consider checking for Qt::ForeignWindow qt.qpa.cocoa.window: NSView is not QNSView, consider checking for Qt::ForeignWindow Designer(97879,0x7fff721fd310) malloc: *** error for object 0x7fc7cf2a3300: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Thanks, R. _______________________________________________ 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 Fri Feb 17 09:10:55 2017 From: alexander.blasche at qt.io (Alex Blasche) Date: Fri, 17 Feb 2017 08:10:55 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <8a0d4dcb2c1cf18de8bcfc33e789e2de@kdab.com> References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <216C8A23-4FFA-423A-BFE3-F6818BC6D739@qt.io> <1965478.yendhyjin9@tjmaciei-mobl1> <2073316.YcQn1BNY45@cartman> <8a0d4dcb2c1cf18de8bcfc33e789e2de@kdab.com> Message-ID: > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Marc Mutz > > Also, to allow others to help with the release process, could you > > explain where the main bottle neck is with the release process please? > > Is it the package generation itself? The smoke testing? Something > > else? > [...] > > I note that an answer on this is still pending, but as an aside: CI on > 5.8 (and 5.6) appears to be smooth sailing the last two days. Hardly any > false failures anymore. The CI integration process is only partly to blame. Yes, after each fix round there is a new round of qt5 git integrations with more unit test fixes followed by a new round of package generation. > I do realise that the main load probably comes from qt5.git > integrations, but even so, if 5.8 (qtbase) integrations run through the > first time instead of requiring half a dozen restages, either the CI > load is lowered significantly, helping to avoid flakiness in other > tests, or allowing more stuff to be merged per unit time. Each of the packages must be tested. We are talking about 17 different types of packages. For each package the tester has to install the package and run a series of tests. This means you have to have testers for each platform and this takes half a day to do. We are talking about principle testing for each feature domain, QtCreator, app install & deployment, completeness of the install package etc. it is not a sexy task either as it is very mundane. This also assumes that each tester has time to do the testing at the same time. Whenever the last platform tester finishes that's when you can progress to the next step. 5.8.1 is a release with a lot of changes. It would not be a low effort release testing. I do not believe that smoke testing is sufficient. At least the past .1 have very much proven this fact. Yes, there is things we can and want to improve but we are not there yet. I also do not believe that making a bad release is helping customers either. > Shutting down 5.8 because of load problems in the CI now makes even less > sense than before. As shown above it is not. -- Alex From philwave at gmail.com Fri Feb 17 09:28:28 2017 From: philwave at gmail.com (Philippe) Date: Fri, 17 Feb 2017 09:28:28 +0100 Subject: [Development] QMacCocoaViewContainer changes? In-Reply-To: <3486735.iQvbknHaF3@portia.local> References: <3486735.iQvbknHaF3@portia.local> Message-ID: <20170217092827.1039.6F0322A@gmail.com> I observed some change too. In my case, a NSView, created on the client side ("my side"), and inserted inside a Qt hierarchy, is now released automatically by Qt. Before, I had to release this NSView "manually". When switching to Qt 5.8, the NSView was released twice (client + Qt sides), causing a crash in OSX code. Simply not releasing the NSView on the client side, is enough (apparently so far), to solve the problem. I did not report a bug, because this looks more like a behavior change (not documented), than a bug. Philippe On Thu, 16 Feb 2017 23:21:52 +0100 René J.V. Bertin wrote: > Hello, > > Has anything changed in Qt 5.8.0 with the way the QMacCocoaViewContainer class has to be used? I observe the following after updating from 5.7.1 to 5.8.0 : > > - Qt Designer crashes when I have Phonon 4.9.x installed with the phonon-backend-vlc git/master backend (https://cgit.kde.org/phonon-vlc.git/). > - the QMacCocoaViewContainer ctor now also calls QMacCocoaViewContainer::setCocoaView() when a NULL NSView pointer is given. > - the QMacCocoaViewContainer example no longer releases the native view after passing it to setCocoaView(), despite what the documentation says, and despite the fact that setCocoaView indeed does a retain. Not releasing the VideoView instance in phonon-vlc's VlcMacWidget ctor also prevents the Designer crash but theoretically means the instance is being leaked. > > The Designer crash is preceded by the terminal output below and occurs in ~QMacCocoaViewContainer(), when doing [nsview release]. This means it's doing one release too many, as confirmed by the malloc error. > qt.qpa.cocoa.window: NSView is not QNSView, consider checking for Qt::ForeignWindow > qt.qpa.cocoa.window: NSView is not QNSView, consider checking for Qt::ForeignWindow > Designer(97879,0x7fff721fd310) malloc: *** error for object 0x7fc7cf2a3300: pointer being freed was not allocated > *** set a breakpoint in malloc_error_break to debug > > > Thanks, > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Fri Feb 17 09:32:02 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 17 Feb 2017 09:32:02 +0100 Subject: [Development] QMacCocoaViewContainer changes? In-Reply-To: References: <3486735.iQvbknHaF3@portia.local> Message-ID: <14740257.KSoQRj9Y5o@bola> On Friday February 17 2017 05:39:44 Timur Pocheptsov wrote: Hello Timur, I was planning to, but after I gather some more observations, to get an idea if indeed the foreign NSView gets released before calling the QMacCocoaViewContainer dtor, and where. I also want to try to get some certainty that we're not talking simply talking about a regression in Qt Designer. What is definitely new in 5.8 is qnsview_cast(), which I think warns a bit too enthusiastically about casting something not a QNSView*. It's not related to this crash, but shouldn't it at least accept instances of classes that inherit QNSView*? A simple cast won't fool the ObjC runtime anyway. R. >Hello, > > >could you, please, create a JIRA ticket for this (if not done yet)? > >I remember some changes - but it was 5.6, so 5.7.1 would be also broken then ... > > >Best regards, > > Timur. From timur.pocheptsov at qt.io Fri Feb 17 09:41:13 2017 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Fri, 17 Feb 2017 08:41:13 +0000 Subject: [Development] QMacCocoaViewContainer changes? In-Reply-To: <14740257.KSoQRj9Y5o@bola> References: <3486735.iQvbknHaF3@portia.local> , <14740257.KSoQRj9Y5o@bola> Message-ID: Ok, don't hesitate to report it. qnsview_cast is using Obj-C RTTI. An object with a type inheriting QNSView will pass isKindOfClass:[QNSView class] test. Best regards, Timur. ________________________________ From: René J.V. Bertin Sent: Friday, February 17, 2017 9:32:02 AM To: Timur Pocheptsov Cc: development at qt-project.org; Harald Sitter Subject: Re: [Development] QMacCocoaViewContainer changes? On Friday February 17 2017 05:39:44 Timur Pocheptsov wrote: Hello Timur, I was planning to, but after I gather some more observations, to get an idea if indeed the foreign NSView gets released before calling the QMacCocoaViewContainer dtor, and where. I also want to try to get some certainty that we're not talking simply talking about a regression in Qt Designer. What is definitely new in 5.8 is qnsview_cast(), which I think warns a bit too enthusiastically about casting something not a QNSView*. It's not related to this crash, but shouldn't it at least accept instances of classes that inherit QNSView*? A simple cast won't fool the ObjC runtime anyway. R. >Hello, > > >could you, please, create a JIRA ticket for this (if not done yet)? > >I remember some changes - but it was 5.6, so 5.7.1 would be also broken then ... > > >Best regards, > > Timur. -------------- next part -------------- An HTML attachment was scrubbed... URL: From timur.pocheptsov at qt.io Fri Feb 17 09:43:44 2017 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Fri, 17 Feb 2017 08:43:44 +0000 Subject: [Development] QMacCocoaViewContainer changes? In-Reply-To: <20170217092827.1039.6F0322A@gmail.com> References: <3486735.iQvbknHaF3@portia.local>, <20170217092827.1039.6F0322A@gmail.com> Message-ID: > I observed some change too. In my case, a NSView, created on the client > side ("my side"), and inserted inside a Qt hierarchy, is now released > automatically by Qt. That's a bug, please, report it. Best regards, Timur. ________________________________ From: Development on behalf of Philippe Sent: Friday, February 17, 2017 9:28:28 AM To: development at qt-project.org Subject: Re: [Development] QMacCocoaViewContainer changes? I observed some change too. In my case, a NSView, created on the client side ("my side"), and inserted inside a Qt hierarchy, is now released automatically by Qt. Before, I had to release this NSView "manually". When switching to Qt 5.8, the NSView was released twice (client + Qt sides), causing a crash in OSX code. Simply not releasing the NSView on the client side, is enough (apparently so far), to solve the problem. I did not report a bug, because this looks more like a behavior change (not documented), than a bug. Philippe On Thu, 16 Feb 2017 23:21:52 +0100 René J.V. Bertin wrote: > Hello, > > Has anything changed in Qt 5.8.0 with the way the QMacCocoaViewContainer class has to be used? I observe the following after updating from 5.7.1 to 5.8.0 : > > - Qt Designer crashes when I have Phonon 4.9.x installed with the phonon-backend-vlc git/master backend (https://cgit.kde.org/phonon-vlc.git/). > - the QMacCocoaViewContainer ctor now also calls QMacCocoaViewContainer::setCocoaView() when a NULL NSView pointer is given. > - the QMacCocoaViewContainer example no longer releases the native view after passing it to setCocoaView(), despite what the documentation says, and despite the fact that setCocoaView indeed does a retain. Not releasing the VideoView instance in phonon-vlc's VlcMacWidget ctor also prevents the Designer crash but theoretically means the instance is being leaked. > > The Designer crash is preceded by the terminal output below and occurs in ~QMacCocoaViewContainer(), when doing [nsview release]. This means it's doing one release too many, as confirmed by the malloc error. > qt.qpa.cocoa.window: NSView is not QNSView, consider checking for Qt::ForeignWindow > qt.qpa.cocoa.window: NSView is not QNSView, consider checking for Qt::ForeignWindow > Designer(97879,0x7fff721fd310) malloc: *** error for object 0x7fc7cf2a3300: pointer being freed was not allocated > *** set a breakpoint in malloc_error_break to debug > > > Thanks, > R. > _______________________________________________ > 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 rjvbertin at gmail.com Fri Feb 17 10:09:14 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 17 Feb 2017 10:09:14 +0100 Subject: [Development] QMacCocoaViewContainer changes? In-Reply-To: References: <3486735.iQvbknHaF3@portia.local> <14740257.KSoQRj9Y5o@bola> Message-ID: <1766166.8gLC0hSyWj@bola> On Friday February 17 2017 08:41:13 Timur Pocheptsov wrote: >qnsview_cast is using Obj-C RTTI. An object with a type inheriting QNSView will pass isKindOfClass:[QNSView class] test. Doh, yes, of course. In that case the message is probably appropriate though still a bit counterproductive if given fo a QMacCocoaViewContainer's view. Should I report that too? R. From timur.pocheptsov at qt.io Fri Feb 17 10:17:23 2017 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Fri, 17 Feb 2017 09:17:23 +0000 Subject: [Development] QMacCocoaViewContainer changes? In-Reply-To: <1766166.8gLC0hSyWj@bola> References: <3486735.iQvbknHaF3@portia.local> <14740257.KSoQRj9Y5o@bola> , <1766166.8gLC0hSyWj@bola> Message-ID: Yes, please, provide all the related details in the report. Best regards, Timur. ________________________________ From: René J.V. Bertin Sent: Friday, February 17, 2017 10:09:14 AM To: Timur Pocheptsov Cc: development at qt-project.org Subject: Re: [Development] QMacCocoaViewContainer changes? On Friday February 17 2017 08:41:13 Timur Pocheptsov wrote: >qnsview_cast is using Obj-C RTTI. An object with a type inheriting QNSView will pass isKindOfClass:[QNSView class] test. Doh, yes, of course. In that case the message is probably appropriate though still a bit counterproductive if given fo a QMacCocoaViewContainer's view. Should I report that too? R. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.harmer at kdab.com Fri Feb 17 10:48:28 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Fri, 17 Feb 2017 09:48:28 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <8a0d4dcb2c1cf18de8bcfc33e789e2de@kdab.com> Message-ID: <2309942.uiURxqf7o9@cartman> On Friday 17 February 2017 08:10:55 Alex Blasche wrote: > > [...] > > > > I note that an answer on this is still pending, but as an aside: CI on > > 5.8 (and 5.6) appears to be smooth sailing the last two days. Hardly any > > false failures anymore. > > The CI integration process is only partly to blame. Yes, after each fix > round there is a new round of qt5 git integrations with more unit test > fixes followed by a new round of package generation. > > I do realise that the main load probably comes from qt5.git > > integrations, but even so, if 5.8 (qtbase) integrations run through the > > first time instead of requiring half a dozen restages, either the CI > > load is lowered significantly, helping to avoid flakiness in other > > tests, or allowing more stuff to be merged per unit time. > > Each of the packages must be tested. We are talking about 17 different types > of packages. For each package the tester has to install the package and run > a series of tests. This means you have to have testers for each platform > and this takes half a day to do. We are talking about principle testing > for each feature domain, QtCreator, app install & deployment, completeness > of the install package etc. it is not a sexy task either as it is very > mundane. Some steps of this can be automated with squish or similar but I appreciate that may not be the case at the current time. > This also assumes that each tester has time to do the testing at the same > time. Whenever the last platform tester finishes that's when you can > progress to the next step. And this is one of the areas which KDAB is offering to help with if it gets a 5.8.1 release out. But we can only do this if the candidate packages are made available. > 5.8.1 is a release with a lot of changes. It would not be a low effort > release testing. I do not believe that smoke testing is sufficient. At > least the past .1 have very much proven this fact. Sure, but 5.9.0 has even more changes and is therefore more of a risk of taking longer. Nobody is debating that making a .1 release is not a lot of effort. What we are arguing is that making 5.8.1 is more important than releasing 5.9.0 a few weeks earlier than if there is a 5.8.1. As makers of a toolkit there is an implicit promise that there will be timely bug fix releases. It seems that The Qt Company has decided otherwise and that releasing 5.9.0 before the summer vacations is more important. At the end of the day, all we, KDAB and other community members, can do is point out that your customers may well not see it this way and offer to help. But since you control all of the infrastructure there is little else we can do about it. > Yes, there is things we can and want to improve but we are not there yet. I > also do not believe that making a bad release is helping customers either. Again, nobody wants a bad release. We're suggesting a different prioritisation of releases, not sacrificing on quality for any of them. Cheers, Sean > > Shutting down 5.8 because of load problems in the CI now makes even less > > sense than before. > > As shown above it is not. > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From roland.m.winklmeier at gmail.com Fri Feb 17 11:20:44 2017 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Fri, 17 Feb 2017 11:20:44 +0100 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <216C8A23-4FFA-423A-BFE3-F6818BC6D739@qt.io> <1965478.yendhyjin9@tjmaciei-mobl1> <2073316.YcQn1BNY45@cartman> Message-ID: Hi Tuukka, 2017-02-16 17:13 GMT+01:00 Tuukka Turunen : > As multiple people and teams have planned their development according to > initially agreed feature freeze time of Qt 5.9, it would be very > inefficient to reopen 5.9 now or postpone getting the release out. > I would use the same argument for all customers and users of Qt who planned their development on a 5.8.1 release, but with my argument that a bug fix release should have priority over a new feature release. > > If we can get KDAB and others helping with Qt 5.9 with even remotely > similar effort than it would be to create Qt 5.8.1 release I am sure we can > make an awesome Qt 5.9.0 ahead of the planned schedule. This means we can > make the CI system improvements earlier and thus also have Qt 5.9.1 earlier. > My question might sound sarcastic but it is really serious: Who does guarantee me that a 5.9.1 release won't be dropped again in favor of the 5.10 release schedule? Maybe I'm not familiar with the process and details how and when a decision for a patch release is made, but I learned from this discussions that it was expected by most people. If there is no guarantee in the future, this decreases dramatically my will to test and fix bugs after a .0 release in this branch. My contribution might not be high and in total insignificant though. I can only repeat my personal opinion: Bug fixes first, then new features. If the time between two feature releases is too close, then increase the time or change to a release-when-its-ready timeline. My 2 cts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Fri Feb 17 13:35:03 2017 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 17 Feb 2017 09:35:03 -0300 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <1960522.RHXxxDOTgF@tjmaciei-mobl1> References: <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> <1960522.RHXxxDOTgF@tjmaciei-mobl1> Message-ID: <2918745.jklkyq4dsb@tonks> On miércoles, 15 de febrero de 2017 17:29:43 ART Thiago Macieira wrote: > On quarta-feira, 15 de fevereiro de 2017 15:11:49 PST Mathias Hasselmann > > wrote: > > That's a somewhat limited point of view. Yes, xz archives are slightly > > smaller, but to be honest: In the days of 4K video streaming saving > > 100MiB of download size doesn't seem as important as it was. > > There are still people with bad or slow connections. And lots of bandwith usage: download from qt, upload to distro server, push to every mirror around, users downloading the source code from distros... Granted, some of we distro maintainers could repack the source code, but it is always better to have the original whenever possible. > > Is it worth to spend 10 additional minutes per CI cycle just to save our > > users a very few seconds of download time? > > Wait, CI cycle? > > I thought we were talking about releases only, which are final as well as > snapshot packages. Why is the CI creating tarballs? If the problem is the CI then the CI might use gz and use xz for released tarballs. -- AlfaScorpii: podés converncerla a tu vieja que le esconda el diccionario a el_machi? Cada vez que aprende una palabra nueva busca cualquier excusa para usarla e-squizo: leí mi primer diccionario a los 5 años [...] e-squizo: como mi vieja no aprenda lo suficiente de hacking no veo como haria para bajar el sitio de la real academia Visto en #grulic, irc.freenode.net 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 rjvbertin at gmail.com Fri Feb 17 14:52:27 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 17 Feb 2017 14:52:27 +0100 Subject: [Development] QMacCocoaViewContainer changes? In-Reply-To: References: <3486735.iQvbknHaF3@portia.local> <1766166.8gLC0hSyWj@bola> Message-ID: <1751372.zNDXN2lypg@portia.local> Here you go: https://bugreports.qt.io/browse/QTBUG-59001 R. From timur.pocheptsov at qt.io Fri Feb 17 14:55:34 2017 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Fri, 17 Feb 2017 13:55:34 +0000 Subject: [Development] QMacCocoaViewContainer changes? In-Reply-To: <1751372.zNDXN2lypg@portia.local> References: <3486735.iQvbknHaF3@portia.local> <1766166.8gLC0hSyWj@bola> , <1751372.zNDXN2lypg@portia.local> Message-ID: Do you have a smaller reproducer for this? Something not as big as designer or vlc? Best regards, Timur. ________________________________ From: René J.V. Bertin Sent: Friday, February 17, 2017 2:52:27 PM To: Timur Pocheptsov Cc: development at qt-project.org; sitter at kde.org Subject: Re: [Development] QMacCocoaViewContainer changes? Here you go: https://bugreports.qt.io/browse/QTBUG-59001 R. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Fri Feb 17 15:10:32 2017 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 17 Feb 2017 15:10:32 +0100 Subject: [Development] QMacCocoaViewContainer changes? In-Reply-To: References: <3486735.iQvbknHaF3@portia.local> <1751372.zNDXN2lypg@portia.local> Message-ID: <3139410.ArV9TrvsKu@portia.local> On Friday February 17 2017 13:55:34 Timur Pocheptsov wrote: > Do you have a smaller reproducer for this? Something not as big as designer or vlc? Sorry, no. Not yet at least. First thing I tried was releasing the native view in the QMacCocoaViewContainer example, but that doesn't cause a crash. I suspect that this is due to Designer's list of available widgets in the Widget Box causing it to call the QMacCocoaViewContainer dtor during startup. R. From tuukka.turunen at qt.io Fri Feb 17 16:05:20 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 17 Feb 2017 15:05:20 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <827B891B-E3DF-43B5-8F34-0AF048D46002@qt.io> <216C8A23-4FFA-423A-BFE3-F6818BC6D739@qt.io> <1965478.yendhyjin9@tjmaciei-mobl1> <2073316.YcQn1BNY45@cartman> Message-ID: <71396406-22AE-4F9A-BE6D-E3A2F5006202@qt.io> From: Development on behalf of Roland Winklmeier Date: Friday, 17 February 2017 at 12.20 To: "development at qt-project.org" Subject: Re: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 Hi Tuukka, 2017-02-16 17:13 GMT+01:00 Tuukka Turunen >: As multiple people and teams have planned their development according to initially agreed feature freeze time of Qt 5.9, it would be very inefficient to reopen 5.9 now or postpone getting the release out. I would use the same argument for all customers and users of Qt who planned their development on a 5.8.1 release, but with my argument that a bug fix release should have priority over a new feature release. If we can get KDAB and others helping with Qt 5.9 with even remotely similar effort than it would be to create Qt 5.8.1 release I am sure we can make an awesome Qt 5.9.0 ahead of the planned schedule. This means we can make the CI system improvements earlier and thus also have Qt 5.9.1 earlier. My question might sound sarcastic but it is really serious: Who does guarantee me that a 5.9.1 release won't be dropped again in favor of the 5.10 release schedule? Maybe I'm not familiar with the process and details how and when a decision for a patch release is made, but I learned from this discussions that it was expected by most people. If there is no guarantee in the future, this decreases dramatically my will to test and fix bugs after a .0 release in this branch. My contribution might not be high and in total insignificant though. This is a valid concern. I can assure you that The Qt Company has nothing against patch releases. You can look back in history and see that we do make patch releases, sometimes quite many of them. But lately it has become harder and harder. Now we want to fix the fundamentals and get back to normal mode of operations with Qt 5.9, including making patch releases. Yours, Tuukka I can only repeat my personal opinion: Bug fixes first, then new features. If the time between two feature releases is too close, then increase the time or change to a release-when-its-ready timeline. My 2 cts. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Fri Feb 17 17:08:45 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 17 Feb 2017 11:08:45 -0500 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: References: Message-ID: <58A7200D.5070206@gmail.com> On 2017-02-15 05:38, Jani Heikkinen wrote: > As you know we need to optimize our systems to be able to keep our > plans in the future. In CI side we are handling at least 4 different > branches at same time. Releasing side we should be able to do many > releases/snapshots parallel, test those releases/snapshots parallel > etc. And all this needs lots of hw capasity (both calculating power & > disc space). > > We are trying to analyze the places where to do optimization and one > place is our src package creation and delivery: At the moment we are > doing, testing & delivering single src packages + separate submodule > src packages, all these with .zip, .7z, .tar.gz & .tar.xz! Huge > amount of src packages/snapshot/release. And currently doing these > both for enterprise and lgpl! In the future (5.10?) we should be able > to use unified ones meaning no separate LGPL & enterprise ones. Are you actually doing *full testing* on all four of these? If yes, that seems superfluous; it should suffice to do full testing on one each of the UNIX and Windows line-ending packages, and for the rest, just verify that their unpacked content is bitwise identical to one of the packages that was fully tested. The only cost for having both .tar.gz and .tar.xz should be disk space and however long it takes to compress the package in the first place. (Doubly so in this case because you can just `cmp <(gzip -c -d < the.tar.gz) <(xz -c -d < the.tar.xz)` to validate that they are identical.) > *:Download statistic: > .7z 7% > .tar.gz 44% > .tar.xz 12% > .zip 37% 12% is impressively high considering how much more difficult it is to even find the .xz package rather than the .gz. (The main download page only provides the .gz; to get the .xz, one must go digging about in the archives.) -- Matthew From mwoehlke.floss at gmail.com Fri Feb 17 17:20:20 2017 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 17 Feb 2017 11:20:20 -0500 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> References: <101421487155580@web24o.yandex.ru> <20170215120506.jyhwmb7yyxn36ife@mitya57.me> <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de> Message-ID: <58A722C4.70608@gmail.com> On 2017-02-15 18:11, Mathias Hasselmann wrote: > The actual value of gzip and the reason for its return seems to be its > significantly lower CPU usage. This is useful to reduce server load on > heavily utilized services like github. This is useful to reduce > development roundtrip cycles. > > Just to illustrate this I've collected some numbers on my Thinkpad: > > Command | Average | Savings | Archive | Savings > | CPU time | p. build | size | @100MBit > ==================================================== > gzip | 00:44.19 | 09:54.58 | 469 MiB | 00:00.00 > gzip -9 | 01:55.58 | 08:43.18 | 465 MiB | 00:00.32 > xz | 08:46.16 | 01:52.60 | 354 MiB | 00:09.20 > xz -9 | 10:38.77 | 00:00.00 | 333 MiB | 00:10.88 > > Is it worth to spend 10 additional minutes per CI cycle just to save our > users a very few seconds of download time? Um... yes? 10 min * once = 10 s * 60 users. Do you imply that fewer than 60 users use the .xz packages? Remember, that's not just *user* benefit, that is also 10 s *per download* less load on the servers. Compression happens once; downloads happen many times. OTOH... A better metric is decompression, which also happens many times. On one of my machines, it takes¹ about 8.5 s to uncompress the .gz (to /dev/null) and about 19 s to uncompress the .xz (also to /dev/null). So... it does cost about 10 s more CPU time to uncompress the .xz. That being the case, I'll grant that *if* you're on a sufficiently high-speed network, maybe it doesn't make sense to download the .xz. (¹ I ran 20 trials each to reduce artifacts from caching, etc. I got very consistent times, so I have high confidence that these numbers are reasonable.) -- Matthew From oktal3700 at gmail.com Sat Feb 18 15:36:07 2017 From: oktal3700 at gmail.com (Mat Sutcliffe) Date: Sat, 18 Feb 2017 14:36:07 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 Message-ID: The upcoming process changes are very welcome. Regarding MSVC 2015/2017 ABI, I already opened QTCREATORBUG-17740. At the risk of simply repeating what others have said, it feels unsatisfying that a delay in the release of 5.8.0 should lead to a shortening of the 5.9.0 release schedule, or that in general, a "time debt" incurred by a delay in one minor release should need to be "caught up" by stealing time from the subsequent minor release. It seems to be a symptom of trying to make a parallel process fit into a serial structure. Keeping 5.9.0 on schedule even while 5.8.0 blows past its planned release date would seem to be appropriate when you have the capability to concurrently maintain two minor (not patchlevel) release branches. In retrospect it feels like a mistake to promise a strict six month minor release cycle (implicitly/unknowingly at the expense of patchlevel releases) if you don't have that capability yet. I look forward to seeing those CI improvements. "We plan, and plan, and then plan again. What we don't do is stress conformance to a plan." - Uncle Bob Martin. My two tenths of a cent. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Feb 18 20:13:37 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 18 Feb 2017 11:13:37 -0800 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: Message-ID: <5098997.BicRX6s0W7@tjmaciei-mobl1> On sábado, 18 de fevereiro de 2017 06:36:07 PST Mat Sutcliffe wrote: > Keeping 5.9.0 on schedule even while 5.8.0 blows past its planned release > date would seem to be appropriate when you have the capability to > concurrently maintain two minor (not patchlevel) release branches. That's exactly what Tuukka proposed we do. We keep 5.9.0 on schedule and, because of that, 5.8.1 becomes impossible and unnecessary. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Sat Feb 18 20:49:28 2017 From: annulen at yandex.ru (Konstantin Tokarev) Date: Sat, 18 Feb 2017 22:49:28 +0300 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <5098997.BicRX6s0W7@tjmaciei-mobl1> References: <5098997.BicRX6s0W7@tjmaciei-mobl1> Message-ID: <14519401487447368@web10g.yandex.ru> 18.02.2017, 22:13, "Thiago Macieira" : > On sábado, 18 de fevereiro de 2017 06:36:07 PST Mat Sutcliffe wrote: >>  Keeping 5.9.0 on schedule even while 5.8.0 blows past its planned release >>  date would seem to be appropriate when you have the capability to >>  concurrently maintain two minor (not patchlevel) release branches. > > That's exactly what Tuukka proposed we do. We keep 5.9.0 on schedule and, > because of that, 5.8.1 becomes impossible and unnecessary. So people who cannot upgrade to 5.8.0 because of bugs would have to wait for 5.9.0 and hope that there will be no other regressions. Great. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From oktal3700 at gmail.com Sat Feb 18 21:11:53 2017 From: oktal3700 at gmail.com (Mat Sutcliffe) Date: Sat, 18 Feb 2017 20:11:53 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <5098997.BicRX6s0W7@tjmaciei-mobl1> References: <5098997.BicRX6s0W7@tjmaciei-mobl1> Message-ID: On 18 February 2017 at 19:13, Thiago Macieira wrote: > On sábado, 18 de fevereiro de 2017 06:36:07 PST Mat Sutcliffe wrote: > > Keeping 5.9.0 on schedule even while 5.8.0 blows past its planned release > > date would seem to be appropriate when you have the capability to > > concurrently maintain two minor (not patchlevel) release branches. > > That's exactly what Tuukka proposed we do. We keep 5.9.0 on schedule and, > because of that, 5.8.1 becomes impossible and unnecessary. > My point was that this decision happened already on 29 November. That was the original planned release date for 5.8.0, and also the day on which the 5.9.0 initial schedule was set. Could it have been predicted at that time what the consequences might be for 5.8.1? -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Feb 18 21:40:47 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 18 Feb 2017 12:40:47 -0800 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <5098997.BicRX6s0W7@tjmaciei-mobl1> Message-ID: <5134146.h9xGcFzzKe@tjmaciei-mobl1> On sábado, 18 de fevereiro de 2017 12:11:53 PST Mat Sutcliffe wrote: > On 18 February 2017 at 19:13, Thiago Macieira > > wrote: > > On sábado, 18 de fevereiro de 2017 06:36:07 PST Mat Sutcliffe wrote: > > > Keeping 5.9.0 on schedule even while 5.8.0 blows past its planned > > > release > > > date would seem to be appropriate when you have the capability to > > > concurrently maintain two minor (not patchlevel) release branches. > > > > That's exactly what Tuukka proposed we do. We keep 5.9.0 on schedule and, > > because of that, 5.8.1 becomes impossible and unnecessary. > > My point was that this decision happened already on 29 November. That was > the original planned release date for 5.8.0, and also the day on which the > 5.9.0 initial schedule was set. Could it have been predicted at that time > what the consequences might be for 5.8.1? Hindsight is 20/20. Let's not rehash coulda-woulda-shoulda. The question is only what to do now. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Feb 18 21:40:11 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 18 Feb 2017 12:40:11 -0800 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <14519401487447368@web10g.yandex.ru> References: <5098997.BicRX6s0W7@tjmaciei-mobl1> <14519401487447368@web10g.yandex.ru> Message-ID: <18144646.GrGa0AsBTG@tjmaciei-mobl1> On sábado, 18 de fevereiro de 2017 11:49:28 PST Konstantin Tokarev wrote: > 18.02.2017, 22:13, "Thiago Macieira" : > > On sábado, 18 de fevereiro de 2017 06:36:07 PST Mat Sutcliffe wrote: > >> Keeping 5.9.0 on schedule even while 5.8.0 blows past its planned > >> release > >> date would seem to be appropriate when you have the capability to > >> concurrently maintain two minor (not patchlevel) release branches. > > > > That's exactly what Tuukka proposed we do. We keep 5.9.0 on schedule and, > > because of that, 5.8.1 becomes impossible and unnecessary. > > So people who cannot upgrade to 5.8.0 because of bugs would have to wait for > 5.9.0 and hope that there will be no other regressions. Great. Or wait for 5.9.1. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From oktal3700 at gmail.com Sat Feb 18 22:37:02 2017 From: oktal3700 at gmail.com (Mat Sutcliffe) Date: Sat, 18 Feb 2017 21:37:02 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <5134146.h9xGcFzzKe@tjmaciei-mobl1> References: <5098997.BicRX6s0W7@tjmaciei-mobl1> <5134146.h9xGcFzzKe@tjmaciei-mobl1> Message-ID: On 18 February 2017 at 20:40, Thiago Macieira wrote: > > Hindsight is 20/20. Let's not rehash coulda-woulda-shoulda. > > The question is only what to do now. > Oh, absolutely. I just thought it might help to understand a little more how we got here. -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Mon Feb 20 10:56:06 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 20 Feb 2017 09:56:06 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: References: <5098997.BicRX6s0W7@tjmaciei-mobl1> <5134146.h9xGcFzzKe@tjmaciei-mobl1>, Message-ID: Mat Sutcliffe (18 February 2017 15:36) >>> "We plan, and plan, and then plan again. What we don't do is stress >>> conformance to a plan." - Uncle Bob Martin. One may generalise von Moltke: plans seldom survive more than a little contact with reality. It remains useful to make them, as long as one remains ready to revise them. On 18 February 2017 at 20:40, Thiago Macieira > wrote: >> Hindsight is 20/20. Let's not rehash coulda-woulda-shoulda. >> >> The question is only what to do now. Mat Sutcliffe (18 February 2017 22:37) replied: > Oh, absolutely. I just thought it might help to understand a little > more how we got here. Indeed - when we have to do something we'd rather not, it *is* important to ask "How did we get here ?" - if only so that we can notice similar things coming, next time around, and revise plans sooner. The central story of Quality Assurance (as distinct from testing, a.k.a. Quality Control, though it's commonly *called* QA in the software industry) is the study of how stuff went wrong so as to avoid doing that again, Eddy. From tuukka.turunen at qt.io Mon Feb 20 13:56:02 2017 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 20 Feb 2017 12:56:02 +0000 Subject: [Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17 In-Reply-To: <5134146.h9xGcFzzKe@tjmaciei-mobl1> References: <5098997.BicRX6s0W7@tjmaciei-mobl1> <5134146.h9xGcFzzKe@tjmaciei-mobl1> Message-ID: >On 18/02/2017, 21.40, "Development on behalf of Thiago Macieira" wrote: > > On sábado, 18 de fevereiro de 2017 12:11:53 PST Mat Sutcliffe wrote: > > On 18 February 2017 at 19:13, Thiago Macieira > > My point was that this decision happened already on 29 November. That was > > the original planned release date for 5.8.0, and also the day on which the > > 5.9.0 initial schedule was set. Could it have been predicted at that time > > what the consequences might be for 5.8.1? > > Hindsight is 20/20. Let's not rehash coulda-woulda-shoulda. > > The question is only what to do now. What I hope we can do is to have everyone helping to get Qt 5.9.0 out as soon as possible and then make also 5.9.1 soon (although I think we do need to make 5.6.3 in between). If we can have the extra help proposed by KDAB and others in the community for making Qt 5.8.1 release geared towards making Qt 5.9 we will be able to make it faster and with higher quality than otherwise possible. One concrete item is manual testing of our various snapshots. The sooner these are fully tested, the better. We have CI and RTA test automation, but these do not cover every aspect. Manual testing is needed as well. Often it is a case that a bug is found in quite late release steps, but has actually been there for some time already. Another way to help is making good bug reports that are also notified to the release team. The better the description of the issue, the easier it is to fix it. Third item is of course fixing things quickly – by having more people fixing the issues identified we will be able to close them sooner and thus proceed faster. For the CI stability most important thing is to reduce the amount of flaky test cases, which cause failures in CI runs. This in turn both adds delay as well as increases the load of the CI. Yours, Tuukka From marc.mutz at kdab.com Mon Feb 20 21:48:50 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 20 Feb 2017 21:48:50 +0100 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: References: <201701302003.25214.marc.mutz@kdab.com> Message-ID: <201702202148.50790.marc.mutz@kdab.com> On Tuesday 31 January 2017 13:32:03 Lars, Knoll wrote: > Let's get this into dev as soon as we can, and make sure we have a great > story to tell for 5.10. The base commit isn't in, yet. There's been no measureable forward progress regarding review. I'm not going to work on the patch series until the basis is merged, since I am not interested in another Q_STRINGTABLE experience. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts From thiago.macieira at intel.com Mon Feb 20 22:02:43 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Feb 2017 13:02:43 -0800 Subject: [Development] Feature Freeze Exception: QStringView In-Reply-To: <201702202148.50790.marc.mutz@kdab.com> References: <201701302003.25214.marc.mutz@kdab.com> <201702202148.50790.marc.mutz@kdab.com> Message-ID: <1907340.NmBgD95Sl0@tjmaciei-mobl1> On segunda-feira, 20 de fevereiro de 2017 12:48:50 PST Marc Mutz wrote: > On Tuesday 31 January 2017 13:32:03 Lars, Knoll wrote: > > Let's get this into dev as soon as we can, and make sure we have a great > > story to tell for 5.10. > > The base commit isn't in, yet. There's been no measureable forward progress > regarding review. I'm not going to work on the patch series until the basis > is merged, since I am not interested in another Q_STRINGTABLE experience. Because there was a rush of P0s relating to tests that were flaky because the CI is 300-1000x slower than a machine ought to be. So the time I had alloted for it was spent elsewhere, applying workarounds to things that shouldn't need fixing. I'll take a look after the Embedded Linux Conference / OpenIoT Summit. I really want QStringView and I'd like to talk to you how Qt6 QString, QStringView and a non-sharing QString class should cooperate to reduce code size in QtCore. Something like QString deriving from QStringView. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andrewponomarenko at yandex.ru Wed Feb 22 08:22:29 2017 From: andrewponomarenko at yandex.ru (Andrey Ponomarenko) Date: Wed, 22 Feb 2017 10:22:29 +0300 Subject: [Development] Search for binary symbols across Qt releases with the help of ABI Navigator Message-ID: <1806321487748149@web4h.yandex.ru> Hello, I'd like to present a new project called "ABI Navigator" for searching binary symbols (functions, methods, global data, etc.) in Qt and other open-source libraries: https://abi-laboratory.pro/index.php?view=navigator The project allows to find out in which versions of the library some symbol is defined, added, removed or changed. The data is taken from the ABI Tracker project: https://abi-laboratory.pro/tracker/timeline/qt/ Example for _Z16qGlobalQHashSeedv from libQt5Core.so: https://abi-laboratory.pro/index.php?view=navigator&selected=_Z16qGlobalQHashSeedv%40%40Qt_5#result The project aims to help library users and maintainers to resolve issues with missed symbols and navigate through the reports in the ABI Tracker. Have you ever encountered the "undefined reference" error or want to know whether the symbol is _stable_ enough to import in your code? Try to find it in the ABI Navigator! Enjoy! From announce at qt-project.org Thu Feb 23 10:55:29 2017 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 23 Feb 2017 09:55:29 +0000 Subject: [Development] [Announce] Qt 5.9.0 Alpha released Message-ID: Hi, I am happy to inform that Qt 5.9.0 Alpha release is out, see http://blog.qt.io/blog/2017/02/23/qt-5-9-alpha-released/ And a bit earlier than planned! Big thanks to everyone involved. br, Jani Heikkinen Release Manager _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From jani.heikkinen at qt.io Thu Feb 23 12:16:28 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 23 Feb 2017 11:16:28 +0000 Subject: [Development] Decrease amounth of delivered src packages In-Reply-To: <58A722C4.70608@gmail.com> References: <101421487155580@web24o.yandex.ru> <20170215120506.jyhwmb7yyxn36ife@mitya57.me> <0d29a7a8-1104-373a-f7ac-36fbfb7012ab@taschenorakel.de>, <58A722C4.70608@gmail.com> Message-ID: Ok, it seems we have reached a consensus here: From now on we will deliver two different src package sets - One set of src packages with ẃindows line endings (.zip, both single one & submodule specific, both enterprise and lgpl) - One set of src packages with unix line endings (.tar.xz, both single one & submodule specific, both enterprise and lgpl) With alpha we sill delivered all as earlier but we will change our system now to adapt the change br, Jani ________________________________________ From: Development on behalf of Matthew Woehlke Sent: Friday, February 17, 2017 6:20:20 PM To: development at qt-project.org Subject: Re: [Development] Decrease amounth of delivered src packages On 2017-02-15 18:11, Mathias Hasselmann wrote: > The actual value of gzip and the reason for its return seems to be its > significantly lower CPU usage. This is useful to reduce server load on > heavily utilized services like github. This is useful to reduce > development roundtrip cycles. > > Just to illustrate this I've collected some numbers on my Thinkpad: > > Command | Average | Savings | Archive | Savings > | CPU time | p. build | size | @100MBit > ==================================================== > gzip | 00:44.19 | 09:54.58 | 469 MiB | 00:00.00 > gzip -9 | 01:55.58 | 08:43.18 | 465 MiB | 00:00.32 > xz | 08:46.16 | 01:52.60 | 354 MiB | 00:09.20 > xz -9 | 10:38.77 | 00:00.00 | 333 MiB | 00:10.88 > > Is it worth to spend 10 additional minutes per CI cycle just to save our > users a very few seconds of download time? Um... yes? 10 min * once = 10 s * 60 users. Do you imply that fewer than 60 users use the .xz packages? Remember, that's not just *user* benefit, that is also 10 s *per download* less load on the servers. Compression happens once; downloads happen many times. OTOH... A better metric is decompression, which also happens many times. On one of my machines, it takes¹ about 8.5 s to uncompress the .gz (to /dev/null) and about 19 s to uncompress the .xz (also to /dev/null). So... it does cost about 10 s more CPU time to uncompress the .xz. That being the case, I'll grant that *if* you're on a sufficiently high-speed network, maybe it doesn't make sense to download the .xz. (¹ I ran 20 trials each to reduce artifacts from caching, etc. I got very consistent times, so I have high confidence that these numbers are reasonable.) -- Matthew _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From roland.m.winklmeier at gmail.com Thu Feb 23 14:56:29 2017 From: roland.m.winklmeier at gmail.com (Roland Winklmeier) Date: Thu, 23 Feb 2017 14:56:29 +0100 Subject: [Development] Warning about unknown escape sequences in qtremoteobjects Message-ID: Dear Qt developers, when building Qt 5.9.0 from git (by coincidence it was the same commit as 5.9.0 Alpha), I got many of the following warnings in qtremoteobjects: In file included from main.cpp:43:0: repparser.h:2:10: warning: unknown escape sequence: '\.' #line 57 "..\..\src\repparser\parser.g" caused by lines like #line 57 "..\..\src\\repparser\parser.g" in repparser.h and repparser.cpp. Those are just warnings, but treated as errors in the dev build. I always try to fix things like those myself, but this time, I'm a bit stuck where this came from. Hence my question: 1. Should it be #line 57 "../../src/repparser/parser.g" or #line 57 "..\\..\\src\\repparser\\parser.g" 2. The files are generated by qlalr. So is the bug in qlalr or is it in the input document, qlalr is parsing or even somewhere else? Any ideas? Cheers R. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Feb 23 17:18:01 2017 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 23 Feb 2017 08:18:01 -0800 Subject: [Development] Warning about unknown escape sequences in qtremoteobjects In-Reply-To: References: Message-ID: <2858018.D92RDGKUkv@tjmaciei-mobl1> On quinta-feira, 23 de fevereiro de 2017 05:56:29 PST Roland Winklmeier wrote: > 2. The files are generated by qlalr. So is the bug in qlalr or is it in the > input document, qlalr is parsing or even somewhere else? Probably a bug in qlalr that no one has ever noticed because no one has ever committed its generated files when run on Windows. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From chgans at gna.org Thu Feb 23 23:08:11 2017 From: chgans at gna.org (Ch'Gans) Date: Fri, 24 Feb 2017 11:08:11 +1300 Subject: [Development] Documentation typo fixes In-Reply-To: References: Message-ID: Hi guys, Who do I need to invite as reviewers for these typo fixes? https://codereview.qt-project.org/186292 Thanks, Chris On 8 February 2017 at 11:03, Ch'Gans wrote: > On 7 February 2017 at 23:18, Edward Welbourne wrote: > [...] >> >> Sze Howe Koh (7 February 2017 04:35) replied: >>> See http://wiki.qt.io/Branch_Guidelines (Note: Qt module repositories >>> don't have a "master" branch) >>> >>> Right now, the branches that accept documentation fixes are: >>> >>> * 5.8 (stable branch) >>> * 5.9 (next release branch) >>> * dev (development branch) >>> >>> Simply put, patches will merge from the top of the list to the bottom >>> of this list. For example, patches that go into "5.8" will eventually >>> be merged into "5.9", which in turn will eventually be merged into >>> "dev". >>> >>> Typo fixes are not new features or major/risky changes, so they can go >>> into the stable branch ("5.8"). >> >> Indeed. This is all being formalised in QUIP 5: >> https://codereview.qt-project.org/178906 >> where you can find out all you wish to know about which changes should >> go to which branches, > > Thanks both of you for the information. > Chris > >> >> Eddy. From szehowe.koh at gmail.com Fri Feb 24 01:02:55 2017 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Fri, 24 Feb 2017 08:02:55 +0800 Subject: [Development] Documentation typo fixes In-Reply-To: References: Message-ID: On 24 February 2017 at 06:08, Ch'Gans wrote: > > Hi guys, > > Who do I need to invite as reviewers for these typo fixes? > https://codereview.qt-project.org/186292 > > > Thanks, > Chris Hi Chris, I'm happy to review documentation patches. > On 8 February 2017 at 11:03, Ch'Gans wrote: > > On 7 February 2017 at 23:18, Edward Welbourne wrote: > > [...] > >> > >> Sze Howe Koh (7 February 2017 04:35) replied: > >>> See http://wiki.qt.io/Branch_Guidelines (Note: Qt module repositories > >>> don't have a "master" branch) > >>> > >>> Right now, the branches that accept documentation fixes are: > >>> > >>> * 5.8 (stable branch) > >>> * 5.9 (next release branch) > >>> * dev (development branch) > >>> > >>> Simply put, patches will merge from the top of the list to the bottom > >>> of this list. For example, patches that go into "5.8" will eventually > >>> be merged into "5.9", which in turn will eventually be merged into > >>> "dev". > >>> > >>> Typo fixes are not new features or major/risky changes, so they can go > >>> into the stable branch ("5.8"). > >> > >> Indeed. This is all being formalised in QUIP 5: > >> https://codereview.qt-project.org/178906 > >> where you can find out all you wish to know about which changes should > >> go to which branches, > > > > Thanks both of you for the information. > > Chris > > > >> > >> Eddy. Regards, Sze-Howe From hamed.masafi at gmail.com Fri Feb 24 10:05:28 2017 From: hamed.masafi at gmail.com (Hamed Masafi) Date: Fri, 24 Feb 2017 12:35:28 +0330 Subject: [Development] Request moving project (noron) to playground area In-Reply-To: <9C905C2E-95CA-4662-B47D-7248D06FFE5C@qt.io> References: <9C905C2E-95CA-4662-B47D-7248D06FFE5C@qt.io> Message-ID: Hi I'd seen Qt Remote Objects. But is has not any document. I read wiki and some information and compiled source and examples. I hope Berrit add some information. Overlas (as I understand) - Share a QObject on server and clients can be access Differences: Noron can serv an object per peer On Thu, Feb 9, 2017 at 12:35 PM, Lars Knoll wrote: > Yes, please have a look at Qt Remote Objects, which has been a playground project for a while. Brett is currently working on upgrading this to a Technology Preview module for Qt. Before doing anything else with this module it’ll be good to understand what the overlap and differences between those modules are. > > Cheers, > Lars > >> On 05 Feb 2017, at 11:16, Soroush Rabiei wrote: >> >> Greetings >> >> Good idea (: it would be great to have RPC integrated into Qt... >> >> There was a similar project (Qt Remote Objects was the name if I'm not >> mistaken). Don't know the details, seems they are planning to provide >> a transparent remote API around Qt's Signal/Slot mechanism... You may >> want to have a look at it, or contact its developers: >> >> http://lists.qt-project.org/pipermail/development/2017-January/028282.html >> >> Cheers, >> Soroush >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > From kevin.funk at kdab.com Fri Feb 24 11:49:18 2017 From: kevin.funk at kdab.com (Kevin Funk) Date: Fri, 24 Feb 2017 11:49:18 +0100 Subject: [Development] Warning about unknown escape sequences in qtremoteobjects In-Reply-To: <2858018.D92RDGKUkv@tjmaciei-mobl1> References: <2858018.D92RDGKUkv@tjmaciei-mobl1> Message-ID: <1686991.doNz7MhPlY@kerberos> On Thursday, 23 February 2017 08:18:01 CET Thiago Macieira wrote: > On quinta-feira, 23 de fevereiro de 2017 05:56:29 PST Roland Winklmeier wrote: > > 2. The files are generated by qlalr. So is the bug in qlalr or is it in > > the > > input document, qlalr is parsing or even somewhere else? > > Probably a bug in qlalr that no one has ever noticed because no one has ever > committed its generated files when run on Windows. Patch for qlalr here: https://codereview.qt-project.org/#/c/186626/1 Regards, Kevin -- Kevin Funk | kevin.funk at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7021 bytes Desc: not available URL: From bstottle at ford.com Fri Feb 24 15:08:10 2017 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Fri, 24 Feb 2017 14:08:10 +0000 Subject: [Development] Request moving project (noron) to playground area In-Reply-To: References: <9C905C2E-95CA-4662-B47D-7248D06FFE5C@qt.io> Message-ID: <18D92F82-76C8-454E-B52F-312CB7E1FA5F@ford.com> > On 2/24/17, 4:05 AM, "Hamed Masafi" wrote: > > Hi Hi Hamed > I'd seen Qt Remote Objects. But is has not any document. I read wiki > and some information and compiled source and examples. I hope Berrit > add some information. I imagine QtRO evolved like most projects, with code preceding documentation. It is documented (although the docs definitely need cleanup before it moves out of TP status), but you need to run make docs on the source to generate the Qt-style docs. The overview and getting started are complete, as are the class descriptions. There are places that needed to be updated with some of the feature changes that have gone in. Along those lines, it looks like only Qt 4.8, 5.6 and 5.8 docs are available online (from doc.qt.io). Is there a way to get to other versions, including possibly the 5.9-alpha versions? Or will the docs for new modules only be available when 5.9 is released? Last question is directed at someone at The Qt Company, but I’m not sure who. > Overlas (as I understand) > - Share a QObject on server and clients can be access > > Differences: > Noron can serv an object per peer You look like you are trying to reinvent QtRO. I think what you call a Peer is what QtRO calls a Node. Your Classes are QtRO Source or Replica objects. From the limited README, it looks like the main difference is that your Class directly connects to the Peer, while in QtRO you get your Replica from the Node. You also have a blocking call built in, QtRO doesn’t (but it could be implemented in user code, although it would probably be unwise). Then there are a bunch of additions in QtRO: * Registry (so you don’t need to know the address of every object) * PODs/Enums (so you can pass more useful types) * QAIM support (built in) * Support for multiple backends (tcp/ip, localsocket, QNX backend right now) * etc.. Hopefully if there are features you think are missing in QtRO you would contribute to the module already going into Qt rather than creating another module? Regards, Brett From andre.hartmann at iseg-hv.de Fri Feb 24 15:29:20 2017 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Fri, 24 Feb 2017 15:29:20 +0100 Subject: [Development] Request moving project (noron) to playground area In-Reply-To: <18D92F82-76C8-454E-B52F-312CB7E1FA5F@ford.com> References: <9C905C2E-95CA-4662-B47D-7248D06FFE5C@qt.io> <18D92F82-76C8-454E-B52F-312CB7E1FA5F@ford.com> Message-ID: <8146d85e-9a76-ded8-3dc9-120286385789@iseg-hv.de> Hi Brett, Am 24.02.2017 um 15:08 schrieb Stottlemyer, Brett (B.S.): >> On 2/24/17, 4:05 AM, "Hamed Masafi" wrote: >> >> Hi > > Hi Hamed > >> I'd seen Qt Remote Objects. But is has not any document. I read wiki >> and some information and compiled source and examples. I hope Berrit >> add some information. > > I imagine QtRO evolved like most projects, with code preceding documentation. It > is documented (although the docs definitely need cleanup before it moves out of TP > status), but you need to run make docs on the source to generate the Qt-style docs. > > The overview and getting started are complete, as are the class descriptions. There > are places that needed to be updated with some of the feature changes that have > gone in. > > Along those lines, it looks like only Qt 4.8, 5.6 and 5.8 docs are available online (from > doc.qt.io). Is there a way to get to other versions, including possibly the 5.9-alpha > versions? Or will the docs for new modules only be available when 5.9 is released? > Last question is directed at someone at The Qt Company, but I’m not sure who. Have a look at http://doc-snapshots.qt.io/ BR, André > >> Overlas (as I understand) >> - Share a QObject on server and clients can be access >> >> Differences: >> Noron can serv an object per peer > > You look like you are trying to reinvent QtRO. I think what you call a Peer is what > QtRO calls a Node. Your Classes are QtRO Source or Replica objects. From the > limited README, it looks like the main difference is that your Class directly connects > to the Peer, while in QtRO you get your Replica from the Node. > > You also have a blocking call built in, QtRO doesn’t (but it could be implemented in > user code, although it would probably be unwise). > > Then there are a bunch of additions in QtRO: > * Registry (so you don’t need to know the address of every object) > * PODs/Enums (so you can pass more useful types) > * QAIM support (built in) > * Support for multiple backends (tcp/ip, localsocket, QNX backend right now) > * etc.. > > Hopefully if there are features you think are missing in QtRO you would contribute > to the module already going into Qt rather than creating another module? > > Regards, > Brett > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From bstottle at ford.com Fri Feb 24 15:30:20 2017 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Fri, 24 Feb 2017 14:30:20 +0000 Subject: [Development] Request moving project (noron) to playground area In-Reply-To: <8146d85e-9a76-ded8-3dc9-120286385789@iseg-hv.de> References: <9C905C2E-95CA-4662-B47D-7248D06FFE5C@qt.io> <18D92F82-76C8-454E-B52F-312CB7E1FA5F@ford.com> <8146d85e-9a76-ded8-3dc9-120286385789@iseg-hv.de> Message-ID: <186AED03-A598-4668-A6D7-1686B796C0FC@ford.com> > On 2/24/17, 9:29 AM, "André Hartmann" wrote: > > Hi Brett, > > Have a look at http://doc-snapshots.qt.io/ Didn’t even know that was there. I was excited for a moment, but for some reason QtRO isn’t included in the TP section. http://doc-snapshots.qt.io/qt5-5.9/qtmodules.html#technology-preview-modules What needs to happen to get QtRO added? Again, the docs are part of the module. Regards, Brett From Riitta-Leena.Miettinen at qt.io Fri Feb 24 15:56:22 2017 From: Riitta-Leena.Miettinen at qt.io (Riitta-Leena Miettinen) Date: Fri, 24 Feb 2017 14:56:22 +0000 Subject: [Development] Request moving project (noron) to playground area Message-ID: > Date: Fri, 24 Feb 2017 14:30:20 +0000 > From: "Stottlemyer, Brett (B.S.)" > To: Qt development mailing list > Subject: Re: [Development] Request moving project (noron) to > playground area > Message-ID: <186AED03-A598-4668-A6D7-1686B796C0FC at ford.com> > Content-Type: text/plain; charset="utf-8" > > > On 2/24/17, 9:29 AM, "Andr? Hartmann" > wrote: > > > > Hi Brett, > > > > Have a look at http://doc-snapshots.qt.io/ > > Didn?t even know that was there. > > I was excited for a moment, but for some reason QtRO isn?t included in the > TP section. > http://doc-snapshots.qt.io/qt5-5.9/qtmodules.html#technology-preview- > modules > > What needs to happen to get QtRO added? Again, the docs are part of the > module. > Hello Brett, You could submit a patch that adds a link to the table that lists all Qt modules. There are some other tasks involved, too. Here is a link to a checklist for adding documentation for a new Qt module: http://wiki.qt.io/Checklist_for_Adding_Documentation_for_a_New_Module Leena Leena Miettinen Documentation Engineer The Qt Company Germany GmbH Rudower Chaussee 13 D-12489, Berlin, Germany Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B riitta-leena.miettinen at qt.io +49 30 63 92 3255 http://qt.io From oktal3700 at gmail.com Fri Feb 24 19:42:32 2017 From: oktal3700 at gmail.com (Mat Sutcliffe) Date: Fri, 24 Feb 2017 18:42:32 +0000 Subject: [Development] Request moving project (noron) to playground area In-Reply-To: References: Message-ID: Until the link is added, you can visit the direct URL http://doc-snapshots.qt.io/qt5-5.9/qtremoteobjects-index.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhihn at gmx.com Fri Feb 24 20:59:28 2017 From: jhihn at gmx.com (Jason H) Date: Fri, 24 Feb 2017 20:59:28 +0100 Subject: [Development] [Announce] Qt 5.9.0 Alpha released In-Reply-To: References: Message-ID: > Sent: Thursday, February 23, 2017 at 4:55 AM > From: "List for announcements regarding Qt releases and development" > To: "announce at qt-project.org" > Subject: [Development] [Announce] Qt 5.9.0 Alpha released > > Hi, > > I am happy to inform that Qt 5.9.0 Alpha release is out, see http://blog.qt.io/blog/2017/02/23/qt-5-9-alpha-released/ > Is there a blocker bug issue in JIRA? Since there are no maintenance releases planned until 5.9, I have two issues: https://bugreports.qt.io/browse/QTBUG-56536 - Nougat camera preview is upside down (P1: Reported 6 months ago) https://bugreports.qt.io/browse/QTBUG-58278 - QML Websockets only connect once (P2: Commercial support started Dec 9, 2016, reported Jan 19) From zoltan.lutor at gmail.com Sun Feb 26 10:34:51 2017 From: zoltan.lutor at gmail.com (=?UTF-8?Q?Zolt=C3=A1n_Lutor?=) Date: Sun, 26 Feb 2017 10:34:51 +0100 Subject: [Development] Fwd: Qt contributions In-Reply-To: References: Message-ID: Hi, I would like to ask help/guidance how the sw mentioned below could be part of official Qt package. Or, if that is not possible - due to lack of interest or whatever reason -, some help in form of: - reviewing current code - giving suggestions how it can be made better - especially the part related to displaying received content in HTML (WebView, whatever) - contributing development of current solution - etc. I'm working on my very first Qt/QML based multi-platform game: goo.gl/3jKIwZ Firs for Android, then Sailfish and maybe iOS (if I manage to get in touch with developer device) but I've not found any (free) advertisement SDK/API/solution usable with Qt/QML ATM. That's the reason behind starting creating my own but I need your help... Thx in advance, Zoltan ps: I'm totally newbie with Qt/QML development, so suggestions/explanations/advice cannot be too detailed... ;) ---------- Forwarded message ---------- Subject: Qt contributions To: "zoltan.lutor at gmail.com" Dear Zoltan, We have a guide for contributors: http://wiki.qt.io/Qt- Contribution-Guidelines. It contains instructions, list of maintainers and contact details like e-mails and IRC channels for discussions. Please, submit your request there again. [image: The Qt Company logo] [image: Facebook] [image: Twitter] [image: LinkedIn] [image: Google+] [image: YouTube] I've progressed with implementing an open source wrapper for Vserv RESTful advertisement API in QML. Quote from API description: Vserv provides a simple HTTP based API to publishers/developers and other ad networks, etc. to fetch ads for mobile sites or mobile applications. The mobile device / server makes a HTTP request to Vserv Marketplace server with the required parameters and in response receives the ad in JSON format. This single API integration gives you the flexibility to fetch banner/ full screen / rich media ads. Available implementation is in pre-beta phase - quite majority of functionality works but there is still room for improvement. Since I'm not so experienced Qt/QML development - I would like to offer it to you and asking for help finishing it and releasing it to the community... API description: https://docs.google.com/document/d/ 139TRSTV33tLxKxbew4yPTPF4uc8PZJPiRkxyo9GymIE/edit Source: https://bitbucket.org/zlutor/qml-wrapper-for-vserv-http-ad-api Thx, Zoltan -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image018.png Type: image/png Size: 954 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.png Type: image/png Size: 1095 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 9485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.png Type: image/png Size: 891 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image016.png Type: image/png Size: 963 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image017.png Type: image/png Size: 1256 bytes Desc: not available URL: From elderorb at gmail.com Mon Feb 27 18:44:09 2017 From: elderorb at gmail.com (Alexander Ivash) Date: Mon, 27 Feb 2017 20:44:09 +0300 Subject: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ? Message-ID: Is it planned to enable mapbox-gl-native building for windows? If yes, then when? Alexander From paolo.angelelli at qt.io Mon Feb 27 21:11:17 2017 From: paolo.angelelli at qt.io (Paolo Angelelli) Date: Mon, 27 Feb 2017 20:11:17 +0000 Subject: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ? In-Reply-To: References: Message-ID: Hi Alexander, we are trying, but we are unsure if we'll be able to ship the mapboxgl plugin for windows with 5.9. In any case, i believe that, if not, mapbox might make it available outside the qt sdk as an additional plugin. regards ________________________________________ From: Development [development-bounces+paolo.angelelli=qt.io at qt-project.org] on behalf of Alexander Ivash [elderorb at gmail.com] Sent: Monday, February 27, 2017 6:44 PM To: development at qt-project.org Subject: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ? Is it planned to enable mapbox-gl-native building for windows? If yes, then when? Alexander _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From marco.a.piccolino at gmail.com Tue Feb 28 09:29:15 2017 From: marco.a.piccolino at gmail.com (Marco Piccolino) Date: Tue, 28 Feb 2017 09:29:15 +0100 Subject: [Development] Fwd: Qt contributions Message-ID: Hi Zoltan, you might also want to take a look at this project which supports admobs, startad.mobi among others: https://github.com/kafeg/adctl Also, we have a Slack chat dedicated to professional Qt mobile application developers that you can join: http://slackin.qtmob.org If your solution is interesting to some you might find a few hands willing to help out with your wrapper. All best, Marco 2017-02-26 10:34 GMT+01:00 : > Send Development mailing list submissions to > development at qt-project.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.qt-project.org/mailman/listinfo/development > or, via email, send a message with subject or body 'help' to > development-request at qt-project.org > > You can reach the person managing the list at > development-owner at qt-project.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Development digest..." > > Today's Topics: > > 1. Re: Request moving project (noron) to playground area > (Riitta-Leena Miettinen) > 2. Re: Request moving project (noron) to playground area > (Mat Sutcliffe) > 3. Re: [Announce] Qt 5.9.0 Alpha released (Jason H) > 4. Fwd: Qt contributions (Zolt?n Lutor) > > > ---------- Messaggio inoltrato ---------- > From: Riitta-Leena Miettinen > To: "development at qt-project.org" > Cc: > Bcc: > Date: Fri, 24 Feb 2017 14:56:22 +0000 > Subject: Re: [Development] Request moving project (noron) to playground > area > > Date: Fri, 24 Feb 2017 14:30:20 +0000 > > From: "Stottlemyer, Brett (B.S.)" > > To: Qt development mailing list > > Subject: Re: [Development] Request moving project (noron) to > > playground area > > Message-ID: <186AED03-A598-4668-A6D7-1686B796C0FC at ford.com> > > Content-Type: text/plain; charset="utf-8" > > > > > On 2/24/17, 9:29 AM, "Andr? Hartmann" > > wrote: > > > > > > Hi Brett, > > > > > > Have a look at http://doc-snapshots.qt.io/ > > > > Didn?t even know that was there. > > > > I was excited for a moment, but for some reason QtRO isn?t included in > the > > TP section. > > http://doc-snapshots.qt.io/qt5-5.9/qtmodules.html#technology-preview- > > modules > > > > What needs to happen to get QtRO added? Again, the docs are part of the > > module. > > > > Hello Brett, > > You could submit a patch that adds a link to the table that lists all Qt > modules. There are some other tasks involved, too. Here is a link to a > checklist for adding documentation for a new Qt module: > > http://wiki.qt.io/Checklist_for_Adding_Documentation_for_a_New_Module > > Leena > > > Leena Miettinen > Documentation Engineer > > The Qt Company Germany GmbH > Rudower Chaussee 13 > D-12489, Berlin, Germany > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > riitta-leena.miettinen at qt.io > +49 30 63 92 3255 > http://qt.io > > > > > > > > > > > > > > ---------- Messaggio inoltrato ---------- > From: Mat Sutcliffe > To: "development at qt-project.org" > Cc: > Bcc: > Date: Fri, 24 Feb 2017 18:42:32 +0000 > Subject: Re: [Development] Request moving project (noron) to playground > area > Until the link is added, you can visit the direct URL > http://doc-snapshots.qt.io/qt5-5.9/qtremoteobjects-index.html > > > ---------- Messaggio inoltrato ---------- > From: Jason H > To: development at qt-project.org > Cc: > Bcc: > Date: Fri, 24 Feb 2017 20:59:28 +0100 > Subject: Re: [Development] [Announce] Qt 5.9.0 Alpha released > > > Sent: Thursday, February 23, 2017 at 4:55 AM > > From: "List for announcements regarding Qt releases and development" < > announce at qt-project.org> > > To: "announce at qt-project.org" > > Subject: [Development] [Announce] Qt 5.9.0 Alpha released > > > > Hi, > > > > I am happy to inform that Qt 5.9.0 Alpha release is out, see > http://blog.qt.io/blog/2017/02/23/qt-5-9-alpha-released/ > > > > Is there a blocker bug issue in JIRA? Since there are no maintenance > releases planned until 5.9, I have two issues: > https://bugreports.qt.io/browse/QTBUG-56536 - Nougat camera preview is > upside down (P1: Reported 6 months ago) > https://bugreports.qt.io/browse/QTBUG-58278 - QML Websockets only connect > once (P2: Commercial support started Dec 9, 2016, reported Jan 19) > > > > > > ---------- Messaggio inoltrato ---------- > From: "Zoltán Lutor" > To: development at qt-project.org > Cc: > Bcc: > Date: Sun, 26 Feb 2017 10:34:51 +0100 > Subject: [Development] Fwd: Qt contributions > Hi, > > I would like to ask help/guidance how the sw mentioned below could be part > of official Qt package. > > Or, if that is not possible - due to lack of interest or whatever reason > -, some help in form of: > - reviewing current code > - giving suggestions how it can be made better - especially the part > related to displaying received content in HTML (WebView, whatever) > - contributing development of current solution > - etc. > > I'm working on my very first Qt/QML based multi-platform game: > goo.gl/3jKIwZ > > Firs for Android, then Sailfish and maybe iOS (if > I manage to get in touch with developer device) but I've not found any > (free) advertisement SDK/API/solution usable with Qt/QML ATM. That's the > reason behind starting creating my own but I need your help... > > Thx in advance, > > Zoltan > > ps: I'm totally newbie with Qt/QML development, so > suggestions/explanations/advice cannot be too detailed... ;) > > ---------- Forwarded message ---------- > Subject: Qt contributions > To: "zoltan.lutor at gmail.com" > > Dear Zoltan, > > We have a guide for contributors: http://wiki.qt.io/Qt-Contribut > ion-Guidelines. It contains instructions, list of maintainers and contact > details like e-mails and IRC channels for discussions. Please, submit your > request there again. > > [image: The Qt Company logo] > > [image: Facebook] > > [image: Twitter] > > [image: LinkedIn] > > [image: Google+] > > [image: YouTube] > > > > I've progressed with implementing an open source wrapper for Vserv RESTful > advertisement API in QML. > > Quote from API description: > > Vserv provides a simple HTTP based API to publishers/developers and other > ad networks, etc. to fetch ads for mobile sites or mobile applications. The > mobile device / server makes a HTTP request to Vserv Marketplace server > with the required parameters and in response receives the ad in JSON > format. This single API integration gives you the flexibility to fetch > banner/ full screen / rich media ads. > > Available implementation is in pre-beta phase - quite majority of > functionality works but there is still room for improvement. > > Since I'm not so experienced Qt/QML development - I would like to offer it > to you and asking for help finishing it and releasing it to the community... > > API description: https://docs.google.com/docume > nt/d/139TRSTV33tLxKxbew4yPTPF4uc8PZJPiRkxyo9GymIE/edit > > Source: https://bitbucket.org/zlutor/qml-wrapper-for-vserv-http-ad-api > > Thx, > > Zoltan > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image016.png Type: image/png Size: 963 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image017.png Type: image/png Size: 1256 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image014.png Type: image/png Size: 891 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image015.png Type: image/png Size: 1095 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image013.png Type: image/png Size: 9485 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image018.png Type: image/png Size: 954 bytes Desc: not available URL: From elderorb at gmail.com Tue Feb 28 10:07:12 2017 From: elderorb at gmail.com (Alexander Ivash) Date: Tue, 28 Feb 2017 12:07:12 +0300 Subject: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ? In-Reply-To: References: Message-ID: >> but we are unsure if we'll be able to ship the mapboxgl plugin for windows with 5.9 Thank you for reply Paolo, will keep fingers crossed then. But what desktop platform (if any) is most stable right now for mapboxgl? Regards, Alexander 2017-02-27 23:11 GMT+03:00 Paolo Angelelli : > Hi Alexander, > > we are trying, but we are unsure if we'll be able to ship the mapboxgl plugin for windows with 5.9. > In any case, i believe that, if not, mapbox might make it available outside the qt sdk as an additional plugin. > > regards > ________________________________________ > From: Development [development-bounces+paolo.angelelli=qt.io at qt-project.org] on behalf of Alexander Ivash [elderorb at gmail.com] > Sent: Monday, February 27, 2017 6:44 PM > To: development at qt-project.org > Subject: [Development] Qt 5.9 alpha & mapbox-gl-native on windows ? > > Is it planned to enable mapbox-gl-native building for windows? If yes, > then when? > > Alexander > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue Feb 28 11:09:13 2017 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 28 Feb 2017 10:09:13 +0000 Subject: [Development] Qt 5.9 API review Message-ID: Hi all, It seems Qt 5.9 API review is still badly ongoing, see https://codereview.qt-project.org/184384 qtbase https://codereview.qt-project.org/184385 qtsvg https://codereview.qt-project.org/184386 qtdeclarative https://codereview.qt-project.org/184387 qtactiveqt https://codereview.qt-project.org/184388 qtlocation https://codereview.qt-project.org/184389 qtsensors https://codereview.qt-project.org/184390 qtconnectivity https://codereview.qt-project.org/184391 qtwayland https://codereview.qt-project.org/184392 qt3d https://codereview.qt-project.org/184393 qtserialbus https://codereview.qt-project.org/184394 qtwebsockets https://codereview.qt-project.org/184395 qtwebengine https://codereview.qt-project.org/184396 qtquickcontrols2 https://codereview.qt-project.org/184397 qtcharts https://codereview.qt-project.org/184398 qtdatavis3d https://codereview.qt-project.org/184399 qtgamepad https://codereview.qt-project.org/184400 qtscxml Please finalize the reviews & do needed fixes as soon as possible so that we will be ready for beta early enough. br, Jani Heikkinen Release Manager From sean.harmer at kdab.com Tue Feb 28 11:18:33 2017 From: sean.harmer at kdab.com (Sean Harmer) Date: Tue, 28 Feb 2017 10:18:33 +0000 Subject: [Development] Qt 5.9 API review In-Reply-To: References: Message-ID: <2711831.JTBQYdeEnl@titan> On Tuesday 28 February 2017 10:09:13 Jani Heikkinen wrote: > Hi all, > > It seems Qt 5.9 API review is still badly ongoing, see > https://codereview.qt-project.org/184392 qt3d We went through this last week and resulted in: https://bugreports.qt.io/secure/RapidBoard.jspa?rapidView=48 We're now working through those as best we can. We may need another pass on the animation stuff but that's a tech preview for 5.9 so not absolutely critical. Cheers, Sean > Please finalize the reviews & do needed fixes as soon as possible so that we > will be ready for beta early enough. > > br, > Jani Heikkinen > Release Manager > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions From edward.welbourne at qt.io Tue Feb 28 16:16:30 2017 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 28 Feb 2017 15:16:30 +0000 Subject: [Development] Qt 5.9 API review In-Reply-To: References: Message-ID: Jani Heikkinen (28 February 2017 11:09): > It seems Qt 5.9 API review is still badly ongoing, see [snip] FTR, we have some on-going fixes in progress in qtbase. > Please finalize the reviews & do needed fixes as soon as possible so that we will be ready for beta early enough. If your module has had updates to fix any API issues found by the review so far, please do let me know (no need to Cc the list) and I'll update its API review, Eddy. From marc.mutz at kdab.com Tue Feb 28 19:38:10 2017 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 28 Feb 2017 19:38:10 +0100 Subject: [Development] CI: module "NIL" (NIL) Message-ID: <201702281938.10870.marc.mutz@kdab.com> Hi, Something's wonky with the CI: e.g. https://codereview.qt-project.org/186905 (http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1488304949) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt, C++ and OpenGL Experts