From iamsergio at gmail.com Sat Oct 1 02:28:18 2016 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Sat, 1 Oct 2016 01:28:18 +0100 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> References: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> Message-ID: On Fri, Sep 30, 2016 at 4:43 PM, Shawn Rutledge wrote: > On 30 Sep 2016, at 14:19, Kai Koehne wrote: >> To make a proposal: Let’s use semicolons in imperative JS parts of QML in our examples and documentation > > Back in Nokia times it was said that we shouldn't use semicolons, because it would speed up the parsing and reduce the size of resources slightly. (Maybe you think performance isn’t impacted by small things like that, but we are at the same time investing effort into other “optimizations” for which I suspect the runtime performance impact may end up being similarly small.) So I’ve been following the no-semicolons convention ever since, except occasionally when C++ habits get the better of me. If you're in a position where semicolons would matter for performance then maybe you shouldn't be using JavaScript on such device. Regards, Sérgio Martins From olivier at woboq.com Sat Oct 1 08:33:36 2016 From: olivier at woboq.com (Olivier Goffart) Date: Sat, 01 Oct 2016 08:33:36 +0200 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> References: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> Message-ID: <4371909.CSJsEUb8ys@maurice> On Freitag, 30. September 2016 15:43:57 CEST Shawn Rutledge wrote: > Back in Nokia times it was said that we shouldn't use semicolons, because it > would speed up the parsing and reduce the size of resources slightly. [...] Back in Nokia times, someone was reviewing a patch and made a comment that a binding looking like this: someProperty: { if (someOtherProperty === 42) return something.foobar; else return somethingElse; } Should be rewritten like this: someProperty: someOtherProperty === 42 ? something.foobar : somethingElse; A week later, one of the bullet point in the log of the team was something like: - replace all ifs with '?' syntax. They indeed spend some time replacing every single 'if' of their JavaScript code (no matter how complex) in their QML application by the ternary operator. They tought it was more efficient because it was suggested to replace one occurrence in a review. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Sat Oct 1 10:24:59 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 1 Oct 2016 10:24:59 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <201609080912.32155.marc.mutz@kdab.com> References: <57CFB58D.2060200@qt.io> <201609080912.32155.marc.mutz@kdab.com> Message-ID: <201610011025.00081.marc.mutz@kdab.com> On Thursday 08 September 2016 09:12:32 Marc Mutz wrote: > On Wednesday 07 September 2016 08:37:01 Friedemann Kleint wrote: > > ** After 5.7 is closed and sanity bot is upgraded (to handle > > cherry-picking), go into cherrypicking mode for 5.6. Developer is > > responsible for doing the cherrypicking > > ** Cherry-picking technicalities need to be figured out: Let sanity bot > > verify source ("cherrypicked from") the SHA1 > > I'm sorry, but this is nonsense. The source control system works by > committing on the older branches and merging up. Cherry-picking from > younger branches works against the source control system. We put up with > cherry-picking for 4.8, because there we dealt with separate repositories, > but that doesn't make is a good model. I just came to realise another reason against cherry-picking: Qt 5.6 is C++98-only while 5.7+ is C++11. That means patches that will be developed against 5.7+ will very likely have C++11 constructs in them that won't work in Qt 5.6. That means that in order to backport, the code needs to be de-C++11-ified, which in turn means the usual reasoning for cherry-picking as a stability feature (it's been integrated already once successfully) falls flat on its face, because the code submitted against 5.7+ must needs be changed (forgive my Victorian) in the process of cherry-picking to 5.6, invalidating any test coverage it may have had as part of the younger branch. To avoid the guaranteed merge conflicts from cherry-picked-and-changed, commits, you'd need to ban any non-cherry-pick changes to 5.6, which effectively means that no developer does any work on 5.6 anymore. Everyone will rely on the CI, and the CI only. OTOH, with very few exceptions such a Q_FOREACH, code that successfully integrated into 5.6 will successfully integrate in 5.7+. In light of this I continue to vote for keeping the "no-cherry-picks allowed" policy that has served us well over the Qt 5 years. If merging is a bottleneck, I think we as contributors just need to unlearn that 5.6 changes magically show up in dev a few days later. Before Liang became the designated merge-monkey (that's not derogative, that's the technical term! :), we had to wait up to a month for a change to percolate up, and that was with fewer active branches in-flight. We survived, and Qt wasn't 1/6th merges (uneducated guesstimate based on equating Liang with merges and applying that to http://www.macieira.org/~thiago/qt-stats/current/qt- all.author.absolute.png (2016W38)). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - Qt, C++ and OpenGL Experts From assangema at gmail.com Sun Oct 2 03:18:56 2016 From: assangema at gmail.com (=?UTF-8?B?5b+D57+U?=) Date: Sun, 2 Oct 2016 09:18:56 +0800 Subject: [Development] scaling the background of QGraphicsView or QGraphicsScene Message-ID: Hi， I subclass the QGraphicsView to reimplement drawBackground and wheelEvent and want to get this effect： but when I wheel the mouse， the background point will scale also。 ​ how can implement that it only scale t*he spacing between points but not the point itself，like this:* *​* *the code:* > void SchView::wheelEvent(QWheelEvent *event) > > { > > qreal scaleFactor = (pow((double)2, event->delta() / 240.0)); > > qreal factor = transform().scale(scaleFactor, scaleFactor).mapRect(QRectF(0, 0, 1, 1)).width(); > > > if (factor < 0.07 || factor > 100) > > return; > > > scale(scaleFactor, scaleFactor); > > } > > void SchView::drawBackground(QPainter *painter, const QRectF &rect) > > { > > int gridSize = 20; > > QPen pen(QColor(Qt::white)); > > painter->setPen(pen); > > > qreal left = int(rect.left()) - (int(rect.left()) % gridSize); > > qreal top = int(rect.top()) - (int(rect.top()) % gridSize); > > > QVarLengthArray points; > > for (qreal x = left; x < rect.right(); x += gridSize){ > > for (qreal y = top; y < rect.bottom(); y += gridSize){ > > points.append(QPointF(x,y)); > > } > > } > > painter->drawPoints(points.data(), points.size()); > > } > > > *Any suggestions are greatly appreciated.* *thanks* ------------------------------ itviewer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 356 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 470 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 318 bytes Desc: not available URL: From sean.harmer at kdab.com Sun Oct 2 11:10:42 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Sun, 2 Oct 2016 10:10:42 +0100 Subject: [Development] scaling the background of QGraphicsView or QGraphicsScene In-Reply-To: References: Message-ID: Hi, use a cosmetic pen (width of zero). Cheers, Sean On 02/10/2016 02:18, 心翔 wrote: > Hi， > I subclass the QGraphicsView to > reimplement drawBackground and wheelEvent and want to get this effect： > > > but when I wheel the mouse， the background point will scale also。 > > ​ > how can implement that it only scale t/he spacing between points but not > the point itself，like this:/ > / > / > / > ​ > / > / > / > /the code:/ > > voidSchView::wheelEvent(QWheelEvent*event) > > { > > qrealscaleFactor=(pow((double)2,event->delta()/240.0)); > > qrealfactor=transform().scale(scaleFactor,scaleFactor).mapRect(QRectF(0,0,1,1)).width(); > > > if(factor<0.07||factor>100) > > return; > > > scale(scaleFactor,scaleFactor); > > } > > > voidSchView::drawBackground(QPainter*painter,constQRectF&rect) > > { > > intgridSize=20; > > QPenpen(QColor(Qt::white)); > > painter->setPen(pen); > > > qrealleft=int(rect.left())-(int(rect.left())%gridSize); > > qrealtop=int(rect.top())-(int(rect.top())%gridSize); > > > QVarLengthArraypoints; > > for(qrealx=left;x > for(qrealy=top;y > points.append(QPointF(x,y)); > > } > > } > > painter->drawPoints(points.data(),points.size()); > > } > > > > > / > / > /Any suggestions are greatly appreciated./ > /thanks/ > / > / > / > / > / > / > ------------------------------------------------------------------------ > itviewer > / > / > > > _______________________________________________ > 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 mitch.curtis at qt.io Sun Oct 2 13:58:12 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Sun, 2 Oct 2016 11:58:12 +0000 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: References: , <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> Message-ID: I don't understand why people get so upset about topics like this. If it's not important to you and not worth your time, don't reply. It's kinda ironic that you're "wasting" time on it at all. The people who do care about having some consistency to improve the quality of Qt should be able to discuss it without being accused of not having anything better to do. Personally, I'm for using semicolons everywhere (docs, examples, module code, auto tests), in a similar fashion as many others have already replied (within blocks of code, where there's more than one statement). There are other conventions in Qt that I don't like, but I've gotten so used to following them that it's started to creep into my personal projects. :x From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Kai Koehne Sent: Friday, 30 September 2016 11:00 PM To: Shawn Rutledge ; development at qt-project.org Subject: Re: [Development] Using semicolons in JS (QML) >> To make a proposal: Let's use semicolons in imperative JS parts of QML in our examples and documentation > > Back in Nokia times it was said that we shouldn't use semicolons, because it would speed up the parsing and reduce the size of resources slightly. (Maybe you think performance isn't impacted by small > things like that, but we are at the same time investing effort into other "optimizations" for which I suspect the runtime performance impact may end up being similarly small.) So I've been following the > no-semicolons convention ever since, except occasionally when C++ habits get the better of me. Interesting. Indeed, I wouldn't have thought it makes any measurable difference. IIRC we had a qml mimizer once, I guess this is still around? > If you think it's important, then write a reformatter tool and figure out how to use it as a git hook. We are wasting time bikeshedding about coding style (do you really have nothing better to do? > all bugs in Qt are fixed?), and IMO the same argument applies in any kind of code: if there's no tool to do the reformatting, maybe it's not so important. It's certainly not that important to me that I will spend a day on writing a git hook that then nobody will use ;) But a lot of programmers (including me) tend to care about code style consistency. So I was making a suggestion that costs us nothing, but leads to a sllightly more consistent documentation and examples in then end. In the same way as I couldn't care less whether to use tabs or spaces, or what the right indentation level is, as long as we stick to one. (And yeah, I also enjoy bikeshedding sometimes, be it at the coffee machine or on a mailing list, even if not 'all Qt in bugs are fixed". And honestly speaking I do not see an issue with this.) > It's just subjective and political, and not the kind of argument I'd ever want to start, personally. Well, it's an entirely voluntary discussion ;) Kai ________________________________ From: Development > on behalf of Shawn Rutledge > Sent: Friday, September 30, 2016 5:43:57 PM To: development at qt-project.org Subject: Re: [Development] Using semicolons in JS (QML) On 30 Sep 2016, at 14:19, Kai Koehne > wrote: > To make a proposal: Let's use semicolons in imperative JS parts of QML in our examples and documentation Back in Nokia times it was said that we shouldn't use semicolons, because it would speed up the parsing and reduce the size of resources slightly. (Maybe you think performance isn't impacted by small things like that, but we are at the same time investing effort into other "optimizations" for which I suspect the runtime performance impact may end up being similarly small.) So I've been following the no-semicolons convention ever since, except occasionally when C++ habits get the better of me. If you think it's important, then write a reformatter tool and figure out how to use it as a git hook. We are wasting time bikeshedding about coding style (do you really have nothing better to do? all bugs in Qt are fixed?), and IMO the same argument applies in any kind of code: if there's no tool to do the reformatting, maybe it's not so important. It's just subjective and political, and not the kind of argument I'd ever want to start, personally. _______________________________________________ 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 thomas.bettler at gmail.com Sun Oct 2 14:42:39 2016 From: thomas.bettler at gmail.com (Thomas Bettler) Date: Sun, 2 Oct 2016 14:42:39 +0200 Subject: [Development] Review needed Message-ID: Hello I'd like to contribute a patch to qt development to make RC4 encryption optional. Currently if qtnetwork is compiled with openssl, openssl must contain RC4 - or qtnetwork fails to compile... RC4 is known to be a weak stream cipher, wich is abandoned and eventually faded out, so depending optional on it would be a good step for now. I'm looking for someone to review my patch at gerrit: https://codereview.qt-project.org/#/c/171968/3 Many thanks for any feedback. Best regards Thomas -------------- next part -------------- An HTML attachment was scrubbed... URL: From assangema at gmail.com Sun Oct 2 15:25:01 2016 From: assangema at gmail.com (itviewer) Date: Sun, 2 Oct 2016 21:25:01 +0800 Subject: [Development] scaling the background of QGraphicsView or QGraphicsScene References: , Message-ID: <201610022124430660124@gmail.com> Hi Sean, Thank you very much, you helped me solve the problem that let me think for several days. you are a good man! itviewer From: Sean Harmer Date: 2016-10-02 17:10 To: development Subject: Re: [Development] scaling the background of QGraphicsView or QGraphicsScene Hi, use a cosmetic pen (width of zero). Cheers, Sean On 02/10/2016 02:18, 心翔 wrote: > Hi， > I subclass the QGraphicsView to > reimplement drawBackground and wheelEvent and want to get this effect： > > > but when I wheel the mouse， the background point will scale also。 > > ​ > how can implement that it only scale t/he spacing between points but not > the point itself，like this:/ > / > / > / > ​ > / > / > / > /the code:/ > > voidSchView::wheelEvent(QWheelEvent*event) > > { > > qrealscaleFactor=(pow((double)2,event->delta()/240.0)); > > qrealfactor=transform().scale(scaleFactor,scaleFactor).mapRect(QRectF(0,0,1,1)).width(); > > > if(factor<0.07||factor>100) > > return; > > > scale(scaleFactor,scaleFactor); > > } > > > voidSchView::drawBackground(QPainter*painter,constQRectF&rect) > > { > > intgridSize=20; > > QPenpen(QColor(Qt::white)); > > painter->setPen(pen); > > > qrealleft=int(rect.left())-(int(rect.left())%gridSize); > > qrealtop=int(rect.top())-(int(rect.top())%gridSize); > > > QVarLengthArraypoints; > > for(qrealx=left;x > for(qrealy=top;y > points.append(QPointF(x,y)); > > } > > } > > painter->drawPoints(points.data(),points.size()); > > } > > > > > / > / > /Any suggestions are greatly appreciated./ > /thanks/ > / > / > / > / > / > / > ------------------------------------------------------------------------ > itviewer > / > / > > > _______________________________________________ > 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 _______________________________________________ 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: 0.gif Type: image/gif Size: 1810 bytes Desc: not available URL: From mitch.curtis at qt.io Sun Oct 2 20:04:29 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Sun, 2 Oct 2016 18:04:29 +0000 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: <1475272622.4135955.742357129.25BF2F40@webmail.messagingengine.com> References: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> <1475272622.4135955.742357129.25BF2F40@webmail.messagingengine.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Robin Burchell > Sent: Friday, 30 September 2016 11:57 PM > To: development at qt-project.org > Subject: Re: [Development] Using semicolons in JS (QML) > > On Fri, Sep 30, 2016, at 11:00 PM, Kai Koehne wrote: > > Interesting. Indeed, I wouldn't have thought it makes any measurable > > difference. IIRC we had a qml mimizer once, I guess this is still around? > > tools/qmlmin in qtdeclarative > > > It's certainly not that important to me that I will spend a day on > > writing a git hook that then nobody will use ;) But a lot of > > programmers (including me) tend to care about code style consistency. > > So I was making a suggestion that costs us nothing, but leads to a > > sllightly more consistent documentation and examples in then end. In > > the same way as I couldn't care less whether to use tabs or spaces, or > > what the right indentation level is, as long as we stick to one. > > > > (And yeah, I also enjoy bikeshedding sometimes, be it at the coffee > > machine or on a mailing list, even if not 'all Qt in bugs are fixed". > > And honestly speaking I do not see an issue with this.) > > The problem is that these kinds of discussions do actually have a cost. > They take time and energy to read and digest, and time to reply to (yes, it's > voluntary, but occasionally something useful comes out of it, although usually > not in any way related to the original topic - I'd count the above mention of > qmlmin in this category for instance). > > The whole principle of bikeshedding as I'd understand it is that it's easy (and > subjectively - somewhat fun) to do, but on the other hand doesn't really get > all that much useful accomplished. And it may not be toxic every once in a > while, but when you do it often enough, the noise starts to drown out the > signal, and you can end up killing off a medium for any sort of reasonable > conversations. It's a fine line to walk. > > As an idea of cost: aside from reading this thread, I spent something like 20 > minutes mulling over this topic (and reading around on the internet for > resources and opinions) while writing this reply for instance, time that I didn't > even really realise I had spent until I was about to click "send" on this mail. > Multiply that by every participant, and by every "low signal" thread, and you > end up with potentially gargantuan amounts of time being spent on more or > less irrelevant details, even if it is fun to do. > > ... > > To the topic at hand, I personally tend to omit semicolons unless they are > clearly needed either to reduce ambiguity or for reasons of e.g. > multiple statements on a single line (already something I prefer to outright > avoid, however). I choose this for aesthetics, much like the "omit braces on > single line if" rule (which is also, coincidentally, somewhat controversial and > ignored from time to time) > > In the wider community (both QML and JS in general), this isn't a unified topic > I'd say. You can find numerous advice going both ways, and I think it's fairly > safe to say that there will always be dissenting voices everywhere, no matter > what you choose. > > So for yourself, my advice would be: pick one that you like and stick with it. I know that you said "for yourself", but since you are essentially taking the same stance with Qt code, wouldn't it be better to consider the points put forth so far and make a decision, so that it's one less opportunity for inconsistency? Then you can justify the 20 minutes you chose to spend researching the subject (although, if you had to research it, you probably learned something new anyway, so I wouldn't say it was wasted time). :D > For Qt, while I would like to see one or the other picked and followed for > consistency's sake, I'm not sure it would be a useful investment of your time > to try to enforce a particular semicolon-style without tooling enforcement, as > it seems like yet another Sisyphean task that will - at best - burn a lot of your > time and energy and end up back in exactly the same situation, all for an > effort which in practice has little real-world gain. QML auto tests are an example of where this would actually have a real-word gain. Some files use them, some don't, and if you're used to always using them, but prefer to follow what has already been done in a particular file for consistency, it means having to make a conscious effort to not type them (and sometimes remove the ones you typed out of habit). If we could agree on using semicolons everywhere, it would become habit, and I wouldn't waste that small amount of mental energy on it. qtdeclarative.git has a fair few QML auto tests, along with qtquickcontrols.git/qtquickcontrols2.git. It does add up. > I think that is why Shawn replied the way he did. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From sean.harmer at kdab.com Mon Oct 3 09:38:39 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 3 Oct 2016 08:38:39 +0100 Subject: [Development] Retargeting requests Message-ID: <529e380e-7393-50fd-efc7-ad997592aa85@kdab.com> Hi Ossi (or anybody else with rights), could you retarget the following commits to the 5.7.1 branch please? https://codereview.qt-project.org/#/c/169378/ https://codereview.qt-project.org/#/c/169386/ https://codereview.qt-project.org/#/c/169392/ https://codereview.qt-project.org/#/c/172623/ https://codereview.qt-project.org/#/c/172624/ https://codereview.qt-project.org/#/c/172625/ Thanks in advance! 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 private at bernhard-lindner.de Mon Oct 3 09:43:49 2016 From: private at bernhard-lindner.de (Bernhard Lindner) Date: Mon, 03 Oct 2016 09:43:49 +0200 Subject: [Development] QDataStream: blackbox or document all versions? In-Reply-To: References: <4148392.zjhzp35ijF@tjmaciei-mobl1> Message-ID: <5223659.HY60YTB0F1@gandalf> > You could choose to turn QDataStream into a black-box, but I think there > should be a white-box alternative which has to be > 1/ as efficient : binary format > 2/ as easy to use : QDataStream is able to serialize any type with the help > of qRegisterMetaTypeStreamOperators > 3/ as generic : it should be able to use any QIODevice for transport/storage +1 > 1/ discards XML and JSON, and 3/ discards QSettings and D-Bus. Thanks for pointing this out! P.S.: https://bugreports.qt.io/browse/QTBUG-25237 -- Regards, Bernhard -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From Shawn.Rutledge at qt.io Mon Oct 3 10:14:11 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 3 Oct 2016 08:14:11 +0000 Subject: [Development] Managing branches of Qt's git modules In-Reply-To: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> References: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> Message-ID: > On 30 Sep 2016, at 12:39, Sean Harmer wrote: > > So, what do people do to checkout all interesting modules to 5.7, 5.8, dev etc on Unix like systems and on Windows? Sometimes I use qtrepotools/bin/qt5_tool -p —Branch 5.8 (or whatever branch) From Shawn.Rutledge at qt.io Mon Oct 3 10:47:36 2016 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 3 Oct 2016 08:47:36 +0000 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: <1475272622.4135955.742357129.25BF2F40@webmail.messagingengine.com> References: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> <1475272622.4135955.742357129.25BF2F40@webmail.messagingengine.com> Message-ID: > On 30 Sep 2016, at 23:57, Robin Burchell wrote: > > For Qt, while I would like to see one or the other picked and followed > for consistency's sake, I'm not sure it would be a useful investment of > your time to try to enforce a particular semicolon-style without tooling > enforcement, as it seems like yet another Sisyphean task that will - at > best - burn a lot of your time and energy and end up back in exactly the > same situation, all for an effort which in practice has little > real-world gain. I think that is why Shawn replied the way he did. Yes that was my point, but stated better. Sorry for over-reacting. The performance impact is of course hardly worth discussion except as an explanation of where the no-semicolons habit came from (at least for people like me who wrote QML during that time). From sean.harmer at kdab.com Mon Oct 3 12:23:37 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 03 Oct 2016 11:23:37 +0100 Subject: [Development] Qt 3D WIP branches In-Reply-To: References: Message-ID: <2011606.sGnUVMMPEo@cartman> Many thanks to whoever created the branches. Cheers, Sean On Friday 30 September 2016 11:46:39 Sean Harmer wrote: > Hi, > > Without knowing the internals of COIN, is it a problem for CI load if we > request some WIP branches for upcoming major Qt 3D features? The > branches we would like are for features that will take many commits to > mature and involve many people so local branches are not enough and we > don't know if they will mature in time for 5.9 so dev is not ideal > either as then we may have to strip a ton of stuff out. > > The branches we would like created are: > > * wip-animation - for key frame animation support > * wip-quickintegration - for providing support to render and interact > with Qt Quick 2 elements in a 3D scene > * wip-particles - for a new particle system in Qt 3D > > There will be others needed later but these are the pressing ones. > > if this is OK, then is this email sufficient to get it rolling or do I > need to file a JIRA too? > > Thanks in advance, > > 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 scott at towel42.com Mon Oct 3 21:15:48 2016 From: scott at towel42.com (Scott Aron Bloom) Date: Mon, 3 Oct 2016 19:15:48 +0000 Subject: [Development] Question about keyboard mapping Message-ID: I have had a bunch of customers report that using our tool over Xceed, ASTEX-X, and now XManager, are having problems with the keyboard mapping. Was there something fixed post Qt 5.5.1 for this type of issue? I am stuck on 5.5.1 for the near future, and will have to back patch it. Scott -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Mon Oct 3 22:42:23 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 3 Oct 2016 22:42:23 +0200 Subject: [Development] Multiple Qt branches on Coverity Scan Message-ID: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> Howdy, I've just contacted Coverity Scan asking how to configure it for supporting multiple branches. The easiest solution seems to be getting N projects, one per branch; other projects are doing the same, for instance https://scan.coverity.com/projects?utf8=%E2%9C%93&search=postgresql https://scan.coverity.com/projects?utf8=%E2%9C%93&search=openssl I'd say we should at least get 5.6 and dev covered (we can then bikeshed on the naming -- "stable" and "dev"?). What do you think? 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 thiago.macieira at intel.com Mon Oct 3 23:09:39 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 03 Oct 2016 23:09:39 +0200 Subject: [Development] Multiple Qt branches on Coverity Scan In-Reply-To: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> References: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> Message-ID: <3265007.irYWg5TUYC@tjmaciei-mobl1> On segunda-feira, 3 de outubro de 2016 22:42:23 CEST Giuseppe D'Angelo wrote: > I'd say we should at least get 5.6 and dev covered (we can then bikeshed > on the naming -- "stable" and "dev"?). What do you think? Please do. That's a good idea, even if we don't have a lot of people looking at those results, any help is good. I think the names should be "5.6" or "lts", the other one stays named as it is. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Oct 3 23:28:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 03 Oct 2016 23:28:50 +0200 Subject: [Development] Multiple Qt branches on Coverity Scan In-Reply-To: <3265007.irYWg5TUYC@tjmaciei-mobl1> References: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> <3265007.irYWg5TUYC@tjmaciei-mobl1> Message-ID: <19429814.F5arqcLjF3@tjmaciei-mobl1> On segunda-feira, 3 de outubro de 2016 23:09:39 CEST Thiago Macieira wrote: > I think the names should be "5.6" or "lts", the other one stays named as it > is. Maybe "lts" is better because we can then reuse the project for the next LTS, whenever that happens. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From samuel.gaist at edeltech.ch Mon Oct 3 23:29:54 2016 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Mon, 3 Oct 2016 23:29:54 +0200 Subject: [Development] Multiple Qt branches on Coverity Scan In-Reply-To: <3265007.irYWg5TUYC@tjmaciei-mobl1> References: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> <3265007.irYWg5TUYC@tjmaciei-mobl1> Message-ID: <8C58FCC3-168C-496D-8029-04568BDEA107@edeltech.ch> > On 3 oct. 2016, at 23:09, Thiago Macieira wrote: > > On segunda-feira, 3 de outubro de 2016 22:42:23 CEST Giuseppe D'Angelo wrote: >> I'd say we should at least get 5.6 and dev covered (we can then bikeshed >> on the naming -- "stable" and "dev"?). What do you think? > > Please do. That's a good idea, even if we don't have a lot of people looking > at those results, any help is good. > > I think the names should be "5.6" or "lts", the other one stays named as it > is. > > -- > 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 Hi, I’d go for LTS, this way it’s clearer why it’s covered and doesn’t need to be changed in the future. Samuel -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: Message signed with OpenPGP using GPGMail URL: From giuseppe.dangelo at kdab.com Mon Oct 3 23:46:13 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 3 Oct 2016 23:46:13 +0200 Subject: [Development] Multiple Qt branches on Coverity Scan In-Reply-To: <19429814.F5arqcLjF3@tjmaciei-mobl1> References: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> <3265007.irYWg5TUYC@tjmaciei-mobl1> <19429814.F5arqcLjF3@tjmaciei-mobl1> Message-ID: <7e837239-7161-c168-e8e6-ff6948ac4126@kdab.com> Il 03/10/2016 23:28, Thiago Macieira ha scritto: > Maybe "lts" is better because we can then reuse the project for the next LTS, > whenever that happens. Given the number of branches that other projects have, I don't think it's going to be a problem in the future to create or destroy new branches. I'm going with "lts" and "dev" anyhow, thanks! 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 assangema at gmail.com Mon Oct 3 23:51:14 2016 From: assangema at gmail.com (itviewer) Date: Tue, 4 Oct 2016 05:51:14 +0800 Subject: [Development] How can I only select border not inside rectangle to select QGraphicsRectItem Message-ID: <2016100405511134713916@gmail.com> Hi, I draw a rectangle with QGraphicsRectItem. it only has a border and not be filled. like this: when I click inside the rectangle,it will be selected，but I would like only click on the border to select, not inside. how can i get it? Thanks. itviewer -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 1.png Type: image/png Size: 515 bytes Desc: not available URL: From chgans at gna.org Mon Oct 3 23:57:02 2016 From: chgans at gna.org (Ch'Gans) Date: Tue, 4 Oct 2016 10:57:02 +1300 Subject: [Development] How can I only select border not inside rectangle to select QGraphicsRectItem In-Reply-To: <2016100405511134713916@gmail.com> References: <2016100405511134713916@gmail.com> Message-ID: On 4 October 2016 at 10:51, itviewer wrote: > Hi, > I draw a rectangle with QGraphicsRectItem. it only has a border and not > be filled. like this: > > when I click inside the rectangle,it will be selected，but I would like > only click on the border to select, not inside. > how can i get it? > Reimplement shape(), and use QPainterPathStroker ? Chris > Thanks. > > > ------------------------------ > itviewer > > _______________________________________________ > 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: 1.png Type: image/png Size: 515 bytes Desc: not available URL: From clinton at elemtech.com Tue Oct 4 01:36:55 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 3 Oct 2016 17:36:55 -0600 (MDT) Subject: [Development] stalled gerrit submission for xcb fix Message-ID: <1889893984.28006270.1475537815175.JavaMail.zimbra@elemtech.com> Hi, This is my first time with a gerrit submission https://codereview.qt-project.org/#/c/169701/ to fix https://bugreports.qt.io/browse/QTBUG-39362 And I'm wondering why there hasn't been a review for this patch. I've tried adding relevant reviewers. In the archive, I see the gerrit server has had email problems, and maybe that is related. Anyway, I thought I'd ask here. Thanks, Clint -------------- next part -------------- An HTML attachment was scrubbed... URL: From nassian at bitshift-dynamics.de Tue Oct 4 05:57:40 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Tue, 4 Oct 2016 05:57:40 +0200 Subject: [Development] How can I only select border not inside rectangle to select QGraphicsRectItem In-Reply-To: <2016100405511134713916@gmail.com> References: <2016100405511134713916@gmail.com> Message-ID: <2F95A266-2779-4BC3-9907-0A10A58BD3BC@bitshift-dynamics.de> Hi, Please note that development at qt-project.org is the mailing list for developers _of_ Qt. Developers who _use_ Qt should use interest at qt-project.org. Beste Grüße / Best regards, Alexander Nassian, bitshift dynamics GmbH > Am 03.10.2016 um 23:51 schrieb itviewer : > > Hi, > I draw a rectangle with QGraphicsRectItem. it only has a border and not be filled. like this: > <1.png> > > when I click inside the rectangle,it will be selected，but I would like only click on the border to select, not inside. > how can i get it? > > Thanks. > > > itviewer > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Oct 4 07:58:21 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 04 Oct 2016 07:58:21 +0200 Subject: [Development] stalled gerrit submission for xcb fix In-Reply-To: <1889893984.28006270.1475537815175.JavaMail.zimbra@elemtech.com> References: <1889893984.28006270.1475537815175.JavaMail.zimbra@elemtech.com> Message-ID: <1601235.8ozIXDxWqC@tjmaciei-mobl1> Em segunda-feira, 3 de outubro de 2016, às 17:36:55 CEST, clinton at elemtech.com escreveu: > Hi, > > This is my first time with a gerrit submission > https://codereview.qt-project.org/#/c/169701/ > to fix > https://bugreports.qt.io/browse/QTBUG-39362 > > And I'm wondering why there hasn't been a review for this patch. I've tried > adding relevant reviewers. If you don't get a review after a week, you send a "ping" (which you have, by uploading new changes). If a week after that it hasn't happened, make sure you've added the maintainer for the relevant module and send a ping again. If that doesn't help, post to the mailing list here (which you now have). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Eike.Ziller at qt.io Tue Oct 4 10:13:21 2016 From: Eike.Ziller at qt.io (Eike Ziller) Date: Tue, 4 Oct 2016 08:13:21 +0000 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: <4371909.CSJsEUb8ys@maurice> References: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> <4371909.CSJsEUb8ys@maurice> Message-ID: <186E3F0D-2D21-418E-B717-A591228745C2@qt.io> > On Oct 1, 2016, at 8:33 AM, Olivier Goffart wrote: > > On Freitag, 30. September 2016 15:43:57 CEST Shawn Rutledge wrote: >> Back in Nokia times it was said that we shouldn't use semicolons, because it >> would speed up the parsing and reduce the size of resources slightly. [...] > > Back in Nokia times, someone was reviewing a patch and made a comment that a > binding looking like this: > > someProperty: { > if (someOtherProperty === 42) > return something.foobar; > else > return somethingElse; > } > > Should be rewritten like this: > > someProperty: someOtherProperty === 42 ? something.foobar : somethingElse; > > A week later, one of the bullet point in the log of the team was something > like: > - replace all ifs with '?' syntax. > > They indeed spend some time replacing every single 'if' of their JavaScript > code (no matter how complex) in their QML application by the ternary operator. > They tought it was more efficient because it was suggested to replace one > occurrence in a review. There was this call for using “simple” expressions, since these were handled by V4 instead of the full-blown JS engine, and not originating just from some review comment. https://blog.qt.io/blog/2013/04/15/evolution-of-the-qml-engine-part-1/ Were they right? (Aside from that I’d say that ?: fits the declarative style much better, so there would also be other reasons to prefer that over an if-expression.) > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Simon.Hausmann at qt.io Tue Oct 4 10:33:50 2016 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Tue, 4 Oct 2016 08:33:50 +0000 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: <186E3F0D-2D21-418E-B717-A591228745C2@qt.io> References: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> <4371909.CSJsEUb8ys@maurice>, <186E3F0D-2D21-418E-B717-A591228745C2@qt.io> Message-ID: Hi, When QML used V8 as JavaScript engine and its own expression interpreter called V4 for "simple" expressions, some of these "simplifications" were needed to ensure the bindings could be understood by the simpler evaluator instead of going for a full fledged V8 binding. These assumptions are not correct anymore. An if statement generates the same intermediate representation in the code generator as a conditional expression, and there is only one code generator. Simon ________________________________ From: Development on behalf of Eike Ziller Sent: Tuesday, October 4, 2016 10:13:21 AM To: Olivier Goffart Cc: development at qt-project.org Subject: Re: [Development] Using semicolons in JS (QML) > On Oct 1, 2016, at 8:33 AM, Olivier Goffart wrote: > > On Freitag, 30. September 2016 15:43:57 CEST Shawn Rutledge wrote: >> Back in Nokia times it was said that we shouldn't use semicolons, because it >> would speed up the parsing and reduce the size of resources slightly. [...] > > Back in Nokia times, someone was reviewing a patch and made a comment that a > binding looking like this: > > someProperty: { > if (someOtherProperty === 42) > return something.foobar; > else > return somethingElse; > } > > Should be rewritten like this: > > someProperty: someOtherProperty === 42 ? something.foobar : somethingElse; > > A week later, one of the bullet point in the log of the team was something > like: > - replace all ifs with '?' syntax. > > They indeed spend some time replacing every single 'if' of their JavaScript > code (no matter how complex) in their QML application by the ternary operator. > They tought it was more efficient because it was suggested to replace one > occurrence in a review. There was this call for using “simple” expressions, since these were handled by V4 instead of the full-blown JS engine, and not originating just from some review comment. https://blog.qt.io/blog/2013/04/15/evolution-of-the-qml-engine-part-1/ Were they right? (Aside from that I’d say that ?: fits the declarative style much better, so there would also be other reasons to prefer that over an if-expression.) > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ 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 edward.welbourne at qt.io Tue Oct 4 13:03:58 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 4 Oct 2016 11:03:58 +0000 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: <201610011025.00081.marc.mutz@kdab.com> References: <57CFB58D.2060200@qt.io> <201609080912.32155.marc.mutz@kdab.com>, <201610011025.00081.marc.mutz@kdab.com> Message-ID: Marc Mutz said: > I just came to realise another reason against cherry-picking: > > Qt 5.6 is C++98-only while 5.7+ is C++11. That means patches that will > be developed against 5.7+ will very likely have C++11 constructs in > them that won't work in Qt 5.6. Conversely, code developed in 5.6 shall avoid C++11 constructs; when we merge to 5.7, we need to review to find C++11 usage we can apply, which tends to get missed after merges. > That means that in order to backport, the code needs to be > de-C++11-ified, which in turn means the usual reasoning for > cherry-picking as a stability feature (it's been integrated already > once successfully) falls flat on its face, because the code submitted > against 5.7+ must needs be changed (forgive my Victorian) in the > process of cherry-picking to 5.6, invalidating any test coverage it > may have had as part of the younger branch. Back-porting doesn't *entirely* invalidate the stability evidence gained in a later branch, any more than conflict resolutions in forward-merging invalidate stability evidence gained in an older branch. Of course, you need to test after back-porting, just as you do after forward-merging, but the existing test coverage is still valuable. > To avoid the guaranteed merge conflicts from > cherry-picked-and-changed, commits, Not sure what you're referring to here. Just to be clear, once we switch to cherry-picking back to 5.6, we shall stop merging forward from 5.6, so there shall be no merge conflicts from those changes being merged up into 5.7 again. That would be dumb. > you'd need to ban any non-cherry-pick changes to 5.6, which > effectively means that no developer does any work on 5.6 anymore. That did seem to be the intent of those who proposed this, yes. Of course, there shall be *some* work on 5.6, but it shall be limited to back-porting already-tested fixes and investigating bugs that are only evident in 5.6. That would be the point of LTS, IIUC. > Everyone will rely on the CI, and the CI only. Again, not sure what you mean here; and those doing back-ports shall of course be doing local testing before they push, so not relying only on the CI - where, in contrast, after a merge we *are* relying on the CI and only the CI, except for the (relatively few) conflicts in each merge, which do get review. > OTOH, with very few exceptions such a Q_FOREACH, code that > successfully integrated into 5.6 will successfully integrate in 5.7+. ... but will, as noted above, contain pre-C++11 code in need of C++1-ifying, after we've done sweeps through the code-base catching such code and modernising most of what's in 5.7 and beyond; so we would need to pay attention to each change flowing up from 5.6, to see what needs such attention. The advantage of cherry-picking is precisely that each one shall need to be done attentively and reviewed, while merging only gets review of its conflicts and happens quietly in the background, with few paying attention to it. > In light of this I continue to vote for keeping the "no-cherry-picks > allowed" policy that has served us well over the Qt 5 years. I remain unconvinced, see above, Eddy. From oswald.buddenhagen at qt.io Tue Oct 4 13:03:56 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 4 Oct 2016 13:03:56 +0200 Subject: [Development] Managing branches of Qt's git modules In-Reply-To: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> References: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> Message-ID: <20161004110356.GO12212@troll08> On Fri, Sep 30, 2016 at 11:39:20AM +0100, Sean Harmer wrote: > just a query as to how people do bulk checkouts of different branches > when working with the Qt git modules. It would be nice to be able to use > git submodule foreach ... but this is a problem because not all modules > use the same branching scheme. > cd qt5 ./init-repository -f --branch From annulen at yandex.ru Tue Oct 4 13:07:55 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 04 Oct 2016 14:07:55 +0300 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: References: <57CFB58D.2060200@qt.io> <201609080912.32155.marc.mutz@kdab.com>, <201610011025.00081.marc.mutz@kdab.com> Message-ID: <122731475579275@web14j.yandex.ru> 04.10.2016, 14:04, "Edward Welbourne" : > Marc Mutz said: >>  I just came to realise another reason against cherry-picking: >> >>  Qt 5.6 is C++98-only while 5.7+ is C++11. That means patches that will >>  be developed against 5.7+ will very likely have C++11 constructs in >>  them that won't work in Qt 5.6. > > Conversely, code developed in 5.6 shall avoid C++11 constructs; when we > merge to 5.7, we need to review to find C++11 usage we can apply, which > tends to get missed after merges. This can be easily fixed by using tools like clang-tidy (modernize* checks) > >>  That means that in order to backport, the code needs to be >>  de-C++11-ified, which in turn means the usual reasoning for >>  cherry-picking as a stability feature (it's been integrated already >>  once successfully) falls flat on its face, because the code submitted >>  against 5.7+ must needs be changed (forgive my Victorian) in the >>  process of cherry-picking to 5.6, invalidating any test coverage it >>  may have had as part of the younger branch. > > Back-porting doesn't *entirely* invalidate the stability evidence gained > in a later branch, any more than conflict resolutions in forward-merging > invalidate stability evidence gained in an older branch. Of course, you > need to test after back-porting, just as you do after forward-merging, > but the existing test coverage is still valuable. > >>  To avoid the guaranteed merge conflicts from >>  cherry-picked-and-changed, commits, > > Not sure what you're referring to here. Just to be clear, once we > switch to cherry-picking back to 5.6, we shall stop merging forward from > 5.6, so there shall be no merge conflicts from those changes being > merged up into 5.7 again. That would be dumb. > >>  you'd need to ban any non-cherry-pick changes to 5.6, which >>  effectively means that no developer does any work on 5.6 anymore. > > That did seem to be the intent of those who proposed this, yes. Of > course, there shall be *some* work on 5.6, but it shall be limited to > back-porting already-tested fixes and investigating bugs that are only > evident in 5.6. That would be the point of LTS, IIUC. > >>  Everyone will rely on the CI, and the CI only. > > Again, not sure what you mean here; and those doing back-ports shall of > course be doing local testing before they push, so not relying only on > the CI - where, in contrast, after a merge we *are* relying on the CI > and only the CI, except for the (relatively few) conflicts in each > merge, which do get review. > >>  OTOH, with very few exceptions such a Q_FOREACH, code that >>  successfully integrated into 5.6 will successfully integrate in 5.7+. > > ... but will, as noted above, contain pre-C++11 code in need of > C++1-ifying, after we've done sweeps through the code-base catching such > code and modernising most of what's in 5.7 and beyond; so we would need > to pay attention to each change flowing up from 5.6, to see what needs > such attention. The advantage of cherry-picking is precisely that each > one shall need to be done attentively and reviewed, while merging only > gets review of its conflicts and happens quietly in the background, with > few paying attention to it. > >>  In light of this I continue to vote for keeping the "no-cherry-picks >>  allowed" policy that has served us well over the Qt 5 years. > > I remain unconvinced, see above, > >         Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Tue Oct 4 15:32:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 04 Oct 2016 15:32:11 +0200 Subject: [Development] Notes on "Managing Qt's branches" session @ QCS 2016 In-Reply-To: References: <57CFB58D.2060200@qt.io> <201610011025.00081.marc.mutz@kdab.com> Message-ID: <18681268.NHyXEButxG@tjmaciei-mobl1> Em terça-feira, 4 de outubro de 2016, às 11:03:58 CEST, Edward Welbourne escreveu: > Marc Mutz said: > > Qt 5.6 is C++98-only while 5.7+ is C++11. That means patches that will > > be developed against 5.7+ will very likely have C++11 constructs in > > them that won't work in Qt 5.6. > > Conversely, code developed in 5.6 shall avoid C++11 constructs; when we > merge to 5.7, we need to review to find C++11 usage we can apply, which > tends to get missed after merges. Adding a few new Q_NULLPTR and Q_DECL_OVERRIDE are not a problem. You can't add new "foreach", but that's about all. So if you write your code in 5.6 using a regular for with iterators, it's fine to keep as-is in 5.7 and up. > > OTOH, with very few exceptions such a Q_FOREACH, code that > > successfully integrated into 5.6 will successfully integrate in 5.7+. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From viktor.engelmann at qt.io Tue Oct 4 15:51:29 2016 From: viktor.engelmann at qt.io (Viktor Engelmann) Date: Tue, 4 Oct 2016 15:51:29 +0200 Subject: [Development] Using semicolons in JS (QML) In-Reply-To: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> References: <89DA3FCB-ED87-4C83-B4A1-9FA9DE3CA4EE@qt.io> Message-ID: <778a5234-148b-bb29-fb9c-f05327384adc@qt.io> Am 30.09.2016 um 17:43 schrieb Shawn Rutledge: > Back in Nokia times it was said that we shouldn't use semicolons, > because it would speed up the parsing [...] As someone who has written countless parsers, I *highly* doubt that this is actually true. Indenting with tabs was also believed to be *much* slower than indenting with spaces (which makes absolutely no sense), and that measurement result turned out to be caused by a bug in firebird. I bet this is also just an urban legend. Someone probably thought "hey - one less character to read - must be faster to load", but as André pointed out, the error recovery will most likely cost more than what you save. Unless if the behavior is baked into the LR(1) state-graph maybe. Also I don't think it is good style to write code that doesn't conform to the actual language, just because *most* parsers correctly *guess* what you meant *most* of the time (except in those pathological cases...). I think that you should *always* tell parsers *precisely* what you mean and don't rely on it's guessing ability. For reference: The Mariner 1 crash (which cost $80 million) was supposedly caused by an error that could have been caught by static analysis at compile time, but was just "guessed away" wrongly. Anyhow, I believe that we have spent more time on this debate than will ever be saved by omitting semicolons. Viktor -- 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 Qt World Summit 2016 Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential Potential on October 18-20 www.qtworldsummit.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_logo_with_text_green_rgb_400x141.png Type: image/png Size: 16849 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_facebook.png Type: image/png Size: 1407 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_twitter.png Type: image/png Size: 1778 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_linkedin.png Type: image/png Size: 1532 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_googleplus.png Type: image/png Size: 1957 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qt_youtube.png Type: image/png Size: 1610 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qtworldsummit2016_banner.jpg Type: image/jpeg Size: 35183 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: viktor_engelmann.vcf Type: text/x-vcard Size: 271 bytes Desc: not available URL: From robert.loehning at qt.io Wed Oct 5 10:59:40 2016 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Wed, 5 Oct 2016 10:59:40 +0200 Subject: [Development] Managing branches of Qt's git modules In-Reply-To: <84c30574-9a04-965a-d585-843e40b28864@kdab.com> References: <54db7145-183f-16eb-a407-2c42c95d0ac3@kdab.com> <201609301257.43726.marc.mutz@kdab.com> <84c30574-9a04-965a-d585-843e40b28864@kdab.com> Message-ID: Am 30.09.2016 um 13:05 schrieb Sean Harmer: > > > On 30/09/2016 11:57, Marc Mutz wrote: >> On Friday 30 September 2016 12:39:20 Sean Harmer wrote: >>> Hi, >>> >>> just a query as to how people do bulk checkouts of different branches >>> when working with the Qt git modules. It would be nice to be able to use >>> git submodule foreach ... but this is a problem because not all modules >>> use the same branching scheme. >>> >>> So, what do people do to checkout all interesting modules to 5.7, 5.8, >>> dev etc on Unix like systems and on Windows? >>> >>> On *nix systems I've been getting away with a simple bash for loop. But >>> on windows I find this painful but maybe that's just my unfamiliarity >>> with windows batch scripts. >> >> to speed up fetching: >> >> git submdule foreach "git fetch --all &" >> >> for everything else there's the repo tool, though I have not gotten >> around >> to checking it out, since most of my work is in qtbase. >> >> git checkout >> git submodule update --rebase > > Thanks! Somehow I'd missed knowing about the --rebase option. Hi, wouldn't that rebase the branches the submodules have currently checked out onto the top of ? Best Regards, Robert > >> doesn't do what you want? > > Looks like it should. > > Thanks, > > Sean > From Kai.Koehne at qt.io Wed Oct 5 15:22:33 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 5 Oct 2016 13:22:33 +0000 Subject: [Development] [closed] Using semicolons in JS (QML) Message-ID: Hi, Alright, to close this thread: It seems the majority agrees that using semicolons after JS statement inside a Javascript {} block is a good idea. The suggestion is to follow this in new code. Personally, I will point out missing ; as defects in reviews. Regards Kai > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Viktor Engelmann > Sent: Tuesday, October 04, 2016 3:51 PM > To: development at qt-project.org > Subject: Re: [Development] Using semicolons in JS (QML) > > Am 30.09.2016 um 17:43 schrieb Shawn Rutledge: > > > Back in Nokia times it was said that we shouldn't use semicolons, > because it would speed up the parsing [...] > > > As someone who has written countless parsers, I *highly* doubt that this is > actually true. Indenting with tabs was also believed to be *much* slower > than indenting with spaces (which makes absolutely no sense), and that > measurement result turned out to be caused by a bug in firebird. I bet this is > also just an urban legend. Someone probably thought "hey - one less > character to read - must be faster to load", but as André pointed out, the > error recovery will most likely cost more than what you save. Unless if the > behavior is baked into the LR(1) state-graph maybe. > > Also I don't think it is good style to write code that doesn't conform to the > actual language, just because *most* parsers correctly *guess* what you > meant *most* of the time (except in those pathological cases...). I think that > you should *always* tell parsers *precisely* what you mean and don't rely > on it's guessing ability. For reference: The Mariner 1 crash (which cost $80 > million) was supposedly caused by an error that could have been caught by > static analysis at compile time, but was just "guessed away" wrongly. > > > Anyhow, I believe that we have spent more time on this debate than will > ever be saved by omitting semicolons. > > > Viktor > > > -- > > > > 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 > > > > > > > > Qt World Summit 2016 | Pier 27, San Francisco, CA Experience Exponential > Potential on October 18-20 > www.qtworldsummit.com From robert.loehning at qt.io Wed Oct 5 18:19:40 2016 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Wed, 5 Oct 2016 18:19:40 +0200 Subject: [Development] bugreports.qt.io: unplanned interruption Message-ID: <5ac10803-4a44-b92e-1aa2-daa03ae7a376@qt.io> Hi, in the past hour loads of reports were created on bugreports.qt.io which did not even attempt providing meaningful data. Since blocking single users did not help, we decided to take the server offline to investigate the situation. It will be back as soon as we found a way to protect the server from this. We apologize for the inconvenience. Best Regards, Robert Löhning From Morten.Sorvig at qt.io Wed Oct 5 22:37:32 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Wed, 5 Oct 2016 20:37:32 +0000 Subject: [Development] QtBase WIP branch request Message-ID: <893A4598-B474-46D0-B1A2-A3E3BE5AAAF8@qt.io> Hi, We’re working on an update to the macOS/Cocoa platform plugin, and I would like to request a WIP branch where the changes can be finalized: wip/remac Thanks! Morten From mitch.curtis at qt.io Thu Oct 6 10:58:06 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Thu, 6 Oct 2016 08:58:06 +0000 Subject: [Development] [closed] Using semicolons in JS (QML) In-Reply-To: References: Message-ID: To make it a bit more formal and hopefully prevent it from being lost in the mail archives, let's update our QML coding conventions: https://codereview.qt-project.org/#/c/173027/ > -----Original Message----- > From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- > project.org] On Behalf Of Kai Koehne > Sent: Wednesday, 5 October 2016 3:23 PM > To: Viktor Engelmann ; development at qt- > project.org > Subject: [Development] [closed] Using semicolons in JS (QML) > > Hi, > > Alright, to close this thread: It seems the majority agrees that using > semicolons after JS statement inside a Javascript {} block is a good idea. The > suggestion is to follow this in new code. Personally, I will point out missing ; > as defects in reviews. > > Regards > > Kai > > > -----Original Message----- > > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > > project.org] On Behalf Of Viktor Engelmann > > Sent: Tuesday, October 04, 2016 3:51 PM > > To: development at qt-project.org > > Subject: Re: [Development] Using semicolons in JS (QML) > > > > Am 30.09.2016 um 17:43 schrieb Shawn Rutledge: > > > > > > Back in Nokia times it was said that we shouldn't use semicolons, > > because it would speed up the parsing [...] > > > > > > As someone who has written countless parsers, I *highly* doubt that > > this is actually true. Indenting with tabs was also believed to be > > *much* slower than indenting with spaces (which makes absolutely no > > sense), and that measurement result turned out to be caused by a bug > > in firebird. I bet this is also just an urban legend. Someone probably > > thought "hey - one less character to read - must be faster to load", > > but as André pointed out, the error recovery will most likely cost > > more than what you save. Unless if the behavior is baked into the LR(1) > state-graph maybe. > > > > Also I don't think it is good style to write code that doesn't conform > > to the actual language, just because *most* parsers correctly *guess* > > what you meant *most* of the time (except in those pathological > > cases...). I think that you should *always* tell parsers *precisely* > > what you mean and don't rely on it's guessing ability. For reference: > > The Mariner 1 crash (which cost $80 > > million) was supposedly caused by an error that could have been caught > > by static analysis at compile time, but was just "guessed away" wrongly. > > > > > > Anyhow, I believe that we have spent more time on this debate than > > will ever be saved by omitting semicolons. > > > > > > Viktor > > > > > > -- > > > > > > > > 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 > > > > > > > > > > > > Qt World Summit 2016 | Pier 27, San Francisco, CA Experience > > Exponential Potential on October 18-20 www.qtworldsummit.com > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at qt.io Thu Oct 6 11:06:38 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 6 Oct 2016 11:06:38 +0200 Subject: [Development] QtBase WIP branch request In-Reply-To: <893A4598-B474-46D0-B1A2-A3E3BE5AAAF8@qt.io> References: <893A4598-B474-46D0-B1A2-A3E3BE5AAAF8@qt.io> Message-ID: <20161006090638.GZ12212@troll08> On Wed, Oct 05, 2016 at 08:37:32PM +0000, Morten Sorvig wrote: > We’re working on an update to the macOS/Cocoa platform plugin, > and I would like to request a WIP branch where the changes can > be finalized: > > wip/remac > you have Good Reasons (TM) for creating a branch according to https://wiki.qt.io/Branch_Guidelines#Creating_a_new_feature_branch , yes? mergable or throw-away? From andre at familiesomers.nl Thu Oct 6 11:10:42 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 6 Oct 2016 11:10:42 +0200 Subject: [Development] [closed] Using semicolons in JS (QML) In-Reply-To: References: Message-ID: So, now we need one of these QUIPs to document the descision if I understand it correctly ? André Op 06/10/2016 om 10:58 schreef Mitch Curtis: > To make it a bit more formal and hopefully prevent it from being lost in the mail archives, let's update our QML coding conventions: > > https://codereview.qt-project.org/#/c/173027/ > >> -----Original Message----- >> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt- >> project.org] On Behalf Of Kai Koehne >> Sent: Wednesday, 5 October 2016 3:23 PM >> To: Viktor Engelmann ; development at qt- >> project.org >> Subject: [Development] [closed] Using semicolons in JS (QML) >> >> Hi, >> >> Alright, to close this thread: It seems the majority agrees that using >> semicolons after JS statement inside a Javascript {} block is a good idea. The >> suggestion is to follow this in new code. Personally, I will point out missing ; >> as defects in reviews. >> >> Regards >> >> Kai >> >>> -----Original Message----- >>> From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- >>> project.org] On Behalf Of Viktor Engelmann >>> Sent: Tuesday, October 04, 2016 3:51 PM >>> To: development at qt-project.org >>> Subject: Re: [Development] Using semicolons in JS (QML) >>> >>> Am 30.09.2016 um 17:43 schrieb Shawn Rutledge: >>> >>> >>> Back in Nokia times it was said that we shouldn't use semicolons, >>> because it would speed up the parsing [...] >>> >>> >>> As someone who has written countless parsers, I *highly* doubt that >>> this is actually true. Indenting with tabs was also believed to be >>> *much* slower than indenting with spaces (which makes absolutely no >>> sense), and that measurement result turned out to be caused by a bug >>> in firebird. I bet this is also just an urban legend. Someone probably >>> thought "hey - one less character to read - must be faster to load", >>> but as André pointed out, the error recovery will most likely cost >>> more than what you save. Unless if the behavior is baked into the LR(1) >> state-graph maybe. >>> Also I don't think it is good style to write code that doesn't conform >>> to the actual language, just because *most* parsers correctly *guess* >>> what you meant *most* of the time (except in those pathological >>> cases...). I think that you should *always* tell parsers *precisely* >>> what you mean and don't rely on it's guessing ability. For reference: >>> The Mariner 1 crash (which cost $80 >>> million) was supposedly caused by an error that could have been caught >>> by static analysis at compile time, but was just "guessed away" wrongly. >>> >>> >>> Anyhow, I believe that we have spent more time on this debate than >>> will ever be saved by omitting semicolons. >>> >>> >>> Viktor >>> >>> >>> -- >>> >>> >>> >>> 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 >>> >>> >>> >>> >>> >>> Qt World Summit 2016 | Pier 27, San Francisco, CA Experience >>> Exponential Potential on October 18-20 www.qtworldsummit.com >>> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at qt.io Thu Oct 6 11:17:41 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 6 Oct 2016 09:17:41 +0000 Subject: [Development] [closed] Using semicolons in JS (QML) In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of André Somers > Sent: Thursday, October 06, 2016 11:11 AM > To: development at qt-project.org > Subject: Re: [Development] [closed] Using semicolons in JS (QML) > > So, now we need one of these QUIPs to document the descision if I > understand it correctly ? Ideally, yes. But I won't spend the time on writing a full QUIP for QML coding conventions, at least not now. (Though I think there should be one, so if there are volunteers ... ;) Regards Kai From tim at klingt.org Thu Oct 6 15:32:40 2016 From: tim at klingt.org (Tim Blechmann) Date: Thu, 6 Oct 2016 21:32:40 +0800 Subject: [Development] QtBase WIP branch request In-Reply-To: <20161006090638.GZ12212@troll08> References: <893A4598-B474-46D0-B1A2-A3E3BE5AAAF8@qt.io> <20161006090638.GZ12212@troll08> Message-ID: >> We’re working on an update to the macOS/Cocoa platform plugin, >> and I would like to request a WIP branch where the changes can >> be finalized: >> >> wip/remac >> > you have Good Reasons (TM) for creating a branch according to > https://wiki.qt.io/Branch_Guidelines#Creating_a_new_feature_branch , yes? i'm experiencing many of the issues that this branch will address (and hacked around them in my own version of the cocoa platform plugin). having a branch which is easy to access would allow me test the changes in a real-world context. tia! tim > mergable or throw-away? From oswald.buddenhagen at qt.io Thu Oct 6 16:10:53 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Thu, 6 Oct 2016 16:10:53 +0200 Subject: [Development] QtBase WIP branch request In-Reply-To: References: <893A4598-B474-46D0-B1A2-A3E3BE5AAAF8@qt.io> <20161006090638.GZ12212@troll08> Message-ID: <20161006141053.GB12212@troll08> On Thu, Oct 06, 2016 at 09:32:40PM +0800, Tim Blechmann wrote: > >> We’re working on an update to the macOS/Cocoa platform plugin, > >> and I would like to request a WIP branch where the changes can > >> be finalized: > >> > >> wip/remac > >> > > you have Good Reasons (TM) for creating a branch according to > > https://wiki.qt.io/Branch_Guidelines#Creating_a_new_feature_branch , yes? > > i'm experiencing many of the issues that this branch will address (and > hacked around them in my own version of the cocoa platform plugin). > having a branch which is easy to access would allow me test the changes > in a real-world context. > as the wiki explains, a gerrit review series is also a branch, so you can just check it out. the one thing the wiki doesn't mention (but probably should): why do you want to branch _at all_? i can think of two valid reasons: - the work is experimental and may end up being discarded wholesale. in this case, having it in a separate branch is cleaner than reverts on the mainline. - the development will take a long/unpredictable time, and you don't want the unfinished parts to be in mainline for the time being, as per feature integration policy. the one thing that is definitely *not* a good reason: there may be dysfunctional intermediate states. nope, you don't get to violate atomicity just because you're on a branch. of course, if you just want to be sloppy and are fine with a throw-away branch, all the power to you. > tia! > tim > > > mergable or throw-away? > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From frank.richter at gmail.com Thu Oct 6 16:50:59 2016 From: frank.richter at gmail.com (Frank Richter) Date: Thu, 06 Oct 2016 14:50:59 +0000 Subject: [Development] Question about keyboard mapping In-Reply-To: References: Message-ID: Hi, I think what happened is that at some point keyboard handling on X11 was changed to use xkb exclusively. This works fine if the server provides the xkb layout identity; this usually is the case for non-ancient(?) X.org servers, but not necessarily for other server vendors. Now, if that identity can not be determined, a fallback is used; still an xkb keyboard layout from the local machine. Unfortunately, the "other" servers mentioned above may not use key codes that match those from the local fallback layout, and you end up with weird behaviour. (In my case it happened with Exceed, and keys were sort of "one off": you pressed a key, but what appeared on screen was an adjacent letter...) Anyway, the "solution" was to evaluate the keyboard mapping available through the core protocol, and synthesize an xkb layout from that. This allows keyboard input to work even if the server doesn't support xkb. You can find patches here: https://github.com/res2k/QtLegacyXKeyboard Hope I could help, -f.r. On Mon, 3 Oct 2016 at 21:16 Scott Aron Bloom wrote: > I have had a bunch of customers report that using our tool over Xceed, > ASTEX-X, and now XManager, are having problems with the keyboard mapping. > > Was there something fixed post Qt 5.5.1 for this type of issue? I am > stuck on 5.5.1 for the near future, and will have to back patch it. > > > > Scott > > > > > _______________________________________________ > 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 randy.oreilly at colorado.edu Thu Oct 6 22:02:35 2016 From: randy.oreilly at colorado.edu (Randall OReilly) Date: Thu, 6 Oct 2016 14:02:35 -0600 Subject: [Development] Question about keyboard mapping In-Reply-To: References: Message-ID: Is this not incorporated into the main Qt codebase? If not, why not? I encountered a similar problem with the Mac Xserver in an earlier version of Qt (I think the first “fallback” fixed that but seems like this is a much more robust solution?). Cheers, - Randy > On Oct 6, 2016, at 8:50 AM, Frank Richter wrote: > > Hi, > I think what happened is that at some point keyboard handling on X11 was changed to use xkb exclusively. > This works fine if the server provides the xkb layout identity; this usually is the case for non-ancient(?) X.org servers, but not necessarily for other server vendors. > Now, if that identity can not be determined, a fallback is used; still an xkb keyboard layout from the local machine. > Unfortunately, the "other" servers mentioned above may not use key codes that match those from the local fallback layout, and you end up with weird behaviour. > (In my case it happened with Exceed, and keys were sort of "one off": you pressed a key, but what appeared on screen was an adjacent letter...) > > Anyway, the "solution" was to evaluate the keyboard mapping available through the core protocol, and synthesize an xkb layout from that. This allows keyboard input to work even if the server doesn't support xkb. You can find patches here: https://github.com/res2k/QtLegacyXKeyboard > > Hope I could help, > -f.r. > > On Mon, 3 Oct 2016 at 21:16 Scott Aron Bloom wrote: > I have had a bunch of customers report that using our tool over Xceed, ASTEX-X, and now XManager, are having problems with the keyboard mapping. > > Was there something fixed post Qt 5.5.1 for this type of issue? I am stuck on 5.5.1 for the near future, and will have to back patch it. > > > > Scott > > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Morten.Sorvig at qt.io Fri Oct 7 09:32:14 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Fri, 7 Oct 2016 07:32:14 +0000 Subject: [Development] QtBase WIP branch request In-Reply-To: <20161006141053.GB12212@troll08> References: <893A4598-B474-46D0-B1A2-A3E3BE5AAAF8@qt.io> <20161006090638.GZ12212@troll08> <20161006141053.GB12212@troll08> Message-ID: > On 6 Oct 2016, at 16:10, Oswald Buddenhagen wrote: > > On Thu, Oct 06, 2016 at 09:32:40PM +0800, Tim Blechmann wrote: >>>> We’re working on an update to the macOS/Cocoa platform plugin, >>>> and I would like to request a WIP branch where the changes can >>>> be finalized: >>>> >>>> wip/remac >>>> >>> you have Good Reasons (TM) for creating a branch according to >>> https://wiki.qt.io/Branch_Guidelines#Creating_a_new_feature_branch , yes? >> >> i'm experiencing many of the issues that this branch will address (and >> hacked around them in my own version of the cocoa platform plugin). >> having a branch which is easy to access would allow me test the changes >> in a real-world context. >> > as the wiki explains, a gerrit review series is also a branch, so you > can just check it out. > > the one thing the wiki doesn't mention (but probably should): why do you > want to branch _at all_? i can think of two valid reasons: > - the work is experimental and may end up being discarded wholesale. in > this case, having it in a separate branch is cleaner than reverts on > the mainline. > - the development will take a long/unpredictable time, and you don't > want the unfinished parts to be in mainline for the time being, as per > feature integration policy. > Those are the reasons, yes. (we won’t discard all of it; parts may be removed or completely rewritten). As a bonus reason sharing becomes easier ('git checkout wip/remac’ vs ‘find the current head of patch series on gerrit’). I would like to develop on dev as soon as possible, once the branch is regression-free (as verified by the CI system), and we have settled on major implementation decisions. What is actually in development? The scope is outlined in QTBUG-49827 and includes - Improving expose event handling - Improving support for Core Animation layer-backed QWindows - Improving support for embedding QWindow in NSView hierarchies - Driving QWindow::requestUpdate() animations via CVDisplayLink Morten From kevin.ottens at kdab.com Fri Oct 7 10:10:39 2016 From: kevin.ottens at kdab.com (Kevin Ottens) Date: Fri, 07 Oct 2016 10:10:39 +0200 Subject: [Development] Qt 3D 5.7 -> 5.7.1 missing merge Message-ID: <1869681.OA0bP6kSdf@wintermute> Hello, I found out yesterday that some patches of the 5.7 branch are not in 5.7.1. Those patches were produced in 5.7 because we were expecting a final 5.7 -> 5.7.1 merge. Those patches are necessary for some examples to work properly, that's why we would need them in 5.7.1 as well. What would be the best approach to deal with it at that point in the cycle? Could someone do the merge? Thanks in advance for help or hints. Regards. -- Dr. Kevin Ottens | kevin.ottens at kdab.com | Software Craftsman KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4661 bytes Desc: not available URL: From oswald.buddenhagen at qt.io Fri Oct 7 10:30:20 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 7 Oct 2016 10:30:20 +0200 Subject: [Development] Qt 3D 5.7 -> 5.7.1 missing merge In-Reply-To: <1869681.OA0bP6kSdf@wintermute> References: <1869681.OA0bP6kSdf@wintermute> Message-ID: <20161007083020.GD12212@troll08> On Fri, Oct 07, 2016 at 10:10:39AM +0200, Kevin Ottens wrote: > I found out yesterday that some patches of the 5.7 branch are not in 5.7.1. > i see no evidence of this being true at this time. > Those patches were produced in 5.7 because we were expecting a final > 5.7 -> 5.7.1 merge. > given that there was not even a mail announcing the completion of said merge yet, what makes you think there is some problem? From oswald.buddenhagen at qt.io Fri Oct 7 10:38:28 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 7 Oct 2016 10:38:28 +0200 Subject: [Development] QtBase WIP branch request In-Reply-To: References: <893A4598-B474-46D0-B1A2-A3E3BE5AAAF8@qt.io> <20161006090638.GZ12212@troll08> <20161006141053.GB12212@troll08> Message-ID: <20161007083827.GE12212@troll08> On Fri, Oct 07, 2016 at 07:32:14AM +0000, Morten Sorvig wrote: > I would like to develop on dev as soon as possible, once the branch is > regression-free (as verified by the CI system), and we have settled on > major implementation decisions. > fair enough. from this i'm also inferring that you want the branch created from current dev. done. From oswald.buddenhagen at qt.io Fri Oct 7 10:42:52 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 7 Oct 2016 10:42:52 +0200 Subject: [Development] HEADS-UP: Branching from '5.7' to '5.7.1' completed Message-ID: <20161007084252.GF12212@troll08> On Mon, Sep 26, 2016 at 07:54:23AM +0000, Jani Heikkinen wrote: > We have now created '5.7.1' branch for Qt 5.7.1 release. Please start > using it for changes targeted to Qt 5.7.1 release. And as usual there > is time to finalize ongoing ones in '5.7' branch; final downmerge from > '5.7' to '5.7.1' will be done after a week. > this was completed yesterday in the afternoon. 5.7 is 5.7.2 content now. From kevin.ottens at kdab.com Fri Oct 7 10:59:33 2016 From: kevin.ottens at kdab.com (Kevin Ottens) Date: Fri, 07 Oct 2016 10:59:33 +0200 Subject: [Development] Qt 3D 5.7 -> 5.7.1 missing merge In-Reply-To: <20161007083020.GD12212@troll08> References: <1869681.OA0bP6kSdf@wintermute> <20161007083020.GD12212@troll08> Message-ID: <2265635.7mGVhvcuyJ@wintermute> Hello, On Friday, 7 October 2016 10:30:20 CEST Oswald Buddenhagen wrote: > On Fri, Oct 07, 2016 at 10:10:39AM +0200, Kevin Ottens wrote: > > I found out yesterday that some patches of the 5.7 branch are not in > > 5.7.1. > > i see no evidence of this being true at this time. Ah, I see, it happened between the time I checked and the time this email finally got off my queue. > > Those patches were produced in 5.7 because we were expecting a final > > 5.7 -> 5.7.1 merge. > > given that there was not even a mail announcing the completion of said > merge yet, what makes you think there is some problem? Indeed now that I could finally pull it sorted itself out. I expected that merge to happen earlier than it did happen though, hence the confusion. Regards. -- Dr. Kevin Ottens | kevin.ottens at kdab.com | Software Craftsman KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.fr KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4661 bytes Desc: not available URL: From jani.heikkinen at qt.io Fri Oct 7 13:26:40 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 7 Oct 2016 11:26:40 +0000 Subject: [Development] Please test Qt 5.6.2 final packages Message-ID: Hi all, We have final Qt 5.6.2 packages here: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.2/571/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.2/505/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.2/442/ src: http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/ (mirroring might still be ongoing) Please test the packages & report all new blockers immediately. If packages are still good enough we will release these packages as Qt 5.6.2 during the next week Packages are RTA tested and all seems to be OK. Please update the known issues page for the release when needed: https://wiki.qt.io/Qt_5.6.2_Known_Issues Changes since previous packages: qt/qtwebengine > Fix crash when using openIn on newly created view > Doc: Fix types of \qmlproperty qt/qtbase > Describe meaning of typographic units in QRawFont documentation > Fix code signing for qmake-generated Xcode projects in Xcode 8 (again) > add buildsystem changelog for 5.6.2 qt/qtrepotools > Do not complain about 2 trailing spaces in md files br, Jani From michalrz at socialbicycles.com Fri Oct 7 14:34:01 2016 From: michalrz at socialbicycles.com (=?UTF-8?Q?Micha=c5=82_'Khorne'_Lowas-Rzechonek?=) Date: Fri, 7 Oct 2016 14:34:01 +0200 Subject: [Development] Font rendering depending on the QPA plugin? In-Reply-To: <5779cf79-ebcb-5b74-fc79-f2bdf844b5f6@socialbicycles.com> References: <5779cf79-ebcb-5b74-fc79-f2bdf844b5f6@socialbicycles.com> Message-ID: <762d7fb7-839a-5e6c-abcb-7f41a80c7dea@socialbicycles.com> Hi, I have a question about font rendering, Qt 5.6.1 on Linux. I am using QPainter to drawText() onto a monochromatic offscreen QPixmap, which then gets saved to a file. What bothers me is that it seems that pixel layout of letters changes depending on QPA plugin I use... with -platform xcb the bitmap renders fine, but with other QPAs the font metrics are completely off. I've inspected them via QFontMetrics and got different results of boundingRect() for the same letter with the same font: QImage image(34, 15, QImage::Format_Mono); QPainter painter(&image); QFont font("fixed", 6); QFontMetrics metrics(font); qDebug() << "f=" << metrics.boundingRect('f') << "j=" << metrics.boundingRect('j') << "W=" << metrics.boundingRect('W'); painter.setFont(font); painter.setPen(Qt::black); painter.eraseRect(0, 0, 34, 15); painter.drawText(0, 0, 34, 15, 0, "fjW"); image.save("test.png", "png"); The result for 'xcb' QPA on linux is fine (font is monospace and bitmapped, size '6 pt' should result in 5x8 px glyphs) f= QRect(0,-7 5x8) j= QRect(0,-7 5x8) W= QRect(0,-7 5x8) but for others I get different results, 'offscreen' yields f= QRect(0,-7 3x7) j= QRect(-1,-6 3x8) W= QRect(0,-6 7x6) and for 'minimal' it's f= QRect(0,-8 8x8) j= QRect(0,-8 8x8) W= QRect(0,-8 8x8) What I would like to get is consistent 5x8 pixel glyphs. I have my own QPA (it's an embedded device) so I am able to manipulate values reported by QPlatformScreen. I've noticed that the DPI has *some* impact on font metrics, but I can't put my finger on it. regards -- Michał 'Khorne' Lowas-Rzechonek Social Bicycles Inc. From chgans at gna.org Fri Oct 7 23:23:56 2016 From: chgans at gna.org (Ch'Gans) Date: Sat, 8 Oct 2016 10:23:56 +1300 Subject: [Development] Please test Qt 5.6.2 final packages In-Reply-To: References: Message-ID: On 8 October 2016 at 00:26, Jani Heikkinen wrote: > > Hi all, > > We have final Qt 5.6.2 packages here: > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.2/571/ > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.2/505/ > Mac: http://download.qt.io/snapshots/qt/5.6/5.6.2/442/ > src: http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/ (mirroring might still be ongoing) > > Please test the packages & report all new blockers immediately. If packages are still good enough we will release these packages as Qt 5.6.2 during the next week > > Packages are RTA tested and all seems to be OK. Hi Jani, Sorry for the dumb question, but may I ask what "RTA tested" mean? Chris From sahumada at texla.cl Fri Oct 7 23:55:11 2016 From: sahumada at texla.cl (Sergio Ahumada) Date: Fri, 7 Oct 2016 23:55:11 +0200 Subject: [Development] Please test Qt 5.6.2 final packages In-Reply-To: References: Message-ID: <02150069-8a6d-1149-d042-a6c79e930281@texla.cl> On 07.10.2016 23:23, Ch'Gans wrote: > On 8 October 2016 at 00:26, Jani Heikkinen wrote: >> >> Hi all, >> >> We have final Qt 5.6.2 packages here: >> >> Windows: http://download.qt.io/snapshots/qt/5.6/5.6.2/571/ >> Linux: http://download.qt.io/snapshots/qt/5.6/5.6.2/505/ >> Mac: http://download.qt.io/snapshots/qt/5.6/5.6.2/442/ >> src: http://download.qt.io/snapshots/qt/5.6/5.6.2/latest_src/ (mirroring might still be ongoing) >> >> Please test the packages & report all new blockers immediately. If packages are still good enough we will release these packages as Qt 5.6.2 during the next week >> >> Packages are RTA tested and all seems to be OK. > > Hi Jani, > > Sorry for the dumb question, but may I ask what "RTA tested" mean? > > Chris Release Test Automation http://wiki.qt.io/Sanity-Test-Guidelines -- Sergio Ahumada sahumada at texla.cl From sh at theharmers.co.uk Sat Oct 8 15:44:59 2016 From: sh at theharmers.co.uk (Sean Harmer) Date: Sat, 8 Oct 2016 14:44:59 +0100 Subject: [Development] macOS CI node segfault Message-ID: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> Hi, Just seen another segfault on one of the mac mini CI nodes: http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRelease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz Cheers, Sean From thiago.macieira at intel.com Sat Oct 8 22:52:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 08 Oct 2016 22:52:50 +0200 Subject: [Development] macOS CI node segfault In-Reply-To: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> References: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> Message-ID: <4068581.Pkko3fkjDZ@tjmaciei-mobl1> Em sábado, 8 de outubro de 2016, às 14:44:59 CEST, Sean Harmer escreveu: > Hi, > > Just seen another segfault on one of the mac mini CI nodes: > > http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498 > b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRel > ease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz Where? That log file does not contain the word "segfault", "error" or the phrase "segmentation fault". That said, we've known moc has been crashing on Mac for a couple of months and we have no idea what's causing it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sh at theharmers.co.uk Sun Oct 9 09:51:47 2016 From: sh at theharmers.co.uk (Sean Harmer) Date: Sun, 9 Oct 2016 08:51:47 +0100 Subject: [Development] macOS CI node segfault In-Reply-To: <4068581.Pkko3fkjDZ@tjmaciei-mobl1> References: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> <4068581.Pkko3fkjDZ@tjmaciei-mobl1> Message-ID: <7ea24c34-3ea4-9ac5-cadc-44577842db95@theharmers.co.uk> Hi Thiago, On 08/10/2016 21:52, Thiago Macieira wrote: > Em sábado, 8 de outubro de 2016, às 14:44:59 CEST, Sean Harmer escreveu: >> Hi, >> >> Just seen another segfault on one of the mac mini CI nodes: >> >> http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498 >> b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRel >> ease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz > > Where? That log file does not contain the word "segfault", "error" or the > phrase "segmentation fault". Something very wrong is going on then. Look at the failed run at Oct 8 2:38 PM from https://codereview.qt-project.org/#/c/168122/ which is where I copied the link from. The report on gerrit says segmentation fault, as did the report when I checked it at the time, yet now indeed the report has no mention of a segfault at all. Sounds like something overwrote the compile report which is a little concerning. > > That said, we've known moc has been crashing on Mac for a couple of months and > we have no idea what's causing it. This was a segfault in the compiler when building .moc/release/moc_qrenderaspect.cpp rather than when running moc but I am suspicious of some bad RAM or something on the hardware. Cheers, Sean From Jedrzej.Nowacki at qt.io Mon Oct 10 10:14:27 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Mon, 10 Oct 2016 08:14:27 +0000 Subject: [Development] macOS CI node segfault In-Reply-To: <7ea24c34-3ea4-9ac5-cadc-44577842db95@theharmers.co.uk> References: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> <4068581.Pkko3fkjDZ@tjmaciei-mobl1>, <7ea24c34-3ea4-9ac5-cadc-44577842db95@theharmers.co.uk> Message-ID: As Thiago said. Moc is crashing on OSX for an unknown reason. It is unlikely to be RAM problem, because we would see much wider distribution of crashes (related bug report: https://bugreports.qt.io/browse/QTQAINFRA-990). Regarding overwriting logs, it is Coin bug. For some reason we naively believed that builds are deterministic and there is only one build log 100 % reproducible... Well something to fix. Cheers, J?drek ________________________________ From: Development on behalf of Sean Harmer Sent: Sunday, October 9, 2016 9:51:47 AM To: development at qt-project.org Subject: Re: [Development] macOS CI node segfault Hi Thiago, On 08/10/2016 21:52, Thiago Macieira wrote: > Em s?bado, 8 de outubro de 2016, ?s 14:44:59 CEST, Sean Harmer escreveu: >> Hi, >> >> Just seen another segfault on one of the mac mini CI nodes: >> >> http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498 >> b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRel >> ease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz > > Where? That log file does not contain the word "segfault", "error" or the > phrase "segmentation fault". Something very wrong is going on then. Look at the failed run at Oct 8 2:38 PM from https://codereview.qt-project.org/#/c/168122/ which is where I copied the link from. The report on gerrit says segmentation fault, as did the report when I checked it at the time, yet now indeed the report has no mention of a segfault at all. Sounds like something overwrote the compile report which is a little concerning. > > That said, we've known moc has been crashing on Mac for a couple of months and > we have no idea what's causing it. This was a segfault in the compiler when building .moc/release/moc_qrenderaspect.cpp rather than when running moc but I am suspicious of some bad RAM or something on the hardware. Cheers, Sean _______________________________________________ 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 iamsergio at gmail.com Mon Oct 10 16:25:17 2016 From: iamsergio at gmail.com (=?UTF-8?Q?S=C3=A9rgio_Martins?=) Date: Mon, 10 Oct 2016 15:25:17 +0100 Subject: [Development] macOS CI node segfault In-Reply-To: <4068581.Pkko3fkjDZ@tjmaciei-mobl1> References: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> <4068581.Pkko3fkjDZ@tjmaciei-mobl1> Message-ID: On Sat, Oct 8, 2016 at 9:52 PM, Thiago Macieira wrote: > That said, we've known moc has been crashing on Mac for a couple of months and > we have no idea what's causing it. I recently hit a moc crash when compiling KHTML, then replaced moc with a script that called "valgrind moc $@", gave the report to olivier and he fixed it immediately. Is it possible to trigger a manual build on macOS node and try until it crashes ? Regards, Sérgio Martins From sean.harmer at kdab.com Mon Oct 10 18:09:02 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 10 Oct 2016 17:09:02 +0100 Subject: [Development] macOS CI node segfault In-Reply-To: References: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> <4068581.Pkko3fkjDZ@tjmaciei-mobl1> Message-ID: <3d1150d2-dafa-d062-c2fc-07612b552f48@kdab.com> On 10/10/2016 15:25, Sérgio Martins wrote: > On Sat, Oct 8, 2016 at 9:52 PM, Thiago Macieira > wrote: >> That said, we've known moc has been crashing on Mac for a couple of months and >> we have no idea what's causing it. > > I recently hit a moc crash when compiling KHTML, then replaced moc > with a script that called "valgrind moc $@", gave the report to > olivier and he fixed it immediately. > Is it possible to trigger a manual build on macOS node and try until > it crashes ? I suspect hw here as it was the compiler, not moc, which crashed in this case. But that's a good idea to try in general in case there is a moc specific issue too. Cheers, Sean > > > Regards, > Sérgio Martins > _______________________________________________ > 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 sh at theharmers.co.uk Mon Oct 10 21:11:56 2016 From: sh at theharmers.co.uk (Sean Harmer) Date: Mon, 10 Oct 2016 20:11:56 +0100 Subject: [Development] macOS CI node segfault In-Reply-To: References: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> <4068581.Pkko3fkjDZ@tjmaciei-mobl1> <7ea24c34-3ea4-9ac5-cadc-44577842db95@theharmers.co.uk> Message-ID: <8391e281-ee5d-cc06-3da0-6a91d565ff72@theharmers.co.uk> On 10/10/2016 09:14, Jedrzej Nowacki wrote: > As Thiago said. Moc is crashing on OSX for an unknown reason. It is > unlikely to be RAM problem, because we would see much wider > distribution of crashes (related bug report: > https://bugreports.qt.io/browse/QTQAINFRA-990). Argh, sorry I indeed misread the segfault error. It is moc, not the compilation of moc's output as I thought. > Regarding overwriting logs, it is Coin bug. For some reason we naively > believed that builds are deterministic and there is only one build log > 100 % reproducible... Well something to fix. Is there a JIRA for this or should I file one? Cheers, Sean > > > Cheers, > > Jędrek > > ------------------------------------------------------------------------ > *From:* Development > on behalf of > Sean Harmer > *Sent:* Sunday, October 9, 2016 9:51:47 AM > *To:* development at qt-project.org > *Subject:* Re: [Development] macOS CI node segfault > > Hi Thiago, > > On 08/10/2016 21:52, Thiago Macieira wrote: >> Em sábado, 8 de outubro de 2016, às 14:44:59 CEST, Sean Harmer escreveu: >>> Hi, >>> >>> Just seen another segfault on one of the mac mini CI nodes: >>> >>> http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498 >>> b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRel >>> ease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz >> >> Where? That log file does not contain the word "segfault", "error" or the >> phrase "segmentation fault". > > Something very wrong is going on then. Look at the failed run at Oct 8 > 2:38 PM from https://codereview.qt-project.org/#/c/168122/ which is > where I copied the link from. The report on gerrit says segmentation > fault, as did the report when I checked it at the time, yet now indeed > the report has no mention of a segfault at all. > > Sounds like something overwrote the compile report which is a little > concerning. > >> >> That said, we've known moc has been crashing on Mac for a couple of months and >> we have no idea what's causing it. > > This was a segfault in the compiler when building > .moc/release/moc_qrenderaspect.cpp rather than when running moc but I am > suspicious of some bad RAM or something on the hardware. > > Cheers, > > Sean > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From clinton at elemtech.com Tue Oct 11 00:58:51 2016 From: clinton at elemtech.com (clinton at elemtech.com) Date: Mon, 10 Oct 2016 16:58:51 -0600 (MDT) Subject: [Development] stalled gerrit submission for xcb fix In-Reply-To: <1601235.8ozIXDxWqC@tjmaciei-mobl1> References: <1889893984.28006270.1475537815175.JavaMail.zimbra@elemtech.com> <1601235.8ozIXDxWqC@tjmaciei-mobl1> Message-ID: <1836631931.36114323.1476140331117.JavaMail.zimbra@elemtech.com> ----- On Oct 3, 2016, at 11:58 PM, Thiago Macieira thiago.macieira at intel.com wrote: > Em segunda-feira, 3 de outubro de 2016, às 17:36:55 CEST, clinton at elemtech.com > escreveu: >> Hi, >> >> This is my first time with a gerrit submission >> https://codereview.qt-project.org/#/c/169701/ >> to fix >> https://bugreports.qt.io/browse/QTBUG-39362 >> >> And I'm wondering why there hasn't been a review for this patch. I've tried >> adding relevant reviewers. > > If you don't get a review after a week, you send a "ping" (which you have, by > uploading new changes). > > If a week after that it hasn't happened, make sure you've added the maintainer > for the relevant module and send a ping again. If that doesn't help, post to > the mailing list here (which you now have). > Thanks. Its been another week now. I believe I have already added the maintainers. I'm still not sure what I can do next. Clint From Jedrzej.Nowacki at qt.io Tue Oct 11 09:21:17 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Tue, 11 Oct 2016 07:21:17 +0000 Subject: [Development] macOS CI node segfault In-Reply-To: <8391e281-ee5d-cc06-3da0-6a91d565ff72@theharmers.co.uk> References: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> <4068581.Pkko3fkjDZ@tjmaciei-mobl1> <7ea24c34-3ea4-9ac5-cadc-44577842db95@theharmers.co.uk> , <8391e281-ee5d-cc06-3da0-6a91d565ff72@theharmers.co.uk> Message-ID: Bug report for it doesn't exist it is something hanging in back of our heads for months, but feel free to fill the form. Cheers, Jędrek ________________________________________ From: Sean Harmer Sent: Monday, October 10, 2016 9:11 PM To: Jedrzej Nowacki; development at qt-project.org Subject: Re: [Development] macOS CI node segfault On 10/10/2016 09:14, Jedrzej Nowacki wrote: > As Thiago said. Moc is crashing on OSX for an unknown reason. It is > unlikely to be RAM problem, because we would see much wider > distribution of crashes (related bug report: > https://bugreports.qt.io/browse/QTQAINFRA-990). Argh, sorry I indeed misread the segfault error. It is moc, not the compilation of moc's output as I thought. > Regarding overwriting logs, it is Coin bug. For some reason we naively > believed that builds are deterministic and there is only one build log > 100 % reproducible... Well something to fix. Is there a JIRA for this or should I file one? Cheers, Sean > > > Cheers, > > Jędrek > > ------------------------------------------------------------------------ > *From:* Development > on behalf of > Sean Harmer > *Sent:* Sunday, October 9, 2016 9:51:47 AM > *To:* development at qt-project.org > *Subject:* Re: [Development] macOS CI node segfault > > Hi Thiago, > > On 08/10/2016 21:52, Thiago Macieira wrote: >> Em sábado, 8 de outubro de 2016, às 14:44:59 CEST, Sean Harmer escreveu: >>> Hi, >>> >>> Just seen another segfault on one of the mac mini CI nodes: >>> >>> http://testresults.qt.io/logs/qt/qt3d/8f273f12204fb46ea508393ea9ad3dcd41a498 >>> b4/OSXOSX_10_10x86_64OSXOSX_10_10x86_64Clangqtci-osx-10.10-x86_64DebugAndRel >>> ease_Release/3c7a8e84853b9a3cd649d77444b6f1a885819671/buildlog.txt.gz >> >> Where? That log file does not contain the word "segfault", "error" or the >> phrase "segmentation fault". > > Something very wrong is going on then. Look at the failed run at Oct 8 > 2:38 PM from https://codereview.qt-project.org/#/c/168122/ which is > where I copied the link from. The report on gerrit says segmentation > fault, as did the report when I checked it at the time, yet now indeed > the report has no mention of a segfault at all. > > Sounds like something overwrote the compile report which is a little > concerning. > >> >> That said, we've known moc has been crashing on Mac for a couple of months and >> we have no idea what's causing it. > > This was a segfault in the compiler when building > .moc/release/moc_qrenderaspect.cpp rather than when running moc but I am > suspicious of some bad RAM or something on the hardware. > > Cheers, > > Sean > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Jedrzej.Nowacki at qt.io Tue Oct 11 09:23:30 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Tue, 11 Oct 2016 07:23:30 +0000 Subject: [Development] macOS CI node segfault In-Reply-To: References: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> <4068581.Pkko3fkjDZ@tjmaciei-mobl1>, Message-ID: Yes, it is possible, but that would be a manual work. From that perspective I would prefer to focus on automatic uploading core dumps. Fredrik volunteered to look into that (thanks!) Cheers, Jędrek ________________________________________ From: Development on behalf of Sérgio Martins Sent: Monday, October 10, 2016 4:25 PM To: Thiago Macieira Cc: development at qt-project.org Subject: Re: [Development] macOS CI node segfault On Sat, Oct 8, 2016 at 9:52 PM, Thiago Macieira wrote: > That said, we've known moc has been crashing on Mac for a couple of months and > we have no idea what's causing it. I recently hit a moc crash when compiling KHTML, then replaced moc with a script that called "valgrind moc $@", gave the report to olivier and he fixed it immediately. Is it possible to trigger a manual build on macOS node and try until it crashes ? Regards, Sérgio Martins _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From assangema at gmail.com Wed Oct 12 04:05:44 2016 From: assangema at gmail.com (=?UTF-8?B?5b+D57+U?=) Date: Wed, 12 Oct 2016 10:05:44 +0800 Subject: [Development] Whether Qt5.8 support Visual Studio '15' now? Message-ID: Hi, I want compile Qt5.8 with Visual Studio '15' ，Not 2015,are there any problems？ Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Maurice.Kalinowski at qt.io Wed Oct 12 09:15:50 2016 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Wed, 12 Oct 2016 07:15:50 +0000 Subject: [Development] Whether Qt5.8 support Visual Studio '15' now? In-Reply-To: References: Message-ID: VS 15 is not released yet, and with 5.8 beta soon to be released, there are some time constraints to check for it. Hence any feedback in advance is nice. Maybe Thiago has been able to look into it. Generally, latest at its release support will be available, probably (given track record) earlier. BR, Maurice From: Development [mailto:development-bounces+maurice.kalinowski=qt.io at qt-project.org] On Behalf Of ?? Sent: Wednesday, October 12, 2016 4:06 AM To: development Subject: [Development] Whether Qt5.8 support Visual Studio '15' now? Hi, I want compile Qt5.8 with Visual Studio '15' ，Not 2015,are there any problems？ Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Oct 12 09:54:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 12 Oct 2016 09:54:01 +0200 Subject: [Development] Whether Qt5.8 support Visual Studio '15' now? In-Reply-To: References: Message-ID: <2324013.aXQF32KYYv@tjmaciei-mobl1> Em quarta-feira, 12 de outubro de 2016, às 07:15:50 CEST, Maurice Kalinowski escreveu: > VS 15 is not released yet, and with 5.8 beta soon to be released, there are > some time constraints to check for it. Hence any feedback in advance is > nice. > Maybe Thiago has been able to look into it. I did, but my changes that added support for the next version got conflict when moving to 5.8, after sitting there for a month not getting approvals, so I abandoned them. I will not be working anymore on enabling new Microsoft compilers. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From announce at qt-project.org Wed Oct 12 11:13:53 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 12 Oct 2016 09:13:53 +0000 Subject: [Development] [Announce] Qt 5.6.2 released Message-ID: Hi all, I am happy to inform that Qt 5.6.2 is released today, see http://blog.qt.io/blog/2016/10/12/qt-5-6-2-released/ Big thanks to everyone involved! br, Jani Heikkinen Release Manager The Qt Company Elektroniikkatie 13 90590 Oulu Finland jani.heikkinen at qt.io +358 50 4873735 http://qt.io _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From thiago.macieira at intel.com Wed Oct 12 21:59:06 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 12 Oct 2016 21:59:06 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 Message-ID: <7496830.S3jACJtUcN@tjmaciei-mobl1> Hello We've got a number of issues that got fixed in 5.7 by the change that made QFactoryLoader stop unloading plugins (notably, the Network Manager bearer plugin). Given that QtDBus in 5.6 is now heavily threaded, a number of new issues have cropped up. I've managed to fix some, but reports from Ubuntu developers indicate the latest fix only uncovered the next issue. If we do stop unloading, the problem goes away. So, ok to backport? See https://codereview.qt-project.org/172014 (original https://codereview.qt-project.org/140750) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Wed Oct 12 22:28:33 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 12 Oct 2016 22:28:33 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <7496830.S3jACJtUcN@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> Message-ID: <20161012202833.GA3971@klara.mpi.htwm.de> On Wed, Oct 12, 2016 at 09:59:06PM +0200, Thiago Macieira wrote: > Hello > > We've got a number of issues that got fixed in 5.7 by the change that made > QFactoryLoader stop unloading plugins (notably, Not unloading plugins is not a fix. Andre' From thiago.macieira at intel.com Wed Oct 12 22:41:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 12 Oct 2016 22:41:41 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <20161012202833.GA3971@klara.mpi.htwm.de> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <20161012202833.GA3971@klara.mpi.htwm.de> Message-ID: <2897625.4g6giq5FI1@tjmaciei-mobl1> Em quarta-feira, 12 de outubro de 2016, às 22:28:33 CEST, André Pönitz escreveu: > On Wed, Oct 12, 2016 at 09:59:06PM +0200, Thiago Macieira wrote: > > Hello > > > > We've got a number of issues that got fixed in 5.7 by the change that made > > QFactoryLoader stop unloading plugins (notably, > > Not unloading plugins is not a fix. No, it's a workaround. But I'm at a loss to fix the current issue. The issue at hand is that the plugin was unloaded between a slot being invoked in a queued connection and the object that would receive the event getting deleted. When deleting the object, the events queued to it are deleted. When metacall events are deleted, the parameters stored in it are destroyed. In order for QMetaType to destroy such a type, it needs to call the destroying functions registered with it. Since we do allow breaking of ODR because of hidden visibility / DLLs, the functions in question may have belonged to the plugin that was unloaded, even if the type wasn't exclusive to that plugin. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From james.turner at kdab.com Wed Oct 12 22:57:42 2016 From: james.turner at kdab.com (James Turner) Date: Wed, 12 Oct 2016 15:57:42 -0500 Subject: [Development] QtBase WIP branch request In-Reply-To: References: <893A4598-B474-46D0-B1A2-A3E3BE5AAAF8@qt.io> <20161006090638.GZ12212@troll08> <20161006141053.GB12212@troll08> Message-ID: > On 7 Oct 2016, at 02:32, Morten Sorvig wrote: > > > What is actually in development? The scope is outlined in QTBUG-49827 and includes > - Improving expose event handling > - Improving support for Core Animation layer-backed QWindows > - Improving support for embedding QWindow in NSView hierarchies > - Driving QWindow::requestUpdate() animations via CVDisplayLink Morten, I was doing some work, and have some patches (not yet available) in this area, to do with embedding NSView hierarchies inside QWidgets. The approximate changes are in the Cocoa QPA, to ensure that child QWindows are inserted into the NSView heirarchy as subviews correctly, and re-ordered in the subviews list (by removing and re-adding, as the AppKit docs suggest). One of the bugs hopefully fixed by this is: https://bugreports.qt.io/browse/QTBUG-7140 I can provide the patches via email, but I wonder if they will be subsumed by this work you’re about to start. Kind regards, James -- James Turner - Senior Software Developer KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3868 bytes Desc: not available URL: From giuseppe.dangelo at kdab.com Thu Oct 13 15:11:18 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 13 Oct 2016 14:11:18 +0100 Subject: [Development] Multiple Qt branches on Coverity Scan In-Reply-To: <7e837239-7161-c168-e8e6-ff6948ac4126@kdab.com> References: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> <3265007.irYWg5TUYC@tjmaciei-mobl1> <19429814.F5arqcLjF3@tjmaciei-mobl1> <7e837239-7161-c168-e8e6-ff6948ac4126@kdab.com> Message-ID: <60230af5-6864-a457-1c2c-2b8b3c00bde6@kdab.com> Heads up: On 03/10/16 22:46, Giuseppe D'Angelo wrote: > I'm going with "lts" and "dev" anyhow, thanks! To avoid losing history, we're sticking with the current "qt-project" to represent "dev", as apparently it's not possible to rename projects. "qt-project-lts" is going to be 5.6. The new branch should be ready soon (was told yesterday afternoon, actually), I'll send an email when this is done. Related: the "qtbase" and "qtdeclarative" standalone projects have not been updated for 2+ years, and they're fully embraced by qt-project[-lts], so they're getting removed. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From marc.mutz at kdab.com Thu Oct 13 15:35:52 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 13 Oct 2016 15:35:52 +0200 Subject: [Development] Multiple Qt branches on Coverity Scan In-Reply-To: <60230af5-6864-a457-1c2c-2b8b3c00bde6@kdab.com> References: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> <7e837239-7161-c168-e8e6-ff6948ac4126@kdab.com> <60230af5-6864-a457-1c2c-2b8b3c00bde6@kdab.com> Message-ID: <201610131535.52574.marc.mutz@kdab.com> On Thursday 13 October 2016 15:11:18 Giuseppe D'Angelo wrote: > Heads up: > > On 03/10/16 22:46, Giuseppe D'Angelo wrote: > > I'm going with "lts" and "dev" anyhow, thanks! > > To avoid losing history, we're sticking with the current "qt-project" to > represent "dev", as apparently it's not possible to rename projects. > "qt-project-lts" is going to be 5.6. The new branch should be ready soon > (was told yesterday afternoon, actually), I'll send an email when this > is done. Will the -lts version start out with its own CIDs or will identical issues have the same CIDs in both projects? If they're different, we'll have a mess. On that note: I've started using Coverity-Id: NNNNN akin to Task-number: in footers of commit messages related to Coverity fixes. Please use them, too. Maybe we can highlight them in Gerrit and link to the issue directly, even? 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 giuseppe.dangelo at kdab.com Thu Oct 13 15:43:13 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 13 Oct 2016 14:43:13 +0100 Subject: [Development] Multiple Qt branches on Coverity Scan In-Reply-To: <201610131535.52574.marc.mutz@kdab.com> References: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> <7e837239-7161-c168-e8e6-ff6948ac4126@kdab.com> <60230af5-6864-a457-1c2c-2b8b3c00bde6@kdab.com> <201610131535.52574.marc.mutz@kdab.com> Message-ID: <20e64ca4-78f5-0d53-32f6-c1ae75f3842f@kdab.com> On 13/10/16 14:35, Marc Mutz wrote: > Will the -lts version start out with its own CIDs or will identical issues > have the same CIDs in both projects? If they're different, we'll have a mess. The idea was to share the database of CIDs so to keep them in sync. That's why it's taking so long to set it up (?). I have no idea how the matching between branches is going to work... HTH, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From jianliang79 at gmail.com Thu Oct 13 16:00:35 2016 From: jianliang79 at gmail.com (Liang Jian) Date: Thu, 13 Oct 2016 22:00:35 +0800 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <2897625.4g6giq5FI1@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <20161012202833.GA3971@klara.mpi.htwm.de> <2897625.4g6giq5FI1@tjmaciei-mobl1> Message-ID: Not unloading plugin is really a bad idea. That will make any memory leak detector report tons of leaks even run a simplest qt widgets program. Find and fix 'real' memory leak will be much harder than before. On Thursday, October 13, 2016, Thiago Macieira wrote: > Em quarta-feira, 12 de outubro de 2016, às 22:28:33 CEST, André Pönitz > escreveu: > > On Wed, Oct 12, 2016 at 09:59:06PM +0200, Thiago Macieira wrote: > > > Hello > > > > > > We've got a number of issues that got fixed in 5.7 by the change that > made > > > QFactoryLoader stop unloading plugins (notably, > > > > Not unloading plugins is not a fix. > > No, it's a workaround. But I'm at a loss to fix the current issue. > > The issue at hand is that the plugin was unloaded between a slot being > invoked > in a queued connection and the object that would receive the event getting > deleted. When deleting the object, the events queued to it are deleted. > When > metacall events are deleted, the parameters stored in it are destroyed. In > order for QMetaType to destroy such a type, it needs to call the destroying > functions registered with it. > > Since we do allow breaking of ODR because of hidden visibility / DLLs, the > functions in question may have belonged to the plugin that was unloaded, > even > if the type wasn't exclusive to that plugin. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sergio.martins at kdab.com Thu Oct 13 16:30:22 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 13 Oct 2016 15:30:22 +0100 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <7496830.S3jACJtUcN@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> Message-ID: On 2016-10-12 20:59, Thiago Macieira wrote: > Hello > > We've got a number of issues that got fixed in 5.7 by the change that > made > QFactoryLoader stop unloading plugins (notably, the Network Manager > bearer > plugin). Given that QtDBus in 5.6 is now heavily threaded, a number of > new > issues have cropped up. I've managed to fix some, but reports from > Ubuntu > developers indicate the latest fix only uncovered the next issue. Hi, More importantly, this also solves all the QStringLiteral related crashes we've been seeing. We need this in 5.6, but it's too big a behaviour change for an LTS release. We need at least a variable to turn it on/off. Suggestion which me and peppe discussed: Make it opt-in in 5.6.3 and write in the ChangeLog that there will be a behaviour change in 5.6.4. Make it opt-out in 5.6.4 (bringing it on-par with 5.8). This gives the user a pre-warning of 3 months, it can still be turned off and fixes many crashes. 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 giuseppe.dangelo at kdab.com Thu Oct 13 16:59:04 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 13 Oct 2016 15:59:04 +0100 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <7496830.S3jACJtUcN@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> Message-ID: <604f3bdf-f17f-18a7-2253-9e0ab648af79@kdab.com> On 12/10/16 20:59, Thiago Macieira wrote: > We've got a number of issues that got fixed in 5.7 by the change that made > QFactoryLoader stop unloading plugins It's actually 5.8, isn't it? 494376f980e96339b6f1eff7c41336ca4d853065 is in 5.8 (and has a documentation bug as it states 5.7!). Which opens the question of what to do in 5.7, and IMHO the same that should happen in 5.6 (see Sérgio's mail) -- 5.7.2 opt-in, 5.7.3 (if it ever happens) opt-out. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From thiago.macieira at intel.com Thu Oct 13 17:16:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 13 Oct 2016 17:16:01 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <2897625.4g6giq5FI1@tjmaciei-mobl1> Message-ID: <2193330.Z42knJvU4i@tjmaciei-mobl1> Em quinta-feira, 13 de outubro de 2016, às 22:00:35 CEST, Liang Jian escreveu: > Not unloading plugin is really a bad idea. > That will make any memory leak detector report tons of leaks even run a > simplest qt widgets program. Find and fix 'real' memory leak will be much > harder than before. The decision is already taken: Qt has stopped unloading plugins in Qt 5.7. The question here is what we should do in 5.6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexandru.croitor at qt.io Thu Oct 13 17:37:22 2016 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Thu, 13 Oct 2016 15:37:22 +0000 Subject: [Development] macOS CI node segfault In-Reply-To: References: <878c6b53-5b9d-4dda-de3e-c54096d4194e@theharmers.co.uk> <4068581.Pkko3fkjDZ@tjmaciei-mobl1> Message-ID: Just got a segmentation fault on OS X 10.9 machine, while compiling, which doesn't seem related to moc. http://testresults.qt.io/logs/qt/qtbase/9859c09bddaf87f49e73c1e8734decab497730ec/OSXOSX_10_08x86_64OSXOSX_10_08x86_64Clangqtci-osx-10.8-x86_64Release_NoFramework/85d6b000f945a84bc84a4f01f53ac65bc05cbe86/testrun_1476370856/testlog.txt.gz http://testresults.qt.io/coin/integration/qt/qtbase/tasks/1476370856 Regards, Alex. On 11 Oct 2016, at 09:23, Jedrzej Nowacki > wrote: Yes, it is possible, but that would be a manual work. From that perspective I would prefer to focus on automatic uploading core dumps. Fredrik volunteered to look into that (thanks!) Cheers, Jędrek ________________________________________ From: Development > on behalf of Sérgio Martins > Sent: Monday, October 10, 2016 4:25 PM To: Thiago Macieira Cc: development at qt-project.org Subject: Re: [Development] macOS CI node segfault On Sat, Oct 8, 2016 at 9:52 PM, Thiago Macieira > wrote: That said, we've known moc has been crashing on Mac for a couple of months and we have no idea what's causing it. I recently hit a moc crash when compiling KHTML, then replaced moc with a script that called "valgrind moc $@", gave the report to olivier and he fixed it immediately. Is it possible to trigger a manual build on macOS node and try until it crashes ? Regards, Sérgio Martins _______________________________________________ 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 apoenitz at t-online.de Thu Oct 13 18:47:26 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 13 Oct 2016 18:47:26 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: References: <7496830.S3jACJtUcN@tjmaciei-mobl1> Message-ID: <20161013164726.GA3339@klara.mpi.htwm.de> On Thu, Oct 13, 2016 at 03:30:22PM +0100, Sergio Martins wrote: > On 2016-10-12 20:59, Thiago Macieira wrote: > >Hello > > > >We've got a number of issues that got fixed in 5.7 by the change that made > >QFactoryLoader stop unloading plugins (notably, the Network Manager bearer > >plugin). Given that QtDBus in 5.6 is now heavily threaded, a number of new > >issues have cropped up. I've managed to fix some, but reports from Ubuntu > >developers indicate the latest fix only uncovered the next issue. > > Hi, > > > More importantly, this also solves all the QStringLiteral related crashes > we've been seeing. These would be fixable by going back to QLatin1String. > We need this in 5.6, but it's too big a behaviour change for an LTS release. > We need at least a variable to turn it on/off. > > > Suggestion which me and peppe discussed: > > Make it opt-in in 5.6.3 and write in the ChangeLog that there will be a > behaviour change in 5.6.4. > Make it opt-out in 5.6.4 (bringing it on-par with 5.8). > > This gives the user a pre-warning of 3 months, it can still be turned off > and fixes many crashes. I still consider the approach of not unloading plugins fundamentally wrong. It only deepens the trench between Qt and valid approaches at software architectures. Andre' From annulen at yandex.ru Thu Oct 13 19:01:57 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 13 Oct 2016 20:01:57 +0300 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <20161013164726.GA3339@klara.mpi.htwm.de> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <20161013164726.GA3339@klara.mpi.htwm.de> Message-ID: <24691476378117@web38j.yandex.ru> 13.10.2016, 19:39, "André Pönitz" : > On Thu, Oct 13, 2016 at 03:30:22PM +0100, Sergio Martins wrote: >>  On 2016-10-12 20:59, Thiago Macieira wrote: >>  >Hello >>  > >>  >We've got a number of issues that got fixed in 5.7 by the change that made >>  >QFactoryLoader stop unloading plugins (notably, the Network Manager bearer >>  >plugin). Given that QtDBus in 5.6 is now heavily threaded, a number of new >>  >issues have cropped up. I've managed to fix some, but reports from Ubuntu >>  >developers indicate the latest fix only uncovered the next issue. >> >>  Hi, >> >>  More importantly, this also solves all the QStringLiteral related crashes >>  we've been seeing. > > These would be fixable by going back to QLatin1String. > >>  We need this in 5.6, but it's too big a behaviour change for an LTS release. >>  We need at least a variable to turn it on/off. >> >>  Suggestion which me and peppe discussed: >> >>  Make it opt-in in 5.6.3 and write in the ChangeLog that there will be a >>  behaviour change in 5.6.4. >>  Make it opt-out in 5.6.4 (bringing it on-par with 5.8). >> >>  This gives the user a pre-warning of 3 months, it can still be turned off >>  and fixes many crashes. > > I still consider the approach of not unloading plugins fundamentally > wrong. It only deepens the trench between Qt and valid approaches > at software architectures. I think not unloading plugins is fundamentally right thing to do, if user does not request unload explicitly. Rationale: * It's risky when plugin uses any non-trivial piece of software, leaving alone any Qt-specific issues, so it's a responsibility of user to ensure that plugin is doing it's deinitialization correctly on all target platforms, and only allow true unloading if this is the case. * It's not supported on all platforms (e.g., uclibc and musl implement dlclose() as a stub). * At application exit OS will unload plugins and clean up related resources much faster than it could be implemented with unload in destructors. -- Regards, Konstantin From apoenitz at t-online.de Thu Oct 13 19:47:57 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 13 Oct 2016 19:47:57 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <24691476378117@web38j.yandex.ru> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <20161013164726.GA3339@klara.mpi.htwm.de> <24691476378117@web38j.yandex.ru> Message-ID: <20161013174757.GA9620@klara.mpi.htwm.de> On Thu, Oct 13, 2016 at 08:01:57PM +0300, Konstantin Tokarev wrote: > > I still consider the approach of not unloading plugins fundamentally > > wrong. It only deepens the trench between Qt and valid approaches at > > software architectures. > > I think not unloading plugins is fundamentally right thing to do, if > user does not request unload explicitly. What should happen *if* the user requests unloading explictly? Andre' PS: > * It's not supported on all platforms (e.g., uclibc and musl implement > dlclose() as a stub). Qt was never about providing common subsets of all supported platforms. > * At application exit OS will unload plugins and clean up related > resources much faster than it could be implemented with unload in > destructors. I am not concerned about toy applications that gets started and closed by the minute. From annulen at yandex.ru Thu Oct 13 19:51:34 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 13 Oct 2016 20:51:34 +0300 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <20161013174757.GA9620@klara.mpi.htwm.de> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <20161013164726.GA3339@klara.mpi.htwm.de> <24691476378117@web38j.yandex.ru> <20161013174757.GA9620@klara.mpi.htwm.de> Message-ID: <140061476381094@web14m.yandex.ru> 13.10.2016, 20:39, "André Pönitz" : > On Thu, Oct 13, 2016 at 08:01:57PM +0300, Konstantin Tokarev wrote: >>  > I still consider the approach of not unloading plugins fundamentally >>  > wrong. It only deepens the trench between Qt and valid approaches at >>  > software architectures. >> >>  I think not unloading plugins is fundamentally right thing to do, if >>  user does not request unload explicitly. > > What should happen *if* the user requests unloading explictly? I think it should be unloaded completely if platform supports that. > > Andre' > > PS: > >>  * It's not supported on all platforms (e.g., uclibc and musl implement >>  dlclose() as a stub). > > Qt was never about providing common subsets of all supported platforms. > >>  * At application exit OS will unload plugins and clean up related >>  resources much faster than it could be implemented with unload in >>  destructors. > > I am not concerned about toy applications that gets started and closed > by the minute. * Do your applications load different plugins every minute? In many cases same plugins are needed for the whole lifetime of application. * In case of very large applications shutdown time is important as well, as it can become annoyingly large. -- Regards, Konstantin From thiago.macieira at intel.com Thu Oct 13 20:16:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 13 Oct 2016 20:16:50 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <20161013174757.GA9620@klara.mpi.htwm.de> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <24691476378117@web38j.yandex.ru> <20161013174757.GA9620@klara.mpi.htwm.de> Message-ID: <2892070.sB9xtAJTzu@tjmaciei-mobl1> Em quinta-feira, 13 de outubro de 2016, às 19:47:57 CEST, André Pönitz escreveu: > I am not concerned about toy applications that gets started and closed > by the minute. Right. Most applications don't unload their plugins, except at program exit. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Thu Oct 13 20:46:46 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Thu, 13 Oct 2016 20:46:46 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <2892070.sB9xtAJTzu@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <24691476378117@web38j.yandex.ru> <20161013174757.GA9620@klara.mpi.htwm.de> <2892070.sB9xtAJTzu@tjmaciei-mobl1> Message-ID: <20161013184646.GA12416@klara.mpi.htwm.de> On Thu, Oct 13, 2016 at 08:16:50PM +0200, Thiago Macieira wrote: > Em quinta-feira, 13 de outubro de 2016, às 19:47:57 CEST, André Pönitz > escreveu: > > I am not concerned about toy applications that gets started and closed > > by the minute. > > Right. Most applications don't unload their plugins, except at program exit. It's not about most that don't, but those that do, or that would like to. At a certain level of complexity one doesn't only want to load plugins on demand, but also unload them when not needed use anymore, or even unload/reload as part of an update. Andre' From jianliang79 at gmail.com Fri Oct 14 03:11:48 2016 From: jianliang79 at gmail.com (Liang Jian) Date: Fri, 14 Oct 2016 09:11:48 +0800 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <2193330.Z42knJvU4i@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <2897625.4g6giq5FI1@tjmaciei-mobl1> <2193330.Z42knJvU4i@tjmaciei-mobl1> Message-ID: It is a pity that qt develpers have made the dicision of not unloading plugins and I have to accept the reality. But I think we should at least introduce a method to disable this feature at runtime (such as through a enviroment variable) ? On Thu, Oct 13, 2016 at 11:16 PM, Thiago Macieira wrote: > Em quinta-feira, 13 de outubro de 2016, às 22:00:35 CEST, Liang Jian > escreveu: > > Not unloading plugin is really a bad idea. > > That will make any memory leak detector report tons of leaks even > run a > > simplest qt widgets program. Find and fix 'real' memory leak will be much > > harder than before. > > The decision is already taken: Qt has stopped unloading plugins in Qt 5.7. > > The question here is what we should do in 5.6. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Oct 14 07:10:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 14 Oct 2016 07:10:00 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <20161013184646.GA12416@klara.mpi.htwm.de> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <2892070.sB9xtAJTzu@tjmaciei-mobl1> <20161013184646.GA12416@klara.mpi.htwm.de> Message-ID: <2809753.3jWMvtKoFs@tjmaciei-mobl1> Em quinta-feira, 13 de outubro de 2016, às 20:46:46 CEST, André Pönitz escreveu: > It's not about most that don't, but those that do, or that would like to. > > At a certain level of complexity one doesn't only want to load plugins > on demand, but also unload them when not needed use anymore, or even > unload/reload as part of an update. We can revisit the idea for QPluginLoader, which is a public API. We are talking in this change about QFactoryLoader, which is a Qt API and which is ALWAYS used until program exit. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Oct 14 07:10:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 14 Oct 2016 07:10:41 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <2193330.Z42knJvU4i@tjmaciei-mobl1> Message-ID: <2079410.pDXGDJHgfL@tjmaciei-mobl1> Em sexta-feira, 14 de outubro de 2016, às 09:11:48 CEST, Liang Jian escreveu: > It is a pity that qt develpers have made the dicision of not unloading > plugins and I have to accept the reality. > But I think we should at least introduce a method to disable this > feature at runtime (such as through a enviroment variable) ? Use QLibrary for your own plugins. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Morten.Sorvig at qt.io Fri Oct 14 09:41:44 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Fri, 14 Oct 2016 07:41:44 +0000 Subject: [Development] QtBase WIP branch request In-Reply-To: References: <893A4598-B474-46D0-B1A2-A3E3BE5AAAF8@qt.io> <20161006090638.GZ12212@troll08> <20161006141053.GB12212@troll08> Message-ID: > On 12 Oct 2016, at 22:57, James Turner wrote: > > >> On 7 Oct 2016, at 02:32, Morten Sorvig wrote: >> >> >> What is actually in development? The scope is outlined in QTBUG-49827 and includes >> - Improving expose event handling >> - Improving support for Core Animation layer-backed QWindows >> - Improving support for embedding QWindow in NSView hierarchies >> - Driving QWindow::requestUpdate() animations via CVDisplayLink > > Morten, I was doing some work, and have some patches (not yet available) in this area, to do with embedding NSView hierarchies inside QWidgets. The approximate changes are in the Cocoa QPA, to ensure that child QWindows are inserted into the NSView heirarchy as subviews correctly, and re-ordered in the subviews list (by removing and re-adding, as the AppKit docs suggest). > > One of the bugs hopefully fixed by this is: > > https://bugreports.qt.io/browse/QTBUG-7140 > > I can provide the patches via email, but I wonder if they will be subsumed by this work you’re about to start. Hi, I don’t think I’ve made this change. Perhaps you can post the patch(es) on codereview? We could then either merge them or move them into the WIP branch. What I’ve seen is that compositing using layer-backed views is required to get proper stacking of QWindows with OpenGL content. But that presumably requires correctly ordered views first. Morten From jianliang79 at gmail.com Fri Oct 14 10:08:27 2016 From: jianliang79 at gmail.com (Liang Jian) Date: Fri, 14 Oct 2016 16:08:27 +0800 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <2079410.pDXGDJHgfL@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <2193330.Z42knJvU4i@tjmaciei-mobl1> <2079410.pDXGDJHgfL@tjmaciei-mobl1> Message-ID: I don't care custom plugin, What I care is the plugins loaded by qt itself, such as qpa plugin, images format plugins ..., These plugins are needed for all qt programs, we can't avoid the leaks caused by not unloading these plugins if my understanding to this issue is right (Maybe you don't think that are leaks but they will confuse memory leak detector), that is why I hope to introduce a method to disable this feature at runtime. On Fri, Oct 14, 2016 at 1:10 PM, Thiago Macieira wrote: > Em sexta-feira, 14 de outubro de 2016, às 09:11:48 CEST, Liang Jian > escreveu: > > It is a pity that qt develpers have made the dicision of not > unloading > > plugins and I have to accept the reality. > > But I think we should at least introduce a method to disable this > > feature at runtime (such as through a enviroment variable) ? > > Use QLibrary for your own plugins. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at qt.io Fri Oct 14 12:39:37 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Fri, 14 Oct 2016 12:39:37 +0200 Subject: [Development] Multiple Qt branches on Coverity Scan In-Reply-To: <20e64ca4-78f5-0d53-32f6-c1ae75f3842f@kdab.com> References: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> <7e837239-7161-c168-e8e6-ff6948ac4126@kdab.com> <60230af5-6864-a457-1c2c-2b8b3c00bde6@kdab.com> <201610131535.52574.marc.mutz@kdab.com> <20e64ca4-78f5-0d53-32f6-c1ae75f3842f@kdab.com> Message-ID: <20161014103937.GC28771@troll08> On Thu, Oct 13, 2016 at 02:43:13PM +0100, Giuseppe D'Angelo wrote: > On 13/10/16 14:35, Marc Mutz wrote: > > Will the -lts version start out with its own CIDs or will identical issues > > have the same CIDs in both projects? If they're different, we'll have a mess. > > The idea was to share the database of CIDs so to keep them in sync. > That's why it's taking so long to set it up (?). I have no idea how the > matching between branches is going to work... > probably not at all. but when you fix an issue in the lower branch, it will also disappear in the higher branch, so there is no need to explicitly mention it at all. just remember to use the issue number from the correct source. From nassian at bitshift-dynamics.de Fri Oct 14 13:59:36 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Fri, 14 Oct 2016 13:59:36 +0200 Subject: [Development] Qt build without Virtual Keyboard Message-ID: Hi, We are trying to build 5.7 on Linux without OpenGL support (so no QtQuick either) and are facing a build error in qtvirtualkeyboard „Module quick not found“. Is QtQuick now mandatory, or is this a known bug? And why is the virtual keyboard building at all when choosing L-GPL? That’s not very nice. Beste Grüße / Best regards, Alexander Nassian, bitshift dynamics GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch.curtis at qt.io Fri Oct 14 15:12:52 2016 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 14 Oct 2016 13:12:52 +0000 Subject: [Development] Qt build without Virtual Keyboard In-Reply-To: References: Message-ID: Qt Quick has always been mandatory for Qt Virtual Keyboard, as the keyboard itself is a Qt Quick Item. I don’t know where or how you got the sources, but you can just remove the qtvirtualkeyboard directory to avoid it being built. If you’re using Git, you can use –module-subset when initialising the repository to only clone the modules you’re interested in: perl init-repository –module-subset=qtbase,qtblah From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Alexander Nassian Sent: Friday, 14 October 2016 2:00 PM To: development Subject: [Development] Qt build without Virtual Keyboard Hi, We are trying to build 5.7 on Linux without OpenGL support (so no QtQuick either) and are facing a build error in qtvirtualkeyboard „Module quick not found“. Is QtQuick now mandatory, or is this a known bug? And why is the virtual keyboard building at all when choosing L-GPL? That’s not very nice. Beste Grüße / Best regards, Alexander Nassian, bitshift dynamics GmbH -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Oct 14 19:44:32 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 14 Oct 2016 10:44:32 -0700 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <2809753.3jWMvtKoFs@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <20161013184646.GA12416@klara.mpi.htwm.de> <2809753.3jWMvtKoFs@tjmaciei-mobl1> Message-ID: <2121185.59jOQB3Cbf@tjmaciei-mobl1> Em sexta-feira, 14 de outubro de 2016, às 07:10:00 PDT, Thiago Macieira escreveu: > We are talking in this change about QFactoryLoader, which is a Qt API and > which is ALWAYS used until program exit. I meant internal Qt API. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Oct 14 20:07:34 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 14 Oct 2016 11:07:34 -0700 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <2079410.pDXGDJHgfL@tjmaciei-mobl1> Message-ID: <18931950.PnVprxCIGU@tjmaciei-mobl1> Em sexta-feira, 14 de outubro de 2016, às 16:08:27 PDT, Liang Jian escreveu: > I don't care custom plugin, What I care is the plugins loaded by qt > itself, such as qpa plugin, images format plugins ..., These plugins are > needed for all qt programs, we can't avoid the leaks caused by not > unloading these plugins if my understanding to this issue is right (Maybe > you don't think that are leaks but they will confuse memory leak detector), > that is why I hope to introduce a method to disable this feature at runtime. What do you prefer? 1) leak 2) crash and leak Either way, the dlclose() call will not happen. Note that this has nothing to do with freeing memory. Only the dlclose(). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Oct 15 00:39:01 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 14 Oct 2016 15:39:01 -0700 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <18931950.PnVprxCIGU@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <18931950.PnVprxCIGU@tjmaciei-mobl1> Message-ID: <5297331.pGBk19uQGM@tjmaciei-mobl1> Em sexta-feira, 14 de outubro de 2016, às 11:07:34 PDT, Thiago Macieira escreveu: > What do you prefer? > > 1) leak > 2) crash and leak > > Either way, the dlclose() call will not happen. > > Note that this has nothing to do with freeing memory. Only the dlclose(). Actually, there's no distinction: both are leaks when the process exits. The only difference is the cause of the exit: it's either a clean exit by returning from main, or a crash. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jianliang79 at gmail.com Sat Oct 15 09:33:53 2016 From: jianliang79 at gmail.com (Liang Jian) Date: Sat, 15 Oct 2016 15:33:53 +0800 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <18931950.PnVprxCIGU@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <2079410.pDXGDJHgfL@tjmaciei-mobl1> <18931950.PnVprxCIGU@tjmaciei-mobl1> Message-ID: Yes, you are right. After applying the patch from https://codereview.qt-project.org/#/c/140750/ I didn't notice any leak report under Windows. Sorry for the noise. But I am still curious about that If we don't unload the plugin, will the destructor of the gobal object in it be called? If it is not called, what if the gobal object of the plugin hold some memory allocated from heap? On Sat, Oct 15, 2016 at 2:07 AM, Thiago Macieira wrote: > Em sexta-feira, 14 de outubro de 2016, às 16:08:27 PDT, Liang Jian > escreveu: > > I don't care custom plugin, What I care is the plugins loaded by qt > > itself, such as qpa plugin, images format plugins ..., These plugins are > > needed for all qt programs, we can't avoid the leaks caused by not > > unloading these plugins if my understanding to this issue is right (Maybe > > you don't think that are leaks but they will confuse memory leak > detector), > > that is why I hope to introduce a method to disable this feature at > runtime. > > What do you prefer? > > 1) leak > 2) crash and leak > > Either way, the dlclose() call will not happen. > > Note that this has nothing to do with freeing memory. Only the dlclose(). > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Oct 15 17:48:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 15 Oct 2016 08:48:11 -0700 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <18931950.PnVprxCIGU@tjmaciei-mobl1> Message-ID: <2437802.tIXx3s0NCJ@tjmaciei-mobl1> Em sábado, 15 de outubro de 2016, às 15:33:53 PDT, Liang Jian escreveu: > But I am still curious about that If we don't unload the plugin, will > the destructor of the gobal object in it be called? If it is not called, > what if the gobal object of the plugin hold some memory allocated from heap? It's easy to test. In any case, I don't consider leaks those that happen because the memory wasn't freed at program exit while holding a pointer to it. In fact, neither does valgrind: those are "still reachable" allocations. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jianliang79 at gmail.com Sun Oct 16 11:51:45 2016 From: jianliang79 at gmail.com (Liang Jian) Date: Sun, 16 Oct 2016 17:51:45 +0800 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <2437802.tIXx3s0NCJ@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <18931950.PnVprxCIGU@tjmaciei-mobl1> <2437802.tIXx3s0NCJ@tjmaciei-mobl1> Message-ID: I would not to say "still reachable" simply means the allocation is not leaked. Think about the following senario: A programer allocate a big chunk of memory from heap and hold it in a global variable, supposed that by design this memory chunk will not used any more at some point and is aimed to be released to save memory, but the programmer forget to free it, this memory will be considered "still reachable" on exit but the fact is that this behaviour do harm to the program since it will waste more memory when running the program. This allocation should be considered as leak. Maybe the "still reachable" memory allocations caused by not destructing global variables of qt plugin will not do any harm to qt app, but others may do harm, how can we easily distinguish the bad ones from the good ones? I think the best approach is to make sure we release all memory allocated from heap on exit. BTW, not every memory leak detector can tell you which memory is "still reachable", I used bulitin memory leak detector of debug version of msvcrt, inspector from Intel and C++ memory leak detector from softwareverify.com, they don't have the concept of "still reachable". Anyway, I still consider that we should introduce a method to disable the not unloading qt plugin feature at runtime, maybe we can only disable this feature in a developer build of qt and that will not cause any crash in a release build. On Sat, Oct 15, 2016 at 11:48 PM, Thiago Macieira wrote: > Em sábado, 15 de outubro de 2016, às 15:33:53 PDT, Liang Jian escreveu: > > But I am still curious about that If we don't unload the plugin, will > > the destructor of the gobal object in it be called? If it is not called, > > what if the gobal object of the plugin hold some memory allocated from > heap? > > It's easy to test. > > In any case, I don't consider leaks those that happen because the memory > wasn't freed at program exit while holding a pointer to it. In fact, > neither > does valgrind: those are "still reachable" allocations. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Oct 16 17:23:42 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 16 Oct 2016 08:23:42 -0700 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <2437802.tIXx3s0NCJ@tjmaciei-mobl1> Message-ID: <67122258.v0Ph2PMzyz@tjmaciei-mobl1> Em domingo, 16 de outubro de 2016, às 17:51:45 PDT, Liang Jian escreveu: > I would not to say "still reachable" simply means the allocation is not > leaked. Doesn't matter. I won't fix a leak something that happened *only* because the application exited. For me, a legitimate leak requires that the operation be repeatable and cause increased memory usage on each repeat. If you can't repaet the operation, then I won't fix it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Mon Oct 17 11:12:23 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 17 Oct 2016 09:12:23 +0000 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <18931950.PnVprxCIGU@tjmaciei-mobl1> <2437802.tIXx3s0NCJ@tjmaciei-mobl1>, Message-ID: Liang Jian said: > I would not to say "still reachable" simply means the allocation is > not leaked. Whether you call it a leak or not is just a matter of labelling; what matters is resource use. Does it increase without limit ? If it doesn't, I'm not too fussed whether you call it a leak: it would, of course, be nice to use less of any resource, but a bounded amount of one-off resource use (that exit() releases) isn't a big deal (unless it's a very big allocation). > Think about the following senario: A programer allocate a big chunk > of memory from heap and hold it in a global variable, supposed that by > design this memory chunk will not used any more at some point and is > aimed to be released to save memory, but the programmer forget to free > it, this memory will be considered "still reachable" on exit but the > fact is that this behaviour do harm to the program since it will waste > more memory when running the program. This allocation should be > considered as leak. It is, of course, always desirable to release memory once one can: however, this is not so desirable as to make it worth crashing to catch every last byte. > Maybe the "still reachable" memory allocations caused by not > destructing global variables of qt plugin will not do any harm to qt > app, but others may do harm, how can we easily distinguish the bad > ones from the good ones? I think the best approach is to make sure we > release all memory allocated from heap on exit. The only value of doing deallocations on exit is to make it possible to catch leaks; and good leak-detection tools distinguish between still-referenced resources and resources the program has allocated and forgotten the details it would need in order to release. In any case, as long as a given still-held-on-exit resource shall be released by exit (and there's only one of it), one can record this in prior runs and ignore it in the tool's reports for later runs. ISTR valgrind can even be configured to filter out expected leaks, so that the ignoring is automatic. While it is good hygiene to make sure one *has* kept track of the means to release all resources allocated - and one can most robustly be sure of this by actually releasing them - it is not really necessary to release all resources, when exit takes care of doing that for you. The problem isn't that we're holding onto resources on exit; it's that we're using more resources than we should; and this - as Thiago points out - isn't really a big deal unless there's a way for it to cycle, adding ever more allocations that won't be released. > BTW, not every memory leak detector can tell you which memory is > "still reachable", I used bulitin memory leak detector of debug > version of msvcrt, inspector from Intel and C++ memory leak detector > from softwareverify.com, they don't have > the concept of "still reachable". Then they're failing at an important part of what their tool should be doing. Encourage them to do better, or switch to Valgrind (which is free, as in liberty, and not just gratis for the first thirty days). > Anyway, I still consider that we should introduce a method to > disable the not unloading qt plugin feature at runtime, maybe we can > only disable this feature in a developer build of qt and that will not > cause any crash in a release build. Introducing a method to dlclose() won't save you from leaks on exit; it'll just make exit happen at some random earlier time, before the user asked for it, when some attempt is made to (release or) exercise a resource created by the plugin, on finding that the method to do that (or some static data it needs to reference while doing it) has been unloaded. So the resource can't be released - you can crash trying, or not try. It *is* frustrating: plugin architectures where you can load and unload do make it possible to upgrade plugins on the fly, which is a very cool thing to do in a long-running application. (I've worked with the code to do this in a web server, for example - we had a process that aimed for (and delivered) uptimes measured in years; getting it to handle DST transitions in its log files was one of the fun riddles I got to solve - so being able to use later releases of a plugin was actually quite important.) The design constraints that make that possible, however, tend to limit one's freedom to do creative O-O things with the plugins (that web server was written in C); maybe it'd be possible to design a better plugin architecture, but we're stuck with one that can't unload safely. Too many things it's reasonable for a plugin author to do (in C++) are apt to make unloading fatal - and we have lots of crash bugs to prove it, Eddy. From marc.mutz at kdab.com Mon Oct 17 11:23:29 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 17 Oct 2016 11:23:29 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: References: <7496830.S3jACJtUcN@tjmaciei-mobl1> Message-ID: <201610171123.29579.marc.mutz@kdab.com> On Monday 17 October 2016 11:12:23 Edward Welbourne wrote: > Liang Jian said: > > I would not to say "still reachable" simply means the allocation is > > > > not leaked. > > Whether you call it a leak or not is just a matter of labelling; what > matters is resource use. Does it increase without limit ? If it > doesn't, I'm not too fussed whether you call it a leak: it would, of > course, be nice to use less of any resource, but a bounded amount of > one-off resource use (that exit() releases) isn't a big deal (unless > it's a very big allocation). Please don't equate 'resource' with 'memory'. Memory is just one of many resources a program may have acquired, and the _only_ resource which does not need to be released at program exit. 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 Mon Oct 17 11:33:27 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 17 Oct 2016 09:33:27 +0000 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <201610171123.29579.marc.mutz@kdab.com> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> , <201610171123.29579.marc.mutz@kdab.com> Message-ID: Marc Mutz > Please don't equate 'resource' with 'memory'. Memory is just one of many > resources a program may have acquired, and the _only_ resource which does not > need to be released at program exit. Open file descriptors ? There may be others, but that's the one I tend to think of. ... and I did qualify with "that gets released on exit" language. Eddy. From annulen at yandex.ru Mon Oct 17 11:41:25 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 17 Oct 2016 12:41:25 +0300 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: References: <7496830.S3jACJtUcN@tjmaciei-mobl1> , <201610171123.29579.marc.mutz@kdab.com> Message-ID: <19091476697285@web11j.yandex.ru> 17.10.2016, 12:33, "Edward Welbourne" : > Marc Mutz >>  Please don't equate 'resource' with 'memory'. Memory is just one of many >>  resources a program may have acquired, and the _only_ resource which does not >>  need to be released at program exit. > > Open file descriptors ? Open file descriptors are closed by OS automatically when process exits. There are kinds of resources that can really leak though, e.g. named semaphores > There may be others, but that's the one I tend to think of. > ... and I did qualify with "that gets released on exit" language. > >         Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From giuseppe.dangelo at kdab.com Mon Oct 17 12:49:22 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 17 Oct 2016 12:49:22 +0200 Subject: [Development] Multiple Qt branches on Coverity Scan In-Reply-To: <60230af5-6864-a457-1c2c-2b8b3c00bde6@kdab.com> References: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> <3265007.irYWg5TUYC@tjmaciei-mobl1> <19429814.F5arqcLjF3@tjmaciei-mobl1> <7e837239-7161-c168-e8e6-ff6948ac4126@kdab.com> <60230af5-6864-a457-1c2c-2b8b3c00bde6@kdab.com> Message-ID: Il 13/10/2016 15:11, Giuseppe D'Angelo ha scritto: > "qt-project-lts" is going to be 5.6. The new branch should be ready soon > (was told yesterday afternoon, actually), I'll send an email when this > is done. Aaand we're live. I've just successfully uploaded a build: https://scan.coverity.com/projects/qt-project-lts I copied the ACLs from the existing qt-project one, it's up to us to keep them in sync (or not in sync, for any reason). The CIDs also seem to be shared, with some already commented upon. 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 giuseppe.dangelo at kdab.com Mon Oct 17 13:32:04 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 17 Oct 2016 13:32:04 +0200 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <2121185.59jOQB3Cbf@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <20161013184646.GA12416@klara.mpi.htwm.de> <2809753.3jWMvtKoFs@tjmaciei-mobl1> <2121185.59jOQB3Cbf@tjmaciei-mobl1> Message-ID: <79c8d1a2-bf17-fd71-ad8c-8eda4902b38d@kdab.com> Il 14/10/2016 19:44, Thiago Macieira ha scritto: >> > We are talking in this change about QFactoryLoader, which is a Qt API and >> > which is ALWAYS used until program exit. > > I meant internal Qt API. ... doesn't this sound like a declaration that we're not able to have internal Qt APIs for Qt plugins that are good enough for having the plugins clean up after themselves, and be able to be unloaded without crashing? Anyhow, I've outlined a plan in my other email. 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 thiago.macieira at intel.com Mon Oct 17 14:46:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Oct 2016 05:46:09 -0700 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <201610171123.29579.marc.mutz@kdab.com> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <201610171123.29579.marc.mutz@kdab.com> Message-ID: <24210981.ylRHlpopEI@tjmaciei-mobl1> Em segunda-feira, 17 de outubro de 2016, às 11:23:29 PDT, Marc Mutz escreveu: > Please don't equate 'resource' with 'memory'. Memory is just one of many > resources a program may have acquired, and the _only_ resource which does > not need to be released at program exit. Well, no. It does not need to close file descriptors either, they are closed by the OS. In fact, most OS resources are automatically freed when the application exits, though on Unix systems that's usually associated with file descriptors, such as file locks. It may have to do the proper shutdown protocol on them, be it save the proper data, send the proper disconnection information on a socket or remove temporary files. But there are a couple of file descriptors applications seldom ever close, like stdin, stdout and stderr. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Oct 17 14:48:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Oct 2016 05:48:11 -0700 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <79c8d1a2-bf17-fd71-ad8c-8eda4902b38d@kdab.com> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <2121185.59jOQB3Cbf@tjmaciei-mobl1> <79c8d1a2-bf17-fd71-ad8c-8eda4902b38d@kdab.com> Message-ID: <1592215.lPMrW86TcE@tjmaciei-mobl1> Em segunda-feira, 17 de outubro de 2016, às 13:32:04 PDT, Giuseppe D'Angelo escreveu: > Il 14/10/2016 19:44, Thiago Macieira ha scritto: > >> > We are talking in this change about QFactoryLoader, which is a Qt API > >> > and > >> > which is ALWAYS used until program exit. > > > > I meant internal Qt API. > > ... doesn't this sound like a declaration that we're not able to have > internal Qt APIs for Qt plugins that are good enough for having the > plugins clean up after themselves, and be able to be unloaded without > crashing? Correct. Sure, it's each plugin's fault -- especially the NM bearer plugin -- but I don't have time to figure out everything that's wrong with it. I'd rather apply this hammer to the problem than leave applications crashing on exit. > Anyhow, I've outlined a plan in my other email. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Mon Oct 17 14:50:04 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 17 Oct 2016 15:50:04 +0300 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <1592215.lPMrW86TcE@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <2121185.59jOQB3Cbf@tjmaciei-mobl1> <79c8d1a2-bf17-fd71-ad8c-8eda4902b38d@kdab.com> <1592215.lPMrW86TcE@tjmaciei-mobl1> Message-ID: <1541161476708604@web7h.yandex.ru> 17.10.2016, 15:48, "Thiago Macieira" : > Em segunda-feira, 17 de outubro de 2016, às 13:32:04 PDT, Giuseppe D'Angelo > escreveu: >>  Il 14/10/2016 19:44, Thiago Macieira ha scritto: >>  >> > We are talking in this change about QFactoryLoader, which is a Qt API >>  >> > and >>  >> > which is ALWAYS used until program exit. >>  > >>  > I meant internal Qt API. >> >>  ... doesn't this sound like a declaration that we're not able to have >>  internal Qt APIs for Qt plugins that are good enough for having the >>  plugins clean up after themselves, and be able to be unloaded without >>  crashing? > > Correct. > > Sure, it's each plugin's fault -- especially the NM bearer plugin -- but I > don't have time to figure out everything that's wrong with it. I'd rather apply > this hammer to the problem than leave applications crashing on exit. > >>  Anyhow, I've outlined a plan in my other email. It may make sense to add generic API for plugin to report if it can be safely dlclosed(), by default everything is unsafe -- Regards, Konstantin From thiago.macieira at intel.com Mon Oct 17 15:27:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 17 Oct 2016 06:27:13 -0700 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <1541161476708604@web7h.yandex.ru> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <1592215.lPMrW86TcE@tjmaciei-mobl1> <1541161476708604@web7h.yandex.ru> Message-ID: <3328573.ox3DVGQYNZ@tjmaciei-mobl1> Em segunda-feira, 17 de outubro de 2016, às 15:50:04 PDT, Konstantin Tokarev escreveu: > 17.10.2016, 15:48, "Thiago Macieira" : > > Em segunda-feira, 17 de outubro de 2016, às 13:32:04 PDT, Giuseppe > > D'Angelo > > > > escreveu: > >> Il 14/10/2016 19:44, Thiago Macieira ha scritto: > >> >> > We are talking in this change about QFactoryLoader, which is a Qt > >> API > >> >> > and > >> >> > which is ALWAYS used until program exit. > >> > > >> > I meant internal Qt API. > >> > >> ... doesn't this sound like a declaration that we're not able to have > >> internal Qt APIs for Qt plugins that are good enough for having the > >> plugins clean up after themselves, and be able to be unloaded without > >> crashing? > > > > Correct. > > > > Sure, it's each plugin's fault -- especially the NM bearer plugin -- but I > > don't have time to figure out everything that's wrong with it. I'd rather > > apply this hammer to the problem than leave applications crashing on > > exit.> > >> Anyhow, I've outlined a plan in my other email. > > It may make sense to add generic API for plugin to report if it can be > safely dlclosed(), by default everything is unsafe Please read again the email that Peppe replied to: This is about QFactoryLoader, which is loads plugins at application starts and NEVER attempts to close them anyway. The only time we'd try to unload is at application exit, which is exactly when it doesn't matter because we're exiting anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lars.knoll at qt.io Mon Oct 17 16:46:29 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 17 Oct 2016 14:46:29 +0000 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <3328573.ox3DVGQYNZ@tjmaciei-mobl1> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <1592215.lPMrW86TcE@tjmaciei-mobl1> <1541161476708604@web7h.yandex.ru> <3328573.ox3DVGQYNZ@tjmaciei-mobl1> Message-ID: <17677B3D-B809-4268-81A2-80DA18D1A8C3@qt.io> On 17 Oct 2016, at 15:27, Thiago Macieira > wrote: Em segunda-feira, 17 de outubro de 2016, às 15:50:04 PDT, Konstantin Tokarev escreveu: 17.10.2016, 15:48, "Thiago Macieira" >: Em segunda-feira, 17 de outubro de 2016, às 13:32:04 PDT, Giuseppe D'Angelo escreveu: Il 14/10/2016 19:44, Thiago Macieira ha scritto: We are talking in this change about QFactoryLoader, which is a Qt API and which is ALWAYS used until program exit. I meant internal Qt API. ... doesn't this sound like a declaration that we're not able to have internal Qt APIs for Qt plugins that are good enough for having the plugins clean up after themselves, and be able to be unloaded without crashing? Correct. Sure, it's each plugin's fault -- especially the NM bearer plugin -- but I don't have time to figure out everything that's wrong with it. I'd rather apply this hammer to the problem than leave applications crashing on exit.> Anyhow, I've outlined a plan in my other email. It may make sense to add generic API for plugin to report if it can be safely dlclosed(), by default everything is unsafe Please read again the email that Peppe replied to: This is about QFactoryLoader, which is loads plugins at application starts and NEVER attempts to close them anyway. The only time we'd try to unload is at application exit, which is exactly when it doesn't matter because we're exiting anyway. I have to agree with Thiago. For QFactoryLoader, it doesn't make a lot of sense to try to unload the plugins, as we only do that on program exit. It would be great to make plugins safe to unload, but we all know that this is tricky to get right. In addition, we don't even control all the plugins we might be loading (thing about additional image formats of styles provided by others), so we have no way of knowing whether we can safely unload the plugin. So I think it's the right thing to change this in 5.6 and not unload those plugins on app exit. Cheers, Lars -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitya57.ml at gmail.com Mon Oct 17 18:46:05 2016 From: mitya57.ml at gmail.com (Dmitry Shachnev) Date: Mon, 17 Oct 2016 19:46:05 +0300 Subject: [Development] Searching for a better place for dbusmenu/dbustray code Message-ID: <20161017164605.rgxpliutzfexyxbm@mitya57.me> Hi all, In QTBUG-55310 [1], we have been discussing the ways on how to make it possible to use our dbusmenu/dbustray implementations on platforms which have their own platform themes (such as Plasma and LXQt). Ideally QSystemTrayIcon (and QMenuBar) should try to use these implementations if the platform themes do not provide their own ones. The first thing that comes to mind is putting this code into QtWidgets library. A side effect of this will be the QtWidgets -> QtDBus dependency, which I think is not acceptable. Currently (since [2]) this code is built as part of static QtThemeSupport library, which is then linked into the Qt5XcbQpa library and into the gtk3 theme plugin. (Another reason why this is bad is duplication of the same code between different libraries.) I propose to make it a separate plugin, linked against QtDBus, which then will be loaded by QtWidgets. In this case I have some questions (copied to here from QTBUG-55310): 1) Where will it make sense to put the plugin? Should I create a separate directory for it in plugins/? Or maybe I can put it in plugins/generic/? 2) So far the only way to load plugins I found is using QFactoryLoader. Should I use it, or is there a more simple way, provided that the plugin will be the only one of its type? If anyone can suggest an alternative to splitting that code into its own plugin, that would be welcome too. [1]: https://bugreports.qt.io/browse/QTBUG-55310 [2]: https://codereview.qt-project.org/172484 Cheers, -- Dmitry Shachnev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From fredrik.devibe at qt.io Tue Oct 18 13:03:51 2016 From: fredrik.devibe at qt.io (Fredrik de Vibe) Date: Tue, 18 Oct 2016 13:03:51 +0200 Subject: [Development] Qt Network Maintainership Changes In-Reply-To: References: Message-ID: <228cf137-ea58-11a5-1172-1d430c761a32@qt.io> Hi all, On 09/06/2016 09:05 PM, Richard Moore wrote: > As some of you may know, I'm planning to step down as maintainer of Qt > Network. This is because now that the Qt company has people in a > position to work on the network stack full time I think it makes much > more sense for them to be the maintainer - it doesn't mean I'll be > moving away from working on Qt (in fact I hope it will mean I'll have > more time to actually get things done as a result). I'd like to nominate > Timur as my replacement - he's already spent an inordinate amount of > time fixing bugs, to say nothing of adding support for HTTP/2 so I'm > sure things are in good hands. ... > On a similar note, I'd like to nominate Jesús Fernández as the > maintainer of the QtNetworkAuth module - he wrote it after all! As by now 15 days (and more) have passed since the announcement, it is now final. Timur is now the maintainer of Qt Network and Jesús is the maintainer of Qt NetworkAuth. The wiki has been updated. A big thanks to Rich and Peter for all the work they have put into Qt Network, their continued contributions are most appreciated! Cheers, - Fredrik - From fabizs at yahoo.com Tue Oct 18 20:47:20 2016 From: fabizs at yahoo.com (Fabio Santos) Date: Tue, 18 Oct 2016 18:47:20 +0000 (UTC) Subject: [Development] Build Qt on Solaris 10 Fail References: <826733019.2818755.1476816441000.ref@mail.yahoo.com> Message-ID: <826733019.2818755.1476816441000@mail.yahoo.com> Hi all, I'm new here and trying to compile Qt on solaris sparc 10, But I receive a error during gmake command, see: CC -c -mt -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -xldscope=hidden -mt -I/usr/sfw/include -I/usr/sfw/include/freetype2 -KPIC -DQT_SHARED -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_S60 -DQ_INTERNAL_QAPP_SRC -DQT_NO_DEBUG -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/solaris-cc -I. -I../../include/QtCore -I../../include -I../../include/QtGui -I.rcc/release-shared -I../3rdparty/xorg -Iimage -I/usr/sfw/include/freetype2 -I../3rdparty/harfbuzz/src -Idialogs -I.moc/release-shared -I/usr/openwin/share/include -I.uic/release-shared -I/usr/sfw/include -o .obj/release-shared/qapplication.o kernel/qapplication.cpp"../../include/QtGui/private/../../../src/gui/painting/qpaintengine_raster_p.h", line 292: Warning: QRasterPaintEngine::clip hides the virtual function QPaintEngineEx::clip(const QPainterPath&, Qt::ClipOperation)."../../include/QtGui/private/../../../src/gui/painting/qpaintengine_raster_p.h", line 292: Warning: QRasterPaintEngine::updateState hides the virtual function QPaintEngineEx::updateState(const QPaintEngineState&)."../../include/QtGui/private/../../../src/gui/painting/qpaintengine_blitter_p.h", line 56: Warning: extra ";" ignored."../../include/QtGui/private/../../../src/gui/painting/qpaintengine_blitter_p.h", line 99: Warning: QBlitterPaintEngine::drawEllipse hides the virtual function QPaintEngineEx::drawEllipse(const QRect&)."../../include/QtCore/private/../../../src/corelib/thread/qthread_p.h", line 285: Warning: threadData hides QScopedLoopLevelCounter::threadData."kernel/qapplication.cpp", line 3168: Error: Overloading ambiguity between "operator!=(const QPointer&, QWidget*)" and "operator!=(const QPointer&, const QWidget*)"."kernel/qapplication.cpp", line 3168: Error: Overloading ambiguity between "operator!=(const QPointer&, QWidget*)" and "operator!=(const QPointer&, const QWidget*)".2 Error(s) and 5 Warning(s) detected.gmake[1]: *** [.obj/release-shared/qapplication.o] Error 2gmake[1]: Leaving directory `/tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/src/gui'gmake: *** [sub-gui-make_default-ordered] Error 2You have new mail in /var/mail/rootbash-3.2# Someone can help me? -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Tue Oct 18 20:51:39 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 18 Oct 2016 21:51:39 +0300 Subject: [Development] Build Qt on Solaris 10 Fail In-Reply-To: <826733019.2818755.1476816441000@mail.yahoo.com> References: <826733019.2818755.1476816441000.ref@mail.yahoo.com> <826733019.2818755.1476816441000@mail.yahoo.com> Message-ID: <5619181476816699@web4j.yandex.ru> 18.10.2016, 21:47, "Fabio Santos via Development" : > Hi all, > > I'm new here and trying to compile Qt on solaris sparc 10, But I receive a error during gmake command, see: I think CC is not supported, it's a very peculiar C++ compiler and it does not have C++11 support. Please use GCC instead. > > CC -c -mt -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -xldscope=hidden -mt -I/usr/sfw/include -I/usr/sfw/include/freetype2 -KPIC -DQT_SHARED -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_S60 -DQ_INTERNAL_QAPP_SRC -DQT_NO_DEBUG -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/solaris-cc -I. -I../../include/QtCore -I../../include -I../../include/QtGui -I.rcc/release-shared -I../3rdparty/xorg -Iimage -I/usr/sfw/include/freetype2 -I../3rdparty/harfbuzz/src -Idialogs -I.moc/release-shared -I/usr/openwin/share/include -I.uic/release-shared -I/usr/sfw/include -o .obj/release-shared/qapplication.o kernel/qapplication.cpp > "../../include/QtGui/private/../../../src/gui/painting/qpaintengine_raster_p.h", line 292: Warning: QRasterPaintEngine::clip hides the virtual function QPaintEngineEx::clip(const QPainterPath&, Qt::ClipOperation). > "../../include/QtGui/private/../../../src/gui/painting/qpaintengine_raster_p.h", line 292: Warning: QRasterPaintEngine::updateState hides the virtual function QPaintEngineEx::updateState(const QPaintEngineState&). > "../../include/QtGui/private/../../../src/gui/painting/qpaintengine_blitter_p.h", line 56: Warning: extra ";" ignored. > "../../include/QtGui/private/../../../src/gui/painting/qpaintengine_blitter_p.h", line 99: Warning: QBlitterPaintEngine::drawEllipse hides the virtual function QPaintEngineEx::drawEllipse(const QRect&). > "../../include/QtCore/private/../../../src/corelib/thread/qthread_p.h", line 285: Warning: threadData hides QScopedLoopLevelCounter::threadData. > "kernel/qapplication.cpp", line 3168: Error: Overloading ambiguity between "operator!=(const QPointer&, QWidget*)" and "operator!=(const QPointer&, const QWidget*)". > "kernel/qapplication.cpp", line 3168: Error: Overloading ambiguity between "operator!=(const QPointer&, QWidget*)" and "operator!=(const QPointer&, const QWidget*)". > 2 Error(s) and 5 Warning(s) detected. > gmake[1]: *** [.obj/release-shared/qapplication.o] Error 2 > gmake[1]: Leaving directory `/tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/src/gui' > gmake: *** [sub-gui-make_default-ordered] Error 2 > You have new mail in /var/mail/root > bash-3.2# > > Someone can help me? > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From fabizs at yahoo.com Tue Oct 18 22:10:07 2016 From: fabizs at yahoo.com (Fabio Santos) Date: Tue, 18 Oct 2016 20:10:07 +0000 (UTC) Subject: [Development] Build Qt on Solaris 10 Fail In-Reply-To: <5619181476816699@web4j.yandex.ru> References: <826733019.2818755.1476816441000.ref@mail.yahoo.com> <826733019.2818755.1476816441000@mail.yahoo.com> <5619181476816699@web4j.yandex.ru> Message-ID: <328016837.2821678.1476821407704@mail.yahoo.com> Hi Kontantin, How can i force to use GCC? Beacuse I set some variables, see: bash-3.2# envHZ=TERM=xtermSHELL=/sbin/shOLDPWD=/tmp/SCI/SuccessfullySPATH=/usr/ccs/bin:/usr/xpg4/bin:/local/lib:/usr/sbin:/usr/sfw/bin:/usr/local/bin:/usr/binMAIL=/var/mail/rootPWD=/tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7TZ=Brazil/EastSHLVL=1HOME=/LOGNAME=rootcc=/usr/local/bin/gccCC=/usr/local/bin/gcc_=/usr/xpg4/bin/envbash-3.2# And change  mkspecs/solaris-cc-64/qmake.conf file: MAKEFILE_GENERATOR      = UNIXTARGET_PLATFORM         = unixTEMPLATE                = appCONFIG                  += qt warn_on release link_prlQT                      += core gui QMAKE_CC                = gccQMAKE_LEX               = flexQMAKE_LEXFLAGS          =QMAKE_YACC              = yaccQMAKE_YACCFLAGS         = -dQMAKE_CFLAGS            = -xarch=generic64QMAKE_CFLAGS_DEPS       = -xMQMAKE_CFLAGS_WARN_ON    =QMAKE_CFLAGS_WARN_OFF   = -wQMAKE_CFLAGS_RELEASE    = -OQMAKE_CFLAGS_DEBUG      = -gQMAKE_CFLAGS_SHLIB      = -KPICQMAKE_CFLAGS_STATIC_LIB = $$QMAKE_CFLAGS_SHLIBQMAKE_CFLAGS_YACC       =QMAKE_CFLAGS_THREAD     = -mtQMAKE_CFLAGS_HIDESYMS   = -xldscope=hidden QMAKE_CXX               = GCCQMAKE_LINK              = GCCQMAKE_LINK_SHLIB        = GCCQMAKE_LFLAGS            = -xarch=generic64QMAKE_LFLAGS_RELEASE    =QMAKE_LFLAGS_DEBUG      =QMAKE_LFLAGS_SHLIB      = -GQMAKE_LFLAGS_PLUGIN     = $$QMAKE_LFLAGS_SHLIBQMAKE_LFLAGS_SONAME     = -h$$LITERAL_WHITESPACEQMAKE_LFLAGS_THREAD     = -mtQMAKE_LFLAGS_NOUNDEF    = -z defsQMAKE_LFLAGS_RPATH      = -R QMAKE_LIBS              =QMAKE_LIBS_DYNLOAD      = -ldlQMAKE_LIBS_X11          = -lXext -lX11 -lresolv -lsocket -lnslQMAKE_LIBS_X11SM        = -lSM -lICEQMAKE_LIBS_NIS          =QMAKE_LIBS_OPENGL       = -lGLQMAKE_LIBS_OPENGL_QT    = -lGLQMAKE_LIBS_THREAD       = -lpthread -lrtQMAKE_LIBS_NETWORK      = -lresolv -lsocket -lxnet -lnsl QMAKE_MOC               = $$[QT_INSTALL_BINS]/mocQMAKE_UIC               = $$[QT_INSTALL_BINS]/uic QMAKE_AR                = GCC -xar -oQMAKE_OBJCOPY           = objcopyQMAKE_RANLIB            = QMAKE_CLEAN             = -r $(OBJECTS_DIR)Templates.DB $(OBJECTS_DIR)SunWS_cache QMAKE_TAR               = tar -cfQMAKE_GZIP              = gzip -9f QMAKE_COPY              = cp -fQMAKE_MOVE              = mv -fQMAKE_DEL_FILE          = rm -fQMAKE_DEL_DIR           = rmdirQMAKE_CHK_DIR_EXISTS    = test -dQMAKE_MKDIR             = mkdir -pinclude(../common/unix.conf) But ./configure remain trying cc... Em Terça-feira, 18 de Outubro de 2016 16:51, Konstantin Tokarev escreveu: 18.10.2016, 21:47, "Fabio Santos via Development" : > Hi all, > > I'm new here and trying to compile Qt on solaris sparc 10, But I receive a error during gmake command, see: I think CC is not supported, it's a very peculiar C++ compiler and it does not have C++11 support. Please use GCC instead. > > CC -c -mt -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -O2 -xldscope=hidden -mt -I/usr/sfw/include -I/usr/sfw/include/freetype2 -KPIC -DQT_SHARED -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_WINDOWSVISTA -DQT_NO_STYLE_WINDOWSXP -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_S60 -DQ_INTERNAL_QAPP_SRC -DQT_NO_DEBUG -DQT_CORE_LIB -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -I../../mkspecs/solaris-cc -I. -I../../include/QtCore -I../../include -I../../include/QtGui -I.rcc/release-shared -I../3rdparty/xorg -Iimage -I/usr/sfw/include/freetype2 -I../3rdparty/harfbuzz/src -Idialogs -I.moc/release-shared -I/usr/openwin/share/include -I.uic/release-shared -I/usr/sfw/include -o .obj/release-shared/qapplication.o kernel/qapplication.cpp > "../../include/QtGui/private/../../../src/gui/painting/qpaintengine_raster_p.h", line 292: Warning: QRasterPaintEngine::clip hides the virtual function QPaintEngineEx::clip(const QPainterPath&, Qt::ClipOperation). > "../../include/QtGui/private/../../../src/gui/painting/qpaintengine_raster_p.h", line 292: Warning: QRasterPaintEngine::updateState hides the virtual function QPaintEngineEx::updateState(const QPaintEngineState&). > "../../include/QtGui/private/../../../src/gui/painting/qpaintengine_blitter_p.h", line 56: Warning: extra ";" ignored. > "../../include/QtGui/private/../../../src/gui/painting/qpaintengine_blitter_p.h", line 99: Warning: QBlitterPaintEngine::drawEllipse hides the virtual function QPaintEngineEx::drawEllipse(const QRect&). > "../../include/QtCore/private/../../../src/corelib/thread/qthread_p.h", line 285: Warning: threadData hides QScopedLoopLevelCounter::threadData. > "kernel/qapplication.cpp", line 3168: Error: Overloading ambiguity between "operator!=(const QPointer&, QWidget*)" and "operator!=(const QPointer&, const QWidget*)". > "kernel/qapplication.cpp", line 3168: Error: Overloading ambiguity between "operator!=(const QPointer&, QWidget*)" and "operator!=(const QPointer&, const QWidget*)". > 2 Error(s) and 5 Warning(s) detected. > gmake[1]: *** [.obj/release-shared/qapplication.o] Error 2 > gmake[1]: Leaving directory `/tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/src/gui' > gmake: *** [sub-gui-make_default-ordered] Error 2 > You have new mail in /var/mail/root > bash-3.2# > > Someone can help me? > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Oct 19 02:09:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 18 Oct 2016 17:09:59 -0700 Subject: [Development] Build Qt on Solaris 10 Fail In-Reply-To: <328016837.2821678.1476821407704@mail.yahoo.com> References: <826733019.2818755.1476816441000.ref@mail.yahoo.com> <5619181476816699@web4j.yandex.ru> <328016837.2821678.1476821407704@mail.yahoo.com> Message-ID: <8954248.T07svmN7AL@tjmaciei-mobl1> On terça-feira, 18 de outubro de 2016 20:10:07 PDT Fabio Santos via Development wrote: > And change mkspecs/solaris-cc-64/qmake.conf file: Don't use solaris-cc-64. Instead, use solaris-g++-64. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From fabizs at yahoo.com Wed Oct 19 17:29:52 2016 From: fabizs at yahoo.com (Fabio Santos) Date: Wed, 19 Oct 2016 15:29:52 +0000 (UTC) Subject: [Development] Build Qt on Solaris 10 Fail In-Reply-To: <8954248.T07svmN7AL@tjmaciei-mobl1> References: <826733019.2818755.1476816441000.ref@mail.yahoo.com> <5619181476816699@web4j.yandex.ru> <328016837.2821678.1476821407704@mail.yahoo.com> <8954248.T07svmN7AL@tjmaciei-mobl1> Message-ID: <1623804893.3512139.1476890992243@mail.yahoo.com> Hi Thiago, Thanks for your help... now I'm using solaris-g++-64  (./configure -platform solaris-g++-64) configure command works fine, but gmake  had problems see: g++ -m64 -Wl,-R,/usr/local/Trolltech/Qt-4.8.7/lib -Wl,-R,/usr/local/Trolltech/Qt-4.8.7/lib -o ../../../bin/uic3 .obj/release-shared/customwidgetsinfo.o .obj/release-shared/databaseinfo.o .obj/release-shared/driver.o .obj/release-shared/treewalker.o .obj/release-shared/ui4.o .obj/release-shared/validator.o .obj/release-shared/cppextractimages.o .obj/release-shared/cppwritedeclaration.o .obj/release-shared/cppwriteicondata.o .obj/release-shared/cppwriteicondeclaration.o .obj/release-shared/cppwriteiconinitialization.o .obj/release-shared/cppwriteincludes.o .obj/release-shared/cppwriteinitialization.o .obj/release-shared/main.o .obj/release-shared/ui3reader.o .obj/release-shared/parser.o .obj/release-shared/domtool.o .obj/release-shared/object.o .obj/release-shared/subclassing.o .obj/release-shared/form.o .obj/release-shared/converter.o .obj/release-shared/widgetinfo.o .obj/release-shared/embed.o .obj/release-shared/qt3to4.o .obj/release-shared/deps.o .obj/release-shared/uic.o    -L/tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/lib -L/usr/sfw/lib/64 -lQt3Support -L/tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/lib -L/usr/sfw/lib/64 -lQtSql -L/usr/openwin/lib/64 -lQtNetwork -lresolv -lsocket -lxnet -lnsl -lQtXml -lQtGui -lQtCore -lpthread -lrtUndefined                       first referenced symbol                             in filepng_set_longjmp_fn                  /tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/lib/libQtGui.sold: fatal: Symbol referencing errors. No output written to ../../../bin/uic3collect2: ld returned 1 exit statusgmake[1]: *** [../../../bin/uic3] Error 1gmake[1]: Leaving directory `/tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/src/tools/uic3'gmake: *** [sub-uic3-make_default-ordered] Error 2You have new mail in /var/mail/rootbash-3.2# Em Terça-feira, 18 de Outubro de 2016 22:10, Thiago Macieira escreveu: On terça-feira, 18 de outubro de 2016 20:10:07 PDT Fabio Santos via Development wrote: > And change  mkspecs/solaris-cc-64/qmake.conf file: Don't use solaris-cc-64. Instead, use solaris-g++-64. -- Thiago Macieira - thiago.macieira (AT) intel.com   Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Wed Oct 19 17:35:15 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 19 Oct 2016 18:35:15 +0300 Subject: [Development] Build Qt on Solaris 10 Fail In-Reply-To: <1623804893.3512139.1476890992243@mail.yahoo.com> References: <826733019.2818755.1476816441000.ref@mail.yahoo.com> <5619181476816699@web4j.yandex.ru> <328016837.2821678.1476821407704@mail.yahoo.com> <8954248.T07svmN7AL@tjmaciei-mobl1> <1623804893.3512139.1476890992243@mail.yahoo.com> Message-ID: <179071476891315@web24o.yandex.ru> 19.10.2016, 18:30, "Fabio Santos via Development" : > Hi Thiago, > > Thanks for your help... now I'm using solaris-g++-64 > > (./configure -platform solaris-g++-64) configure command works fine, but gmake  had problems see: > > g++ -m64 -Wl,-R,/usr/local/Trolltech/Qt-4.8.7/lib -Wl,-R,/usr/local/Trolltech/Qt-4.8.7/lib -o ../../../bin/uic3 .obj/release-shared/customwidgetsinfo.o .obj/release-shared/databaseinfo.o .obj/release-shared/driver.o .obj/release-shared/treewalker.o .obj/release-shared/ui4.o .obj/release-shared/validator.o .obj/release-shared/cppextractimages.o .obj/release-shared/cppwritedeclaration.o .obj/release-shared/cppwriteicondata.o .obj/release-shared/cppwriteicondeclaration.o .obj/release-shared/cppwriteiconinitialization.o .obj/release-shared/cppwriteincludes.o .obj/release-shared/cppwriteinitialization.o .obj/release-shared/main.o .obj/release-shared/ui3reader.o .obj/release-shared/parser.o .obj/release-shared/domtool.o .obj/release-shared/object.o .obj/release-shared/subclassing.o .obj/release-shared/form.o .obj/release-shared/converter.o .obj/release-shared/widgetinfo.o .obj/release-shared/embed.o .obj/release-shared/qt3to4.o .obj/release-shared/deps.o .obj/release-shared/uic.o    -L/tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/lib -L/usr/sfw/lib/64 -lQt3Support -L/tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/lib -L/usr/sfw/lib/64 -lQtSql -L/usr/openwin/lib/64 -lQtNetwork -lresolv -lsocket -lxnet -lnsl -lQtXml -lQtGui -lQtCore -lpthread -lrt > Undefined                       first referenced >  symbol                             in file > png_set_longjmp_fn                  /tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/lib/libQtGui.so It can be that you are somehow using header files from one libpng version and link with other. > ld: fatal: Symbol referencing errors. No output written to ../../../bin/uic3 > collect2: ld returned 1 exit status > gmake[1]: *** [../../../bin/uic3] Error 1 > gmake[1]: Leaving directory `/tmp/SCI/SuccessfullyS/qt-everywhere-opensource-src-4.8.7/src/tools/uic3' > gmake: *** [sub-uic3-make_default-ordered] Error 2 > You have new mail in /var/mail/root > > bash-3.2# > > Em Terça-feira, 18 de Outubro de 2016 22:10, Thiago Macieira escreveu: > > On terça-feira, 18 de outubro de 2016 20:10:07 PDT Fabio Santos via > Development wrote: >> And change  mkspecs/solaris-cc-64/qmake.conf file: > > Don't use solaris-cc-64. Instead, use solaris-g++-64. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Wed Oct 19 19:02:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 19 Oct 2016 10:02:55 -0700 Subject: [Development] Build Qt on Solaris 10 Fail In-Reply-To: <1623804893.3512139.1476890992243@mail.yahoo.com> References: <826733019.2818755.1476816441000.ref@mail.yahoo.com> <8954248.T07svmN7AL@tjmaciei-mobl1> <1623804893.3512139.1476890992243@mail.yahoo.com> Message-ID: <32154597.nVzcKKpp9X@tjmaciei-mobl1> On quarta-feira, 19 de outubro de 2016 15:29:52 PDT Fabio Santos via Development wrote: > Hi Thiago, > Thanks for your help... now I'm using solaris-g++-64 > (./configure -platform solaris-g++-64) configure command works fine, but > gmake had problems see: > > g++ -m64 -Wl,-R,/usr/local/Trolltech/Qt-4.8.7/lib You're compiling Qt 4. This is the mailing list to discuss the development of (not development with) Qt 5. Qt 4 is not being developed anymore. Even for just developing applications, you should upgrade . -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lorn.potter at canonical.com Thu Oct 20 07:39:44 2016 From: lorn.potter at canonical.com (Lorn Potter) Date: Thu, 20 Oct 2016 07:39:44 +0200 Subject: [Development] Qt Network Maintainership Changes In-Reply-To: <228cf137-ea58-11a5-1172-1d430c761a32@qt.io> References: <228cf137-ea58-11a5-1172-1d430c761a32@qt.io> Message-ID: <37e4f998-e497-81ca-33ed-0dd271294d2d@canonical.com> On 18/10/16 13:03, Fredrik de Vibe wrote: > As by now 15 days (and more) have passed since the announcement, it is > now final. Timur is now the maintainer of Qt Network and Jesús is the > maintainer of Qt NetworkAuth. The wiki has been updated. Congrats guys! :) Looking forward to working with you on bearer/access and what ever else I can help on. > > A big thanks to Rich and Peter for all the work they have put into Qt > Network, their continued contributions are most appreciated! +2 -- Software Engineer System Enablement, Canonical Ltd QtSystemInfo, QtSensors maintainer From philwave at gmail.com Thu Oct 20 17:28:39 2016 From: philwave at gmail.com (Philippe) Date: Thu, 20 Oct 2016 17:28:39 +0200 Subject: [Development] std::atomic Message-ID: <20161020172838.DDD3.6F0322A@gmail.com> std::atomic is used as underlying implementation for the the Qt atomic API with CLang on Mac. But why not with Visual Studio 2015? You will certainly mention some bug, but then where is the problem? (shortly) Thanks Philippe From olivier at woboq.com Thu Oct 20 18:55:12 2016 From: olivier at woboq.com (Olivier Goffart) Date: Thu, 20 Oct 2016 18:55:12 +0200 Subject: [Development] std::atomic In-Reply-To: <20161020172838.DDD3.6F0322A@gmail.com> References: <20161020172838.DDD3.6F0322A@gmail.com> Message-ID: <1809693.F48pRg2Ut2@maurice> On Donnerstag, 20. Oktober 2016 17:28:39 CEST Philippe wrote: > std::atomic is used as underlying implementation for the the Qt atomic > API with CLang on Mac. > But why not with Visual Studio 2015? You will certainly mention some bug, > but then where is the problem? (shortly) The answer is in qbasicatomic.h // We only support one fallback: MSVC, because even on version 2015, it lacks full constexpr support #elif defined(Q_CC_MSVC) # include https://code.woboq.org/qt5/qtbase/src/corelib/thread/qbasicatomic.h.html#55 We need constexpr because we want QBasicAtomic to be a statically initialized, which can only be achieved with literal type. (Which means we need constexpr support to be able to use std::atomic) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Thu Oct 20 22:43:39 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 20 Oct 2016 13:43:39 -0700 Subject: [Development] std::atomic In-Reply-To: <20161020172838.DDD3.6F0322A@gmail.com> References: <20161020172838.DDD3.6F0322A@gmail.com> Message-ID: <1549487.v67b2cB2iU@tjmaciei-mobl1> Em quinta-feira, 20 de outubro de 2016, às 17:28:39 PDT, Philippe escreveu: > std::atomic is used as underlying implementation for the the Qt atomic > API with CLang on Mac. > But why not with Visual Studio 2015? You will certainly mention some bug, > but then where is the problem? (shortly) Because the Microsoft compiler does not support constexpr properly. See https://connect.microsoft.com/VisualStudio/feedback/details/2011648 I haven't tested Update 3 to see if that is fixed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sergio.martins at kdab.com Fri Oct 21 00:11:58 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 20 Oct 2016 23:11:58 +0100 Subject: [Development] std::atomic In-Reply-To: <1549487.v67b2cB2iU@tjmaciei-mobl1> References: <20161020172838.DDD3.6F0322A@gmail.com> <1549487.v67b2cB2iU@tjmaciei-mobl1> Message-ID: On 2016-10-20 21:43, Thiago Macieira wrote: > Em quinta-feira, 20 de outubro de 2016, às 17:28:39 PDT, Philippe > escreveu: >> std::atomic is used as underlying implementation for the the Qt atomic >> API with CLang on Mac. >> But why not with Visual Studio 2015? You will certainly mention some >> bug, >> but then where is the problem? (shortly) > > Because the Microsoft compiler does not support constexpr properly. See > https://connect.microsoft.com/VisualStudio/feedback/details/2011648 > > I haven't tested Update 3 to see if that is fixed. Do you have a testcase for this bug ? I couldn't reproduce with Update2 by using a class with constexpr ctor and an array member, so I think I'm not testing it correctly. 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 fromqt at tungware.se Fri Oct 21 00:37:19 2016 From: fromqt at tungware.se (Henry Skoglund) Date: Fri, 21 Oct 2016 00:37:19 +0200 Subject: [Development] std::atomic In-Reply-To: References: <20161020172838.DDD3.6F0322A@gmail.com> <1549487.v67b2cB2iU@tjmaciei-mobl1> Message-ID: <9036c842-1bcb-2542-a132-a26d7c07b440@tungware.se> On 2016-10-21 00:11, Sergio Martins wrote: > On 2016-10-20 21:43, Thiago Macieira wrote: >> Em quinta-feira, 20 de outubro de 2016, às 17:28:39 PDT, Philippe >> escreveu: >>> std::atomic is used as underlying implementation for the the Qt atomic >>> API with CLang on Mac. >>> But why not with Visual Studio 2015? You will certainly mention some >>> bug, >>> but then where is the problem? (shortly) >> >> Because the Microsoft compiler does not support constexpr properly. See >> https://connect.microsoft.com/VisualStudio/feedback/details/2011648 >> >> I haven't tested Update 3 to see if that is fixed. > > Do you have a testcase for this bug ? > I couldn't reproduce with Update2 by using a class with constexpr ctor > and an array member, so I think I'm not testing it correctly. If you click on "DETAILS" there is a testcase attached. Also, I just tested on Visual Studio 2015 Update 3 and it still fails. /Rgrds Henry From thiago.macieira at intel.com Fri Oct 21 07:54:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 20 Oct 2016 22:54:08 -0700 Subject: [Development] std::atomic In-Reply-To: References: <20161020172838.DDD3.6F0322A@gmail.com> <1549487.v67b2cB2iU@tjmaciei-mobl1> Message-ID: <2612487.DWT3fnp5lW@tjmaciei-mobl1> Em quinta-feira, 20 de outubro de 2016, às 23:11:58 PDT, Sergio Martins escreveu: > > Because the Microsoft compiler does not support constexpr properly. See > > https://connect.microsoft.com/VisualStudio/feedback/details/2011648 > > > > I haven't tested Update 3 to see if that is fixed. > > Do you have a testcase for this bug ? The proper testcase is to uncomment that line and compile Qt. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Fri Oct 21 08:27:29 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 21 Oct 2016 06:27:29 +0000 Subject: [Development] Qt 5.7.1 snapshot available Message-ID: Hi all, We have new Qt 5.7.1 snapshot available Linux: http://download.qt.io/snapshots/qt/5.7/5.7.1/524/ Mac: http://download.qt.io/snapshots/qt/5.7/5.7.1/491/ Windows: http://download.qt.io/snapshots/qt/5.7/5.7.1/592/ src: http://download.qt.io/snapshots/qt/5.7/5.7.1/latest_src/ These aren't yet final Qt 5.71 packages but pretty close so please test the packages to see how close the release we are. The target is to release Qt 5.7.1 during October; let's see after we get the packages tested. So please make sure all blockers are visible in 5.7.1 release blocker list: https://bugreports.qt.io/issues/?filter=17833 Please also update Qt 5.7.1 known issues list if needed: https://wiki.qt.io/Qt_5.7.1_Known_Issues We already started to create initial changelogs. Please take those over & finalize as soon as possible. br, Jani From gunnar.roth at gmx.de Fri Oct 21 13:42:44 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Fri, 21 Oct 2016 13:42:44 +0200 Subject: [Development] std::atomic In-Reply-To: <9036c842-1bcb-2542-a132-a26d7c07b440@tungware.se> References: <20161020172838.DDD3.6F0322A@gmail.com> <1549487.v67b2cB2iU@tjmaciei-mobl1> , <9036c842-1bcb-2542-a132-a26d7c07b440@tungware.se> Message-ID: An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Fri Oct 21 21:53:43 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Fri, 21 Oct 2016 21:53:43 +0200 Subject: [Development] Multiple Qt branches on Coverity Scan In-Reply-To: References: <6639540e-0af4-8440-f60c-6946d9f1b791@kdab.com> <3265007.irYWg5TUYC@tjmaciei-mobl1> <19429814.F5arqcLjF3@tjmaciei-mobl1> <7e837239-7161-c168-e8e6-ff6948ac4126@kdab.com> <60230af5-6864-a457-1c2c-2b8b3c00bde6@kdab.com> Message-ID: <3a46680b-d8ee-43c4-a503-bd4459d4b3d4@kdab.com> Il 21/10/2016 18:16, Mutz, Marc ha scritto: > > Just one request: can anyone uploading a build of either branch please > set the description to the SHA-1 the build is based on? Apparently, > Coverity does not relate to VCS at all. I will switch to qt5.git soon. So far I've been just using the tip of 5.6 / dev (at the time of the build), and timestamping the builds in the description. 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 a.rehn at menlosystems.com Sun Oct 23 15:53:30 2016 From: a.rehn at menlosystems.com (Arno Rehn) Date: Sun, 23 Oct 2016 15:53:30 +0200 Subject: [Development] QtWebChannel: Upstreaming of Python client Message-ID: <200afb57-55a0-14f7-c27e-bf9852cca9e4@menlosystems.com> 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? Regards, -- Arno Rehn Tel +49 89 189 166 0 Fax +49 89 189 166 111 a.rehn at menlosystems.com www.menlosystems.com Menlo Systems GmbH Am Klopferspitz 19a, 82152 Martinsried, Germany Amtsgericht München HRB 138145 Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr. DE217772017, St.-Nr. 14316170324 From jani.heikkinen at qt.io Mon Oct 24 15:09:29 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 24 Oct 2016 13:09:29 +0000 Subject: [Development] Qt 5.8.0 Beta packages available for testing Message-ID: Hi all, We have finally (almost) full set of Qt 5.8.0 beta installers for testing windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/627/ mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/521/ linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/553/ src: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/ (submodules are just copied so mirroring is still ongoing) Packages are RTA tested & seems to be pretty much OK so please test the packages and make sure all blockers are visible in blocker list (https://bugreports.qt.io/issues/?filter=17924 ). All known blockers should be fixed in these packages so these will be released as Qt 5.8.0 beta if no new blockers found during testing. Packages are based on https://codereview.qt-project.org/#/c/174531/ br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From net147 at gmail.com Tue Oct 25 05:17:51 2016 From: net147 at gmail.com (Jonathan Liu) Date: Tue, 25 Oct 2016 14:17:51 +1100 Subject: [Development] QtWebChannel: Upstreaming of Python client In-Reply-To: <200afb57-55a0-14f7-c27e-bf9852cca9e4@menlosystems.com> References: <200afb57-55a0-14f7-c27e-bf9852cca9e4@menlosystems.com> Message-ID: 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. > > Regards, > > -- > Arno Rehn > Tel +49 89 189 166 0 > Fax +49 89 189 166 111 > a.rehn at menlosystems.com > www.menlosystems.com > > Menlo Systems GmbH > Am Klopferspitz 19a, 82152 Martinsried, Germany > Amtsgericht München HRB 138145 > Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth > USt.-IdNr. DE217772017, St.-Nr. 14316170324 Regards, Jonathan From Jedrzej.Nowacki at qt.io Tue Oct 25 09:22:41 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Tue, 25 Oct 2016 07:22:41 +0000 Subject: [Development] Coin news Message-ID: Good news everyone! Changing Coin to test changes against Qt5 instead of the latest version of all modules reduced load on the CI significantly and now the build queue is sane even in rush hours (reaching around ~250 items instead of ~1700). I hope every one feels that integrations are quicker, especially on leaf modules. As we managed to reduce the load, we are now hitting a new bottle neck in CI. Qt5 updates are not passing often enough and they are crucial, not only for releases, but for the whole system. As the first step, we will reduce quality criteria for "flaky" definition for Qt5 integrations. Currently, if Coin encounters a test failure it tries to re-run it 5 times in addition. If all pass then the test run is accepted. For Qt5 we will re-run the test only once. The change is based on assumption that flakiness, in most cases, is not caused by an intermodule operation and we believe that the assumption is correct. I would like to also remind everyone, that intermodule API changes need to be merged in two steps. For example if you plan to change a method "void foo()" in qtbase to "void foo(const QString&)", that would be the right order of execution: 1. Commit a change to qtbase that _adds_ foo(const QString&) 2. Update all modules that use foo() to use foo(const QString&) 3. Wait until Qt5(dev branch) submodule update, that gathers changes from 1 and 2 4. Remove old foo() from qtbase If you do not follow we would have to revert your changes. Cheers, Jędrek From Jedrzej.Nowacki at qt.io Tue Oct 25 09:26:02 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Tue, 25 Oct 2016 07:26:02 +0000 Subject: [Development] Coin update Message-ID: Hi, We need to update the Coin server, so the service will be interrupted for a while today. Sorry for the short notice. Cheers, Jędrek From massimocallegari at yahoo.it Tue Oct 25 09:38:34 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Tue, 25 Oct 2016 07:38:34 +0000 (UTC) Subject: [Development] Qt 5.8.0 Beta packages available for testing In-Reply-To: References: Message-ID: <489369822.218505.1477381114056@mail.yahoo.com> Hi, please add the following to the blockers list: https://bugreports.qt.io/browse/QTBUG-56164 Without it, I am either stuck on Qt 5.7 or forced to say goodbye to Qt. Thanks,Massimo Da: Jani Heikkinen A: "development at qt-project.org" Inviato: Lunedì 24 Ottobre 2016 15:09 Oggetto: [Development] Qt 5.8.0 Beta packages available for testing Hi all, We have finally (almost) full set of Qt 5.8.0 beta installers for testing   windows:http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/627/ mac:http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/521/ linux:http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/553/ src:http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/ (submodules are just copied so mirroring is still ongoing)   Packages are RTA tested & seems to be pretty much OK so please test the packages and make sure all blockers are visible in blocker list (https://bugreports.qt.io/issues/?filter=17924 ). All known blockers should be fixed in these packages so these will be released as Qt 5.8.0 beta if no new blockers found during testing.   Packages are based onhttps://codereview.qt-project.org/#/c/174531/   br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From lars.knoll at qt.io Tue Oct 25 10:51:53 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 25 Oct 2016 08:51:53 +0000 Subject: [Development] QtWebChannel: Upstreaming of Python client In-Reply-To: References: <200afb57-55a0-14f7-c27e-bf9852cca9e4@menlosystems.com> Message-ID: <7602FCC9-32D8-495D-B87D-EB90735D6BDD@qt.io> On 25/10/16 05:17, "Development on behalf of Jonathan Liu" 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. Cheers, Lars From oswald.buddenhagen at qt.io Tue Oct 25 10:55:34 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Tue, 25 Oct 2016 10:55:34 +0200 Subject: [Development] Coin news In-Reply-To: References: Message-ID: <20161025085534.GB11027@troll08> On Tue, Oct 25, 2016 at 07:22:41AM +0000, Jędrzej Nowacki wrote: > I would like to also remind everyone, that intermodule API changes need to be merged in two steps. For example if you plan to change a method "void foo()" in qtbase to "void foo(const QString&)", that would be the right order of execution: > 1. Commit a change to qtbase that _adds_ foo(const QString&) > 1a. wait for qt5 integration. 2 would not integrate in the submodules without 1 being in qt5 already. > 2. Update all modules that use foo() to use foo(const QString&) > 3. Wait until Qt5(dev branch) submodule update, that gathers changes from 1 and 2 > only 2 at this point. > 4. Remove old foo() from qtbase > 4a. wait again until the final qt5 integration to see it in packages. so six steps in total. and it takes exactly as long as it sounds. > If you do not follow we would have to revert your changes. > > Cheers, > J�drek > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From johannes.lochmann at topcontrol.it Tue Oct 25 13:36:29 2016 From: johannes.lochmann at topcontrol.it (Johannes Lochmann) Date: Tue, 25 Oct 2016 13:36:29 +0200 Subject: [Development] QtWebChannel: Upstreaming of Python client In-Reply-To: <7602FCC9-32D8-495D-B87D-EB90735D6BDD@qt.io> References: <200afb57-55a0-14f7-c27e-bf9852cca9e4@menlosystems.com> <7602FCC9-32D8-495D-B87D-EB90735D6BDD@qt.io> Message-ID: 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! Regards, Johannes From Jedrzej.Nowacki at qt.io Tue Oct 25 14:51:58 2016 From: Jedrzej.Nowacki at qt.io (Jedrzej Nowacki) Date: Tue, 25 Oct 2016 12:51:58 +0000 Subject: [Development] Coin update In-Reply-To: References: Message-ID: Hi, The update went terribly wrong. We essentially lost the machine, because of a snapshot which corrupted partition. We needed to reinstall everything. The machinery is running now, but it doesn't accept standard builds until we reconstruct cache (qt5 builds for all active branches). It can take 2-3 hours. Sorry for the inconvenience. Cheers, Jędrek ________________________________________ From: Development on behalf of Jedrzej Nowacki Sent: Tuesday, October 25, 2016 9:26:02 AM To: development at qt-project.org Subject: [Development] Coin update Hi, We need to update the Coin server, so the service will be interrupted for a while today. Sorry for the short notice. Cheers, Jędrek _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Oct 25 16:04:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Oct 2016 07:04:04 -0700 Subject: [Development] Qt 5.8.0 Beta packages available for testing In-Reply-To: <489369822.218505.1477381114056@mail.yahoo.com> References: <489369822.218505.1477381114056@mail.yahoo.com> Message-ID: <27362004.nYDb5CGm8Q@tjmaciei-mobl1> Em terça-feira, 25 de outubro de 2016, às 07:38:34 PDT, Massimo Callegari via Development escreveu: > Hi, please add the following to the blockers list: > https://bugreports.qt.io/browse/QTBUG-56164 That's not a bug, so it can't be a blocker. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From b.terrier at gmail.com Tue Oct 25 16:42:43 2016 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Tue, 25 Oct 2016 16:42:43 +0200 Subject: [Development] Qt 5.8.0 Beta packages available for testing In-Reply-To: References: Message-ID: Hi, I just found a bug in 5.8 which make "impossible" to build Qt with MSVC on French systems: https://bugreports.qt.io/browse/QTBUG-56731 There is a workaround though: fix qconfig.pri after running configure. On a side note this bug might cause side effects on English systems as QT_CL_MAJOR_VERSION and QT_CL_PATCH_VERSION may not be properly set. Best regards, Benjamin Terrier 2016-10-24 15:09 GMT+02:00 Jani Heikkinen : > Hi all, > > We have finally (almost) full set of Qt 5.8.0 beta installers for testing > > > > windows: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/627/ > > mac: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/521/ > > linux: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/553/ > > src: http://download.qt.io/snapshots/qt/5.8/5.8.0-beta/latest_src/ > (submodules are just copied so mirroring is still ongoing) > > > > Packages are RTA tested & seems to be pretty much OK so please test the > packages and make sure all blockers are visible in blocker list ( > https://bugreports.qt.io/issues/?filter=17924 ) > . All known blockers > should be fixed in these packages so these will be released as Qt 5.8.0 > beta if no new blockers found during testing. > > > > Packages are based on https://codereview.qt-project.org/#/c/174531/ > > > > br, > > Jani > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Oct 25 16:53:55 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Oct 2016 07:53:55 -0700 Subject: [Development] Qt 5.8.0 Beta packages available for testing In-Reply-To: References: Message-ID: <11544911.dg45VfDvDn@tjmaciei-mobl1> Em terça-feira, 25 de outubro de 2016, às 16:42:43 PDT, Benjamin TERRIER escreveu: > I just found a bug in 5.8 which make "impossible" to build Qt with MSVC on > French systems: > > https://bugreports.qt.io/browse/QTBUG-56731 > > There is a workaround though: fix qconfig.pri after running configure. > > On a side note this bug might cause side effects on English systems as > QT_CL_MAJOR_VERSION and QT_CL_PATCH_VERSION may not be properly set. > > Best regards, Should be fixed by https://codereview.qt-project.org/172928, which landed in 5.6 as 6851cf52afe188e94344ce22074af97e054f5896 but hasn't made its way to 5.8 yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From b.terrier at gmail.com Tue Oct 25 17:14:47 2016 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Tue, 25 Oct 2016 17:14:47 +0200 Subject: [Development] Qt 5.8.0 Beta packages available for testing In-Reply-To: <11544911.dg45VfDvDn@tjmaciei-mobl1> References: <11544911.dg45VfDvDn@tjmaciei-mobl1> Message-ID: 2016-10-25 16:53 GMT+02:00 Thiago Macieira : > > Em terça-feira, 25 de outubro de 2016, às 16:42:43 PDT, Benjamin TERRIER > escreveu: > > I just found a bug in 5.8 which make "impossible" to build Qt with MSVC on > > French systems: > > > > https://bugreports.qt.io/browse/QTBUG-56731 > > > > There is a workaround though: fix qconfig.pri after running configure. > > > > On a side note this bug might cause side effects on English systems as > > QT_CL_MAJOR_VERSION and QT_CL_PATCH_VERSION may not be properly set. > > > > Best regards, > > Should be fixed by https://codereview.qt-project.org/172928, which landed in > 5.6 as 6851cf52afe188e94344ce22074af97e054f5896 but hasn't made its way to 5.8 > yet. This patch fixes tools\configure\environment.cpp However in 5.8 the fixed line does not exist anymore in this file, but the same regexp appeared in configure.pri (which is a new file compared to 5.6). So the same fix should be applied to configure.pri, but at 2 places (see bug report). I guess it is because of the new configure system. From kevin.kofler at chello.at Tue Oct 25 17:54:02 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Tue, 25 Oct 2016 17:54:02 +0200 Subject: [Development] Qt 5.8.0 Beta packages available for testing References: <489369822.218505.1477381114056@mail.yahoo.com> <27362004.nYDb5CGm8Q@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > Em terça-feira, 25 de outubro de 2016, às 07:38:34 PDT, Massimo Callegari > via Development escreveu: >> Hi, please add the following to the blockers list: >> https://bugreports.qt.io/browse/QTBUG-56164 > > That's not a bug, so it can't be a blocker. It's a regression, ergo it is a bug. Kevin Kofler From thiago.macieira at intel.com Tue Oct 25 18:21:17 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Oct 2016 09:21:17 -0700 Subject: [Development] Qt 5.8.0 Beta packages available for testing In-Reply-To: References: <11544911.dg45VfDvDn@tjmaciei-mobl1> Message-ID: <21108559.Bu0R7vtve6@tjmaciei-mobl1> Em terça-feira, 25 de outubro de 2016, às 17:14:47 PDT, Benjamin TERRIER escreveu: > This patch fixes tools\configure\environment.cpp > > However in 5.8 the fixed line does not exist anymore in this file, but > the same regexp appeared in configure.pri (which is a new file > compared to 5.6). > So the same fix should be applied to configure.pri, but at 2 places > (see bug report). > > I guess it is because of the new configure system. It's possible. I would much rather extract from the compiler's macros, but that patch wasn't added. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Oct 25 18:22:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Oct 2016 09:22:16 -0700 Subject: [Development] Qt 5.8.0 Beta packages available for testing In-Reply-To: References: <27362004.nYDb5CGm8Q@tjmaciei-mobl1> Message-ID: <4176148.e8OCjC8JGJ@tjmaciei-mobl1> Em terça-feira, 25 de outubro de 2016, às 17:54:02 PDT, Kevin Kofler escreveu: > Thiago Macieira wrote: > > Em terça-feira, 25 de outubro de 2016, às 07:38:34 PDT, Massimo Callegari > > > > via Development escreveu: > >> Hi, please add the following to the blockers list: > >> https://bugreports.qt.io/browse/QTBUG-56164 > > > > That's not a bug, so it can't be a blocker. > > It's a regression, ergo it is a bug. It was never supported, therefore it can't be a bug, much less a regression. Indeed we removed some functionality, but one that was technically abusing qmake because it wasn't supported. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Oct 25 19:43:35 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Oct 2016 10:43:35 -0700 Subject: [Development] Backporting the "stop unloading plugins" change to 5.6 In-Reply-To: <17677B3D-B809-4268-81A2-80DA18D1A8C3@qt.io> References: <7496830.S3jACJtUcN@tjmaciei-mobl1> <3328573.ox3DVGQYNZ@tjmaciei-mobl1> <17677B3D-B809-4268-81A2-80DA18D1A8C3@qt.io> Message-ID: <64282389.MineVoVJyr@tjmaciei-mobl1> On segunda-feira, 17 de outubro de 2016 14:46:29 PDT Lars Knoll wrote: > I have to agree with Thiago. For QFactoryLoader, it doesn't make a lot of > sense to try to unload the plugins, as we only do that on program exit. > > It would be great to make plugins safe to unload, but we all know that this > is tricky to get right. In addition, we don't even control all the plugins > we might be loading (thing about additional image formats of styles > provided by others), so we have no way of knowing whether we can safely > unload the plugin. > > So I think it's the right thing to change this in 5.6 and not unload those > plugins on app exit. https://codereview.qt-project.org/174911 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From massimocallegari at yahoo.it Tue Oct 25 20:12:27 2016 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Tue, 25 Oct 2016 18:12:27 +0000 (UTC) Subject: [Development] Qt 5.8.0 Beta packages available for testing In-Reply-To: <4176148.e8OCjC8JGJ@tjmaciei-mobl1> References: <27362004.nYDb5CGm8Q@tjmaciei-mobl1> <4176148.e8OCjC8JGJ@tjmaciei-mobl1> Message-ID: <215195724.1438208.1477419147369@mail.yahoo.com> > > Thiago Macieira wrote: > > > Em terça-feira, 25 de outubro de 2016, às 07:38:34 PDT, Massimo Callegari > > > > > > via Development escreveu: > > >> Hi, please add the following to the blockers list: > > >> https://bugreports.qt.io/browse/QTBUG-56164 > > > > > > That's not a bug, so it can't be a blocker. > > > > It's a regression, ergo it is a bug. > > It was never supported, therefore it can't be a bug, much less a regression. > Indeed we removed some functionality, but one that was technically abusing > qmake because it wasn't supported. That is not true. See the official Qt documentation, end of page, "Configuration Features" paragraph: http://doc.qt.io/qt-5/qmake-project-files.html Honestly I don't care much if it was there by mistake or unsupported or whatever. It was a usable feature. Period. As I stated before, pkg-config is fundamental to access libraries outside of Qt's scope, either on Linux, MSYS2 on Windows or Homebrew/Macports on Mac OS, so we need to keep on having that feature from Qt. If you want developers to stop having such access, then I would much like call it a regression and IMHO it should be fixed before releasing Qt 5.8.0. From thiago.macieira at intel.com Tue Oct 25 20:43:17 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 25 Oct 2016 11:43:17 -0700 Subject: [Development] Qt 5.8.0 Beta packages available for testing In-Reply-To: <215195724.1438208.1477419147369@mail.yahoo.com> References: <4176148.e8OCjC8JGJ@tjmaciei-mobl1> <215195724.1438208.1477419147369@mail.yahoo.com> Message-ID: <2406947.rlqLSXQ4Jx@tjmaciei-mobl1> On terça-feira, 25 de outubro de 2016 18:12:27 PDT Massimo Callegari via Development wrote: > > It was never supported, therefore it can't be a bug, much less a > > regression. Indeed we removed some functionality, but one that was > > technically abusing > > qmake because it wasn't supported. > > That is not true. See the official Qt documentation, end of page, > "Configuration Features" paragraph: > http://doc.qt.io/qt-5/qmake-project-files.html > > Honestly I don't care much if it was there by mistake or unsupported or > whatever. It was a usable feature. Period. By abusing qmake. Your bug report showed you used this line: macx:QT_CONFIG -= no-pkg-config That above is the abuse. Show us code that worked without that line and has stopped working. That will qualify as a regression. You can continue to abuse Qt's configuration in 5.8. It just changed what variables you have to abuse. No compatiblity is guaranteed because it's an abuse. > As I stated before, pkg-config is fundamental to access libraries outside of > Qt's scope, either on Linux, MSYS2 on Windows or Homebrew/Macports on Mac > OS, so we need to keep on having that feature from Qt. I'm not disputing that. That's why I reopened the issue and made it a feature request so that we officially support it, without abuses required. > If you want developers to stop having such access, then I would much like > call it a regression and IMHO it should be fixed before releasing Qt 5.8.0. It wasn't a feature before, therefore it's not a bug and not a regression. Alternatively, we can call it a bug that has been present for a long time. It still wouldn't be a regression. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jani.heikkinen at qt.io Wed Oct 26 06:52:15 2016 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 26 Oct 2016 04:52:15 +0000 Subject: [Development] Maintainers: Your action needed Message-ID: Hi all, Qt 5.7.1 change files are still badly ongoing, see https://codereview.qt-project.org/#/q/branch:5.7.1+message:%22Add+changes+file+for+5.7.1%22,n,z I created initial drafts so maintainers, please finalize those now & get those approved! br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Oct 26 08:47:48 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 26 Oct 2016 08:47:48 +0200 Subject: [Development] Coin news In-Reply-To: <20161025085534.GB11027@troll08> References: <20161025085534.GB11027@troll08> Message-ID: <201610260847.48967.marc.mutz@kdab.com> On Tuesday 25 October 2016 10:55:34 Oswald Buddenhagen wrote: > On Tue, Oct 25, 2016 at 07:22:41AM +0000, Jędrzej Nowacki wrote: > > I would like to also remind everyone, that intermodule API changes need > > to be merged in two steps. For example if you plan to change a method > > "void foo()" in qtbase to "void foo(const QString&)", that would be the > > right order of execution: 1. Commit a change to qtbase that _adds_ > > foo(const QString&) > > 1a. wait for qt5 integration. 2 would not integrate in the submodules > without 1 being in qt5 already. > > > 2. Update all modules that use foo() to use foo(const QString&) > > 3. Wait until Qt5(dev branch) submodule update, that gathers changes from > > 1 and 2 > > only 2 at this point. > > > 4. Remove old foo() from qtbase > > 4a. wait again until the final qt5 integration to see it in packages. > > so six steps in total. and it takes exactly as long as it sounds. > > > If you do not follow we would have to revert your changes. Alternatively, #define a macro in the upstream module when adding the new API, and check for it in the downstream module to decide which API to use. These two changes can then proceed independently, followed at any time after just one qt5.git integration by two clean-up commits. 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 Wed Oct 26 09:10:21 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Wed, 26 Oct 2016 07:10:21 +0000 Subject: [Development] Qt 5.8.0 Beta packages available for testing In-Reply-To: <2406947.rlqLSXQ4Jx@tjmaciei-mobl1> References: <4176148.e8OCjC8JGJ@tjmaciei-mobl1> <215195724.1438208.1477419147369@mail.yahoo.com> <2406947.rlqLSXQ4Jx@tjmaciei-mobl1> Message-ID: On 25/10/16 20:43, "Development on behalf of Thiago Macieira" wrote: >On terça-feira, 25 de outubro de 2016 18:12:27 PDT Massimo Callegari via >Development wrote: >> > It was never supported, therefore it can't be a bug, much less a >> > regression. Indeed we removed some functionality, but one that was >> > technically abusing >> > qmake because it wasn't supported. >> >> That is not true. See the official Qt documentation, end of page, >> "Configuration Features" paragraph: >> http://doc.qt.io/qt-5/qmake-project-files.html >> >> Honestly I don't care much if it was there by mistake or unsupported or >> whatever. It was a usable feature. Period. > >By abusing qmake. Your bug report showed you used this line: > >macx:QT_CONFIG -= no-pkg-config > >That above is the abuse. Show us code that worked without that line and has >stopped working. That will qualify as a regression. > >You can continue to abuse Qt's configuration in 5.8. It just changed what >variables you have to abuse. No compatiblity is guaranteed because it's an >abuse. > >> As I stated before, pkg-config is fundamental to access libraries outside of >> Qt's scope, either on Linux, MSYS2 on Windows or Homebrew/Macports on Mac >> OS, so we need to keep on having that feature from Qt. > >I'm not disputing that. That's why I reopened the issue and made it a feature >request so that we officially support it, without abuses required. > >> If you want developers to stop having such access, then I would much like >> call it a regression and IMHO it should be fixed before releasing Qt 5.8.0. > >It wasn't a feature before, therefore it's not a bug and not a regression. > >Alternatively, we can call it a bug that has been present for a long time. It >still wouldn't be a regression. Agree with Thiago. Having said that, as we have been doing quite many changes to the configuration system, let’s see if we can get this fixed somewhat properly for 5.8 final. But it’s not a blocker for the beta. Cheers, Lars From Kai.Koehne at qt.io Wed Oct 26 09:21:53 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 26 Oct 2016 07:21:53 +0000 Subject: [Development] OpenGL Issues in Qt5.7 In-Reply-To: References: Message-ID: > -----Original Message----- > From: Liu, Jeff (SRDC SW) [mailto:Jeff1.Liu at amd.com] > Sent: Wednesday, October 26, 2016 7:09 AM > To: gunnar.sletta at jollamobile.com; gunnar at sletta.org; Liang Qi > ; Kai Koehne ; development at qt- > project.org > Subject: RE: OpenGL Issues in Qt5.7 > > > > Spread to Qt mail-list to ask for help. > > > > From: Liu, Jeff (SRDC SW) > Sent: Tuesday, October 25, 2016 2:26 PM > To: 'gunnar.sletta at jollamobile.com'; 'gunnar at sletta.org'; 'liang.qi at qt.io'; > 'kai.koehne at qt.io' > Subject: OpenGL Issues in Qt5.7 > > > > Hi Sletta, Qi and Koehne, Hi Jeff! > This is Jeff from AMD, recently a customer reports a game issue with AMD > cards, but the game runs well on Nvidia card, after some debug, I find out > that the issues are caused by Qt libraries, when Qt programs with OpenGL > API, it doesn’t follow the OpenGL programming specification strictly, so it will > report errors on AMD platform. > > Now we find out the two following issues, both issues come from Qt paint > engine. > > 1. QTBUG-56234 - OpenGL glVertexAttribArray API usage error in > Qt5Guid.dll > > I submit a ticket to address this issue, and this issue is assigned to Sletta, but > it seems no one starts to work on it, the usage of glVertexAttribArray API is > wrong, it is still used in the old way (OpenGL 3.0), but it apparently violate the > latest OpenGL specification (OpenGL 4.1) Liang already commented on this one. Laszlo (the new assignee) probably has a better idea about this, too. > 2. I don’t submit the ticket for the second issue yet, Qt paint engine uses > GL_RED to upload the texture, so based on the spec, the texture will be > (GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, which is a > constant 0 value in AMD platform, if changed to src * mask.r, then everything > will be correct, I will submit a ticket to address it later. Feel free to report this, too. > I don’t know what’s the right way to report and fix Qt issues, there may be > more issues later in the game, so I write an email to you guys (I find your > emails from code.qt.io), please tell me what should I do to co-work with you > and make these issues fixed. Reporting them on bugreports.qt.io is certainly a good start :) If you're a commercial customer you should also go through Qt Support - often enough the support team can help directly, or escalate things. Regards Kai From sean.harmer at kdab.com Wed Oct 26 09:54:36 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Wed, 26 Oct 2016 08:54:36 +0100 Subject: [Development] OpenGL Issues in Qt5.7 In-Reply-To: References: Message-ID: <5810613C.6010109@kdab.com> Hi, On 26/10/2016 08:21, Kai Koehne wrote: >> -----Original Message----- >> From: Liu, Jeff (SRDC SW) [mailto:Jeff1.Liu at amd.com] >> Sent: Wednesday, October 26, 2016 7:09 AM >> To: gunnar.sletta at jollamobile.com; gunnar at sletta.org; Liang Qi >> ; Kai Koehne ; development at qt- >> project.org >> Subject: RE: OpenGL Issues in Qt5.7 >> >> >> >> Spread to Qt mail-list to ask for help. >> >> >> >> From: Liu, Jeff (SRDC SW) >> Sent: Tuesday, October 25, 2016 2:26 PM >> To: 'gunnar.sletta at jollamobile.com'; 'gunnar at sletta.org'; 'liang.qi at qt.io'; >> 'kai.koehne at qt.io' >> Subject: OpenGL Issues in Qt5.7 >> >> >> >> Hi Sletta, Qi and Koehne, > Hi Jeff! > >> This is Jeff from AMD, recently a customer reports a game issue with AMD >> cards, but the game runs well on Nvidia card, after some debug, I find out >> that the issues are caused by Qt libraries, when Qt programs with OpenGL >> API, it doesn’t follow the OpenGL programming specification strictly, so it will >> report errors on AMD platform. >> >> Now we find out the two following issues, both issues come from Qt paint >> engine. >> >> 1. QTBUG-56234 - OpenGL glVertexAttribArray API usage error in >> Qt5Guid.dll >> >> I submit a ticket to address this issue, and this issue is assigned to Sletta, but >> it seems no one starts to work on it, the usage of glVertexAttribArray API is >> wrong, it is still used in the old way (OpenGL 3.0), but it apparently violate the >> latest OpenGL specification (OpenGL 4.1) > Liang already commented on this one. Laszlo (the new assignee) probably > has a better idea about this, too. As commented on the bug, this QOpenGL2PaintEngine is only meant for use with a 2.x OpenGL context. The paint engine will not work properly with a Core Profile context. All the shaders are also legacy (attribute + varying vs in + out). > >> 2. I don’t submit the ticket for the second issue yet, Qt paint engine uses >> GL_RED to upload the texture, so based on the spec, the texture will be >> (GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, which is a >> constant 0 value in AMD platform, if changed to src * mask.r, then everything >> will be correct, I will submit a ticket to address it later. > Feel free to report this, too. Again, this would really require a new OpenGL paint engine for modern OpenGL to be written. Afaik nobody is working on this or even looking into it. Using Qt Quick 2 would be an easier path if it suits your use case. I'd love to have the ability to composite widget painting with modern GL so if you want to work on such a thing then please do feel free to do so. Cheers, Sean From sh at theharmers.co.uk Wed Oct 26 09:56:47 2016 From: sh at theharmers.co.uk (Sean Harmer) Date: Wed, 26 Oct 2016 08:56:47 +0100 Subject: [Development] OpenGL Issues in Qt5.7 In-Reply-To: <5810613C.6010109@kdab.com> References: <5810613C.6010109@kdab.com> Message-ID: <581061BF.5080400@theharmers.co.uk> And now Gunnar has just pointed out there is work in this area: :) https://codereview.qt-project.org/#/c/166202/ Cheers, Sean On 26/10/2016 08:54, Sean Harmer wrote: > Hi, > > On 26/10/2016 08:21, Kai Koehne wrote: >>> -----Original Message----- >>> From: Liu, Jeff (SRDC SW) [mailto:Jeff1.Liu at amd.com] >>> Sent: Wednesday, October 26, 2016 7:09 AM >>> To: gunnar.sletta at jollamobile.com; gunnar at sletta.org; Liang Qi >>> ; Kai Koehne ; development at qt- >>> project.org >>> Subject: RE: OpenGL Issues in Qt5.7 >>> >>> >>> >>> Spread to Qt mail-list to ask for help. >>> >>> >>> >>> From: Liu, Jeff (SRDC SW) >>> Sent: Tuesday, October 25, 2016 2:26 PM >>> To: 'gunnar.sletta at jollamobile.com'; 'gunnar at sletta.org'; >>> 'liang.qi at qt.io'; >>> 'kai.koehne at qt.io' >>> Subject: OpenGL Issues in Qt5.7 >>> >>> >>> >>> Hi Sletta, Qi and Koehne, >> Hi Jeff! >> >>> This is Jeff from AMD, recently a customer reports a game issue with >>> AMD >>> cards, but the game runs well on Nvidia card, after some debug, I >>> find out >>> that the issues are caused by Qt libraries, when Qt programs with >>> OpenGL >>> API, it doesn’t follow the OpenGL programming specification >>> strictly, so it will >>> report errors on AMD platform. >>> >>> Now we find out the two following issues, both issues come from Qt >>> paint >>> engine. >>> >>> 1. QTBUG-56234 - OpenGL glVertexAttribArray API usage error in >>> Qt5Guid.dll >>> >>> I submit a ticket to address this issue, and this issue is assigned >>> to Sletta, but >>> it seems no one starts to work on it, the usage of >>> glVertexAttribArray API is >>> wrong, it is still used in the old way (OpenGL 3.0), but it >>> apparently violate the >>> latest OpenGL specification (OpenGL 4.1) >> Liang already commented on this one. Laszlo (the new assignee) probably >> has a better idea about this, too. > > As commented on the bug, this QOpenGL2PaintEngine is only meant for > use with a 2.x OpenGL context. The paint engine will not work properly > with a Core Profile context. All the shaders are also legacy > (attribute + varying vs in + out). > >> >>> 2. I don’t submit the ticket for the second issue yet, Qt >>> paint engine uses >>> GL_RED to upload the texture, so based on the spec, the texture will be >>> (GL_RED value, 0,0,1), but in pixel shader, it uses src * mask.a, >>> which is a >>> constant 0 value in AMD platform, if changed to src * mask.r, then >>> everything >>> will be correct, I will submit a ticket to address it later. >> Feel free to report this, too. > > Again, this would really require a new OpenGL paint engine for modern > OpenGL to be written. Afaik nobody is working on this or even looking > into it. Using Qt Quick 2 would be an easier path if it suits your use > case. I'd love to have the ability to composite widget painting with > modern GL so if you want to work on such a thing then please do feel > free to do so. > > Cheers, > > Sean > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ola at silentwings.no Wed Oct 26 10:18:49 2016 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Wed, 26 Oct 2016 10:18:49 +0200 Subject: [Development] Compile errors, Qt configured with -qreal float Message-ID: I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from source when configuring Qt with -qreal float and building using g++ on Linux. The affected modules are Charts and Location. https://bugreports.qt.io/browse/QTBUG-56715 I would think that this should be given a higher priority than P3. I initially reported this for 5.6.2 using a cross compile arm toolchain, but now I see it also affects 5.8 beta on the desktop. If -qreal float is a supported configuration, shouldn't this have been caught in the CI system automatically? Cheers, Ola Røer Thorsen -------------- next part -------------- An HTML attachment was scrubbed... URL: From a.rehn at menlosystems.com Wed Oct 26 10:32:32 2016 From: a.rehn at menlosystems.com (Arno Rehn) Date: Wed, 26 Oct 2016 10:32:32 +0200 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: 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. Regards, -- Arno Rehn Tel +49 89 189 166 0 Fax +49 89 189 166 111 a.rehn at menlosystems.com www.menlosystems.com Menlo Systems GmbH Am Klopferspitz 19a, 82152 Martinsried, Germany Amtsgericht München HRB 138145 Geschäftsführung: Dr. Michael Mei, Dr. Ronald Holzwarth USt.-IdNr. DE217772017, St.-Nr. 14316170324 From oswald.buddenhagen at qt.io Wed Oct 26 11:28:28 2016 From: oswald.buddenhagen at qt.io (Oswald Buddenhagen) Date: Wed, 26 Oct 2016 11:28:28 +0200 Subject: [Development] Coin news In-Reply-To: <201610260847.48967.marc.mutz@kdab.com> References: <20161025085534.GB11027@troll08> <201610260847.48967.marc.mutz@kdab.com> Message-ID: <20161026092828.GA4067@troll08> On Wed, Oct 26, 2016 at 08:47:48AM +0200, Marc Mutz wrote: > On Tuesday 25 October 2016 10:55:34 Oswald Buddenhagen wrote: > > On Tue, Oct 25, 2016 at 07:22:41AM +0000, Jędrzej Nowacki wrote: > > > I would like to also remind everyone, that intermodule API changes need > > > to be merged in two steps. For example if you plan to change a method > > > "void foo()" in qtbase to "void foo(const QString&)", that would be the > > > right order of execution: 1. Commit a change to qtbase that _adds_ > > > foo(const QString&) > > > > 1a. wait for qt5 integration. 2 would not integrate in the submodules > > without 1 being in qt5 already. > > > > > 2. Update all modules that use foo() to use foo(const QString&) > > > 3. Wait until Qt5(dev branch) submodule update, that gathers changes from > > > 1 and 2 > > > > only 2 at this point. > > > > > 4. Remove old foo() from qtbase > > > > 4a. wait again until the final qt5 integration to see it in packages. > > > > so six steps in total. and it takes exactly as long as it sounds. > > > > > If you do not follow we would have to revert your changes. > > Alternatively, #define a macro in the upstream module when adding the new API, > and check for it in the downstream module to decide which API to use. These > two changes can then proceed independently, followed at any time after just > one qt5.git integration by two clean-up commits. > that's indeed better in the optimal case: 1. prepare downstream module and update upstream module 2. have them integrated into qt5. make sure that the upstream update does not go in before the downstream adjustment (you can generally assume an atomic integration). 3. clean up both modules 4. have them integrated into qt5. make sure the upstream cleanup does not go in before the downstream cleanup. another good thing about this variant is that you can atomically fix issues introduced due to signal/slot overloading, which you'd otherwise have to do separately in advance, introducing yet another two-stage integration. a downside is that the history is messier, because there are inherently at least two commits in every downstream module. and it may get even more messy if you notice later in the process that you need to adjust the downstreams further before the qt5 integration succeeds. that's because the downstream integrations are basically dummies and you don't notice that something went wrong until the qt5 integration which pulls in the upstream change. > 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 From kangjoni76 at gmail.com Wed Oct 26 11:57:55 2016 From: kangjoni76 at gmail.com (kang joni) Date: Wed, 26 Oct 2016 16:57:55 +0700 Subject: [Development] clangbackend qtcreator 4.2 memory hogging Message-ID: I have small project in which contains 2k SLOC with heavy v8 js template included in source file. For small opening 3-4 sources file this take almost 870mb in memory with no precompiled header being checked plus qtcreator eats 280mb with 2gb Intel celeron and this is definitely not desirable for me. I have feature request whether is this possible to put heavy c++ symbol data in sqlite file with multithread concurrent access mechanism instead to keep clangbackend memory usage being low? From Marco.Bubke at qt.io Wed Oct 26 12:08:27 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Wed, 26 Oct 2016 10:08:27 +0000 Subject: [Development] clangbackend qtcreator 4.2 memory hogging In-Reply-To: References: Message-ID: If c++ modules becomes supported it could go down but actually you should request that in the clang mailling list. We open a translation unit for every file and they are that big. We research precompiled header to improve speed and maybe they provide advantages in memory usage too. ________________________________ From: Development on behalf of kang joni Sent: Wednesday, October 26, 2016 11:57:55 AM To: development at qt-project.org Subject: [Development] clangbackend qtcreator 4.2 memory hogging I have small project in which contains 2k SLOC with heavy v8 js template included in source file. For small opening 3-4 sources file this take almost 870mb in memory with no precompiled header being checked plus qtcreator eats 280mb with 2gb Intel celeron and this is definitely not desirable for me. I have feature request whether is this possible to put heavy c++ symbol data in sqlite file with multithread concurrent access mechanism instead to keep clangbackend memory usage being low? _______________________________________________ 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 kangjoni76 at gmail.com Wed Oct 26 12:35:49 2016 From: kangjoni76 at gmail.com (kang joni) Date: Wed, 26 Oct 2016 17:35:49 +0700 Subject: [Development] clangbackend qtcreator 4.2 memory hogging In-Reply-To: References: Message-ID: so I'm now just thinking the possibility to pack list of clang symbol internal chunk of class to be serialized into qdatastream binary and send it over sqlite column. But this is just my dummy thought. Could you please possibly integrate this project http://rprichard.github.io/sourceweb/ into qtcreator as well. I had succeed with it readonly indexing my production project at 60k SLOC and the whole nodejs project source tree with it's dependency project like openssl, v8 js ,libuv etc... @Marco Bubke what do you think, they have friendly BSD license mainly btw? On 10/26/16, Marco Bubke wrote: > If c++ modules becomes supported it could go down but actually you should > request that in the clang mailling list. We open a translation unit for > every file and they are that big. We research precompiled header to improve > speed and maybe they provide advantages in memory usage too. > > ________________________________ > From: Development on > behalf of kang joni > Sent: Wednesday, October 26, 2016 11:57:55 AM > To: development at qt-project.org > Subject: [Development] clangbackend qtcreator 4.2 memory hogging > > I have small project in which contains 2k SLOC with heavy v8 js > template included in source file. > For small opening 3-4 sources file this take almost 870mb in memory > with no precompiled header being checked plus qtcreator eats 280mb > with 2gb Intel celeron and this is definitely not desirable for me. I > have feature request whether is this possible to put heavy c++ symbol > data in sqlite file with multithread concurrent access mechanism > instead to keep clangbackend memory usage being low? > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From thiago.macieira at intel.com Wed Oct 26 17:01:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 26 Oct 2016 08:01:50 -0700 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: References: Message-ID: <2101779.fnLOf9PaFa@tjmaciei-mobl1> On quarta-feira, 26 de outubro de 2016 10:18:49 PDT Ola Røer Thorsen wrote: > I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from source > when configuring Qt with -qreal float and building using g++ on Linux. The > affected modules are Charts and Location. > > https://bugreports.qt.io/browse/QTBUG-56715 > > I would think that this should be given a higher priority than P3. I > initially reported this for 5.6.2 using a cross compile arm toolchain, but > now I see it also affects 5.8 beta on the desktop. > > If -qreal float is a supported configuration, shouldn't this have been > caught in the CI system automatically? We don't test every module with every configuration. It's just too many permutations possible. Thanks for reporting, those issues are easy to fix. The line in question is: bottomRight.setLatitude(qMax(bottomRight.latitude(), -85.05113)); To fix this, the literal number needs to be written as: qreal(-85.05113). There's also a qMin line right above with the same problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sergio.martins at kdab.com Wed Oct 26 18:40:52 2016 From: sergio.martins at kdab.com (Sergio Martins) Date: Wed, 26 Oct 2016 17:40:52 +0100 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: <2101779.fnLOf9PaFa@tjmaciei-mobl1> References: <2101779.fnLOf9PaFa@tjmaciei-mobl1> Message-ID: <24535acc50f7e02457f1d62c3f829b97@kdab.com> On 2016-10-26 16:01, Thiago Macieira wrote: > On quarta-feira, 26 de outubro de 2016 10:18:49 PDT Ola Røer Thorsen > wrote: >> I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from >> source >> when configuring Qt with -qreal float and building using g++ on Linux. >> The >> affected modules are Charts and Location. >> >> https://bugreports.qt.io/browse/QTBUG-56715 >> >> I would think that this should be given a higher priority than P3. I >> initially reported this for 5.6.2 using a cross compile arm toolchain, >> but >> now I see it also affects 5.8 beta on the desktop. >> >> If -qreal float is a supported configuration, shouldn't this have been >> caught in the CI system automatically? > > We don't test every module with every configuration. It's just too many > permutations possible. > > Thanks for reporting, those issues are easy to fix. The line in > question is: > > bottomRight.setLatitude(qMax(bottomRight.latitude(), > -85.05113)); > > To fix this, the literal number needs to be written as: > qreal(-85.05113). > There's also a qMin line right above with the same problem. That's not enough and probably just 10% of the cost of the solution. One also needs to figure the contribution process and commit. The problem here is not technical, it's about inertia. The real issue understanding is "why don't users contribute trivial changes that they need". You see it all the time: - users complaining on a JIRA bug for 2 years instead of submitting a one-liner - users reporting wiki typo instead of editing wiki - users refusing to contribute because "I'm not a Qt developer" - users feeling entitled to a warranty - users not understanding that the qt-project has different responsibilities than TQC Ofc, this is not about Ola Thorsten, it's about our project and how we communicate with users. 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 thiago.macieira at intel.com Wed Oct 26 23:20:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 26 Oct 2016 14:20:38 -0700 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: <24535acc50f7e02457f1d62c3f829b97@kdab.com> References: <2101779.fnLOf9PaFa@tjmaciei-mobl1> <24535acc50f7e02457f1d62c3f829b97@kdab.com> Message-ID: <82131118.kgTvksx8EI@tjmaciei-mobl1> On quarta-feira, 26 de outubro de 2016 17:40:52 PDT Sergio Martins wrote: > On 2016-10-26 16:01, Thiago Macieira wrote: > > On quarta-feira, 26 de outubro de 2016 10:18:49 PDT Ola Røer Thorsen > > > > wrote: > >> I'm getting compile errors building both Qt 5.6.2 and 5.8 beta from > >> source > >> when configuring Qt with -qreal float and building using g++ on Linux. > >> The > >> affected modules are Charts and Location. > >> > >> https://bugreports.qt.io/browse/QTBUG-56715 > >> > >> I would think that this should be given a higher priority than P3. I > >> initially reported this for 5.6.2 using a cross compile arm toolchain, > >> but > >> now I see it also affects 5.8 beta on the desktop. > >> > >> If -qreal float is a supported configuration, shouldn't this have been > >> caught in the CI system automatically? > > > > We don't test every module with every configuration. It's just too many > > permutations possible. > > > > Thanks for reporting, those issues are easy to fix. The line in > > > > question is: > > bottomRight.setLatitude(qMax(bottomRight.latitude(), > > -85.05113)); > > > > To fix this, the literal number needs to be written as: > > qreal(-85.05113). > > There's also a qMin line right above with the same problem. > > That's not enough and probably just 10% of the cost of the solution. One > also needs to figure the contribution process and commit. The problem > here is not technical, it's about inertia. I diidn't mean that Ola should contribute the fix. I was merely pointing out the fix for whoever will have to fix the issue. In any event, this change in qtbase will help too (5.8 only): https://codereview.qt-project.org/175025 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ola at silentwings.no Thu Oct 27 00:49:21 2016 From: ola at silentwings.no (=?UTF-8?Q?Ola_R=C3=B8er_Thorsen?=) Date: Thu, 27 Oct 2016 00:49:21 +0200 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: <82131118.kgTvksx8EI@tjmaciei-mobl1> References: <2101779.fnLOf9PaFa@tjmaciei-mobl1> <24535acc50f7e02457f1d62c3f829b97@kdab.com> <82131118.kgTvksx8EI@tjmaciei-mobl1> Message-ID: 2016-10-26 23:20 GMT+02:00 Thiago Macieira : > On quarta-feira, 26 de outubro de 2016 17:40:52 PDT Sergio Martins wrote: > > That's not enough and probably just 10% of the cost of the solution. One > > also needs to figure the contribution process and commit. The problem > > here is not technical, it's about inertia. > > I diidn't mean that Ola should contribute the fix. I was merely pointing > out > the fix for whoever will have to fix the issue. > > I tried fixing it anyway :-) https://codereview.qt-project.org/#/c/175026/ https://codereview.qt-project.org/#/c/175029/ In any event, this change in qtbase will help too (5.8 only): > https://codereview.qt-project.org/175025 > > That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be careless about mixing floats and doubles? I think it's a good practice to avoid mixing when possible, with regards to performance especially on smaller embedded devices. Cheers, Ola -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Oct 27 01:23:15 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 26 Oct 2016 16:23:15 -0700 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: References: <82131118.kgTvksx8EI@tjmaciei-mobl1> Message-ID: <2040035.tAy37G7WHk@tjmaciei-mobl1> On quinta-feira, 27 de outubro de 2016 00:49:21 PDT Ola Røer Thorsen wrote: > > https://codereview.qt-project.org/175025 > > That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be > careless about mixing floats and doubles? I think it's a good practice to > avoid mixing when possible, with regards to performance especially on > smaller embedded devices. Yes and no. qMax and qMin have been the bane of qreal for the last 10 years because they are template functions. Solving those two will solve 95%+ of the qreal=float issues. That means the chance of having a release that fails to build under that condition lessens considerably. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Oct 27 08:23:57 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 27 Oct 2016 08:23:57 +0200 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: <2040035.tAy37G7WHk@tjmaciei-mobl1> References: <2040035.tAy37G7WHk@tjmaciei-mobl1> Message-ID: <201610270823.57812.marc.mutz@kdab.com> On Thursday 27 October 2016 01:23:15 Thiago Macieira wrote: > On quinta-feira, 27 de outubro de 2016 00:49:21 PDT Ola Røer Thorsen wrote: > > > https://codereview.qt-project.org/175025 > > > > That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be > > careless about mixing floats and doubles? I think it's a good practice to > > avoid mixing when possible, with regards to performance especially on > > smaller embedded devices. > > Yes and no. qMax and qMin have been the bane of qreal for the last 10 years > because they are template functions. Solving those two will solve 95%+ of > the qreal=float issues. That means the chance of having a release that > fails to build under that condition lessens considerably. And, again, by proprietarily extending a perfectly adequate std functionality, we lock ourselves deeper into our NIHS, losing new functionality provided by newer std versions, in this case: variadic std::min/max. 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 nassian at bitshift-dynamics.de Thu Oct 27 08:28:34 2016 From: nassian at bitshift-dynamics.de (Alexander Nassian) Date: Thu, 27 Oct 2016 08:28:34 +0200 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: <201610270823.57812.marc.mutz@kdab.com> References: <2040035.tAy37G7WHk@tjmaciei-mobl1> <201610270823.57812.marc.mutz@kdab.com> Message-ID: <154E7153-5D7B-4D76-9D6B-5A2951D73DAA@bitshift-dynamics.de> > Am 27.10.2016 um 08:23 schrieb Marc Mutz : > >> On Thursday 27 October 2016 01:23:15 Thiago Macieira wrote: >> On quinta-feira, 27 de outubro de 2016 00:49:21 PDT Ola Røer Thorsen wrote: >>>> https://codereview.qt-project.org/175025 >>> >>> That's sort of a "sledge hammer" fix. Wouldn't this make it easier to be >>> careless about mixing floats and doubles? I think it's a good practice to >>> avoid mixing when possible, with regards to performance especially on >>> smaller embedded devices. >> >> Yes and no. qMax and qMin have been the bane of qreal for the last 10 years >> because they are template functions. Solving those two will solve 95%+ of >> the qreal=float issues. That means the chance of having a release that >> fails to build under that condition lessens considerably. > > And, again, by proprietarily extending a perfectly adequate std functionality, > we lock ourselves deeper into our NIHS, losing new functionality provided by > newer std versions, in this case: variadic std::min/max. > And depend more and more on different std implementations that introduce different behavior on different platforms and compilers? And let external software (that gcc issue is not that long in the past) break Qt's binary compatibility? Personally, I always prefer the uniform Qt style as I can rely on that platform and compiler independent functionality. Also I prefer code that looks like made out of a single piece. I don't like to incorporate x different libraries with x different coding and API styles. If so, I could also go and use GTK *ugh* Just my 2 cents ;) Best regards, Alexander Nassian From thiago.macieira at intel.com Thu Oct 27 08:41:19 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 26 Oct 2016 23:41:19 -0700 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: <201610270823.57812.marc.mutz@kdab.com> References: <2040035.tAy37G7WHk@tjmaciei-mobl1> <201610270823.57812.marc.mutz@kdab.com> Message-ID: <16424905.WZvKqLXPhv@tjmaciei-mobl1> On quinta-feira, 27 de outubro de 2016 08:23:57 PDT Marc Mutz wrote: > And, again, by proprietarily extending a perfectly adequate std > functionality, we lock ourselves deeper into our NIHS, losing new > functionality provided by newer std versions, in this case: variadic > std::min/max. Hm... you're actually right. We should use std::min and std::max since we can now rely on them existing and being properly implemented. I don't know a Standard Library equivalent of qBound, but I wasn't fixing that one due to too many permutations. We should drop qMin and qMax like we have the QtAlgorithms header. I trust you checked VS 2013 and Dinkumware. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at qt.io Thu Oct 27 08:50:15 2016 From: Kai.Koehne at qt.io (Kai Koehne) Date: Thu, 27 Oct 2016 06:50:15 +0000 Subject: [Development] QCS2016 Session Notes - QUIPs for Qt In-Reply-To: References: Message-ID: Hi, I'd like to request a QUIP number for the handling of 3rd party code in Qt repositories. Anyhow, it seems to me that we're stuck currently in the bootstrapping process of QUIPs: http://quips-qt-io.herokuapp.com/quip-0003.html >The minimum QUIP boostrapping process was discussed: > >1. Post QUIP 1 to qt-development mailing list for discussion. >2. Arrange for hosting of HTML generated from QUIPs (ed. note: quips.qt.io has since been made available) >3. Create new git repository to hold QUIPs So I'd like to request a gerrit repository for holding QUIPs, .e.g codereview.qt-project.org/qt/quips.git . Regards Kai > -----Original Message----- > From: Development [mailto:development-bounces+kai.koehne=qt.io at qt- > project.org] On Behalf Of Tero Kojo > Sent: Monday, September 26, 2016 9:01 AM > To: Louai Al-Khanji ; development at qt-project.org > Subject: Re: [Development] QCS2016 Session Notes - QUIPs for Qt > > Hi, > > This initiative is much appreciated, thank you Louai! > Having been in the session at QtCon, I don't have any problems with the > proposed format and process as outlined in the initial QUIPS. > > I'd like to request two QUIP numbers "Qt Community Code of Conduct", and > another one for "Code of Conduct for Qt Events". > I guess the repo isn't there yet, do we wait on the lazy agreement process > until it is created? > > Tero > > > -----Original Message----- > > From: Development [mailto:development-bounces+tero.kojo=qt.io at qt- > > project.org] On Behalf Of Louai Al-Khanji > > Sent: tiistai 20. syyskuuta 2016 1.45 > > To: development at qt-project.org > > Subject: [Development] QCS2016 Session Notes - QUIPs for Qt > > > > Hi all, > > > > Here are my notes from the QUIPs session. Thank you for your patience. > > :-) > > > > QUIPs are a proposed design process for Qt, modeled after Python’s PEPs. > > > > QUIP 1 introduces the general concept: > > > > http://quips-qt-io.herokuapp.com/quip-0001.html > > > > QUIP 2 details the Qt governance model, it’s simply the current wiki > > page converted into a QUIP: > > > > http://quips-qt-io.herokuapp.com/quip-0002.html > > > > QUIP 3 is an informational QUIP containing the session notes, which > > are repeated below: > > > > http://quips-qt-io.herokuapp.com/quip-0003.html > > > > The heroku domain is obviously a placeholder. > > > > I have also attached the source files for proposed QUIPs 1, 2, and 3 > > to this e- mail. > > > > One item left open was licensing of the QUIPs themselves. For these I > > propose Creative Commons CC0. > > > > Any and all feedback welcome. > > > > Cheers, > > Louai > > > > ---------------- BEGIN NOTES ---------------- > > > > At the Qt Contributors' Summit 2016 in Berlin a session was held to > > discuss the idea of introducing QUIPs as a new process for Qt governance. > > > > The general idea was introduced by looking at QUIPs 1 and 2, and by > > looking at some Python PEPs. The general feedback was positive. An > > attempt was made to identify the minimum set of work required to > > bootstrap QUIP, which was the main theme of the session. > > > > The overall discussion is summarized below, in roughly chronological order. > > > > - Discussed background of QUIP, the process and the documents. > > Referred to > > Python and looked at QUIP 1 and QUIP 2 which had been prepared prior > > to the > > session. > > > > - The idea is to have a new git repository with the QUIP text files > > > > - Managed through Qt's normal work flow, currently gerrit code > > review > > > > - The maintainer of the quips repository takes on required editorial > > duties > > - Agreed that the text documents should be limited to 80 character lines. > > > > - Agreed that care must be taken to ensure that QUIPs are written in > > "proper" > > English so as to be clear, understandable and concise. > > > > - Talked about how a new QUIP is introduced. The most important thing is > to > > reserve a number, which is the identifier of any one QUIP. The title can > > change, and is expected to do so from time to time. > > > > - New QUIP documents will go through a review process like any other > > patch to > > Qt. The author of the QUIP is responsible for logging this discussion in the > > evolving QUIP itself. > > > > - The important thing is to bootstrap the process. Once it is bootstrapped, it > > is possible to fine-tune the QUIP process through QUIPs. It is expected > that > > this will happen. > > > > - The question of what goes into a QUIP was discussed. QUIP 1 gives a > rough > > overview of the different kinds of possible QUIPs. It is expected that the > > content be further specified in revisions of QUIP 1 or in follow-up QUIPs. > > > > - Like any other part of Qt, QUIPs are living documents. They can be > updated, > > amended or entirely superseded by later ones. > > > > - QUIP licensing was discussed. Python's PEPs are required to be > > either placed > > in the public domain or licensed under the Open Publication License. The > > former is not possible in all jurisdictions and the latter has apparently > > been superseded by the Creative Commons licenses the CC0 license was > > suggested. > > > > - The minimum QUIP boostrapping process was discussed: > > > > 1. Post QUIP 1 to qt-development mailing list for discussion. > > > > 2. Arrange for hosting of HTML generated from QUIPs (ed. note: > quips.qt.io > > has since been made available) > > > > 3. Create new git repository to hold QUIPs > > > > - The initial QUIP process was discussed: > > > > 1. Author of QUIP reserves new number in QUIP 0 (the index QUIP) > through > > gerrit > > > > 2. The author gives notice of new QUIP by sending it to qt-development, > > either inline or as a text attachment (things like this can be refined > > later through QUIPs) > > > > 3. Concurrently the author pushes the draft to gerrit where further > > discussion can take place. This discussion must be described in the QUIP. > > > > 4. Decisions are achieved through the same lazy consensus mechanism > that > > is in place today. In that respect nothing changes. > > > > 5. A final +2 from the QUIP maintainer(s) is required. This differs slightly > > from other parts of Qt as only the maintainer(s) can +2 changes to this > > repository. > > > > - Louai naively volunteered to convert existing material on the wiki into a > > series of QUIPs. > > > > - There was a question whether community guidelines could be described > > in a > > QUIP. The answer is a resounding yes. > > > > - The QUIP lifecycle was discussed. The following two items were explored: > > > > 1. Superseding QUIPs. These are QUIPs that both change some > mechanism > > described in an earlier QUIP and change the content of that QUIP > > substantially. For small changes existing QUIPs can be updated. > > > > 2. Retroactive QUIPs are possible. That is to say, QUIPs can be written > > to describe a change that occured in the past. For instance, an > > Implementation Track QUIP can be written after something has been > > added. > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Thu Oct 27 09:50:00 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 27 Oct 2016 09:50:00 +0200 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: <16424905.WZvKqLXPhv@tjmaciei-mobl1> References: <201610270823.57812.marc.mutz@kdab.com> <16424905.WZvKqLXPhv@tjmaciei-mobl1> Message-ID: <201610270950.01174.marc.mutz@kdab.com> On Thursday 27 October 2016 08:41:19 Thiago Macieira wrote: > On quinta-feira, 27 de outubro de 2016 08:23:57 PDT Marc Mutz wrote: > > And, again, by proprietarily extending a perfectly adequate std > > functionality, we lock ourselves deeper into our NIHS, losing new > > functionality provided by newer std versions, in this case: variadic > > std::min/max. > > Hm... you're actually right. We should use std::min and std::max since we > can now rely on them existing and being properly implemented. I don't know > a Standard Library equivalent of qBound, but I wasn't fixing that one due > to too many permutations. > > We should drop qMin and qMax like we have the QtAlgorithms header. > > I trust you checked VS 2013 and Dinkumware. Well, we have no variadic qMin(), so existing qMin() uses will all be binary. And binary std::min() is C++98, which we require since Qt 5.0. Ergo, nothing to do, except check whether we rely on the corrected relation between min and max anywhere (for equivalent elements, min() should returnt the one max() does not, which IIRC qMin()/qMax() do, but, notably, std::min/max do not, unless they changed it in C++14+). 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 jedrzej.nowacki at qt.io Thu Oct 27 10:12:48 2016 From: jedrzej.nowacki at qt.io (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 27 Oct 2016 10:12:48 +0200 Subject: [Development] Coin news In-Reply-To: <20161026092828.GA4067@troll08> References: <201610260847.48967.marc.mutz@kdab.com> <20161026092828.GA4067@troll08> Message-ID: <15556696.4ukyrP6Bjy@42> On onsdag 26. oktober 2016 11.28.28 CEST Oswald Buddenhagen wrote: > that's indeed better in the optimal case: > 1. prepare downstream module and update upstream module > 2. have them integrated into qt5. make sure that the upstream update > does not go in before the downstream adjustment (you can generally > assume an atomic integration). > 3. clean up both modules > 4. have them integrated into qt5. make sure the upstream cleanup does > not go in before the downstream cleanup. The only problem is that you have to be sure to prepare downstream module right, because only one code path will be tested, but it is still ok. Btw. earlier by referring to a two steps process I meant that you need to > another good thing about this variant is that you can atomically fix > issues introduced due to signal/slot overloading, which you'd otherwise > have to do separately in advance, introducing yet another two-stage > integration. Yes. > a downside is that the history is messier, because there are inherently > at least two commits in every downstream module. and it may get even > more messy if you notice later in the process that you need to adjust > the downstreams further before the qt5 integration succeeds. that's > because the downstream integrations are basically dummies and you don't > notice that something went wrong until the qt5 integration which pulls > in the upstream change. I would not be worried about history too much, it just reflects the reality. I had idea to mitigate the late discovery problem by adding a 2nd job to CI that would do a fast qt5 incremental build check just on Linux. With proper setup (unionfs like partitions) and reduced load (that we've achieved) we could potentially run it for every patch set. Cheers, Jędrek From tor.arne.vestbo at qt.io Thu Oct 27 12:32:36 2016 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 27 Oct 2016 12:32:36 +0200 Subject: [Development] Coin news In-Reply-To: References: Message-ID: <81bff2cb-9bd9-4a19-cb59-d54682a6470e@qt.io> On 25/10/2016 09:22, Jedrzej Nowacki wrote: > I would like to also remind everyone, that intermodule API changes > need to be merged in two steps. For example if you plan to change a > method "void foo()" in qtbase to "void foo(const QString&)", that > would be the right order of execution: 1. Commit a change to qtbase > that _adds_ foo(const QString&) 2. Update all modules that use foo() > to use foo(const QString&) 3. Wait until Qt5(dev branch) submodule > update, that gathers changes from 1 and 2 4. Remove old foo() from > qtbase If you do not follow we would have to revert your changes. What happened to pinned sync.profile %dependencies? That seems like a much smoother workflow: 1. pin qtbase sha in dependent module 2. update qtbase, changing method in one go 3. update dependent module to use new api, along with an unpin qtbase sha This doesn't split the logical change in qtbase into two just to keep the world building. tor arne From tor.arne.vestbo at qt.io Thu Oct 27 14:13:59 2016 From: tor.arne.vestbo at qt.io (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Thu, 27 Oct 2016 14:13:59 +0200 Subject: [Development] Coin news In-Reply-To: <2334797.LBq0p9n6vn@42> References: <81bff2cb-9bd9-4a19-cb59-d54682a6470e@qt.io> <2334797.LBq0p9n6vn@42> Message-ID: On 27/10/2016 14:08, Jędrzej Nowacki wrote: >> What happened to pinned sync.profile %dependencies? That seems like a >> much smoother workflow: >> >> 1. pin qtbase sha in dependent module >> 2. update qtbase, changing method in one go >> 3. update dependent module to use new api, along with an unpin qtbase sha >> >> This doesn't split the logical change in qtbase into two just to keep >> the world building. >> >> tor arne > > The functionality was semi broken for last two years. So I assumed that nobody > was using it really. The feature got dropped together with sync.profile > support. It could be re-activated assuming that it would be worth it. Hmm, I've been using it with success, but it probably had some rough edges I didn't notice at the time. I do think such a way to track dependencies (with the sources, in the module and branch), with pinning, e.g [1], is a very nice thing to have. tor arne [1] http://guides.rubygems.org/patterns/#pessimistic-version-constraint From announce at qt-project.org Thu Oct 27 14:32:36 2016 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 27 Oct 2016 12:32:36 +0000 Subject: [Development] [Announce] Qt Creator 4.2 Beta1 released Message-ID: We are happy to announce the release of Qt Creator 4.2 Beta1 http://blog.qt.io/blog/2016/10/26/qt-creator-4-2-beta-released/ -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin eike.ziller at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From a.volkov at rusbitech.ru Thu Oct 27 15:43:59 2016 From: a.volkov at rusbitech.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCS0L7Qu9C60L7Qsg==?=) Date: Thu, 27 Oct 2016 16:43:59 +0300 Subject: [Development] Branch for adding Q_DECL_OVERRIDEs Message-ID: <5812049F.3070303@rusbitech.ru> Hi all, Many methods are still missing 'override' specifier. You can find them by compiling with gcc's -Wsuggest-override. It improves code readability and helps to find unused code (e.g. https://codereview.qt-project.org/#/c/174370/ ) Are there plans about adding 'override' or 'Q_DECL_OVERRIDE' and which branch is preferred for such changes? Best regards, Alexander. From giuseppe.dangelo at kdab.com Thu Oct 27 15:51:37 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 27 Oct 2016 15:51:37 +0200 Subject: [Development] Branch for adding Q_DECL_OVERRIDEs In-Reply-To: <5812049F.3070303@rusbitech.ru> References: <5812049F.3070303@rusbitech.ru> Message-ID: <757c17ba-46e3-4622-c014-d869d1827b58@kdab.com> Il 27/10/2016 15:43, Александр Волков ha scritto: > Are there plans about adding 'override' or 'Q_DECL_OVERRIDE' > and which branch is preferred for such changes? They should be added everywhere (because they cost nothing, and they allow us to catch bugs), but they should especially added in places that generate warnings (due to "inconsistent" usage). The right branch for all of these fixes is the oldest branch which is 1) still open, and 2) where the fix applies. For qtsvg the open branches are 5.6, 5.7, 5.8, dev; so pick the oldest one where your fix applies (likely 5.6). Hope this helps, -- 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 Oct 27 17:25:34 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 27 Oct 2016 08:25:34 -0700 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: <201610270950.01174.marc.mutz@kdab.com> References: <16424905.WZvKqLXPhv@tjmaciei-mobl1> <201610270950.01174.marc.mutz@kdab.com> Message-ID: <2353046.86kVkOr2Un@tjmaciei-mobl1> On quinta-feira, 27 de outubro de 2016 09:50:00 PDT Marc Mutz wrote: > (for equivalent elements, min() should returnt > the one max() does not, which IIRC qMin()/qMax() do, but, notably, > std::min/max do not, unless they changed it in C++14+). If they're equal, they're equal. Making a distinction between which one it returns if they're equal implies the type was badly designed in the first place... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From giuseppe.dangelo at kdab.com Thu Oct 27 18:35:37 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Thu, 27 Oct 2016 18:35:37 +0200 Subject: [Development] Branch for adding Q_DECL_OVERRIDEs In-Reply-To: <581221AB.8050109@rusbitech.ru> References: <5812049F.3070303@rusbitech.ru> <757c17ba-46e3-4622-c014-d869d1827b58@kdab.com> <581217A7.9080706@rusbitech.ru> <5d929fcc-61bd-19ba-27be-00b5fccf23bd@kdab.com> <581221AB.8050109@rusbitech.ru> Message-ID: <3b91f415-a4c9-e2da-9452-4f004820ffa7@kdab.com> Hi, please keep the discussion on the mailing list, so others can chime in. Il 27/10/2016 17:47, Александр Волков ha scritto: > 27.10.2016 18:19, Giuseppe D'Angelo пишет: >> Don't worry too much. To minimize merge conflicts I'm quite sure we'll >> keep using Q_DECL_OVERRIDE as long as 5.6 will be open. So use that :) >> We'll do a cleanup pass in the future. > > BTW, should 'override' be added in the following case: > struct A { > virtual void f(); > }; > struct B : A { > void f() final; // override also? > }; > ? > > Unfortunately gcc reports a warning for f() > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010) > There some such places in Qt, for example in > corelib/kernel/qeventdispatcher_glib_p.h, > where Q_DECL_OVERRIDE should be added to make it compilable with gcc > [-Werror, -Wsuggest-override]. > The question is whether to follow a reasonable style > https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override > or a style forced by gcc? To be honest I don't know if we have a consensus on this. (How many cases of "final" in our classes do we have anyhow?) 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 rolland at ghs.com Thu Oct 27 18:43:39 2016 From: rolland at ghs.com (Rolland Dudemaine) Date: Thu, 27 Oct 2016 16:43:39 +0000 Subject: [Development] Branch for adding Q_DECL_OVERRIDEs Message-ID: Using the GHS compiler, i see thousands of examples of this. To the point that (bad practice warning!) I disabled the warning. --Rolland ________________________________ De: Giuseppe D'Angelo Envoyé: 27 oct. 2016 18:36 À: Александр Волков; development at qt-project.org Objet: Re: [Development] Branch for adding Q_DECL_OVERRIDEs Hi, please keep the discussion on the mailing list, so others can chime in. Il 27/10/2016 17:47, Александр Волков ha scritto: > 27.10.2016 18:19, Giuseppe D'Angelo пишет: >> Don't worry too much. To minimize merge conflicts I'm quite sure we'll >> keep using Q_DECL_OVERRIDE as long as 5.6 will be open. So use that :) >> We'll do a cleanup pass in the future. > > BTW, should 'override' be added in the following case: > struct A { > virtual void f(); > }; > struct B : A { > void f() final; // override also? > }; > ? > > Unfortunately gcc reports a warning for f() > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010) > There some such places in Qt, for example in > corelib/kernel/qeventdispatcher_glib_p.h, > where Q_DECL_OVERRIDE should be added to make it compilable with gcc > [-Werror, -Wsuggest-override]. > The question is whether to follow a reasonable style > https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override > or a style forced by gcc? To be honest I don't know if we have a consensus on this. (How many cases of "final" in our classes do we have anyhow?) 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 -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Thu Oct 27 18:45:36 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 27 Oct 2016 19:45:36 +0300 Subject: [Development] Branch for adding Q_DECL_OVERRIDEs In-Reply-To: References: Message-ID: <91461477586736@web24g.yandex.ru> 27.10.2016, 19:44, "Rolland Dudemaine" : > Using the GHS compiler, i see thousands of examples of this. > To the point that (bad practice warning!) I disabled the warning. Better take clang-tidy and fix up things automatically > > --Rolland > ---------------------------------------- > De: Giuseppe D'Angelo > Envoyé: 27 oct. 2016 18:36 > À: Александр Волков; development at qt-project.org > Objet: Re: [Development] Branch for adding Q_DECL_OVERRIDEs > >> Hi, >> >> please keep the discussion on the mailing list, so others can chime in. >> >> Il 27/10/2016 17:47, Александр Волков ha scritto: >>> 27.10.2016 18:19, Giuseppe D'Angelo пишет: >>>> Don't worry too much. To minimize merge conflicts I'm quite sure we'll >>>> keep using Q_DECL_OVERRIDE as long as 5.6 will be open. So use that :) >>>> We'll do a cleanup pass in the future. >>> >>> BTW, should 'override' be added in the following case: >>> struct A { >>>    virtual void f(); >>> }; >>> struct B : A { >>>    void f() final; // override also? >>> }; >>> ? >>> >>> Unfortunately gcc reports a warning for f() >>> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010) >>> There some such places in Qt, for example in >>> corelib/kernel/qeventdispatcher_glib_p.h, >>> where Q_DECL_OVERRIDE should be added to make it compilable with gcc >>> [-Werror, -Wsuggest-override]. >>> The question is whether to follow a reasonable style >>> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override >>> or a style forced by gcc? >> >> To be honest I don't know if we have a consensus on this. (How many >> cases of "final" in our classes do we have anyhow?) >> >> 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 > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From edward.welbourne at qt.io Thu Oct 27 18:49:42 2016 From: edward.welbourne at qt.io (Edward Welbourne) Date: Thu, 27 Oct 2016 16:49:42 +0000 Subject: [Development] Branch for adding Q_DECL_OVERRIDEs In-Reply-To: <3b91f415-a4c9-e2da-9452-4f004820ffa7@kdab.com> References: <5812049F.3070303@rusbitech.ru> <757c17ba-46e3-4622-c014-d869d1827b58@kdab.com> <581217A7.9080706@rusbitech.ru> <5d929fcc-61bd-19ba-27be-00b5fccf23bd@kdab.com> <581221AB.8050109@rusbitech.ru>, <3b91f415-a4c9-e2da-9452-4f004820ffa7@kdab.com> Message-ID: Giuseppe D'Angelo said: > To be honest I don't know if we have a consensus on this. (How many > cases of "final" in our classes do we have anyhow?) 43 in qtbase, all marking a class or struct as final. Otherwise, "final" is only used in comments; never to mark a method. ... that I can see, in qtbase, using crude grep and by-eye filtering. If we have macros to complicate life, I'll have missed the results, Eddy. From Marco.Bubke at qt.io Thu Oct 27 19:49:09 2016 From: Marco.Bubke at qt.io (Marco Bubke) Date: Thu, 27 Oct 2016 17:49:09 +0000 Subject: [Development] Branch for adding Q_DECL_OVERRIDEs In-Reply-To: <3b91f415-a4c9-e2da-9452-4f004820ffa7@kdab.com> References: <5812049F.3070303@rusbitech.ru> <757c17ba-46e3-4622-c014-d869d1827b58@kdab.com> <581217A7.9080706@rusbitech.ru> <5d929fcc-61bd-19ba-27be-00b5fccf23bd@kdab.com> <581221AB.8050109@rusbitech.ru> <3b91f415-a4c9-e2da-9452-4f004820ffa7@kdab.com> Message-ID: Final can be used by the compiler by optimazing the virtual call away but it has the drawback that you cannot overload it in testing code to mock or fake a class. On October 27, 2016 18:36:01 Giuseppe D'Angelo wrote: > Hi, > > please keep the discussion on the mailing list, so others can chime in. > > Il 27/10/2016 17:47, Александр Волков ha scritto: >> 27.10.2016 18:19, Giuseppe D'Angelo пишет: >>> Don't worry too much. To minimize merge conflicts I'm quite sure we'll >>> keep using Q_DECL_OVERRIDE as long as 5.6 will be open. So use that :) >>> We'll do a cleanup pass in the future. >> >> BTW, should 'override' be added in the following case: >> struct A { >> virtual void f(); >> }; >> struct B : A { >> void f() final; // override also? >> }; >> ? >> >> Unfortunately gcc reports a warning for f() >> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78010) >> There some such places in Qt, for example in >> corelib/kernel/qeventdispatcher_glib_p.h, >> where Q_DECL_OVERRIDE should be added to make it compilable with gcc >> [-Werror, -Wsuggest-override]. >> The question is whether to follow a reasonable style >> https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override >> or a style forced by gcc? > > To be honest I don't know if we have a consensus on this. (How many > cases of "final" in our classes do we have anyhow?) > > 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 > From thiago.macieira at intel.com Thu Oct 27 20:13:43 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 27 Oct 2016 11:13:43 -0700 Subject: [Development] Branch for adding Q_DECL_OVERRIDEs In-Reply-To: <5812049F.3070303@rusbitech.ru> References: <5812049F.3070303@rusbitech.ru> Message-ID: <1516965.3ZG8LCHyAW@tjmaciei-mobl1> On quinta-feira, 27 de outubro de 2016 16:43:59 PDT Александр Волков wrote: > Hi all, > > Many methods are still missing 'override' specifier. > You can find them by compiling with gcc's -Wsuggest-override. > It improves code readability and helps to find unused code > (e.g. https://codereview.qt-project.org/#/c/174370/ ) > Are there plans about adding 'override' or 'Q_DECL_OVERRIDE' > and which branch is preferred for such changes? I would prefer we did not add Q_DECL_OVERRIDE at all to current code. We may add "override" if that keyword is allowed by all compilers, otherwise leave it as it is. GCC and Clang support a warning for "inconsistent override", which is caused by having some overridden methods marked but not others. So the recommendation is: 1) for new classes, always mark with Q_DECL_OVERRIDE 2) for existing classes, if possible use Q_DECL_OVERRIDE, but be careful to be consistent (be careful with #ifdef'ed functions too!). It's ok to add a handful of other Q_DECL_OVERRIDE to other functions in the same class, but don't do it if it uglifies your patch. Instead, leave it out. 3) if you get an inconsistent override use warning, fix it Note that only #3 applies to the 5.6 branch. You can't add new public classes or public methods in 5.6 or 5.7. And you should not be adding even new, private, polymorphic classes in those branch. And there's only a short window while that is permitted in 5.8 too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Thu Oct 27 22:49:13 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 27 Oct 2016 22:49:13 +0200 Subject: [Development] Compile errors, Qt configured with -qreal float References: <2101779.fnLOf9PaFa@tjmaciei-mobl1> <24535acc50f7e02457f1d62c3f829b97@kdab.com> Message-ID: Sergio Martins wrote: > The real issue understanding is "why don't users contribute trivial > changes that they need". > > You see it all the time: > > - users complaining on a JIRA bug for 2 years instead of submitting a > one-liner > - users reporting wiki typo instead of editing wiki > - users refusing to contribute because "I'm not a Qt developer" > - users feeling entitled to a warranty > - users not understanding that the qt-project has different > responsibilities than TQC > > > Ofc, this is not about Ola Thorsten, it's about our project and how we > communicate with users. There is one main reason for that: the CLA. The high barrier to entry of Gerrit (need to use some arcane command lines to submit the patch to the correct place, vs. uploading a patch to a web interface in e.g. ReviewBoard, or the pull request workflow people are used to nowadays) does not help either. (But this is kinda off topic because Ola Thorsten actually submitted the trivial fixes.) Kevin Kofler From kevin.kofler at chello.at Thu Oct 27 22:54:16 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 27 Oct 2016 22:54:16 +0200 Subject: [Development] Compile errors, Qt configured with -qreal float References: <2040035.tAy37G7WHk@tjmaciei-mobl1> <201610270823.57812.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > And, again, by proprietarily extending a perfectly adequate std > functionality, we lock ourselves deeper into our NIHS, losing new > functionality provided by newer std versions, in this case: variadic > std::min/max. So once again you want to artificially restrict what Qt does and block a convenient improvement just because the STL doesn't have it. :-( And then you go and claim the Qt implementation has no benefits over the STL one, which is no wonder if you prevent any from going in. And then, you yourself wrote: > for equivalent elements, min() should returnt the one max() does not, > which IIRC qMin()/qMax() do, but, notably, std::min/max do not, unless > they changed it in C++14+ which means that the STL versions are NOT "perfectly adequate". And just like Alexander Nassian, I also think consistent APIs (no std::*) should be a goal. Kevin Kofler From tony.sarajarvi at qt.io Fri Oct 28 12:48:09 2016 From: tony.sarajarvi at qt.io (=?iso-8859-2?Q?Tony_Saraj=E4rvi?=) Date: Fri, 28 Oct 2016 10:48:09 +0000 Subject: [Development] Coin update In-Reply-To: References: Message-ID: Pardon... we forgot to trigger a garbage collector so the Coin is down for a while. Should come up in a moment. Aplogies for the disturbance. -Tony > -----Original Message----- > From: Development [mailto:development- > bounces+tony.sarajarvi=qt.io at qt-project.org] On Behalf Of Jedrzej Nowacki > Sent: 25. lokakuuta 2016 15:52 > To: development at qt-project.org > Subject: Re: [Development] Coin update > > Hi, > > The update went terribly wrong. We essentially lost the machine, because > of a snapshot which corrupted partition. We needed to reinstall everything. > The machinery is running now, but it doesn't accept standard builds until we > reconstruct cache (qt5 builds for all active branches). It can take 2-3 hours. > > Sorry for the inconvenience. > > Cheers, > Jędrek > ________________________________________ > From: Development project.org> on behalf of Jedrzej Nowacki > Sent: Tuesday, October 25, 2016 9:26:02 AM > To: development at qt-project.org > Subject: [Development] Coin update > > Hi, > We need to update the Coin server, so the service will be interrupted for a > while today. Sorry for the short notice. > Cheers, > Jędrek > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From marc.mutz at kdab.com Fri Oct 28 13:14:07 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 28 Oct 2016 13:14:07 +0200 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: References: <201610270823.57812.marc.mutz@kdab.com> Message-ID: <201610281314.08079.marc.mutz@kdab.com> On Thursday 27 October 2016 22:54:16 Kevin Kofler wrote: > Marc Mutz wrote: > > And, again, by proprietarily extending a perfectly adequate std > > functionality, we lock ourselves deeper into our NIHS, losing new > > functionality provided by newer std versions, in this case: variadic > > std::min/max. > > So once again you want to artificially restrict what Qt does and block a > convenient improvement just because the STL doesn't have it. :-( Yes, because the improvement, if it is one, should be made to std::min(), not qMin(). If it is an improvement, it will pass muster in the committee. If it isn't, it doesn't, and qMin() shouldn't have such a non-improvement, either. > which means that the STL versions are NOT "perfectly adequate". They are. It took two decades for this bug to be noticed, and while it should be fixed, in std2, probably, code that relies on either behaviour must atm be considered buggy. 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 abbapoh at gmail.com Fri Oct 28 14:31:39 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Fri, 28 Oct 2016 15:31:39 +0300 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: <201610281314.08079.marc.mutz@kdab.com> References: <201610270823.57812.marc.mutz@kdab.com> <201610281314.08079.marc.mutz@kdab.com> Message-ID: But is's not fixed yet? 2016-10-28 14:14 GMT+03:00 Marc Mutz : > > They are. It took two decades for this bug to be noticed, and while it > should > be fixed, in std2, probably, code that relies on either behaviour must atm > be > considered buggy. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri Oct 28 20:05:02 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 28 Oct 2016 20:05:02 +0200 Subject: [Development] Compile errors, Qt configured with -qreal float In-Reply-To: References: <201610281314.08079.marc.mutz@kdab.com> Message-ID: <201610282005.03407.marc.mutz@kdab.com> On Friday 28 October 2016 14:31:39 Иван Комиссаров wrote: > But is's not fixed yet? I didn't look into C++17, but I'd be surprised if it was changed in std. I'd expect such a change in std2, when it happens. Thanks, Marc > 2016-10-28 14:14 GMT+03:00 Marc Mutz : > > They are. It took two decades for this bug to be noticed, and while it > > should > > be fixed, in std2, probably, code that relies on either behaviour must > > atm be > > considered buggy. -- 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 kollix at aon.at Sat Oct 29 09:14:24 2016 From: kollix at aon.at (Martin Koller) Date: Sat, 29 Oct 2016 09:14:24 +0200 Subject: [Development] Qt / NaCl / emscripten Message-ID: <1755711.mHmzcoAJ6W@lapi.koller> Hi, I wanted to give WebAssembly a try and wanted to compile wip/nacl with emscripten. However, compilation fails as it seems some files of pepper are missing here, e.g. pepper_55/src/ppapi_cpp/font_dev.cc I tried with 3 different pepper versions (44, 49, 55). None of these could compile since every one was missing a file (not always the same). Can you tell us with which version it should be able to compile ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From sean.harmer at kdab.com Sun Oct 30 10:03:59 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Sun, 30 Oct 2016 09:03:59 +0000 Subject: [Development] Distributing 3rd party closed source libs Message-ID: Hi, a very common request is for Qt 3D to support the Autodesk FBX file format which is a pretty standard format for exchanging 3D meshes, and animations. Unfortunately the format is undocumented and proprietary but Autodesk does provide a free (as in beer) SDK that can be used to parse FBX files. Guillermo and Mauro have been making the QMesh geometry loading component plugin based to help support more formats. One of the formats we'd like to support is FBX. For developers building from git, this is manageable, although not ideal, by downloading the fbx sdk and pointing the build at it. What can we do in terms of pre-compiled release builds of Qt? Is it feasible for us to distribute the runtime lib required by the plugin from the fbx SDK? Or do we need to find some other solution such as build the plugin for the release packages but require the user to install the fbx SDK? I guess this is similar to the database driver plugins. 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 rich at kde.org Sun Oct 30 12:36:14 2016 From: rich at kde.org (Richard Moore) Date: Sun, 30 Oct 2016 11:36:14 +0000 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: References: Message-ID: On 30 October 2016 at 09:03, Sean Harmer wrote: > What can we do in terms of pre-compiled release builds of Qt? Is it > feasible for us to distribute the runtime lib required by the plugin from > the fbx SDK? Or do we need to find some other solution such as build the > plugin for the release packages but require the user to install the fbx SDK? > ​​The database plugins need to be compiled separately iirc, but another option would be to dlopen the autodesk shared library. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sun Oct 30 18:11:31 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 30 Oct 2016 10:11:31 -0700 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: References: Message-ID: <2158717.MPJuvCE9X9@tjmaciei-mobl1> On domingo, 30 de outubro de 2016 09:03:59 PDT Sean Harmer wrote: > I guess this is similar to the database driver plugins. Right. We ship the compiled plugins for both MySQL and PostgreSQL, but not their libraries, so the plugins can't be loaded unless the user installs the required client libraries (and in the case of MySQL, since they change the soname often, it's a difficult proposal). We do not ship compiled plugins for the proprietary databases, like OCI, Interbase and TDS. People who want one of those can download the sources and compile themselves. That's just the plugin, no need to recompile all of Qt. With my OSS hat on, I would say we shouldn't ship even a non-working binary. People who want it should download the source for the module and compile themselves. It is, after all, just a qmake && make. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From cgilbert at knaldtech.com Mon Oct 31 01:48:30 2016 From: cgilbert at knaldtech.com (Chris Gilbert) Date: Sun, 30 Oct 2016 17:48:30 -0700 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: <2158717.MPJuvCE9X9@tjmaciei-mobl1> References: <2158717.MPJuvCE9X9@tjmaciei-mobl1> Message-ID: Greetings, We use both QT5 and the Autodesk FBX loader in our application - and we would strongly prefer Qt to NOT link it in. There is a need quite often for us to update the Autodesk FBX SDK asymmetrically to QT, and it would be preferable QT doesn't use it in order to avoid potential conflicts. Also, I believe there is a provision in the Autodesk FBX library which forbids inclusion in free/open source software. (Anti-blender provision) As a result, I believe Blender and some other applications (UE4) have done their own implementation, perhaps QT could borrow from that? Thanks, Chris Gilbert Knald Technologies, LLC On 10/30/2016 10:11 AM, Thiago Macieira wrote: > On domingo, 30 de outubro de 2016 09:03:59 PDT Sean Harmer wrote: >> I guess this is similar to the database driver plugins. > Right. > > We ship the compiled plugins for both MySQL and PostgreSQL, but not their > libraries, so the plugins can't be loaded unless the user installs the > required client libraries (and in the case of MySQL, since they change the > soname often, it's a difficult proposal). > > We do not ship compiled plugins for the proprietary databases, like OCI, > Interbase and TDS. People who want one of those can download the sources and > compile themselves. That's just the plugin, no need to recompile all of Qt. > > With my OSS hat on, I would say we shouldn't ship even a non-working binary. > People who want it should download the source for the module and compile > themselves. It is, after all, just a qmake && make. > From Morten.Sorvig at qt.io Mon Oct 31 09:35:03 2016 From: Morten.Sorvig at qt.io (Morten Sorvig) Date: Mon, 31 Oct 2016 08:35:03 +0000 Subject: [Development] Qt / NaCl / emscripten Message-ID: > On 29 Oct 2016, at 09:14, Martin Koller wrote: > > Hi, > > I wanted to give WebAssembly a try and wanted to compile wip/nacl with emscripten. > However, compilation fails as it seems some files of pepper are missing here, > e.g. pepper_55/src/ppapi_cpp/font_dev.cc > > I tried with 3 different pepper versions (44, 49, 55). > None of these could compile since every one was missing a file (not always the same). Looking at my local build I have pepper_47 here. In general, try removing the missing file from the build (see pepper.js.pri); it might not be needed. Morten From sean.harmer at kdab.com Mon Oct 31 10:08:06 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 31 Oct 2016 09:08:06 +0000 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: References: <2158717.MPJuvCE9X9@tjmaciei-mobl1> Message-ID: Hi, On 31/10/2016 00:48, Chris Gilbert wrote: > Greetings, > > We use both QT5 and the Autodesk FBX loader in our application - and we > would strongly prefer Qt to NOT link it in. > > There is a need quite often for us to update the Autodesk FBX SDK > asymmetrically to QT, and it would be preferable QT doesn't use it in > order to avoid potential conflicts. > > Also, I believe there is a provision in the Autodesk FBX library which > forbids inclusion in free/open source software. > (Anti-blender provision) > > As a result, I believe Blender and some other applications (UE4) have > done their own implementation, perhaps QT could borrow from that? Yeah, trouble with that approach is we are always chasing feature support and we'd rather focus efforts elsewhere. The options look like: * Provide a precompiled plugin like Qt does for the mysql/postgres database driver plugins but which requires the user to install the fbx dll's. * Source only plugin to allow users to easily build it against the fbx sdk. * dlopen the fbx lib from a plugin. We do not intend to ship the fbx sdk or compile it in or link it directly to Qt for the reasons you mention. Cheers, Sean ps Thanks for the Lys tool. Really useful and I use it a lot. :) > > Thanks, > Chris Gilbert > Knald Technologies, LLC > > On 10/30/2016 10:11 AM, Thiago Macieira wrote: >> On domingo, 30 de outubro de 2016 09:03:59 PDT Sean Harmer wrote: >>> I guess this is similar to the database driver plugins. >> Right. >> >> We ship the compiled plugins for both MySQL and PostgreSQL, but not their >> libraries, so the plugins can't be loaded unless the user installs the >> required client libraries (and in the case of MySQL, since they change >> the >> soname often, it's a difficult proposal). >> >> We do not ship compiled plugins for the proprietary databases, like OCI, >> Interbase and TDS. People who want one of those can download the >> sources and >> compile themselves. That's just the plugin, no need to recompile all >> of Qt. >> >> With my OSS hat on, I would say we shouldn't ship even a non-working >> binary. >> People who want it should download the source for the module and compile >> themselves. It is, after all, just a qmake && make. >> > > _______________________________________________ > 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 lars.knoll at qt.io Mon Oct 31 10:22:34 2016 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 31 Oct 2016 09:22:34 +0000 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: References: <2158717.MPJuvCE9X9@tjmaciei-mobl1> Message-ID: On 31/10/16 10:08, "Development on behalf of Sean Harmer" wrote: >Hi, > >On 31/10/2016 00:48, Chris Gilbert wrote: >> Greetings, >> >> We use both QT5 and the Autodesk FBX loader in our application - and we >> would strongly prefer Qt to NOT link it in. >> >> There is a need quite often for us to update the Autodesk FBX SDK >> asymmetrically to QT, and it would be preferable QT doesn't use it in >> order to avoid potential conflicts. >> >> Also, I believe there is a provision in the Autodesk FBX library which >> forbids inclusion in free/open source software. >> (Anti-blender provision) >> >> As a result, I believe Blender and some other applications (UE4) have >> done their own implementation, perhaps QT could borrow from that? > >Yeah, trouble with that approach is we are always chasing feature >support and we'd rather focus efforts elsewhere. The options look like: > >* Provide a precompiled plugin like Qt does for the mysql/postgres >database driver plugins but which requires the user to install the fbx >dll's. > >* Source only plugin to allow users to easily build it against the fbx sdk. > >* dlopen the fbx lib from a plugin. > >We do not intend to ship the fbx sdk or compile it in or link it >directly to Qt for the reasons you mention. We’re facing the same problem in a couple of places in Qt. For postgres/mysql we provide a precompiles plugin, but don’t ship the client libs which has proven to be problematic, as users wonder why it doesn’t work, or because of BC issues on Windows. Other SQL plugins such as Oracle or DB2 are only reachable through compiling the source code. Unfortunately we don’t make that easy currently, as these plugins are shipped as part of qtbase, not as a standalone package. It might make sense to rethink this, and provide those plugins as standalone source packages, that can be easily compiled within creator by our users. That would of probably also require that they live in a repository separate from qtbase (for SQL) or qt3d (in your case). Cheers, Lars > >Cheers, > >Sean > >ps Thanks for the Lys tool. Really useful and I use it a lot. :) > >> >> Thanks, >> Chris Gilbert >> Knald Technologies, LLC >> >> On 10/30/2016 10:11 AM, Thiago Macieira wrote: >>> On domingo, 30 de outubro de 2016 09:03:59 PDT Sean Harmer wrote: >>>> I guess this is similar to the database driver plugins. >>> Right. >>> >>> We ship the compiled plugins for both MySQL and PostgreSQL, but not their >>> libraries, so the plugins can't be loaded unless the user installs the >>> required client libraries (and in the case of MySQL, since they change >>> the >>> soname often, it's a difficult proposal). >>> >>> We do not ship compiled plugins for the proprietary databases, like OCI, >>> Interbase and TDS. People who want one of those can download the >>> sources and >>> compile themselves. That's just the plugin, no need to recompile all >>> of Qt. >>> >>> With my OSS hat on, I would say we shouldn't ship even a non-working >>> binary. >>> People who want it should download the source for the module and compile >>> themselves. It is, after all, just a qmake && make. >>> >> >> _______________________________________________ >> 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 >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From sh at theharmers.co.uk Mon Oct 31 14:06:04 2016 From: sh at theharmers.co.uk (Sean Harmer) Date: Mon, 31 Oct 2016 13:06:04 +0000 Subject: [Development] Distributing 3rd party closed source libs In-Reply-To: References: <2158717.MPJuvCE9X9@tjmaciei-mobl1> Message-ID: <4ceeae28-2a26-d636-ef54-29c034d60815@theharmers.co.uk> Hi Lars, On 31/10/2016 09:22, Lars Knoll wrote: > > > On 31/10/16 10:08, "Development on behalf of Sean Harmer" wrote: > >> Hi, >> >> On 31/10/2016 00:48, Chris Gilbert wrote: >>> Greetings, >>> >>> We use both QT5 and the Autodesk FBX loader in our application - and we >>> would strongly prefer Qt to NOT link it in. >>> >>> There is a need quite often for us to update the Autodesk FBX SDK >>> asymmetrically to QT, and it would be preferable QT doesn't use it in >>> order to avoid potential conflicts. >>> >>> Also, I believe there is a provision in the Autodesk FBX library which >>> forbids inclusion in free/open source software. >>> (Anti-blender provision) >>> >>> As a result, I believe Blender and some other applications (UE4) have >>> done their own implementation, perhaps QT could borrow from that? >> >> Yeah, trouble with that approach is we are always chasing feature >> support and we'd rather focus efforts elsewhere. The options look like: >> >> * Provide a precompiled plugin like Qt does for the mysql/postgres >> database driver plugins but which requires the user to install the fbx >> dll's. >> >> * Source only plugin to allow users to easily build it against the fbx sdk. >> >> * dlopen the fbx lib from a plugin. >> >> We do not intend to ship the fbx sdk or compile it in or link it >> directly to Qt for the reasons you mention. > > We’re facing the same problem in a couple of places in Qt. For postgres/mysql we provide a precompiles plugin, but don’t ship the client libs which has proven to be problematic, as users wonder why it doesn’t work, or because of BC issues on Windows. > > Other SQL plugins such as Oracle or DB2 are only reachable through compiling the source code. Unfortunately we don’t make that easy currently, as these plugins are shipped as part of qtbase, not as a standalone package. > > It might make sense to rethink this, and provide those plugins as standalone source packages, that can be easily compiled within creator by our users. That would of probably also require that they live in a repository separate from qtbase (for SQL) or qt3d (in your case). I like that idea. We could add those repos as source only options to the Qt SDK installer to make it easy for end user developers. To this end, could somebody create us a qt3d-plugins git repo and gerrit project please? Many thanks, Sean From rafael.roquetto at kdab.com Mon Oct 31 18:58:00 2016 From: rafael.roquetto at kdab.com (Rafael Roquetto) Date: Mon, 31 Oct 2016 15:58:00 -0200 Subject: [Development] Nominating James McDonnell for approver status Message-ID: <20161031175759.GA19662@polaris.localdomain> Hello, I would like to propose the nomination of James McDonnell for approver status. James works at QNX and has been actively contributing with the maintenance of Qt on QNX. Apart from all the patches he submitted and general bugfixing, he has also been a very good helping hand when it comes to testing pre-release versions of Qt on QNX. Kind regards, 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3599 bytes Desc: not available URL: