From aleixpol at kde.org Sat Jan 2 03:52:35 2016 From: aleixpol at kde.org (Aleix Pol) Date: Sat, 2 Jan 2016 03:52:35 +0100 Subject: [Development] Qt WebKit dependency in Qt Assistant Message-ID: Hi, One of the big news lately is the deprecation of Qt WebKit module. One of the Qt dependencies on it is assistant (which is a tool I use quite often, really) and AFAIK it's using it quite thoroughly. It used to be powered by QTextBrowser though, as far as I remember. What's the plan there? Regards, Aleix From suy at badopi.org Sat Jan 2 10:07:28 2016 From: suy at badopi.org (Alejandro Exojo) Date: Sat, 2 Jan 2016 10:07:28 +0100 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: References: Message-ID: <201601021007.28247.suy@badopi.org> El Saturday 02 January 2016, Aleix Pol escribió: > Hi, > One of the big news lately is the deprecation of Qt WebKit module. > > One of the Qt dependencies on it is assistant (which is a tool I use > quite often, really) and AFAIK it's using it quite thoroughly. It used > to be powered by QTextBrowser though, as far as I remember. > > What's the plan there? It can be compiled to use QTextBrowser instead of WebKit, and it received some commits a year ago to improve that abstraction: http://code.qt.io/cgit/qt/qttools.git/commit/?id=dd45163e883d9db55ce0361db81b96a0c0f97bd7 http://code.qt.io/cgit/qt/qttools.git/commit/?id=008926f193ceb29da6ca94fae6a7efb3ca0e0f09 No WebEngine support for now, though. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net From kollix at aon.at Sat Jan 2 12:38:54 2016 From: kollix at aon.at (Martin Koller) Date: Sat, 02 Jan 2016 12:38:54 +0100 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: <201601021007.28247.suy@badopi.org> References: <201601021007.28247.suy@badopi.org> Message-ID: <1650974.jJlmPADSSI@lapi.koller> On Saturday 02 January 2016 10:07:28 Alejandro Exojo wrote: > El Saturday 02 January 2016, Aleix Pol escribió: > > Hi, > > One of the big news lately is the deprecation of Qt WebKit module. > > > > One of the Qt dependencies on it is assistant (which is a tool I use > > quite often, really) and AFAIK it's using it quite thoroughly. It used > > to be powered by QTextBrowser though, as far as I remember. > > > > What's the plan there? > > It can be compiled to use QTextBrowser instead of WebKit, and it received some > commits a year ago to improve that abstraction: ... and I hope this is not the final plan (using QTextBrowser instead of a real HTML engine), since then our help pages (we integrated assistant into our product) would no longer render correctly. -- 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 thiago.macieira at intel.com Sat Jan 2 14:55:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 02 Jan 2016 11:55:41 -0200 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: <1650974.jJlmPADSSI@lapi.koller> References: <201601021007.28247.suy@badopi.org> <1650974.jJlmPADSSI@lapi.koller> Message-ID: <3151077.AAmOysVcun@tjmaciei-mobl4> On Saturday 02 January 2016 12:38:54 Martin Koller wrote: > On Saturday 02 January 2016 10:07:28 Alejandro Exojo wrote: > > El Saturday 02 January 2016, Aleix Pol escribió: > > > Hi, > > > One of the big news lately is the deprecation of Qt WebKit module. > > > > > > One of the Qt dependencies on it is assistant (which is a tool I use > > > quite often, really) and AFAIK it's using it quite thoroughly. It used > > > to be powered by QTextBrowser though, as far as I remember. > > > > > > What's the plan there? > > > > It can be compiled to use QTextBrowser instead of WebKit, and it received > > some > > commits a year ago to improve that abstraction: > ... and I hope this is not the final plan (using QTextBrowser instead of a > real HTML engine), since then our help pages (we integrated assistant into > our product) would no longer render correctly. You can still use QtWebKit. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From suy at badopi.org Sat Jan 2 15:53:59 2016 From: suy at badopi.org (Alejandro Exojo) Date: Sat, 2 Jan 2016 15:53:59 +0100 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: <1650974.jJlmPADSSI@lapi.koller> References: <201601021007.28247.suy@badopi.org> <1650974.jJlmPADSSI@lapi.koller> Message-ID: <201601021553.59951.suy@badopi.org> El Saturday 02 January 2016, Martin Koller escribió: > ... and I hope this is not the final plan (using QTextBrowser instead of a > real HTML engine), since then our help pages (we integrated assistant into > our product) would no longer render correctly. From the commit message that I've linked to: commit 008926f193ceb29da6ca94fae6a7efb3ca0e0f09 Author: Friedemann Kleint Date: Fri Nov 28 10:18:38 2014 +0100 Assistant: Introduce DEFINES per browser type. This makes it easier to add additional browser types and switch between browsers. So no, the intention seems to make it more suitable for Qt WebEngine. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net From bstottle at ford.com Sat Jan 2 18:51:47 2016 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Sat, 2 Jan 2016 17:51:47 +0000 Subject: [Development] API Change in QtRemoteObjects Message-ID: Hello, For those of you using the QtRemoteObjects playground module (QtRO for short), some changes went in over the holidays that changed the public API. So you will need to update your code when you update to any version of master past 16959709b59db45c07385ecc13b76061de851edf (or see the (merged) review: https://codereview.qt-project.org/#/c/144624/). >From the commit message: > Convert Nodes to QObject based class(es) > > This change affects lots of lines of code, but is > basically a refactoring, not changing much. It > does change the QtRO API, though. > > In the interest of making it easier to expose QtRO > types to QML, the move to QObject types for Nodes was > necessary. > > The static generators allowed for different "types² > of Nodes to be created with different combinations of > 1 or 2 QUrl parameters, but this also forced a Node > type that had methods that might not make sense (for > instance, enableRemoting() from a Node that wasn't a > Host Node). And Nodes needed to be copy-able. > > This change addresses those issues by creating > three distinct types. QRemoteObjectNode is > the most basic type, and only supports acquiring > Replica objects. QRemoteObjectHost Nodes add the > ability to share Source objects on the network. Both > Node and Host types support connecting to a Registry. > > QRemoteObjectRegistryHost Nodes host a Registry object > other nodes can connect to. > > This change requires converting end-user code from > the static functions (createHostNode, etc) to using > the new types explicitly. > > Aside from the obvious change from static generator > functions, there are two other impacts to user code: > 1) connect() was renamed to connectToNode to not > conflict with QObject's connect() > 2) default QUrls for Hosting and Registry were removed > (it was too easy to create name clashes with unexpected > results). Apologies for any inconvenience, but this will make QML integration simpler, and makes the APIs more aligned with other Qt APIs. Happy Holidays/Happy New Year! Brett From charleyb123 at gmail.com Sat Jan 2 19:14:58 2016 From: charleyb123 at gmail.com (charleyb123 .) Date: Sat, 2 Jan 2016 11:14:58 -0700 Subject: [Development] API Change in QtRemoteObjects In-Reply-To: References: Message-ID: Hi, Brett-- IMHO, this is a very good change. The library will be easier to use, and more accessible from QML. Also, now is probably the time to make such an API change. I'm watching this effort with great interest -- thanks for all your hard work. --charley On Sat, Jan 2, 2016 at 10:51 AM, Stottlemyer, Brett (B.S.) < bstottle at ford.com> wrote: > Hello, > > For those of you using the QtRemoteObjects playground module (QtRO for > short), some changes went in over the holidays that changed the public > API. So you will need to update your code when you update to any version > of master past 16959709b59db45c07385ecc13b76061de851edf (or see the > (merged) review: https://codereview.qt-project.org/#/c/144624/). > > From the commit message: > > Convert Nodes to QObject based class(es) > > > > This change affects lots of lines of code, but is > > basically a refactoring, not changing much. It > > does change the QtRO API, though. > > > > In the interest of making it easier to expose QtRO > > types to QML, the move to QObject types for Nodes was > > necessary. > > > > The static generators allowed for different "types² > > of Nodes to be created with different combinations of > > 1 or 2 QUrl parameters, but this also forced a Node > > type that had methods that might not make sense (for > > instance, enableRemoting() from a Node that wasn't a > > Host Node). And Nodes needed to be copy-able. > > > > This change addresses those issues by creating > > three distinct types. QRemoteObjectNode is > > the most basic type, and only supports acquiring > > Replica objects. QRemoteObjectHost Nodes add the > > ability to share Source objects on the network. Both > > Node and Host types support connecting to a Registry. > > > > QRemoteObjectRegistryHost Nodes host a Registry object > > other nodes can connect to. > > > > This change requires converting end-user code from > > the static functions (createHostNode, etc) to using > > the new types explicitly. > > > > Aside from the obvious change from static generator > > functions, there are two other impacts to user code: > > 1) connect() was renamed to connectToNode to not > > conflict with QObject's connect() > > 2) default QUrls for Hosting and Registry were removed > > (it was too easy to create name clashes with unexpected > > results). > > Apologies for any inconvenience, but this will make QML integration > simpler, and makes the APIs more aligned with other Qt APIs. > > Happy Holidays/Happy New Year! > Brett > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gna.org Sat Jan 2 22:45:55 2016 From: chgans at gna.org (Ch'Gans) Date: Sun, 3 Jan 2016 10:45:55 +1300 Subject: [Development] API Change in QtRemoteObjects In-Reply-To: References: Message-ID: Was going through the changes out of curiosity and found that: Is a '\n' is missing at line 51? See https://codereview.qt-project.org/#/c/144624/10/examples/RemoteObjects/ModelViewClient/main.cpp My 2 cents, Chris On 3 January 2016 at 06:51, Stottlemyer, Brett (B.S.) wrote: > Hello, > > For those of you using the QtRemoteObjects playground module (QtRO for > short), some changes went in over the holidays that changed the public > API. So you will need to update your code when you update to any version > of master past 16959709b59db45c07385ecc13b76061de851edf (or see the > (merged) review: https://codereview.qt-project.org/#/c/144624/). > > From the commit message: >> Convert Nodes to QObject based class(es) >> >> This change affects lots of lines of code, but is >> basically a refactoring, not changing much. It >> does change the QtRO API, though. >> >> In the interest of making it easier to expose QtRO >> types to QML, the move to QObject types for Nodes was >> necessary. >> >> The static generators allowed for different "types² >> of Nodes to be created with different combinations of >> 1 or 2 QUrl parameters, but this also forced a Node >> type that had methods that might not make sense (for >> instance, enableRemoting() from a Node that wasn't a >> Host Node). And Nodes needed to be copy-able. >> >> This change addresses those issues by creating >> three distinct types. QRemoteObjectNode is >> the most basic type, and only supports acquiring >> Replica objects. QRemoteObjectHost Nodes add the >> ability to share Source objects on the network. Both >> Node and Host types support connecting to a Registry. >> >> QRemoteObjectRegistryHost Nodes host a Registry object >> other nodes can connect to. >> >> This change requires converting end-user code from >> the static functions (createHostNode, etc) to using >> the new types explicitly. >> >> Aside from the obvious change from static generator >> functions, there are two other impacts to user code: >> 1) connect() was renamed to connectToNode to not >> conflict with QObject's connect() >> 2) default QUrls for Hosting and Registry were removed >> (it was too easy to create name clashes with unexpected >> results). > > Apologies for any inconvenience, but this will make QML integration > simpler, and makes the APIs more aligned with other Qt APIs. > > Happy Holidays/Happy New Year! > Brett > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Friedemann.Kleint at theqtcompany.com Mon Jan 4 13:45:21 2016 From: Friedemann.Kleint at theqtcompany.com (Friedemann Kleint) Date: Mon, 4 Jan 2016 13:45:21 +0100 Subject: [Development] High-DPI on Win In-Reply-To: <3709A7D425EE8C45991DB29EC2FACA882721C642@GL-EXC-01.iesve.com> References: <3709A7D425EE8C45991DB29EC2FACA882721C5DB@GL-EXC-01.iesve.com> <2309553.y6aCcg1HXa@tjmaciei-mobl4> <3709A7D425EE8C45991DB29EC2FACA882721C642@GL-EXC-01.iesve.com> Message-ID: <568A6961.9090305@theqtcompany.com> Hi, >(3) Don't calculate the scale from the display resolution (QPlatformScreen::pixelDensity()). >In QT5.5 the devicePixelRatio is obviously set to either 1.0 or 2.0 depending on the >resolution of the display. I'm not sure for Qt5.6, but it seems to be alike here. However, in Win the >user can set a scaling such as 100%, 125%, 150%, 200%, and 250%, and the user >can do so - and may want to do so - for whatever display she/he is using (anyone with ailing eyes is >happy to use 125% on regular screens, or 250% on HDPI screens ;)). So - IMHO - >the devicePixelRatio should actually be set to exactly this value, independent on any display resolution. The Windows setting is not related to any scaling done by Qt. It only changes the return values of the metrics functions (logical DPI, font + icon sizes, etc); no devicePixelRatio scaling is done there. >Sadly, I must agree with you that Qt does indeed not handle high-dpi windows very well L I have Qt applications that I cannot use on my system, and have resorted to qt.conf to >turn off DPI-awareness for them; fuzzy scaling was preferable to not being able to use the application. There is a restriction currently in that the Windows styles are not suitable for scaling. We recommend using Fusion style for High DPI. Regards, Friedemann -- Friedemann Kleint | The Qt Company From marc.mutz at kdab.com Tue Jan 5 13:52:06 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 5 Jan 2016 13:52:06 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths Message-ID: <201601051352.06816.marc.mutz@kdab.com> Hi, I was just wondering why the *_libpaths are QScopedPointer instead of just QStringList? If the answer is "lazy evaluation", a bool *_libpaths_inited would be preferable, if the lists can ever be empty., or not? The handling code is made very complicated by the use of QScopedPointer... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From ulf.hermann at theqtcompany.com Tue Jan 5 12:56:55 2016 From: ulf.hermann at theqtcompany.com (Ulf Hermann) Date: Tue, 5 Jan 2016 12:56:55 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601051352.06816.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <568BAF87.3060904@theqtcompany.com> > I was just wondering why the *_libpaths are QScopedPointer > instead of just QStringList? If the answer is "lazy evaluation", a bool > *_libpaths_inited would be preferable, if the lists can ever be empty., or > not? The handling code is made very complicated by the use of > QScopedPointer... There is a difference between empty library paths and uninitialized library paths. An additional blah_inited would be a possible alternate solution. Mind, however, that the manual_libpaths are only used if you actually change the library paths with {add|remove|set}LibraryPath(). Otherwise they are never initialized. The *_libpaths members used to be plain pointers to avoid paying the price of constructing a QStringList if they are unused. That is a pretty pointless optimization and so I made them QScopedPointers, which reduced the life cycle management code. If you can reduce it even more, go ahead. Ulf From marc.mutz at kdab.com Tue Jan 5 15:37:51 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 5 Jan 2016 15:37:51 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <568BAF87.3060904@theqtcompany.com> References: <201601051352.06816.marc.mutz@kdab.com> <568BAF87.3060904@theqtcompany.com> Message-ID: <201601051537.52190.marc.mutz@kdab.com> On Tuesday 05 January 2016 12:56:55 Ulf Hermann wrote: > avoid paying the price of constructing a QStringList if they are unused. That's what I was wondering about: constructing a QStringList is just a copy of a pointer, and while not totally free, it is next to nothing compared to the additional heap allocation of a new'ed QStringList... (we need std::optional :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Tue Jan 5 14:41:52 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 05 Jan 2016 07:41:52 -0600 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601051537.52190.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <568BAF87.3060904@theqtcompany.com> <201601051537.52190.marc.mutz@kdab.com> Message-ID: <2082261.eIJjJmcJUW@tjmaciei-mobl4> On Tuesday 05 January 2016 15:37:51 Marc Mutz wrote: > On Tuesday 05 January 2016 12:56:55 Ulf Hermann wrote: > > avoid paying the price of constructing a QStringList if they are unused. > > That's what I was wondering about: constructing a QStringList is just a copy > of a pointer, and while not totally free, it is next to nothing compared to > the additional heap allocation of a new'ed QStringList... It's still a good enough trade-off, considering we'd need to keep a bool elsewhere. > (we need std::optional :) Aye. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Tue Jan 5 15:55:43 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 5 Jan 2016 15:55:43 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <2082261.eIJjJmcJUW@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <201601051537.52190.marc.mutz@kdab.com> <2082261.eIJjJmcJUW@tjmaciei-mobl4> Message-ID: <201601051555.44052.marc.mutz@kdab.com> On Tuesday 05 January 2016 14:41:52 Thiago Macieira wrote: > On Tuesday 05 January 2016 15:37:51 Marc Mutz wrote: > > On Tuesday 05 January 2016 12:56:55 Ulf Hermann wrote: > > > avoid paying the price of constructing a QStringList if they are > > > unused. > > > > That's what I was wondering about: constructing a QStringList is just a > > copy of a pointer, and while not totally free, it is next to nothing > > compared to the additional heap allocation of a new'ed QStringList... > > It's still a good enough trade-off, considering we'd need to keep a bool > elsewhere. Do I understand correctly that you're saying a bool is worse than a heap allocation? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From mathias at taschenorakel.de Tue Jan 5 15:15:52 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Tue, 5 Jan 2016 15:15:52 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <2082261.eIJjJmcJUW@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <568BAF87.3060904@theqtcompany.com> <201601051537.52190.marc.mutz@kdab.com> <2082261.eIJjJmcJUW@tjmaciei-mobl4> Message-ID: <568BD018.40608@taschenorakel.de> Am 05.01.2016 um 14:41 schrieb Thiago Macieira: > On Tuesday 05 January 2016 15:37:51 Marc Mutz wrote: >> On Tuesday 05 January 2016 12:56:55 Ulf Hermann wrote: >>> avoid paying the price of constructing a QStringList if they are unused. >> >> That's what I was wondering about: constructing a QStringList is just a copy >> of a pointer, and while not totally free, it is next to nothing compared to >> the additional heap allocation of a new'ed QStringList... > > It's still a good enough trade-off, considering we'd need to keep a bool > elsewhere. > >> (we need std::optional :) > > Aye. What speaks against shipping a copy of std(::experimental)::optional and using that one when the configure script notices std::optional not being available yet? How about letting qmake picking the right std::optional when configuring a project? Ciao, Mathias From rjvbertin at gmail.com Tue Jan 5 15:46:12 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 05 Jan 2016 15:46:12 +0100 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" Message-ID: <3041715.L3EpGueuhN@patux> Hi, An idea has come up, discussing with David Faure to develop a QProcess variant or a separate class ("QGuiProcess") to allow dependent code to start applications in proper fashion, taking platform specifics into account, such that the new application opens the way users of the platform would expect. For instance, starting an OS X application with a system() or fork()/exec() causes that application to open in the layer behind the one occupied by the calling process. This is easiest to see when starting an application from a terminal, say %> /Applications/Safari.app/Contents/MacOS/Safari the safari window(s) will open behind the terminal. I presume this is common enough knowledge, but can of course provide a very simple QProcess-based demonstrator. This is undoubtedly one of the reasons why the QCocoaIntegration ctor does an "activateIgnoringOtherApps" to bring the new application to the foreground forcibly [1] It is not impossible to bring a different application to the front but the ideal way on OS X to open applications for GUI use is to use LaunchServices. This causes them to open in the foreground layer, unless another application is moved to that layer after the new process has been started. For instance, opening Safari via Finder or Dock will cause it to open foremost, unless you click on, say, your email client immediately to go back to whatever you were doing. This provides a good balance between delivering a newly launched application ready for use (= in the foreground) and preventing focus stealing. LaunchServices should support most if not all features currently available for applications started with QProcess::startDetached, and it should also be possible to provide termination/exit notification through NSWorkSpace. One could thus imagine documented tokens like QProcess::NormalLaunch vs. QProcess::GUILaunch where the latter leads to the use of LaunchServices on OS X, for instance QProcess *QProcess::startDetached(QString &program, QStringList &args, QProcess::LaunchType type) Returning a QProcess instance here would allow parents to be notified of child termination the same way that is possible with "non detached" QProcess instances (and remove the need for the version that takes a pid* argument). The alternative would be a separate class (say QGuiProcess) that always uses LaunchServices on OS X. The documentation would discuss details like the fact that LaunchServices will invoke Terminal.app when used to start a shell script. I'll be letting these thoughts mature before I start drafting an implementation, but it'd help to know if such an evolution or new class would be acceptable in Qt. It'd also be nice to know if something like this is already planned or under development, of course. Thanks, René [1] Side-note : that doesn't always cause the menubar to appear, for some reason, possibly because the activate message is sent too early? From marc.mutz at kdab.com Tue Jan 5 17:56:18 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 5 Jan 2016 17:56:18 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <568BD018.40608@taschenorakel.de> References: <201601051352.06816.marc.mutz@kdab.com> <2082261.eIJjJmcJUW@tjmaciei-mobl4> <568BD018.40608@taschenorakel.de> Message-ID: <201601051756.18974.marc.mutz@kdab.com> On Tuesday 05 January 2016 15:15:52 Mathias Hasselmann wrote: > Am 05.01.2016 um 14:41 schrieb Thiago Macieira: > > On Tuesday 05 January 2016 15:37:51 Marc Mutz wrote: > >> On Tuesday 05 January 2016 12:56:55 Ulf Hermann wrote: > >>> avoid paying the price of constructing a QStringList if they are > >>> unused. > >> > >> That's what I was wondering about: constructing a QStringList is just a > >> copy of a pointer, and while not totally free, it is next to nothing > >> compared to the additional heap allocation of a new'ed QStringList... > > > > It's still a good enough trade-off, considering we'd need to keep a bool > > elsewhere. > > > >> (we need std::optional :) > > > > Aye. > > What speaks against shipping a copy of std(::experimental)::optional and > using that one when the configure script notices std::optional not being > available yet? How about letting qmake picking the right std::optional > when configuring a project? At least two things: 1. We'd need to rename the copy, and how, without requiring template aliases, would we then use one or the other (if we don't rename, we'll run afoul of the ODR) 2. The implementation may require features we don't require, yet. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Wed Jan 6 01:47:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 05 Jan 2016 16:47:16 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601051555.44052.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <2082261.eIJjJmcJUW@tjmaciei-mobl4> <201601051555.44052.marc.mutz@kdab.com> Message-ID: <1570172.e8MUXuy7sS@tjmaciei-mobl4> On Tuesday 05 January 2016 15:55:43 Marc Mutz wrote: > On Tuesday 05 January 2016 14:41:52 Thiago Macieira wrote: > > On Tuesday 05 January 2016 15:37:51 Marc Mutz wrote: > > > On Tuesday 05 January 2016 12:56:55 Ulf Hermann wrote: > > > > avoid paying the price of constructing a QStringList if they are > > > > unused. > > > > > > That's what I was wondering about: constructing a QStringList is just a > > > copy of a pointer, and while not totally free, it is next to nothing > > > compared to the additional heap allocation of a new'ed QStringList... > > > > It's still a good enough trade-off, considering we'd need to keep a bool > > elsewhere. > > Do I understand correctly that you're saying a bool is worse than a heap > allocation? No. My point was on convenience to the code, considering this is a corner case. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 6 01:49:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 05 Jan 2016 16:49:47 -0800 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: <3041715.L3EpGueuhN@patux> References: <3041715.L3EpGueuhN@patux> Message-ID: <2410121.JqzdYGHRjx@tjmaciei-mobl4> On Tuesday 05 January 2016 15:46:12 René J.V. Bertin wrote: > Hi, > > An idea has come up, discussing with David Faure to develop a QProcess > variant or a separate class ("QGuiProcess") to allow dependent code to > start applications in proper fashion, taking platform specifics into > account, such that the new application opens the way users of the platform > would expect. Sounds like the problem is elsewhere. If QProcess is not working, then maybe the problem is how those processes expect parameters in the first place. > For instance, starting an OS X application with a system() or fork()/exec() > causes that application to open in the layer behind the one occupied by the > calling process. This is easiest to see when starting an application from a > terminal, say > > %> /Applications/Safari.app/Contents/MacOS/Safari > > the safari window(s) will open behind the terminal. Right. You should open the bundle, not the executable inside it. That's not a problem of QProcess, you just ran the wrong thing. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From s.stirtzel at googlemail.com Wed Jan 6 12:41:29 2016 From: s.stirtzel at googlemail.com (Samuel Stirtzel) Date: Wed, 6 Jan 2016 12:41:29 +0100 Subject: [Development] Android Qt service discovery (was: Requesting New Repository - QtZeroConf) Message-ID: 2015-09-09 23:56 GMT+02:00 Jonathan Bagg : > Project name: QtZeroConf > > Project description: > QtZeroConf is a wrapper class for various mDNS discovery libraries across > multiple platforms: > > Linux -> Avahi-client > Android -> Avahi-core or Android Network Discovery Service Hi, is there any sample code available for the avahi-core based service discovery? Recently I have compiled avahi with the Qt5 and Android patches via android-ndk, but some code is necessary to use avahi-core in Qt applications [1]. So before I start reinventing the wheel, I'd rather ask here if any code is already available. [1] Like the emission of signals for the services found, embedded server setup. Basically something like https://github.com/lathiat/avahi/blob/master/examples/core-browse-services.c but with a "qt poll" instead of a "simple poll" etc. -- Regards Samuel From drwho at infidigm.net Wed Jan 6 16:12:19 2016 From: drwho at infidigm.net (drwho at infidigm.net) Date: Wed, 6 Jan 2016 10:12:19 -0500 Subject: [Development] Android Qt service discovery (was: Requesting New Repository - QtZeroConf) In-Reply-To: References: Message-ID: <9d983d220640a40bea96d3b784e5951c.squirrel@www.infidigm.net> >> Project name: QtZeroConf >> >> Project description: >> QtZeroConf is a wrapper class for various mDNS discovery libraries >> across >> multiple platforms: >> >> Linux -> Avahi-client >> Android -> Avahi-core or Android Network Discovery Service > > Hi, > > is there any sample code available for the avahi-core based service > discovery? > > Recently I have compiled avahi with the Qt5 and Android patches via > android-ndk, > but some code is necessary to use avahi-core in Qt applications [1]. > So before I start reinventing the wheel, I'd rather ask here if any > code is already available. https://github.com/jbagg/QtZeroConf serviceAdded(QZeroConfService *) is emitted when the service IP address is resolved. There is also an example app that works on Android in the source. Jon From s.stirtzel at googlemail.com Wed Jan 6 18:09:46 2016 From: s.stirtzel at googlemail.com (Samuel Stirtzel) Date: Wed, 6 Jan 2016 18:09:46 +0100 Subject: [Development] Android Qt service discovery (was: Requesting New Repository - QtZeroConf) In-Reply-To: <9d983d220640a40bea96d3b784e5951c.squirrel@www.infidigm.net> References: <9d983d220640a40bea96d3b784e5951c.squirrel@www.infidigm.net> Message-ID: 2016-01-06 16:12 GMT+01:00 : >>> Project name: QtZeroConf >>> >>> Project description: >>> QtZeroConf is a wrapper class for various mDNS discovery libraries >>> across >>> multiple platforms: >>> >>> Linux -> Avahi-client >>> Android -> Avahi-core or Android Network Discovery Service >> >> Hi, >> >> is there any sample code available for the avahi-core based service >> discovery? >> >> Recently I have compiled avahi with the Qt5 and Android patches via >> android-ndk, >> but some code is necessary to use avahi-core in Qt applications [1]. >> So before I start reinventing the wheel, I'd rather ask here if any >> code is already available. > > https://github.com/jbagg/QtZeroConf > > serviceAdded(QZeroConfService *) is emitted when the service IP address is > resolved. > > There is also an example app that works on Android in the source. > It works nice on linux and android and it's easy to use, kudos for your great work. -- Regards Samuel From kevin.kofler at chello.at Wed Jan 6 18:38:53 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 06 Jan 2016 18:38:53 +0100 Subject: [Development] RFC: new moc feature References: <5662AEB9.5060705@kdab.com> <201512052006.22869.marc.mutz@kdab.com> <566338FB.5050601@kdab.com> <201512052137.32784.marc.mutz@kdab.com> <0DFE5BBF-C58F-49BD-96A5-28A9F1C0C053@theqtcompany.com> Message-ID: Knoll Lars wrote: > Just as a side note: While perf ensures there’s no collisions between > valid keys in the hash table, you still end up doing one string comparison > in the end to ensure that your input string matches the key. Why? Just document that passing an unknown string is undefined behavior, then if your invalid input happens to collide with the hash of something valid, it'll just be a synonym, undefined means undefined. Kevin Kofler From kevin.kofler at chello.at Wed Jan 6 19:14:41 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 06 Jan 2016 19:14:41 +0100 Subject: [Development] Qt WebKit dependency in Qt Assistant References: Message-ID: Hi, Aleix Pol wrote: > One of the big news lately is the deprecation of Qt WebKit module. > > One of the Qt dependencies on it is assistant (which is a tool I use > quite often, really) and AFAIK it's using it quite thoroughly. It used > to be powered by QTextBrowser though, as far as I remember. We tried building Qt Assistant against QTextBrowser in Fedora long ago (IIRC, in an attempt to get rid of the circular dependency between Qt 4 and QtWebKit 4). We found that it was a very bad idea because the Qt help was looking horrible as a result, not to mention third-party help using Assistant. So this was very quickly reverted to QtWebKit. AFAIK, QTextBrowser's HTML and especially CSS support has not improved significantly, if at all, since then. This is really not funny: * you (= the Qt project) stop maintaining QtWebKit, * you deprecate it, * you stop providing even security updates for it, * and now you stop even shipping it at all, and yet you haven't even ported YOUR OWN code away from it! (And the QTextBrowser "solution" leaves A LOT to be desired.) Kevin Kofler From kevin.kofler at chello.at Wed Jan 6 19:21:20 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 06 Jan 2016 19:21:20 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <2082261.eIJjJmcJUW@tjmaciei-mobl4> <568BD018.40608@taschenorakel.de> <201601051756.18974.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > 1. We'd need to rename the copy, and how, without requiring template > aliases, would we then use one or the other (if we don't rename, we'll > run afoul of the ODR) Just use good old #define: #if HAVE_STD_OPTIONAL #define Q_OPTIONAL std::optional #elif HAVE_STD_EXPERIMENTAL_OPTIONAL #define Q_OPTIONAL std::experimental::optional #else #define Q_OPTIONAL QtPrivate::optional #endif Kevin Kofler From annulen at yandex.ru Wed Jan 6 19:51:54 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 06 Jan 2016 21:51:54 +0300 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: References: Message-ID: <1121931452106314@web12o.yandex.ru> 06.01.2016, 21:15, "Kevin Kofler" : > Hi, > > Aleix Pol wrote: >>  One of the big news lately is the deprecation of Qt WebKit module. >> >>  One of the Qt dependencies on it is assistant (which is a tool I use >>  quite often, really) and AFAIK it's using it quite thoroughly. It used >>  to be powered by QTextBrowser though, as far as I remember. > > We tried building Qt Assistant against QTextBrowser in Fedora long ago > (IIRC, in an attempt to get rid of the circular dependency between Qt 4 and > QtWebKit 4). We found that it was a very bad idea because the Qt help was > looking horrible as a result, not to mention third-party help using > Assistant. So this was very quickly reverted to QtWebKit. AFAIK, > QTextBrowser's HTML and especially CSS support has not improved > significantly, if at all, since then. > > This is really not funny: > * you (= the Qt project) stop maintaining QtWebKit, > * you deprecate it, > * you stop providing even security updates for it, > * and now you stop even shipping it at all, > and yet you haven't even ported YOUR OWN code away from it! (And the > QTextBrowser "solution" leaves A LOT to be desired.) You might want to ship unofficial QtWebKit 5.6 in Fedora. -- Regards, Konstantin From thiago.macieira at intel.com Wed Jan 6 19:58:17 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 06 Jan 2016 10:58:17 -0800 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: <1121931452106314@web12o.yandex.ru> References: <1121931452106314@web12o.yandex.ru> Message-ID: <16136611.JMvqI1fFuM@tjmaciei-mobl4> On Wednesday 06 January 2016 21:51:54 Konstantin Tokarev wrote: > > and yet you haven't even ported YOUR OWN code away from it! (And the > > QTextBrowser "solution" leaves A LOT to be desired.) > > You might want to ship unofficial QtWebKit 5.6 in Fedora. We will release a 5.6 version with buildsystem updates. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at theqtcompany.com Wed Jan 6 20:01:39 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Wed, 6 Jan 2016 19:01:39 +0000 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: References: Message-ID: > -----Ursprüngliche Nachricht----- > Von: Development [mailto:development-bounces at qt-project.org] Im > Auftrag von Kevin Kofler > Gesendet: Mittwoch, 6. Januar 2016 19:15 > An: development at qt-project.org > Betreff: Re: [Development] Qt WebKit dependency in Qt Assistant > > Hi, > > Aleix Pol wrote: > > One of the big news lately is the deprecation of Qt WebKit module. > > > > One of the Qt dependencies on it is assistant (which is a tool I use > > quite often, really) and AFAIK it's using it quite thoroughly. It used > > to be powered by QTextBrowser though, as far as I remember. > > We tried building Qt Assistant against QTextBrowser in Fedora long ago (IIRC, > in an attempt to get rid of the circular dependency between Qt 4 and > QtWebKit 4). We found that it was a very bad idea because the Qt help was > looking horrible as a result, not to mention third-party help using Assistant. > So this was very quickly reverted to QtWebKit. AFAIK, QTextBrowser's HTML > and especially CSS support has not improved significantly, if at all, since then. That's the plan for the Qt SDK in 5.6 though: The doc team simplified the CSS somewhat so that QTextBrowser can handle it. While the rendered page is arguably not as polished as with a 'proper' HTML renderer, it's IMO good enough. There has also been patches for using QtWebEngine as a backend, but this does not cover all platforms that we currently provide binaries for (e.g. MinGW would be left out). > This is really not funny: > * you (= the Qt project) stop maintaining QtWebKit, > * you deprecate it, > * you stop providing even security updates for it, > * and now you stop even shipping it at all, and yet you haven't even ported > YOUR OWN code away from it! (And the QTextBrowser "solution" leaves A > LOT to be desired.) We'll provide source packages for qtwebkit as long as it's feasible. Regards Kai From annulen at yandex.ru Wed Jan 6 20:09:26 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 06 Jan 2016 22:09:26 +0300 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: <16136611.JMvqI1fFuM@tjmaciei-mobl4> References: <1121931452106314@web12o.yandex.ru> <16136611.JMvqI1fFuM@tjmaciei-mobl4> Message-ID: <1141641452107366@web12o.yandex.ru> 06.01.2016, 21:58, "Thiago Macieira" : > On Wednesday 06 January 2016 21:51:54 Konstantin Tokarev wrote: >>  > and yet you haven't even ported YOUR OWN code away from it! (And the >>  > QTextBrowser "solution" leaves A LOT to be desired.) >> >>  You might want to ship unofficial QtWebKit 5.6 in Fedora. > > We will release a 5.6 version with buildsystem updates. 5.6 branch contains a few bug fixes and improvements over 5.5.1, all of which were approved by maintainer, so Fedora folks might want to ship it instead. -- Regards, Konstantin From apoenitz at t-online.de Wed Jan 6 20:36:34 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 6 Jan 2016 20:36:34 +0100 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: References: Message-ID: <20160106193634.GA2720@klara.mpi.htwm.de> On Wed, Jan 06, 2016 at 07:14:41PM +0100, Kevin Kofler wrote: > Hi, > > Aleix Pol wrote: > > One of the big news lately is the deprecation of Qt WebKit module. > > > > One of the Qt dependencies on it is assistant (which is a tool I use > > quite often, really) and AFAIK it's using it quite thoroughly. It used > > to be powered by QTextBrowser though, as far as I remember. > > We tried building Qt Assistant against QTextBrowser in Fedora long ago > (IIRC, in an attempt to get rid of the circular dependency between Qt 4 and > QtWebKit 4). We found that it was a very bad idea because the Qt help was > looking horrible as a result, not to mention third-party help using > Assistant. So this was very quickly reverted to QtWebKit. AFAIK, > QTextBrowser's HTML and especially CSS support has not improved > significantly, if at all, since then. Wrong conclusion. The fact that QTextBrowser hasn't changed does not mean the help display is the same as before. Maybe the set of CSS features the help style uses changed? Oh wait. It has. Even a couple of time since "long ago". Last time on 2015-10-16, with the commit message mentioning "including simplified CSS rules suitable for rendering with a QTextBrowser". > This is really not funny: > * you (= the Qt project) stop maintaining QtWebKit, > * you deprecate it, > * you stop providing even security updates for it, > * and now you stop even shipping it at all, > and yet you haven't even ported YOUR OWN code away from it! (And the > QTextBrowser "solution" leaves A LOT to be desired.) See above. Andre' From kevin.kofler at chello.at Wed Jan 6 22:24:25 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 06 Jan 2016 22:24:25 +0100 Subject: [Development] Qt WebKit dependency in Qt Assistant References: <1121931452106314@web12o.yandex.ru> <16136611.JMvqI1fFuM@tjmaciei-mobl4> <1141641452107366@web12o.yandex.ru> Message-ID: Konstantin Tokarev wrote: > 5.6 branch contains a few bug fixes and improvements over 5.5.1, all of > which were approved by maintainer, so Fedora folks might want to ship it > instead. We will be shipping QtWebKit from the 5.6 branch. That's what Rawhide already has. And IMHO, releasing a version that's not from the 5.6 branch as "QtWebKit 5.6" is a horrible idea! Please don't do that! Kevin Kofler From thiago.macieira at intel.com Wed Jan 6 23:06:59 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 06 Jan 2016 14:06:59 -0800 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: References: <1141641452107366@web12o.yandex.ru> Message-ID: <1781649.uDmaly7O9K@tjmaciei-mobl4> On Wednesday 06 January 2016 22:24:25 Kevin Kofler wrote: > Konstantin Tokarev wrote: > > 5.6 branch contains a few bug fixes and improvements over 5.5.1, all of > > which were approved by maintainer, so Fedora folks might want to ship it > > instead. > > We will be shipping QtWebKit from the 5.6 branch. That's what Rawhide > already has. > > And IMHO, releasing a version that's not from the 5.6 branch as "QtWebKit > 5.6" is a horrible idea! Please don't do that! The idea was to release that branch, indeed. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From aleixpol at kde.org Thu Jan 7 01:10:13 2016 From: aleixpol at kde.org (Aleix Pol) Date: Thu, 7 Jan 2016 01:10:13 +0100 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: References: Message-ID: On Wed, Jan 6, 2016 at 8:01 PM, Koehne Kai wrote: >> -----Ursprüngliche Nachricht----- >> Von: Development [mailto:development-bounces at qt-project.org] Im >> Auftrag von Kevin Kofler >> Gesendet: Mittwoch, 6. Januar 2016 19:15 >> An: development at qt-project.org >> Betreff: Re: [Development] Qt WebKit dependency in Qt Assistant >> >> Hi, >> >> Aleix Pol wrote: >> > One of the big news lately is the deprecation of Qt WebKit module. >> > >> > One of the Qt dependencies on it is assistant (which is a tool I use >> > quite often, really) and AFAIK it's using it quite thoroughly. It used >> > to be powered by QTextBrowser though, as far as I remember. >> >> We tried building Qt Assistant against QTextBrowser in Fedora long ago (IIRC, >> in an attempt to get rid of the circular dependency between Qt 4 and >> QtWebKit 4). We found that it was a very bad idea because the Qt help was >> looking horrible as a result, not to mention third-party help using Assistant. >> So this was very quickly reverted to QtWebKit. AFAIK, QTextBrowser's HTML >> and especially CSS support has not improved significantly, if at all, since then. > > That's the plan for the Qt SDK in 5.6 though: The doc team simplified the CSS somewhat so that QTextBrowser can handle it. While the rendered page is arguably not as polished as with a 'proper' HTML renderer, it's IMO good enough. > > There has also been patches for using QtWebEngine as a backend, but this does not cover all platforms that we currently provide binaries for (e.g. MinGW would be left out). > >> This is really not funny: >> * you (= the Qt project) stop maintaining QtWebKit, >> * you deprecate it, >> * you stop providing even security updates for it, >> * and now you stop even shipping it at all, and yet you haven't even ported >> YOUR OWN code away from it! (And the QTextBrowser "solution" leaves A >> LOT to be desired.) > > We'll provide source packages for qtwebkit as long as it's feasible. Hi, That's the answer I was looking forward to. Thanks Kai and the team. :) Regards, Aleix From Lars.Knoll at theqtcompany.com Thu Jan 7 08:38:10 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 7 Jan 2016 07:38:10 +0000 Subject: [Development] RFC: new moc feature In-Reply-To: References: <5662AEB9.5060705@kdab.com> <201512052006.22869.marc.mutz@kdab.com> <566338FB.5050601@kdab.com> <201512052137.32784.marc.mutz@kdab.com> <0DFE5BBF-C58F-49BD-96A5-28A9F1C0C053@theqtcompany.com> Message-ID: <9E3C75CF-001F-4B55-8C77-7C6D72CEDB13@theqtcompany.com> On 06/01/16 18:38, "Development on behalf of Kevin Kofler" wrote: >Knoll Lars wrote: >> Just as a side note: While perf ensures there’s no collisions between >> valid keys in the hash table, you still end up doing one string comparison >> in the end to ensure that your input string matches the key. > >Why? Just document that passing an unknown string is undefined behavior, >then if your invalid input happens to collide with the hash of something >valid, it'll just be a synonym, undefined means undefined. Because that leads to completely unpredictable behaviour for any user. A simple typo in your input string and you might get whatever result. The only case where this is acceptable is if you can guarantee through external means that the string you parse will only ever contain valid keys. But it’s certainly nothing you want in more general purpose library code or the example Sean mentioned. Lars From Eike.Ziller at theqtcompany.com Thu Jan 7 09:57:39 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Thu, 7 Jan 2016 08:57:39 +0000 Subject: [Development] Qt WebKit dependency in Qt Assistant In-Reply-To: <201601021553.59951.suy@badopi.org> References: <201601021007.28247.suy@badopi.org> <1650974.jJlmPADSSI@lapi.koller> <201601021553.59951.suy@badopi.org> Message-ID: > On Jan 2, 2016, at 3:53 PM, Alejandro Exojo wrote: > > El Saturday 02 January 2016, Martin Koller escribió: >> ... and I hope this is not the final plan (using QTextBrowser instead of a >> real HTML engine), since then our help pages (we integrated assistant into >> our product) would no longer render correctly. > > From the commit message that I've linked to: > > commit 008926f193ceb29da6ca94fae6a7efb3ca0e0f09 > Author: Friedemann Kleint > Date: Fri Nov 28 10:18:38 2014 +0100 > > Assistant: Introduce DEFINES per browser type. > > This makes it easier to add additional browser types and > switch between browsers. > > So no, the intention seems to make it more suitable for Qt WebEngine. > You can help drive https://codereview.qt-project.org/126715 forward. Br, Eike -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From rjvbertin at gmail.com Thu Jan 7 10:04:51 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 07 Jan 2016 10:04:51 +0100 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" References: <3041715.L3EpGueuhN@patux> <2410121.JqzdYGHRjx@tjmaciei-mobl4> Message-ID: <2058518.tptgUkBaMG@patux.local> Thiago Macieira wrote: > Sounds like the problem is elsewhere. If QProcess is not working, then maybe > the problem is how those processes expect parameters in the first place. Who said anything about parameters? If you meant arguments then indeed, OS X provides 2 ways to hand of arguments that correspond to documents (files) to open. The standard argc,argv way and something that is a lot like DBus messages. But that's not the point here. > ... > > Right. You should open the bundle, not the executable inside it. That's not a > problem of QProcess, you just ran the wrong thing. It's a little bit more subtle than that, and if you look at qprocess_unix.cpp you'll see a bit of code that does the opposite when it encounters an app bundle. But what you're basically saying is that if QProcess cannot do the job for us, we just have to use something other than Qt? R. From erik.verbruggen at theqtcompany.com Thu Jan 7 10:45:15 2016 From: erik.verbruggen at theqtcompany.com (Erik Verbruggen) Date: Thu, 7 Jan 2016 10:45:15 +0100 Subject: [Development] V4 porting In-Reply-To: References: <20151224111811.5922896.50992.54182@theqtcompany.com> Message-ID: <568E33AB.1080606@theqtcompany.com> On 24-12-2015 12:42, Dmitriy - wrote: > Thank. > I want to port JIT. Where should I start? > You have any roadmap for this? > > Now I'm using qmljs tool for testing purpose. We use the assembler classes from WTF (JavaScriptCore) to generate the code, so you'll have to start with writing one for your CPU architecture. IIRC, the MIPS assembler is the one with the least weird stuff. After that, you'll have to grab your ABI documentation and teach the TargetPlatform class (in qv4targetplatform_p.h) about the calling convention. If you set RegAllocIsSupported=0 you can leave getPlatformRegisterInfo empty. If you want to debug the generated code, you can write a JSC::tryToDisassemble function that will be called after generating the JITted code for a function (if you set the environment variable QV4_SHOW_ASM=1). As a minimalistic start, I'd try to get something like "function x(){return 0}" working. Hope this helps. -- Erik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From abbapoh at gmail.com Thu Jan 7 15:05:37 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Thu, 7 Jan 2016 17:05:37 +0300 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <2082261.eIJjJmcJUW@tjmaciei-mobl4> <568BD018.40608@taschenorakel.de> <201601051756.18974.marc.mutz@kdab.com> Message-ID: Still, what about policy not to use std:: classes in Qt API? Are optional inplementations compatible with each other like std::pair ot not? 2016-01-06 21:21 GMT+03:00 Kevin Kofler : > Marc Mutz wrote: > > 1. We'd need to rename the copy, and how, without requiring template > > aliases, would we then use one or the other (if we don't rename, we'll > > run afoul of the ODR) > > Just use good old #define: > #if HAVE_STD_OPTIONAL > #define Q_OPTIONAL std::optional > #elif HAVE_STD_EXPERIMENTAL_OPTIONAL > #define Q_OPTIONAL std::experimental::optional > #else > #define Q_OPTIONAL QtPrivate::optional > #endif > > Kevin Kofler > > _______________________________________________ > 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 Morten.Sorvig at theqtcompany.com Thu Jan 7 15:06:39 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Thu, 7 Jan 2016 14:06:39 +0000 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: <2058518.tptgUkBaMG@patux.local> References: <3041715.L3EpGueuhN@patux> <2410121.JqzdYGHRjx@tjmaciei-mobl4> <2058518.tptgUkBaMG@patux.local> Message-ID: <1FA408A8-105E-432D-A331-1D6AAD202A2C@digia.com> > On 07 Jan 2016, at 10:04, René J. V. Bertin wrote: > >> >> Right. You should open the bundle, not the executable inside it. That's not a >> problem of QProcess, you just ran the wrong thing. > > It's a little bit more subtle than that, and if you look at qprocess_unix.cpp > you'll see a bit of code that does the opposite when it encounters an app > bundle. > > But what you're basically saying is that if QProcess cannot do the job for us, > we just have to use something other than Qt? One alternative could be to branch out from cross-paltform code and just call the native API, which will do exactly what you want. Recent versions of Qt makes this easier on OS X, we’ve for example added QString:toNSString() and QUrl::toNSURL() for data conversion. Another point: Isn't there a fundamental incompatibiity between LaunchServices and QProcess? LanchServices may ‘activate’ an already running process, while QProcess always starts a new process. Morten From thiago.macieira at intel.com Thu Jan 7 16:16:21 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 07 Jan 2016 07:16:21 -0800 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: <2058518.tptgUkBaMG@patux.local> References: <3041715.L3EpGueuhN@patux> <2410121.JqzdYGHRjx@tjmaciei-mobl4> <2058518.tptgUkBaMG@patux.local> Message-ID: <1794907.v1iCWKUuXY@tjmaciei-mobl4> On Thursday 07 January 2016 10:04:51 René J. V. Bertin wrote: > But what you're basically saying is that if QProcess cannot do the job for > us, we just have to use something other than Qt? So a class in QCocoaExtras is the solution, right? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Jan 7 18:08:47 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 7 Jan 2016 18:08:47 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <201601071808.47703.marc.mutz@kdab.com> On Thursday 07 January 2016 15:05:37 Иван Комиссаров wrote: > Still, what about policy not to use std:: classes in Qt API? > Are optional inplementations compatible with each other like std::pair ot > not? Whether by design or accident, apps can currently use a different C++ standard library than the one Qt was built with. I believe the only use-case of this is OS X, with libc++ and libstdc++. At some point, this feature became part of the Qt BC guarantees. This means that except for very few exceptions like std::exception (no pun intended), std:: types cannot form part of the Qt ABI (not API, ABI), because even if the layout of a std::pair is defined by the standard, the std::pair from one impl is called std::_1::pair, or something like that (inline namespaces), so the symbol names would clash. I believe that is not a valid use-case of binary compatibility to support different std impls with the same binary, because it precisely means we cannot use, say pair, shared_ptr, or function in the Qt API. But for now, it's like it is. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From vikascodestuff at gmail.com Thu Jan 7 17:35:31 2016 From: vikascodestuff at gmail.com (Vikas Bhargava) Date: Thu, 7 Jan 2016 11:35:31 -0500 Subject: [Development] QStateMachine and SCXML? Message-ID: Hi, Can someone point me to the latest on whether State Machine initialization based on a scxml specification would be supported. The last discussion I could find on the topic is at least 5 years old. The current State Machine framework has no support as far as I can see. Regards, Vikas -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gna.org Thu Jan 7 21:14:25 2016 From: chgans at gna.org (Ch'Gans) Date: Fri, 8 Jan 2016 09:14:25 +1300 Subject: [Development] QStateMachine and SCXML? In-Reply-To: References: Message-ID: Just discovered this few days ago: https://github.com/KDAB/KDStateMachineEditor Hope this helps. Chris On 8 January 2016 at 05:35, Vikas Bhargava wrote: > Hi, > Can someone point me to the latest on whether State Machine initialization > based on a scxml specification would be supported. The last discussion I > could find > on the topic is at least 5 years old. The current State Machine framework > has no support as far as I can see. > > Regards, > Vikas > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From rjvbertin at gmail.com Thu Jan 7 22:14:47 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Thu, 07 Jan 2016 22:14:47 +0100 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" References: <3041715.L3EpGueuhN@patux> <2410121.JqzdYGHRjx@tjmaciei-mobl4> <2058518.tptgUkBaMG@patux.local> <1FA408A8-105E-432D-A331-1D6AAD202A2C@digia.com> Message-ID: <11002383.Lrxd2GGWnv@portia.local> Sorvig Morten wrote: > Another point: Isn't there a fundamental incompatibiity between LaunchServices > and QProcess? LanchServices may ‘activate’ an already running process, while > QProcess always starts a new process. This is something that I think we have not yet taken into consideration. It doesn't necessarily matter for a "startDetached" form of launching though, where/when you don't care if the detached process is a newly started one or an already running process. It should be possible to detect termination for such a "reused" process too (via an NSNotificationCentre), so I think one could write a class that behaves as the same regardless of whether the process it interfaces with is a newly started process or not. Maybe rather a QGuiProcess then? Or is OS X really the only OS where there exists a specific spawning API for GUI apps in addition to a more traditional Posix one? NB: a contact at Apple taught me 2 things in this context: - app bundle executables may not always start through system() or exec() in the future (which will probably force a redesign of QProcess) - even in cases where fork+exec is appropriate, one should rather use posix_spawn(). (This would concern shell scripts, non gui apps or "agents" that should remain in the background until they decide otherwise themselves, etc.) R. From thiago.macieira at intel.com Thu Jan 7 22:23:45 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 07 Jan 2016 13:23:45 -0800 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: <11002383.Lrxd2GGWnv@portia.local> References: <3041715.L3EpGueuhN@patux> <1FA408A8-105E-432D-A331-1D6AAD202A2C@digia.com> <11002383.Lrxd2GGWnv@portia.local> Message-ID: <1480913.Lrqr7IgLMB@tjmaciei-mobl4> On Thursday 07 January 2016 22:14:47 René J. V. Bertin wrote: > Maybe rather a QGuiProcess then? Or is OS X really the only OS where there > exists a specific spawning API for GUI apps in addition to a more > traditional Posix one? The burden is on you to prove this class would be beneficial in cross-platform contexts too. > - even in cases where fork+exec is appropriate, one should rather use > posix_spawn(). (This would concern shell scripts, non gui apps or "agents" > that should remain in the background until they decide otherwise > themselves, etc.) Not gonna happen. posix_spawn is too limited. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at theqtcompany.com Fri Jan 8 08:18:54 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Fri, 8 Jan 2016 07:18:54 +0000 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? In-Reply-To: References: Message-ID: Hi John, This item was discussed at Qt Contributor’s Summit, please see session notes: http://wiki.qt.io/QtCS2015_LTS For compilers this is also documented to the Qt Base change log: http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1 For 5.6 the current list of supported platforms and compilers is the following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we are working to add OS X 10.11 to CI and fully support it) The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent versions. Those who have such older platforms to support, are recommended to stay with the LTS version for a while. This approach allows us to move faster for new features planned for future Qt releases. For application developers the documentation is often the best source to find the list of supported platforms: http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been updated to 5.6, but will be before the final release. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of John Layt Sent: keskiviikkona 30. joulukuuta 2015 20.43 To: development at qt-project.org Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? Hi, Can I just clarify what the minimum deployment platforms are for 5.7 onwards? That is, the lowest version of each OS that the code must still run on? Far as I can tell it's something like: Windows 7 (or Vista?) Windows Embedded Compact 2013 OSX 10.8 iOS 5.0? Android 4.1 (API Level 16)? RHEL 6.6 Ubuntu 11.10? There really should be a wiki page for this... Cheers! John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Frederik.Gladhorn at theqtcompany.com Fri Jan 8 09:12:43 2016 From: Frederik.Gladhorn at theqtcompany.com (Gladhorn Frederik) Date: Fri, 8 Jan 2016 08:12:43 +0000 Subject: [Development] Expect delays in Continuous Integration today Message-ID: Hi all, in order to fix https://bugreports.qt.io/browse/QTBUG-50065 and others linked to it, we need to clean up the way we use -prefix in continuous integration. Up to now we used the source dir as prefix in many configurations while expecting make install to work, which is more of a hack that worked by accident. We will change to the proper usage of prefix pointing to a different path, sadly this means slight changes to our collected artifacts which in turn means that modules depending on qtbase will not build until the first round of fresh builds. Due to this we'll disable and gradually re-enable building of all modules. Sorry for the inconvenience, we're working on a better solution for the next time (versioning our archives), but for now we do not want to stand in the way of the Qt 5.6.0 release any longer. During the day things should go back to normal step by step. In the mean time it might be OK to hold off staging patches today unless they are very urgent to keep the noise lower. Greetings, Frederik -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eike.Ziller at theqtcompany.com Fri Jan 8 10:03:36 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Fri, 8 Jan 2016 09:03:36 +0000 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: <11002383.Lrxd2GGWnv@portia.local> References: <3041715.L3EpGueuhN@patux> <2410121.JqzdYGHRjx@tjmaciei-mobl4> <2058518.tptgUkBaMG@patux.local> <1FA408A8-105E-432D-A331-1D6AAD202A2C@digia.com> <11002383.Lrxd2GGWnv@portia.local> Message-ID: > On Jan 7, 2016, at 10:14 PM, René J. V. Bertin wrote: > > Sorvig Morten wrote: > >> Another point: Isn't there a fundamental incompatibiity between LaunchServices >> and QProcess? LanchServices may ‘activate’ an already running process, while >> QProcess always starts a new process. That should be possible to be prohibited with launch flag kLSLaunchNewInstance > This is something that I think we have not yet taken into consideration. It > doesn't necessarily matter for a "startDetached" form of launching though, If you just care about starting an application and being notified when it finishes, without the need for output/input streams or PIDs, then you can probably just run “/usr/bin/open -n -W " Br, Eike > where/when you don't care if the detached process is a newly started one or an > already running process. It should be possible to detect termination for such a > "reused" process too (via an NSNotificationCentre), so I think one could write a > class that behaves as the same regardless of whether the process it interfaces > with is a newly started process or not. > > Maybe rather a QGuiProcess then? Or is OS X really the only OS where there > exists a specific spawning API for GUI apps in addition to a more traditional > Posix one? > > NB: a contact at Apple taught me 2 things in this context: > - app bundle executables may not always start through system() or exec() in the > future (which will probably force a redesign of QProcess) > - even in cases where fork+exec is appropriate, one should rather use > posix_spawn(). (This would concern shell scripts, non gui apps or "agents" that > should remain in the background until they decide otherwise themselves, etc.) > > R. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From rjvbertin at gmail.com Fri Jan 8 10:52:14 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 08 Jan 2016 10:52:14 +0100 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" References: <3041715.L3EpGueuhN@patux> <1FA408A8-105E-432D-A331-1D6AAD202A2C@digia.com> <11002383.Lrxd2GGWnv@portia.local> <1480913.Lrqr7IgLMB@tjmaciei-mobl4> Message-ID: <1750840.futb0kCIkp@patux.local> Thiago Macieira wrote: > On Thursday 07 January 2016 22:14:47 René J. V. Bertin wrote: >> is OS X really the only OS where there >> exists a specific spawning API for GUI apps in addition to a more >> traditional Posix one? > > The burden is on you to prove this class would be beneficial in cross-platform > contexts too. Of course (and that'd be fine as long as "you =/= me myself and I" ;)) But I'd hope this would be the best place to know if Qt supports (or plans to support) platforms where there also exists a specific way to launch applications so that they behave like GUI applications should behave on that platform. Or if there are platforms where such a dedicated launch API will be introduced in some nearish future (MS Windows or Android come to mind). I suppose one could even consider the session management env.variables on Unix/Linux. There's an alternative though, from which this whole idea sprung: let QProcess itself determine if an app bundle executable is being started, and use LaunchServices if that is the case - i.e. if the the command is either "foo.app" or "/path/to/foo.app" or "/path/to/foo.app/Contents/MacOS/foo-bundle-exec". (the latter is a bit tricky because you'd probably want to verify that it is indeed the bundle exec that is being started.) This has the advantage of being transparent and leading to expected behaviour from the user POV, but there are some details to be worked out regarding channels and possibly other QProcess features that cannot be supported this way. Should be fine for QProcess::startDetached though. What about the idea of a QProcess::startDetached variant that returns a QProcess instance? That'd make sense (IMHO) if it's possible to provide (at least) termination notification through the QProcess::finished signal - and I don't see why the fact of starting something in detached fashion would make it uninteresting to know if/when that process exits (e.g. to start it up again). The question would be of course to what extent it is possible to support this on more than a single platform. > > Not gonna happen. posix_spawn is too limited. In what sense? Looking at the documentation it would appear the opposite, an API with way too many options that have to be set correctly ... R. From rjvbertin at gmail.com Fri Jan 8 11:09:41 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 08 Jan 2016 11:09:41 +0100 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: References: <3041715.L3EpGueuhN@patux> <11002383.Lrxd2GGWnv@portia.local> Message-ID: <5525902.Jps4RkPotF@patux> On Friday January 08 2016 09:03:36 Ziller Eike wrote: >> This is something that I think we have not yet taken into consideration. It >> doesn't necessarily matter for a "startDetached" form of launching though, > >If you just care about starting an application and being notified when it finishes, without the need for output/input streams or PIDs, then you can probably just run “/usr/bin/open -n -W " True, or no, that'd rather be "/usr/bin/open [-n] -W -a appbundle|bundle-exec". It wouldn't always be trivial to get the invocation just right, as that is a wrapper to LSOpenURLWithRole() whereas we'd probably use something more simple, with less ambiguous specification of the arguments. Besides, we identified a need to know the pid and also to be notified of process termination. FWIW, I did manage to write a short enough AppleScript routine to hardcode a command that pipes it into /usr/bin/osascript and that activates the launched application if it's a GUI application. It works but is not very elegant as AppleScript was never designed for this role: it requires polling (in the AppleScript routine) and an external termination timer (or a more complex script that adds a timeout to the polling loop). It's something that might be added to QMacExtras though, or a repository of contributed stuff if something like that exists, because it does have the advantage of working on the result of a launch procedure, regardless of how the launch was done. Then again, if AppleScript is to make its appearance in Qt it'd probably be more appropriate to provide a full bridge to it in QMacExtras ... but let's forget I said that for now ;) R. From Morten.Sorvig at theqtcompany.com Fri Jan 8 11:12:47 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Fri, 8 Jan 2016 10:12:47 +0000 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: References: <3041715.L3EpGueuhN@patux> <2410121.JqzdYGHRjx@tjmaciei-mobl4> <2058518.tptgUkBaMG@patux.local> <1FA408A8-105E-432D-A331-1D6AAD202A2C@digia.com> <11002383.Lrxd2GGWnv@portia.local> Message-ID: <0D566E9A-6C47-4EBE-8629-01B435B9EE96@digia.com> > On 08 Jan 2016, at 10:03, Ziller Eike wrote: > > >> On Jan 7, 2016, at 10:14 PM, René J. V. Bertin wrote: >> >> Sorvig Morten wrote: >> >>> Another point: Isn't there a fundamental incompatibiity between LaunchServices >>> and QProcess? LanchServices may ‘activate’ an already running process, while >>> QProcess always starts a new process. > > That should be possible to be prohibited with launch flag kLSLaunchNewInstance But you seldom want to have two instances of (say) Mail running - you start it, or bring the existing one to front. So kLSLaunchNewInstance does not seems that useful in practice. > >> This is something that I think we have not yet taken into consideration. It >> doesn't necessarily matter for a "startDetached" form of launching though, > > If you just care about starting an application and being notified when it finishes, without the need for output/input streams or PIDs, then you can probably just run “/usr/bin/open -n -W " It could be long wait for the notification: closing the last application window does usually not cause the application process to exit. If we want to implement “user is done” type of notifications we might be heading in the wrong direction here. Morten From Jake.Petroules at theqtcompany.com Fri Jan 8 11:24:04 2016 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Fri, 8 Jan 2016 10:24:04 +0000 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? In-Reply-To: References: Message-ID: We're raising the minimum OS X to 10.8 (2012). The iOS minimum is still 6 (also 2012), but I wonder whether we should also raise that a version (or even two) considering its uniquely rapid upgrade cycle (frequently upgraded hardware, less user ability to opt out of software updates). Bumping it to iOS 8 would also allow us to stop making static builds and thus gain support for App Extensions. Thoughts? Tor Arne? -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company From: Development > on behalf of Turunen Tuukka > Date: Thursday, January 7, 2016 at 11:18 PM To: John Layt >, "development at qt-project.org" > Subject: Re: [Development] Minimum Deployment Platforms for 5.7 onwards? Hi John, This item was discussed at Qt Contributor’s Summit, please see session notes: http://wiki.qt.io/QtCS2015_LTS For compilers this is also documented to the Qt Base change log: http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1 For 5.6 the current list of supported platforms and compilers is the following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we are working to add OS X 10.11 to CI and fully support it) The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent versions. Those who have such older platforms to support, are recommended to stay with the LTS version for a while. This approach allows us to move faster for new features planned for future Qt releases. For application developers the documentation is often the best source to find the list of supported platforms: http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been updated to 5.6, but will be before the final release. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of John Layt Sent: keskiviikkona 30. joulukuuta 2015 20.43 To: development at qt-project.org Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? Hi, Can I just clarify what the minimum deployment platforms are for 5.7 onwards? That is, the lowest version of each OS that the code must still run on? Far as I can tell it's something like: Windows 7 (or Vista?) Windows Embedded Compact 2013 OSX 10.8 iOS 5.0? Android 4.1 (API Level 16)? RHEL 6.6 Ubuntu 11.10? There really should be a wiki page for this... Cheers! John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From coroberti at gmail.com Fri Jan 8 11:50:34 2016 From: coroberti at gmail.com (Robert Iakobashvili) Date: Fri, 8 Jan 2016 12:50:34 +0200 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? In-Reply-To: References: Message-ID: Dear Jake, Unless app developers would like to drop their existing apps and rename/launch instead new apps, they're forced to keep compatibility with the very first iOS-version when their app was accepted to iTunes Store. So, dropping iOS-6 is a not issue for me, but dropping iOS-7 - yes. jm2c Kind regards, Robert On Fri, Jan 8, 2016 at 12:24 PM, Petroules Jake < Jake.Petroules at theqtcompany.com> wrote: > We're raising the minimum OS X to 10.8 (2012). The iOS minimum is still 6 > (also 2012), but I wonder whether we should also raise that a version (or > even two) considering its uniquely rapid upgrade cycle (frequently upgraded > hardware, less user ability to opt out of software updates). > > Bumping it to iOS 8 would also allow us to stop making static builds and > thus gain support for App Extensions. > > Thoughts? Tor Arne? > -- > Jake Petroules - jake.petroules at theqtcompany.com > Consulting Services Engineer - The Qt Company > > From: Development on behalf of > Turunen Tuukka > Date: Thursday, January 7, 2016 at 11:18 PM > To: John Layt , "development at qt-project.org" < > development at qt-project.org> > Subject: Re: [Development] Minimum Deployment Platforms for 5.7 onwards? > > > > Hi John, > > > > This item was discussed at Qt Contributor’s Summit, please see session > notes: http://wiki.qt.io/QtCS2015_LTS > > > > For compilers this is also documented to the Qt Base change log: > http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1 > > > > For 5.6 the current list of supported platforms and compilers is the > following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we > are working to add OS X 10.11 to CI and fully support it) > > > > The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older > (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent > versions. Those who have such older platforms to support, are recommended > to stay with the LTS version for a while. This approach allows us to move > faster for new features planned for future Qt releases. > > > > For application developers the documentation is often the best source to > find the list of supported platforms: > http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been > updated to 5.6, but will be before the final release. > > > > Yours, > > > > Tuukka > > > > > > > > *From:* Development [mailto:development-bounces at qt-project.org > ] *On Behalf Of *John Layt > *Sent:* keskiviikkona 30. joulukuuta 2015 20.43 > *To:* development at qt-project.org > *Subject:* [Development] Minimum Deployment Platforms for 5.7 onwards? > > > > Hi, > > Can I just clarify what the minimum deployment platforms are for 5.7 > onwards? That is, the lowest version of each OS that the code must still > run on? Far as I can tell it's something like: > > Windows 7 (or Vista?) > > Windows Embedded Compact 2013 > > OSX 10.8 > > iOS 5.0? > > Android 4.1 (API Level 16)? > > RHEL 6.6 > > Ubuntu 11.10? > > There really should be a wiki page for this... > > > > Cheers! > > John. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at theqtcompany.com Fri Jan 8 11:57:22 2016 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Fri, 8 Jan 2016 10:57:22 +0000 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? In-Reply-To: References: Message-ID: <8A6EF6BE-4CFC-4621-B363-43EEA45F26C3@theqtcompany.com> On Jan 8, 2016, at 2:50 AM, Robert Iakobashvili > wrote: Dear Jake, Unless app developers would like to drop their existing apps and rename/launch instead new apps, they're forced to keep compatibility with the very first iOS-version when their app was accepted to iTunes Store. No you're not. Your users on that version (are you sure you even have any?) simply won't get the updated app requiring the new version, and will remain on their current version. There's no reason to rename your app or create a new iTunes Connect entry. So, dropping iOS-6 is a not issue for me, but dropping iOS-7 - yes. jm2c Kind regards, Robert On Fri, Jan 8, 2016 at 12:24 PM, Petroules Jake > wrote: We're raising the minimum OS X to 10.8 (2012). The iOS minimum is still 6 (also 2012), but I wonder whether we should also raise that a version (or even two) considering its uniquely rapid upgrade cycle (frequently upgraded hardware, less user ability to opt out of software updates). Bumping it to iOS 8 would also allow us to stop making static builds and thus gain support for App Extensions. Thoughts? Tor Arne? -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company From: Development > on behalf of Turunen Tuukka > Date: Thursday, January 7, 2016 at 11:18 PM To: John Layt >, "development at qt-project.org" > Subject: Re: [Development] Minimum Deployment Platforms for 5.7 onwards? Hi John, This item was discussed at Qt Contributor’s Summit, please see session notes: http://wiki.qt.io/QtCS2015_LTS For compilers this is also documented to the Qt Base change log: http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1 For 5.6 the current list of supported platforms and compilers is the following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we are working to add OS X 10.11 to CI and fully support it) The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent versions. Those who have such older platforms to support, are recommended to stay with the LTS version for a while. This approach allows us to move faster for new features planned for future Qt releases. For application developers the documentation is often the best source to find the list of supported platforms: http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been updated to 5.6, but will be before the final release. Yours, Tuukka From: Development [mailto:development-bounces at qt-project.org] On Behalf Of John Layt Sent: keskiviikkona 30. joulukuuta 2015 20.43 To: development at qt-project.org Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? Hi, Can I just clarify what the minimum deployment platforms are for 5.7 onwards? That is, the lowest version of each OS that the code must still run on? Far as I can tell it's something like: Windows 7 (or Vista?) Windows Embedded Compact 2013 OSX 10.8 iOS 5.0? Android 4.1 (API Level 16)? RHEL 6.6 Ubuntu 11.10? There really should be a wiki page for this... Cheers! John. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From gmaxera at gmail.com Fri Jan 8 11:58:37 2016 From: gmaxera at gmail.com (Gian Maxera) Date: Fri, 8 Jan 2016 10:58:37 +0000 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? In-Reply-To: References: Message-ID: Dear Robert, are you sure the apple store force to keep compatibility of the very first iOS version ?? From what I know, you can drop compatibility of older iOS version when you release a new version on the app store. And when someone install your app in an older phone, a popup appear warning the user that will be installed an older version because the last version of the app required a more recent iOS. Ciao, Gianluca. > On 8 Jan 2016, at 10:50, Robert Iakobashvili wrote: > > Dear Jake, > Unless app developers would like to drop their existing apps > and rename/launch instead new apps, > they're forced to keep compatibility with the very first iOS-version > when their app was accepted to iTunes Store. > > So, dropping iOS-6 is a not issue for me, but dropping iOS-7 - yes. > > jm2c > > Kind regards, > Robert > > On Fri, Jan 8, 2016 at 12:24 PM, Petroules Jake > wrote: > We're raising the minimum OS X to 10.8 (2012). The iOS minimum is still 6 (also 2012), but I wonder whether we should also raise that a version (or even two) considering its uniquely rapid upgrade cycle (frequently upgraded hardware, less user ability to opt out of software updates). > > Bumping it to iOS 8 would also allow us to stop making static builds and thus gain support for App Extensions. > > Thoughts? Tor Arne? > -- > Jake Petroules - jake.petroules at theqtcompany.com > Consulting Services Engineer - The Qt Company > > From: Development > on behalf of Turunen Tuukka > > Date: Thursday, January 7, 2016 at 11:18 PM > To: John Layt >, "development at qt-project.org " > > Subject: Re: [Development] Minimum Deployment Platforms for 5.7 onwards? > > > > Hi John, > > > > This item was discussed at Qt Contributor’s Summit, please see session notes: http://wiki.qt.io/QtCS2015_LTS > > > For compilers this is also documented to the Qt Base change log: http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1 >   <> > For 5.6 the current list of supported platforms and compilers is the following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we are working to add OS X 10.11 to CI and fully support it) > > > > The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent versions. Those who have such older platforms to support, are recommended to stay with the LTS version for a while. This approach allows us to move faster for new features planned for future Qt releases. > > > > For application developers the documentation is often the best source to find the list of supported platforms: http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been updated to 5.6, but will be before the final release. > > > > Yours, > > > > Tuukka > > > > > > > > From: Development [mailto:development-bounces at qt-project.org ] On Behalf Of John Layt > Sent: keskiviikkona 30. joulukuuta 2015 20.43 > To: development at qt-project.org > Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? > > > > Hi, > > Can I just clarify what the minimum deployment platforms are for 5.7 onwards? That is, the lowest version of each OS that the code must still run on? Far as I can tell it's something like: > > Windows 7 (or Vista?) > > Windows Embedded Compact 2013 > > OSX 10.8 > > iOS 5.0? > > Android 4.1 (API Level 16)? > > RHEL 6.6 > > Ubuntu 11.10? > > There really should be a wiki page for this... > > > > Cheers! > > John. > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.funk at kdab.com Fri Jan 8 12:12:28 2016 From: kevin.funk at kdab.com (Kevin Funk) Date: Fri, 08 Jan 2016 12:12:28 +0100 Subject: [Development] QStateMachine and SCXML? In-Reply-To: References: Message-ID: <1632542.rpfQVaNgFk@kerberos> On Friday, January 08, 2016 09:14:25 AM Ch'Gans wrote: > Just discovered this few days ago: > https://github.com/KDAB/KDStateMachineEditor Heya, unfortunately KDStateMachineEditor has nothing to do with Vikas' request. KDStateMachineEditor can import/export SCXML from/to its internal state machine representation, that's true. You can import an SCXML file, and you'd get the graphical representation of the state machine in the editor interface; or you'd export a currently edited state machine as SCXML. Which it cannot do is *initializing* a QStateMachine based on a SCXML specification. Vikas was probably referring to scc: https://blog.qt.io/blog/2009/08/10/introducing-scc-the-scxml-compiler-for-the-qt-state-machine-framework/ We played around with that idea in the past, too, but abandoned it b/c the SCXML *format* is just too far away from the Qt world. @Vikas: What you might want to do: Check out the new Declarative State Machine Framework in Qt 5.4 which KDAB and Ford Motor Company have developed in a joint effort to overcome the problems using SCXML as description format: http://doc.qt.io/qt-5/qtqml-statemachine-qmlmodule.html Instead of using XML, this uses QML to describe a state machine, with all the benefits you get by leveraging QML features such as property bindings, etc. Example: DSM.StateMachine { id: stateMachine initialState: state running: true DSM.State { id: state DSM.TimeoutTransition { targetState: finalState timeout: 1000 } } DSM.FinalState { id: finalState } } Hope this helps, Cheers, Kevin > Hope this helps. > Chris > > On 8 January 2016 at 05:35, Vikas Bhargava wrote: > > Hi, > > Can someone point me to the latest on whether State Machine initialization > > based on a scxml specification would be supported. The last discussion I > > could find > > on the topic is at least 5 years old. The current State Machine framework > > has no support as far as I can see. > > > > Regards, > > Vikas > > > > _______________________________________________ > > 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 -- Kevin Funk | kevin.funk at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7021 bytes Desc: not available URL: From rjvbertin at gmail.com Fri Jan 8 12:56:43 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 08 Jan 2016 12:56:43 +0100 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" References: <3041715.L3EpGueuhN@patux> <2410121.JqzdYGHRjx@tjmaciei-mobl4> <2058518.tptgUkBaMG@patux.local> <1FA408A8-105E-432D-A331-1D6AAD202A2C@digia.com> <11002383.Lrxd2GGWnv@portia.local> <0D566E9A-6C47-4EBE-8629-01B435B9EE96@digia.com> Message-ID: <1598504.fRsuBOLsXD@portia.local> Sorvig Morten wrote: > But you seldom want to have two instances of (say) Mail running - you start > it, or bring the existing one to front. So kLSLaunchNewInstance does not seems > that useful in practice. It'd probably depend on the application whether you want to be able to launch a separate instance. Something like Qt Creator would be an example where you might indeed want to be able to start a 2nd instance that has a different project/session open. In other words, an API for gui-style launching of applications would probably need a flag to indicate whether or not a new instance is desired in case an instance is already running. > It could be long wait for the notification: closing the last application > window does usually not cause the application process to exit. If we want to Doesn't the same apply to other kinds of applications, or at least to the current termination notification for GUI applications started through QProcess? R. From tor.arne.vestbo at theqtcompany.com Fri Jan 8 13:42:27 2016 From: tor.arne.vestbo at theqtcompany.com (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 8 Jan 2016 13:42:27 +0100 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? In-Reply-To: References: Message-ID: <568FAEB3.4020401@theqtcompany.com> On 08/01/16 11:24, Petroules Jake wrote: > We're raising the minimum OS X to 10.8 (2012). The iOS minimum is still > 6 (also 2012), but I wonder whether we should also raise that a version > (or even two) considering its uniquely rapid upgrade cycle (frequently > upgraded hardware, less user ability to opt out of software updates). > > Bumping it to iOS 8 would also allow us to stop making static builds and > thus gain support for App Extensions. > I don't see any reason to bump > iOS 6.0 as of now. tor arne From Morten.Sorvig at theqtcompany.com Fri Jan 8 13:57:26 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Fri, 8 Jan 2016 12:57:26 +0000 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: <1598504.fRsuBOLsXD@portia.local> References: <3041715.L3EpGueuhN@patux> <2410121.JqzdYGHRjx@tjmaciei-mobl4> <2058518.tptgUkBaMG@patux.local> <1FA408A8-105E-432D-A331-1D6AAD202A2C@digia.com> <11002383.Lrxd2GGWnv@portia.local> <0D566E9A-6C47-4EBE-8629-01B435B9EE96@digia.com> <1598504.fRsuBOLsXD@portia.local> Message-ID: > On 08 Jan 2016, at 12:56, René J. V. Bertin wrote: > > Sorvig Morten wrote: > >> But you seldom want to have two instances of (say) Mail running - you start >> it, or bring the existing one to front. So kLSLaunchNewInstance does not seems >> that useful in practice. > > It'd probably depend on the application whether you want to be able to launch a > separate instance. Something like Qt Creator would be an example where you might > indeed want to be able to start a 2nd instance that has a different > project/session open. > > In other words, an API for gui-style launching of applications would probably > need a flag to indicate whether or not a new instance is desired in case an > instance is already running. How can you know what the target application prefers? (now or in the future). > >> It could be long wait for the notification: closing the last application >> window does usually not cause the application process to exit. If we want to > > Doesn't the same apply to other kinds of applications, or at least to the > current termination notification for GUI applications started through QProcess? It does, but I think that’s fine. QProcess works with processes on the unix level and behaves as expected. For a Gui-level features perhaps ‘process’ is the wrong abstraction and we want to have API on QDesktopServices instead. Morten From rjvbertin at gmail.com Fri Jan 8 15:16:35 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 08 Jan 2016 15:16:35 +0100 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" References: <3041715.L3EpGueuhN@patux> <2410121.JqzdYGHRjx@tjmaciei-mobl4> <2058518.tptgUkBaMG@patux.local> <1FA408A8-105E-432D-A331-1D6AAD202A2C@digia.com> <11002383.Lrxd2GGWnv@portia.local> <0D566E9A-6C47-4EBE-8629-01B435B9EE96@digia.com> <1598504.fRsuBOLsXD@portia.local> Message-ID: <2872969.4IFEN1SzVd@patux.local> Sorvig Morten wrote: >> In other words, an API for gui-style launching of applications would probably >> need a flag to indicate whether or not a new instance is desired in case an >> instance is already running. > > How can you know what the target application prefers? (now or in the future). Methinks that the calling application is in a much better position to know that than Qt itself, and if not can at least expose the choice to the user. A priori target (= launched) application preference shouldn't be an issue here: it is what will happen when the default launch type is used without attempt to override. I don't know of a way to override launching a new instance, btw. > It does, but I think that’s fine. QProcess works with processes on the unix > level and behaves as expected. Then I don't see the problem for the equivalent notification if it is delivered through the same channel. I don't think we should be concerned with events like closing the last window in a "child" application. Whether or not that means something to the parent application is an unknown at this point and level, but either way it's a different kind of event. One of the kind that could be signalled through QDesktopServices. Startup notification in the sense "the app is now all up and running and ready for user interaction" is a different matter, but also a separate question. > For a Gui-level features perhaps ‘process’ is the wrong abstraction and we > want to have API on QDesktopServices instead. No, I think you'd still want a process for lowlevel things like knowing if a child (still) runs, starting and stopping it, possibly even killing it if a desktop-level request to quit has no effect. I hadn't thought about QDesktopServices yet. It's a very small class currently; it would not be illogical to implement a specific GUI way of launching in the form of something like QProcess *QDesktopServices::launchApplication() would it? On standard (or XDG-style) Unix platforms that could then include a way to start an application through its .desktop file, for instance. René From thiago.macieira at intel.com Fri Jan 8 17:26:56 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 08 Jan 2016 08:26:56 -0800 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: <1750840.futb0kCIkp@patux.local> References: <3041715.L3EpGueuhN@patux> <1480913.Lrqr7IgLMB@tjmaciei-mobl4> <1750840.futb0kCIkp@patux.local> Message-ID: <1852119.gx9PXCOtb3@tjmaciei-mobl4> On Friday 08 January 2016 10:52:14 René J. V. Bertin wrote: > What about the idea of a QProcess::startDetached variant that returns a > QProcess instance? That'd make sense (IMHO) if it's possible to provide > (at least) termination notification through the QProcess::finished signal - > and I don't see why the fact of starting something in detached fashion > would make it uninteresting to know if/when that process exits (e.g. to > start it up again). The question would be of course to what extent it is > possible to support this on more than a single platform. I think you meant something other than startDetached. You can't get notification signals from detached processes because they are detached. They are meant to outlive the current application. You can't get SIGCHLD for them. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From frederik.gladhorn at theqtcompany.com Fri Jan 8 17:55:35 2016 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Fri, 8 Jan 2016 17:55:35 +0100 Subject: [Development] Expect delays in Continuous Integration today In-Reply-To: References: Message-ID: <1648846.Ui5boi0jYa@frederik-thinkcentre-m93p> And we should be back to normal :) Staging in all branches is enabled and we are a big step closer to producing the final 5.6 packages. Cheers, Frederik On Friday, January 08, 2016 08:12:43 AM Gladhorn Frederik wrote: > Hi all, > > > in order to fix https://bugreports.qt.io/browse/QTBUG-50065 and others > linked to it, we need to clean up the way we use -prefix in continuous > integration. > > Up to now we used the source dir as prefix in many configurations while > expecting make install to work, which is more of a hack that worked by > accident. > > > We will change to the proper usage of prefix pointing to a different path, > sadly this means slight changes to our collected artifacts which in turn > means that modules depending on qtbase will not build until the first round > of fresh builds. > > > Due to this we'll disable and gradually re-enable building of all modules. > > Sorry for the inconvenience, we're working on a better solution for the next > time (versioning our archives), but for now we do not want to stand in the > way of the Qt 5.6.0 release any longer. > > During the day things should go back to normal step by step. In the mean > time it might be OK to hold off staging patches today unless they are very > urgent to keep the noise lower. > > > Greetings, > > Frederik From jlayt at kde.org Fri Jan 8 18:05:16 2016 From: jlayt at kde.org (John Layt) Date: Fri, 8 Jan 2016 17:05:16 +0000 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? In-Reply-To: References: Message-ID: On 8 January 2016 at 07:18, Turunen Tuukka wrote: > > > Hi John, > > > > This item was discussed at Qt Contributor’s Summit, please see session > notes: http://wiki.qt.io/QtCS2015_LTS > > > > For compilers this is also documented to the Qt Base change log: > http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1 > > > > For 5.6 the current list of supported platforms and compilers is the > following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we > are working to add OS X 10.11 to CI and fully support it) > > > > The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older > (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent > versions. Those who have such older platforms to support, are recommended > to stay with the LTS version for a while. This approach allows us to move > faster for new features planned for future Qt releases. > > > > For application developers the documentation is often the best source to > find the list of supported platforms: > http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been > updated to 5.6, but will be before the final release. > Thanks Tuukka, but that's all a bit messy and hard to work out (not to mention the LTS email threads here which are impossible to follow). It makes my point really that there's no one canonical source telling us Qt contributors what platforms we need to design or code features for in the next Qt release, or for fixes in the last bug release. I need to know what versions of the platform API's I can use, not what's Official, Reference, CI, or Community supported. I've taken the liberty of starting a wiki page to try summarise things the way I'd like to see them laid out: https://wiki.qt.io/PlatformSupport Feel free to edit or fix or move to a more appropriate place. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Fri Jan 8 18:25:22 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 08 Jan 2016 18:25:22 +0100 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" References: <3041715.L3EpGueuhN@patux> <1480913.Lrqr7IgLMB@tjmaciei-mobl4> <1750840.futb0kCIkp@patux.local> <1852119.gx9PXCOtb3@tjmaciei-mobl4> Message-ID: <2306060.dd4nXWngHh@portia.local> Thiago Macieira wrote: > On Friday 08 January 2016 10:52:14 René J. V. Bertin wrote: > I think you meant something other than startDetached. You can't get > notification signals from detached processes because they are detached. They > are meant to outlive the current application. You can't get SIGCHLD for them. That's true for signals that depend on that particular kind of parent/child relationship. But there are more ways in which a process can detach from its calling process, and undoubtedly more ways to get notification signals from a process that doesn't have the current process as its ppid. On OS X this is as simple as setting up an NSNotificationCenter and then comparing the pid of each event of interest with that of the application(s) to monitor. The signal handler (one per notification of interest) can be defined as as addition to the NSWorkspace implementation, no need to subclass NSWorkspace for that. R From thiago.macieira at intel.com Fri Jan 8 19:11:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 08 Jan 2016 10:11:08 -0800 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: <2306060.dd4nXWngHh@portia.local> References: <3041715.L3EpGueuhN@patux> <1852119.gx9PXCOtb3@tjmaciei-mobl4> <2306060.dd4nXWngHh@portia.local> Message-ID: <1842747.dIvuuQls4t@tjmaciei-mobl4> On Friday 08 January 2016 18:25:22 René J. V. Bertin wrote: > That's true for signals that depend on that particular kind of parent/child > relationship. But there are more ways in which a process can detach from its > calling process, and undoubtedly more ways to get notification signals from > a process that doesn't have the current process as its ppid. On OS X this > is as simple as setting up an NSNotificationCenter and then comparing the > pid of each event of interest with that of the application(s) to monitor. > The signal handler (one per notification of interest) can be defined as as > addition to the NSWorkspace implementation, no need to subclass NSWorkspace > for that. This all sounds like qtmacextras functionality. There's no equivalent in other platforms. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jaramago.fernandez.javier at gmail.com Fri Jan 8 21:40:58 2016 From: jaramago.fernandez.javier at gmail.com (Javier Jaramago Fernandez) Date: Fri, 8 Jan 2016 21:40:58 +0100 Subject: [Development] Design choice of QFileSystemModel Message-ID: Anyone knows about the issue related to this thread? qt-forum . In concrete I wanted to know about this statement: "I can tell you that the filter is not being invalidated, but that there is a list within QFileSystemModel that contains exceptions from the filtering and calling setRootPath adds that directory to the list" This is actually happening in Qt 5.5.1. Is this an intended design choice or should I report it as a bug? -- Javier Jaramago Fernández. -------------- next part -------------- An HTML attachment was scrubbed... URL: From szehowe.koh at gmail.com Sat Jan 9 03:23:29 2016 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Sat, 9 Jan 2016 10:23:29 +0800 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? In-Reply-To: References: Message-ID: On 9 January 2016 at 01:05, John Layt wrote: > > On 8 January 2016 at 07:18, Turunen Tuukka wrote: >> >> >> >> Hi John, >> >> >> >> This item was discussed at Qt Contributor’s Summit, please see session notes: http://wiki.qt.io/QtCS2015_LTS >> >> >> >> For compilers this is also documented to the Qt Base change log: http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1 >> >> >> >> For 5.6 the current list of supported platforms and compilers is the following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we are working to add OS X 10.11 to CI and fully support it) >> >> >> >> The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent versions. Those who have such older platforms to support, are recommended to stay with the LTS version for a while. This approach allows us to move faster for new features planned for future Qt releases. >> >> >> >> For application developers the documentation is often the best source to find the list of supported platforms: http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been updated to 5.6, but will be before the final release. > > > Thanks Tuukka, but that's all a bit messy and hard to work out (not to mention the LTS email threads here which are impossible to follow). It makes my point really that there's no one canonical source telling us Qt contributors what platforms we need to design or code features for in the next Qt release, or for fixes in the last bug release. I need to know what versions of the platform API's I can use, not what's Official, Reference, CI, or Community supported. > > I've taken the liberty of starting a wiki page to try summarise things the way I'd like to see them laid out: > > https://wiki.qt.io/PlatformSupport > > Feel free to edit or fix or move to a more appropriate place. > > John. Thanks for creating this summary, John. Would you be willing to merge your content into this existing page? https://wiki.qt.io/Supported_Platforms Regards, Sze-Howe
This email has been sent from a virus-free computer protected by Avast.
www.avast.com
From denis.shienkov at gmail.com Sat Jan 9 15:30:37 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sat, 9 Jan 2016 17:30:37 +0300 Subject: [Development] [autotests] Why the objects are used in 'heap' instead of 'stack' Message-ID: <5691198D.1070902@gmail.com> Hi all, Is there are any reasons why the tested objects are created in 'heap' instead of 'stack' (in the majority of cases)? E.g. we can look on \qtbase\tests\auto\network\socket\qtcpsocket\tst_qtcpsocket.cpp as example, where in each test are used the new/delete: void tst_QTcpSocket::foo() { QTcpSocket *socket = new QTcpSocket; // make tests delete socket; } instead of void tst_QTcpSocket::foo() { QTcpSocket socket; // make tests } BR, Denis From thiago.macieira at intel.com Sat Jan 9 16:49:33 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 09 Jan 2016 07:49:33 -0800 Subject: [Development] [autotests] Why the objects are used in 'heap' instead of 'stack' In-Reply-To: <5691198D.1070902@gmail.com> References: <5691198D.1070902@gmail.com> Message-ID: <13703551.njA6qOsYse@tjmaciei-mobl4> On Saturday 09 January 2016 17:30:37 Denis Shienkov wrote: > E.g. we can look on > \qtbase\tests\auto\network\socket\qtcpsocket\tst_qtcpsocket.cpp as example, > where in each test are used the new/delete: > > void tst_QTcpSocket::foo() > { > QTcpSocket *socket = new QTcpSocket; > // make tests > delete socket; > } Because they are not like that. Here's an actual copy/paste from the test: void tst_QTcpSocket::waitForReadyReadInASlot() { QTcpSocket *socket = newSocket(); [... other code ...] delete socket; } What's the difference? QTcpSocket *tst_QTcpSocket::newSocket() const { QTcpSocket *socket; #ifndef QT_NO_SSL QFETCH_GLOBAL(bool, ssl); socket = ssl ? new QSslSocket : new QTcpSocket; #else socket = new QTcpSocket; #endif -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From coroberti at gmail.com Sun Jan 10 06:51:45 2016 From: coroberti at gmail.com (Robert Iakobashvili) Date: Sun, 10 Jan 2016 07:51:45 +0200 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? In-Reply-To: References: Message-ID: Yes, Gian, you are right. iTunes delivers updates only to the users with appropriate iOS version. And users with older iOS could be told to upgrade their hardware. When they get a newer HW, they can get the updated software in due course. Thanks for clarifying it. Kind regards, Robert On Fri, Jan 8, 2016 at 12:58 PM, Gian Maxera wrote: > Dear Robert, > are you sure the apple store force to keep compatibility of the very first > iOS version ?? > From what I know, you can drop compatibility of older iOS version when you > release a new version on the app store. > And when someone install your app in an older phone, a popup appear > warning the user that will be installed an older version because the last > version of the app required a more recent iOS. > > Ciao, > Gianluca. > > > On 8 Jan 2016, at 10:50, Robert Iakobashvili wrote: > > Dear Jake, > Unless app developers would like to drop their existing apps > and rename/launch instead new apps, > they're forced to keep compatibility with the very first iOS-version > when their app was accepted to iTunes Store. > > So, dropping iOS-6 is a not issue for me, but dropping iOS-7 - yes. > > jm2c > > Kind regards, > Robert > > On Fri, Jan 8, 2016 at 12:24 PM, Petroules Jake < > Jake.Petroules at theqtcompany.com> wrote: > >> We're raising the minimum OS X to 10.8 (2012). The iOS minimum is still 6 >> (also 2012), but I wonder whether we should also raise that a version (or >> even two) considering its uniquely rapid upgrade cycle (frequently upgraded >> hardware, less user ability to opt out of software updates). >> >> Bumping it to iOS 8 would also allow us to stop making static builds and >> thus gain support for App Extensions. >> >> Thoughts? Tor Arne? >> -- >> Jake Petroules - jake.petroules at theqtcompany.com >> Consulting Services Engineer - The Qt Company >> >> From: Development on behalf of >> Turunen Tuukka >> Date: Thursday, January 7, 2016 at 11:18 PM >> To: John Layt , "development at qt-project.org" < >> development at qt-project.org> >> Subject: Re: [Development] Minimum Deployment Platforms for 5.7 onwards? >> >> >> >> Hi John, >> >> >> >> This item was discussed at Qt Contributor’s Summit, please see session >> notes: http://wiki.qt.io/QtCS2015_LTS >> >> >> >> For compilers this is also documented to the Qt Base change log: >> http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1 >> >> >> >> For 5.6 the current list of supported platforms and compilers is the >> following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we >> are working to add OS X 10.11 to CI and fully support it) >> >> >> >> The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older >> (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent >> versions. Those who have such older platforms to support, are recommended >> to stay with the LTS version for a while. This approach allows us to move >> faster for new features planned for future Qt releases. >> >> >> >> For application developers the documentation is often the best source to >> find the list of supported platforms: >> http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been >> updated to 5.6, but will be before the final release. >> >> >> >> Yours, >> >> >> >> Tuukka >> >> >> >> >> >> >> >> *From:* Development [mailto:development-bounces at qt-project.org >> ] *On Behalf Of *John Layt >> *Sent:* keskiviikkona 30. joulukuuta 2015 20.43 >> *To:* development at qt-project.org >> *Subject:* [Development] Minimum Deployment Platforms for 5.7 onwards? >> >> >> >> Hi, >> >> Can I just clarify what the minimum deployment platforms are for 5.7 >> onwards? That is, the lowest version of each OS that the code must still >> run on? Far as I can tell it's something like: >> >> Windows 7 (or Vista?) >> >> Windows Embedded Compact 2013 >> >> OSX 10.8 >> >> iOS 5.0? >> >> Android 4.1 (API Level 16)? >> >> RHEL 6.6 >> >> Ubuntu 11.10? >> >> There really should be a wiki page for this... >> >> >> >> Cheers! >> >> John. >> >> _______________________________________________ >> 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 tuukka.turunen at theqtcompany.com Sun Jan 10 07:29:32 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Sun, 10 Jan 2016 06:29:32 +0000 Subject: [Development] Minimum Deployment Platforms for 5.7 onwards? In-Reply-To: References: , Message-ID: <1B98C0E3-D541-490C-B8A6-867DB79EB6B1@theqtcompany.com> Thanks John. The reason why we have been so far listing all the supported platforms is limitations of new platform versions until needed fixes are in place. Let's think how to best unify the way you propose to the wiki and doc supported platform pages. I do fully agree with you point, we need to make it very clear what is supported - especially now as the plan is to move a bit faster than before in the releases following LTS. -- Tuukka > Sze Howe Koh kirjoitti 9.1.2016 kello 4.23: > >> On 9 January 2016 at 01:05, John Layt wrote: >> >>> On 8 January 2016 at 07:18, Turunen Tuukka wrote: >>> >>> >>> >>> Hi John, >>> >>> >>> >>> This item was discussed at Qt Contributor’s Summit, please see session notes: http://wiki.qt.io/QtCS2015_LTS >>> >>> >>> >>> For compilers this is also documented to the Qt Base change log: http://code.qt.io/cgit/qt/qtbase.git/tree/dist/changes-5.5.1 >>> >>> >>> >>> For 5.6 the current list of supported platforms and compilers is the following: http://wiki.qt.io/Qt-5.6.0-tools-and-versions (note that we are working to add OS X 10.11 to CI and fully support it) >>> >>> >>> >>> The idea is that by making Qt 5.6 LTS, we gain more freedom to drop older (non-c++11) compilers as well as older platforms from Qt 5.7 and subsequent versions. Those who have such older platforms to support, are recommended to stay with the LTS version for a while. This approach allows us to move faster for new features planned for future Qt releases. >>> >>> >>> >>> For application developers the documentation is often the best source to find the list of supported platforms: http://doc.qt.io/QtSupportedPlatforms/index.html This has not yet been updated to 5.6, but will be before the final release. >> >> >> Thanks Tuukka, but that's all a bit messy and hard to work out (not to mention the LTS email threads here which are impossible to follow). It makes my point really that there's no one canonical source telling us Qt contributors what platforms we need to design or code features for in the next Qt release, or for fixes in the last bug release. I need to know what versions of the platform API's I can use, not what's Official, Reference, CI, or Community supported. >> >> I've taken the liberty of starting a wiki page to try summarise things the way I'd like to see them laid out: >> >> https://wiki.qt.io/PlatformSupport >> >> Feel free to edit or fix or move to a more appropriate place. >> >> John. > > Thanks for creating this summary, John. Would you be willing to merge > your content into this existing page? > https://wiki.qt.io/Supported_Platforms > > > Regards, > Sze-Howe > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From denis.shienkov at gmail.com Sun Jan 10 09:03:59 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Sun, 10 Jan 2016 11:03:59 +0300 Subject: [Development] [autotests] Why the objects are used in 'heap' instead of 'stack' In-Reply-To: <13703551.njA6qOsYse@tjmaciei-mobl4> References: <5691198D.1070902@gmail.com> <13703551.njA6qOsYse@tjmaciei-mobl4> Message-ID: <5692106F.90600@gmail.com> Ok, this is enough :) 09.01.2016 18:49, Thiago Macieira пишет: > On Saturday 09 January 2016 17:30:37 Denis Shienkov wrote: >> E.g. we can look on >> \qtbase\tests\auto\network\socket\qtcpsocket\tst_qtcpsocket.cpp as example, >> where in each test are used the new/delete: >> >> void tst_QTcpSocket::foo() >> { >> QTcpSocket *socket = new QTcpSocket; >> // make tests >> delete socket; >> } > Because they are not like that. > > Here's an actual copy/paste from the test: > > void tst_QTcpSocket::waitForReadyReadInASlot() > { > QTcpSocket *socket = newSocket(); > [... other code ...] > delete socket; > } > > What's the difference? > > QTcpSocket *tst_QTcpSocket::newSocket() const > { > QTcpSocket *socket; > #ifndef QT_NO_SSL > QFETCH_GLOBAL(bool, ssl); > socket = ssl ? new QSslSocket : new QTcpSocket; > #else > socket = new QTcpSocket; > #endif > From pierluigi.fiorini at gmail.com Mon Jan 11 00:27:08 2016 From: pierluigi.fiorini at gmail.com (Pier Luigi Fiorini) Date: Mon, 11 Jan 2016 00:27:08 +0100 Subject: [Development] Update QtWayland CI to Wayland 1.6+ Message-ID: Hi, We are starting to have QtWayland patches that require at least Wayland 1.6 available, such as: - https://codereview.qt-project.org/#/c/104222/ - https://codereview.qt-project.org/#/c/112141/ - https://codereview.qt-project.org/#/c/144891/ We need to update CI to at least Wayland 1.6 as soon as possible. If I recall CI is running Ubuntu 14.04 LTS now, but LTS is released every two years. The next LTS should be 16.04 which means that until April we cannot merge those patches making the first one more than 1 year old. Would it be possible to switch to a distro that potentially has more frequent updates to avoid repeating the same problem again in the future? -- Out of the box experience http://hawaiios.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Mon Jan 11 11:55:30 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Mon, 11 Jan 2016 11:55:30 +0100 Subject: [Development] Design choice of QFileSystemModel In-Reply-To: References: Message-ID: <56938A22.3050605@familiesomers.nl> Op 08/01/2016 om 21:40 schreef Javier Jaramago Fernandez: > Anyone knows about the issue related to this thread? qt-forum > . In > concrete I wanted to know about this statement: > > "I can tell you that the filter is not being invalidated, but that > there is a list within QFileSystemModel that contains exceptions from > the filtering and calling setRootPath adds that directory to the list" > > This is actually happening in Qt 5.5.1. Is this an intended design > choice or should I report it as a bug? > Reading through that thread, I am wondering why people are modifying the QFileSystemModel's rootPath all the time, instead of leaving that static and setting the root index for the view instead... André -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikkel at krautz.dk Wed Jan 13 00:36:14 2016 From: mikkel at krautz.dk (Mikkel Krautz) Date: Wed, 13 Jan 2016 00:36:14 +0100 Subject: [Development] OS X SDK set via configure is not used during build (dev branch) Message-ID: Hi, I'm currently on 10.10, Yosemite, using Xcode 7.1.1 (as of this writing). This version of Xcode only ships with the 10.11 SDK. But I am on 10.10. When I built Qt (dev branch), by passing -sdk macosx10.11 -- the only SDK I have -- to configure, I get build failures. Inspecting the compiler flags, I see that the OS X 10.10 SDK is being used (-isysroot, etc.). It seems to be because qtbase/mkspecs/common/macx.conf sets QMAKE_MAC_SDK to "macosx". As a quick local fix, I set this to "macosx10.11", and I could correctly build Qt again. I don't think this is a configuration error on my end, or a bug in Xcode. For example, xcodebuild correctly translates the non-versioned "macosx" SDK to "macosx10.11". $ xcodebuild -sdk macosx Build settings from command line: SDKROOT = macosx10.11 [...] Does anyone know what's going on? Thanks, Mikkel From thiago.macieira at intel.com Wed Jan 13 00:55:48 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 12 Jan 2016 15:55:48 -0800 Subject: [Development] OS X SDK set via configure is not used during build (dev branch) In-Reply-To: References: Message-ID: <1459106.uDgAvuznkS@tjmaciei-mobl4> On Wednesday 13 January 2016 00:36:14 Mikkel Krautz wrote: > Hi, > > I'm currently on 10.10, Yosemite, using Xcode 7.1.1 (as of this writing). > > This version of Xcode only ships with the 10.11 SDK. But I am on 10.10. > > When I built Qt (dev branch), by passing -sdk macosx10.11 -- the only > SDK I have -- to configure, I get build failures. > > Inspecting the compiler flags, I see that the OS X 10.10 SDK is being > used (-isysroot, etc.). Remove all .qmake.{cache,super} files you may have. The build stores the version of the SDK it found when you first ran qmake and won't check again. This wasn't a problem in the past because Apple used to provide the same SDK for more than one version of Xcode, so you were unlikely to upgrade and lose the SDK you last had. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mikkel at krautz.dk Wed Jan 13 02:14:00 2016 From: mikkel at krautz.dk (Mikkel Krautz) Date: Wed, 13 Jan 2016 02:14:00 +0100 Subject: [Development] OS X SDK set via configure is not used during build (dev branch) In-Reply-To: <1459106.uDgAvuznkS@tjmaciei-mobl4> References: <1459106.uDgAvuznkS@tjmaciei-mobl4> Message-ID: On Wed, Jan 13, 2016 at 12:55 AM, Thiago Macieira wrote: > On Wednesday 13 January 2016 00:36:14 Mikkel Krautz wrote: >> Hi, >> >> I'm currently on 10.10, Yosemite, using Xcode 7.1.1 (as of this writing). >> >> This version of Xcode only ships with the 10.11 SDK. But I am on 10.10. >> >> When I built Qt (dev branch), by passing -sdk macosx10.11 -- the only >> SDK I have -- to configure, I get build failures. >> >> Inspecting the compiler flags, I see that the OS X 10.10 SDK is being >> used (-isysroot, etc.). > > Remove all .qmake.{cache,super} files you may have. The build stores the > version of the SDK it found when you first ran qmake and won't check again. > This wasn't a problem in the past because Apple used to provide the same SDK > for more than one version of Xcode, so you were unlikely to upgrade and lose > the SDK you last had. I am pretty sure I had the files cleaned before trying this, so I tried again: $ cd qt5 $ git submodule foreach --recursive git clean -dfx -f $ find . | grep qmake.cache ./qtbase/qmake/cachekeys.h ./qtbase/tests/auto/tools/qmake/testdata/export_across_file_boundaries/.qmake.cache $ find . | grep qmake.super $ Building: $ cd qtbase $ OPENSSL_LIBS="-L${MUMBLE_PREFIX}/lib -lssl -lcrypto" ./configure -developer-build -opensource -nomake examples -sdk macosx10.11 -I ${MUMBLE_PREFIX}/include -openssl-linked $ make Full output at https://gist.github.com/mkrautz/2041003a8aeb63a792b8 Initially, I had MAKEFLAGS set to -j8. When I did that, I observed that *some* clang++ invocations correctly used the 10.11 SDK. Here's me running "make -j8", right after I ran "make": https://gist.github.com/mkrautz/d96d5329807addf8abc2 So, some things are using the correct sysroot. From Lars.Knoll at theqtcompany.com Wed Jan 13 12:15:05 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 13 Jan 2016 11:15:05 +0000 Subject: [Development] New KDE Free Qt Foundation agreement and changes to Qt Message-ID: <578CF287-C1BC-4F31-9DA6-78F75157DD72@theqtcompany.com> Hi everybody, The Qt Company has over the last days signed a new and updated agreement with the KDE Free Foundation. With this new agreement come some adjustments to the open source licensing of Qt. Basically LGPLv3 will in the future be our main license for frameworks, GPLv3 for the tooling. At the same time, The Qt Company committed to open source the currently commercial only parts of Qt for Application Development under the GPLv3 and make those available to the open source community. I have discussed this change with many of our Maintainers over the last week, getting a lot of positive feedback to this change. Please have a read through the blog post at http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation for all the details. We have already pushed the sources of Qt Charts, Qt Data Visualisation and the Qt virtual keyboard to codereview, and you can pull the code from there. I would personally like to see most of these things integrated into the Qt 5.7 open source packages already, and minimise the feature delta between the OSS and commercial versions of Qt for Application Development. Cheers, Lars From Richard.Gustavsen at theqtcompany.com Wed Jan 13 12:21:24 2016 From: Richard.Gustavsen at theqtcompany.com (Gustavsen Richard) Date: Wed, 13 Jan 2016 11:21:24 +0000 Subject: [Development] RFC: QProcess variant or separate class for launching applications "GUI-style" In-Reply-To: <5525902.Jps4RkPotF@patux> References: <3041715.L3EpGueuhN@patux> <11002383.Lrxd2GGWnv@portia.local> , <5525902.Jps4RkPotF@patux> Message-ID: > True, or no, that'd rather be "/usr/bin/open [-n] -W -a appbundle|bundle-exec". It wouldn't always be trivial to get the invocation just right, as that is a wrapper to LSOpenURLWithRole() whereas we'd probably use something more simple, with less ambiguous specification of the arguments. Besides, we identified a need to know the pid and also to be notified of process termination. Note that this will also work on OS X (didn't read the other mails, ignore if it QDesktopServices has been discussed): QDesktopServices::openUrl(QUrl("file:///Applications/Safari.app")); -Richard From pullmoll at t-online.de Wed Jan 13 13:21:23 2016 From: pullmoll at t-online.de (=?ISO-8859-1?Q?J=FCrgen_Buchm=FCller?=) Date: Wed, 13 Jan 2016 13:21:23 +0100 Subject: [Development] Qt5 + Windows + static libraries Message-ID: <1452687683.1598.24.camel@t-online.de> Hi devs! When porting our project from Qt4 to Qt5, I ran into a severe problem with the Windows version. On Linux everything worked fine, on Windows it did not. Instantiating a "QApplication app;" and qDebug()ing the "app.instance()" always returned NULL on Windows. The details of my odyssey with this problem can be found here: https://forum.qt.io/topic/55404/qcoreapplication-instance-is-null The problem resulted from the executable, which was built in debug mode, also importing the Qt5 release-DLLs, which alone took me quite some time to find out. And after much more trial and error, the root cause of the problem turned out to be two of our submodules being built as static libraries and linked against in some other submodules of the application. As it seems now, creating "CONFIG += static create_prl" libraries and linking against these with "CONFIG += link_prl" makes the submodules (DLLs) which link against the static libs also import the release Qt5- DLLs in a debug build. Is this a known problem? Am I the first one to stumble upon this issue? Is it my fault or is this a real bug? Cheers Jürgen From oswald.buddenhagen at theqtcompany.com Wed Jan 13 15:11:44 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 13 Jan 2016 15:11:44 +0100 Subject: [Development] Qt5 + Windows + static libraries In-Reply-To: <1452687683.1598.24.camel@t-online.de> References: <1452687683.1598.24.camel@t-online.de> Message-ID: <20160113141144.GB22076@troll08.it.local> On Wed, Jan 13, 2016 at 01:21:23PM +0100, Jürgen Buchmüller wrote: > And after much more trial and error, the root cause of the problem > turned out to be two of our submodules being built as static libraries > and linked against in some other submodules of the application. > > As it seems now, creating "CONFIG += static create_prl" libraries and > linking against these with "CONFIG += link_prl" makes the submodules > (DLLs) which link against the static libs also import the release Qt5- > DLLs in a debug build. > i see no bug report here. when the prl files name release dlls, your static libraries are evidently linked against them. From gmaxera at gmail.com Wed Jan 13 15:57:36 2016 From: gmaxera at gmail.com (Gian Maxera) Date: Wed, 13 Jan 2016 14:57:36 +0000 Subject: [Development] is this a bug on QMediaPlayer on Android ? Message-ID: <5DCE17B0-75AD-4BE5-B810-81CDE8709EE8@gmail.com> Hello, my app crash when trying to play a sound with QMediaPlayer on Android. This is the error: No implementation found for void org.qtproject.qt5.android.multimedia.QtAndroidMediaPlayer.onStateChangedNative(int, long) I’m using Qt 5.5.1 Ciao, Gianluca. From pullmoll at t-online.de Wed Jan 13 16:13:18 2016 From: pullmoll at t-online.de (=?ISO-8859-1?Q?J=FCrgen_Buchm=FCller?=) Date: Wed, 13 Jan 2016 16:13:18 +0100 Subject: [Development] Qt5 + Windows + static libraries In-Reply-To: <20160113141144.GB22076@troll08.it.local> References: <1452687683.1598.24.camel@t-online.de> <20160113141144.GB22076@troll08.it.local> Message-ID: <1452697998.1598.32.camel@t-online.de> Am Mittwoch, den 13.01.2016, 15:11 +0100 schrieb Oswald Buddenhagen: > > i see no bug report here. when the prl files name release dlls, your > static libraries are evidently linked against them. D'OH! The problem is that the static submodules are compiled with the debug_and_release flag in CONFIG. I wasn't aware that this is obviously a default, or the default with QtCreator. My project doesn't define debug_and_release anywhere. Simply adding "CONFIG -= debug_and_release" in the *.pro files now builds the static libs in debug mode and Qt5 release DLLs are no longer imported. From perezmeyer at gmail.com Thu Jan 14 03:50:36 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 13 Jan 2016 23:50:36 -0300 Subject: [Development] New KDE Free Qt Foundation agreement and changes to Qt In-Reply-To: <578CF287-C1BC-4F31-9DA6-78F75157DD72@theqtcompany.com> References: <578CF287-C1BC-4F31-9DA6-78F75157DD72@theqtcompany.com> Message-ID: <14387794.CZ4Dshb0uG@luna> Simply wonderful, thanks a lot you all =) -- "So long, and thanks for all the fish!" The Hitchhickers guide to the Galaxy Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From andreas at hanssen.name Thu Jan 14 08:49:35 2016 From: andreas at hanssen.name (Andreas Aardal Hanssen) Date: Thu, 14 Jan 2016 08:49:35 +0100 Subject: [Development] New KDE Free Qt Foundation agreement and changes to Qt In-Reply-To: <578CF287-C1BC-4F31-9DA6-78F75157DD72@theqtcompany.com> References: <578CF287-C1BC-4F31-9DA6-78F75157DD72@theqtcompany.com> Message-ID: 2016-01-13 12:15 GMT+01:00 Knoll Lars : > Hi everybody, > The Qt Company has over the last days signed a new and updated agreement > with the KDE Free Foundation. With this new agreement come some adjustments > to the open source licensing of Qt. Basically LGPLv3 will in the future be > our main license for frameworks, GPLv3 for the tooling. > At the same time, The Qt Company committed to open source the currently > commercial only parts of Qt for Application Development under the GPLv3 and > make those available to the open source community. > I have discussed this change with many of our Maintainers over the last > week, getting a lot of positive feedback to this change. > With Qt 5.6 being LTS and 5.7 removing licenses from modules, is there enough thunder in 6.0 to get people away from the cooosy 5.6 release? ;-) I mean - judging solely on historical events, the .0s have needed some time to stabilize and the big bang features typically don't show up in the very latest minor releases. Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at theqtcompany.com Thu Jan 14 09:05:40 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 14 Jan 2016 08:05:40 +0000 Subject: [Development] New KDE Free Qt Foundation agreement and changes to Qt In-Reply-To: References: <578CF287-C1BC-4F31-9DA6-78F75157DD72@theqtcompany.com> Message-ID: <7497729F-CE8F-4B5B-8AD3-C48F6FB5A9ED@theqtcompany.com> On 14/01/16 08:49, "Development on behalf of Andreas Aardal Hanssen" wrote: >2016-01-13 12:15 GMT+01:00 Knoll Lars : > >Hi everybody, >The Qt Company has over the last days signed a new and updated agreement with the KDE Free Foundation. With this new agreement come some adjustments to the open source licensing of Qt. Basically LGPLv3 will in the future be our main license for frameworks, > GPLv3 for the tooling. >At the same time, The Qt Company committed to open source the currently commercial only parts of Qt for Application Development under the GPLv3 and make those available to the open source community. >I have discussed this change with many of our Maintainers over the last week, getting a lot of positive feedback to this change. > > > > >With Qt 5.6 being LTS and 5.7 removing licenses from modules, is there enough thunder in 6.0 to get people away from the cooosy 5.6 release? ;-) I mean - judging solely on historical events, the .0s have needed some time to stabilize and the big bang features > typically don't show up in the very latest minor releases. We’ll be working on that thunder. There’s some ideas we have for 5.8 and later :) Cheers, Lars From jedrzej.nowacki at theqtcompany.com Thu Jan 14 10:15:40 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 14 Jan 2016 10:15:40 +0100 Subject: [Development] Update QtWayland CI to Wayland 1.6+ In-Reply-To: References: Message-ID: <2068353.uLVHXMb8fz@42> On Monday 11 of January 2016 00:27:08 Pier Luigi Fiorini wrote: > Hi, > > We are starting to have QtWayland patches that require at least Wayland 1.6 > available, such as: > > - https://codereview.qt-project.org/#/c/104222/ > - https://codereview.qt-project.org/#/c/112141/ > - https://codereview.qt-project.org/#/c/144891/ > > We need to update CI to at least Wayland 1.6 as soon as possible. > > If I recall CI is running Ubuntu 14.04 LTS now, but LTS is released every > two years. > > The next LTS should be 16.04 which means that until April we cannot merge > those patches making the first one more than 1 year old. > > Would it be possible to switch to a distro that potentially has more > frequent updates to avoid repeating the same problem again in the future? Hi, I guess the whole point of having Ubuntu 14.04 LTS in CI is to support that platform as long as it is important. As you said it will be important until 16.04 release. I think we could potentially remove 14.04 from CI on dev branch after Qt 5.7 release. Can't you "ifdef" you code, so it "works" with the older Wayland too? Cheers, Jędrek From pasi.keranen at theqtcompany.com Thu Jan 14 12:58:21 2016 From: pasi.keranen at theqtcompany.com (=?utf-8?B?S2Vyw6RuZW4gUGFzaQ==?=) Date: Thu, 14 Jan 2016 11:58:21 +0000 Subject: [Development] Charts and DataVis (New KDE Free Qt Foundation Agreement and Changes) Message-ID: <7CD5687C-E6C8-44FC-B637-8DA1FC29CBD5@theqtcompany.com> Hi, As Lars mentioned in his email on KDE Free Qt foundation agreement and changes, we’re pushing source of Qt Charts and Qt DataVisualization to codereview. I’d like to propose these two modules to be taken as part of Qt add-on modules, they have been part of commercial Qt releases for some time now. And I’d like to propose Tomi Korpipää to be named as the maintainer of Qt DataVisualization, Tomi has been one of the key developers in the development of DataVisualization from the beginning. Also I’d like to propose Miikka Heikkinen as maintainer for Qt Charts, Miikka has a long history with the module and has recently started adding OpenGL optimisations to some of the parts. Regards, Pasi -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Thu Jan 14 13:02:03 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Thu, 14 Jan 2016 12:02:03 +0000 Subject: [Development] Charts and DataVis (New KDE Free Qt Foundation Agreement and Changes) In-Reply-To: <7CD5687C-E6C8-44FC-B637-8DA1FC29CBD5@theqtcompany.com> References: <7CD5687C-E6C8-44FC-B637-8DA1FC29CBD5@theqtcompany.com> Message-ID: +1 From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Keränen Pasi Sent: torstaina 14. tammikuuta 2016 13.58 To: development at qt-project.org Subject: [Development] Charts and DataVis (New KDE Free Qt Foundation Agreement and Changes) Hi, As Lars mentioned in his email on KDE Free Qt foundation agreement and changes, we’re pushing source of Qt Charts and Qt DataVisualization to codereview. I’d like to propose these two modules to be taken as part of Qt add-on modules, they have been part of commercial Qt releases for some time now. And I’d like to propose Tomi Korpipää to be named as the maintainer of Qt DataVisualization, Tomi has been one of the key developers in the development of DataVisualization from the beginning. Also I’d like to propose Miikka Heikkinen as maintainer for Qt Charts, Miikka has a long history with the module and has recently started adding OpenGL optimisations to some of the parts. Regards, Pasi -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Thu Jan 14 14:54:36 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 14 Jan 2016 14:54:36 +0100 Subject: [Development] Charts and DataVis (New KDE Free Qt Foundation Agreement and Changes) In-Reply-To: <7CD5687C-E6C8-44FC-B637-8DA1FC29CBD5@theqtcompany.com> References: <7CD5687C-E6C8-44FC-B637-8DA1FC29CBD5@theqtcompany.com> Message-ID: <201601141454.37395.marc.mutz@kdab.com> On Thursday 14 January 2016 12:58:21 Keränen Pasi wrote: > Hi, > > As Lars mentioned in his email on KDE Free Qt foundation agreement and > changes, we’re pushing source of Qt Charts and Qt DataVisualization to > codereview. What's the state of BC/SC promises on those? Ie. are we free to review the API and throw out QList, say, or will we be restrained by SC? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Lars.Knoll at theqtcompany.com Thu Jan 14 14:40:50 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 14 Jan 2016 13:40:50 +0000 Subject: [Development] Charts and DataVis (New KDE Free Qt Foundation Agreement and Changes) In-Reply-To: <201601141454.37395.marc.mutz@kdab.com> References: <7CD5687C-E6C8-44FC-B637-8DA1FC29CBD5@theqtcompany.com> <201601141454.37395.marc.mutz@kdab.com> Message-ID: <93868EB6-0B0D-4707-85A3-CB07433C6CC8@theqtcompany.com> On 14/01/16 14:54, "Development on behalf of Marc Mutz" wrote: >On Thursday 14 January 2016 12:58:21 Keränen Pasi wrote: >> Hi, >> >> As Lars mentioned in his email on KDE Free Qt foundation agreement and >> changes, we’re pushing source of Qt Charts and Qt DataVisualization to >> codereview. > >What's the state of BC/SC promises on those? Ie. are we free to review the API >and throw out QList, say, or will we be restrained by SC? We should aim for keeping SC, but I’d anyway like to align the .so versions with the rest of Qt, so we will most likely break BC. Cheers, Lars From thiago.macieira at intel.com Thu Jan 14 15:39:29 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 14 Jan 2016 06:39:29 -0800 Subject: [Development] Update QtWayland CI to Wayland 1.6+ In-Reply-To: <2068353.uLVHXMb8fz@42> References: <2068353.uLVHXMb8fz@42> Message-ID: <3727175.kPGsayWS9r@tjmaciei-mobl4> On Thursday 14 January 2016 10:15:40 Jędrzej Nowacki wrote: > I guess the whole point of having Ubuntu 14.04 LTS in CI is to support that > platform as long as it is important. As you said it will be important until > 16.04 release. I think we could potentially remove 14.04 from CI on dev > branch after Qt 5.7 release. Can't you "ifdef" you code, so it "works" with > the older Wayland too? I don't think it makes sense to support Wayland that old, especially not on a distro that decided to not support Wayland. It's probably better to just skip building Wayland altogether if the found libraries are too old. We just need a newer distro that does support Wayland to be present. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jedrzej.nowacki at theqtcompany.com Thu Jan 14 16:05:17 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Thu, 14 Jan 2016 16:05:17 +0100 Subject: [Development] Update QtWayland CI to Wayland 1.6+ In-Reply-To: <3727175.kPGsayWS9r@tjmaciei-mobl4> References: <2068353.uLVHXMb8fz@42> <3727175.kPGsayWS9r@tjmaciei-mobl4> Message-ID: <1772765.s8pGWdcMpc@42> On Thursday 14 of January 2016 06:39:29 Thiago Macieira wrote: > On Thursday 14 January 2016 10:15:40 Jędrzej Nowacki wrote: > > I guess the whole point of having Ubuntu 14.04 LTS in CI is to support > > that > > > > platform as long as it is important. As you said it will be important > > until > > 16.04 release. I think we could potentially remove 14.04 from CI on dev > > branch after Qt 5.7 release. Can't you "ifdef" you code, so it "works" > > with > > the older Wayland too? > > I don't think it makes sense to support Wayland that old, especially not on > a distro that decided to not support Wayland. It's probably better to just > skip building Wayland altogether if the found libraries are too old. > > We just need a newer distro that does support Wayland to be present. True, so the assumption is that Qt should compile on the 14.04 for now. It doesn't mean that the provided Wayland will be used. I'm fine with that :-) Cheers, Jędrek From Shawn.Rutledge at theqtcompany.com Thu Jan 14 16:12:43 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Thu, 14 Jan 2016 15:12:43 +0000 Subject: [Development] Update QtWayland CI to Wayland 1.6+ In-Reply-To: <1772765.s8pGWdcMpc@42> References: <2068353.uLVHXMb8fz@42> <3727175.kPGsayWS9r@tjmaciei-mobl4> <1772765.s8pGWdcMpc@42> Message-ID: <5394CEE9-BBD1-47D0-BBCE-4005D226D4DA@digia.com> > On 14 Jan 2016, at 16:05, Jędrzej Nowacki wrote: > > On Thursday 14 of January 2016 06:39:29 Thiago Macieira wrote: >> On Thursday 14 January 2016 10:15:40 Jędrzej Nowacki wrote: >>> I guess the whole point of having Ubuntu 14.04 LTS in CI is to support >>> that >>> >>> platform as long as it is important. As you said it will be important >>> until >>> 16.04 release. I think we could potentially remove 14.04 from CI on dev >>> branch after Qt 5.7 release. Can't you "ifdef" you code, so it "works" >>> with >>> the older Wayland too? >> >> I don't think it makes sense to support Wayland that old, especially not on >> a distro that decided to not support Wayland. It's probably better to just >> skip building Wayland altogether if the found libraries are too old. >> >> We just need a newer distro that does support Wayland to be present. > > True, so the assumption is that Qt should compile on the 14.04 for now. It > doesn't mean that the provided Wayland will be used. I'm fine with that :-) But the one that we ship with the Qt installer had better work, right? It’s built on some version of RedHat AFAIK. From pierluigi.fiorini at gmail.com Thu Jan 14 16:23:06 2016 From: pierluigi.fiorini at gmail.com (Pier Luigi Fiorini) Date: Thu, 14 Jan 2016 16:23:06 +0100 Subject: [Development] Update QtWayland CI to Wayland 1.6+ In-Reply-To: <2068353.uLVHXMb8fz@42> References: <2068353.uLVHXMb8fz@42> Message-ID: 2016-01-14 10:15 GMT+01:00 Jędrzej Nowacki : > On Monday 11 of January 2016 00:27:08 Pier Luigi Fiorini wrote: > > Hi, > > > > We are starting to have QtWayland patches that require at least Wayland > 1.6 > > available, such as: > > > > - https://codereview.qt-project.org/#/c/104222/ > > - https://codereview.qt-project.org/#/c/112141/ > > - https://codereview.qt-project.org/#/c/144891/ > > > > We need to update CI to at least Wayland 1.6 as soon as possible. > > > > If I recall CI is running Ubuntu 14.04 LTS now, but LTS is released every > > two years. > > > > The next LTS should be 16.04 which means that until April we cannot merge > > those patches making the first one more than 1 year old. > > > > Would it be possible to switch to a distro that potentially has more > > frequent updates to avoid repeating the same problem again in the future? > > Hi, > > I guess the whole point of having Ubuntu 14.04 LTS in CI is to support > that > platform as long as it is important. As you said it will be important until > 16.04 release. I think we could potentially remove 14.04 from CI on dev > branch > after Qt 5.7 release. Can't you "ifdef" you code, so it "works" with the > older > Wayland too? Nope, unfortunately in order to use the newer protocol we need to link to libwayland >= 1.6 Recent versions of Wayland (>= 1.8) should let us target a new protocol version while linking to an older version mitigating the problem in the future, but still Ubuntu is probably not the best option for Wayland. -- Out of the box experience http://hawaiios.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From pierluigi.fiorini at gmail.com Thu Jan 14 16:32:33 2016 From: pierluigi.fiorini at gmail.com (Pier Luigi Fiorini) Date: Thu, 14 Jan 2016 16:32:33 +0100 Subject: [Development] Update QtWayland CI to Wayland 1.6+ In-Reply-To: <3727175.kPGsayWS9r@tjmaciei-mobl4> References: <2068353.uLVHXMb8fz@42> <3727175.kPGsayWS9r@tjmaciei-mobl4> Message-ID: 2016-01-14 15:39 GMT+01:00 Thiago Macieira : > On Thursday 14 January 2016 10:15:40 Jędrzej Nowacki wrote: > > I guess the whole point of having Ubuntu 14.04 LTS in CI is to support > that > > platform as long as it is important. As you said it will be important > until > > 16.04 release. I think we could potentially remove 14.04 from CI on dev > > branch after Qt 5.7 release. Can't you "ifdef" you code, so it "works" > with > > the older Wayland too? > > I don't think it makes sense to support Wayland that old, especially not > on a > distro that decided to not support Wayland. It's probably better to just > skip > building Wayland altogether if the found libraries are too old. > > We just need a newer distro that does support Wayland to be present. That looks like a future proof solution, perhaps OpenSuSE - the new 42 release has Wayland 1.8 as far as I can tell [*] [*] http://download.opensuse.org/repositories/openSUSE:/42/images/repo/openSUSE-42.1-x86_64-Build0008-Media1/suse/x86_64/libwayland-server0-1.8.0-1.4.x86_64.rpm -- Out of the box experience http://hawaiios.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Jan 14 18:25:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 14 Jan 2016 09:25:16 -0800 Subject: [Development] Update QtWayland CI to Wayland 1.6+ In-Reply-To: <5394CEE9-BBD1-47D0-BBCE-4005D226D4DA@digia.com> References: <1772765.s8pGWdcMpc@42> <5394CEE9-BBD1-47D0-BBCE-4005D226D4DA@digia.com> Message-ID: <2722677.PqiqKUgldS@tjmaciei-mobl4> On Thursday 14 January 2016 15:12:43 Rutledge Shawn wrote: > > True, so the assumption is that Qt should compile on the 14.04 for now. It > > doesn't mean that the provided Wayland will be used. I'm fine with that > > :-) Right, that's just a matter of a configure-time check and disable the module if it's too old. > But the one that we ship with the Qt installer had better work, right? It’s > built on some version of RedHat AFAIK. Assuming there's a interest in providing binaries, yes. It would be really nice to build the QPA plugin for Wayland in our regular binaries, so the machine used to build the binaries will need a recent version of Wayland. I don't think there's use in providing a pre-built Compositor module for desktop Linux. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Fri Jan 15 03:58:12 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jan 2016 03:58:12 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <2082261.eIJjJmcJUW@tjmaciei-mobl4> <568BD018.40608@taschenorakel.de> <201601051756.18974.marc.mutz@kdab.com> Message-ID: Иван Комиссаров wrote: > Still, what about policy not to use std:: classes in Qt API? So why not just add a QOptional that works the same as std::optional? Kevin Kofler From marc.mutz at kdab.com Fri Jan 15 12:20:27 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 15 Jan 2016 12:20:27 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <201601151220.27198.marc.mutz@kdab.com> On Friday 15 January 2016 03:58:12 Kevin Kofler wrote: > Иван Комиссаров wrote: > > Still, what about policy not to use std:: classes in Qt API? > > So why not just add a QOptional that works the same as std::optional? a) because we can't (we don't yet require the necessary language features) b) because once introduced, people will add all kinds of Qt-specific stuff to it, making it impossible to replace it with std::optional down the road. And since it will be good enough for the low demands of Qt development, it will no longer see development and fall behind the state of the art. Consider QVector: it has been Qt-ifed by both adding (technically) useless duplicate Qt-ish API, CoW, and a Qt-specific type classification scheme plus corresponding optimisations that make it very hard to argue for std::vector use instead. The Qt community had two decades where they could have influenced the direction std::vector would take so it could allow the same optimisations that QVector has, but the time and energy was instead put into re-writing the containers for every major release (yes, for Qt 5, too, and Thiago's Qt 6 QVector again looks much different from the Qt 5 one). The CoW makes QVector slow and increase code size, leads to hidden detaches that not even Qt experts regularly avoid in their daily work, and doesn't even work properly because you can take iterators into a QVector and, after copying the vector, change both copies through the iterator into the first. That is a conscious trade-off because making the container unsharable, as it must become once it hands out iterators, would make CoW fail to take effect _all the time_. But it leads to careless copying of QVectors that also doesn't really help with porting to std::vector. All the while - and I don't believe I'm saying this - std::vector *blazes the trail* with move semantics, emplace_back and stateful allocators (making QVarLengthArray all but useless). Does QVector use move semantics? No. Does QVector have emplace_back? No. Does QVector have an allocator, even one that, citing Alexandrescu, actually deals with allocation? No. Does QVector, even with Q_PRIMITIVE_TYPE payloads, expand to less code as std::vector? No: https://codereview.qt-project.org/145587 (comment from 01-14 11:21). Does QVector have a debug mode comparable to that of std::vector implementations? Nope. Or: The only reason I ever used std::list was to use its splice() feature. Does QLinkedList have splice()? No, of course not. Because it _cannot_ (it's CoWed: how do you take ownership of nodes if the they are shared? By copying all other nodes in a detach()?). This is why we need to stop duplicating std API. It's not Qt's core competency to meddle with things we only have a half-interest in. It's fun to write QOptional. Until it isn't anymore. And then the (Qt) world needs to live with the poor-man's std::optional for the next few decades. Please, no. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From abbapoh at gmail.com Fri Jan 15 11:28:32 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Fri, 15 Jan 2016 13:28:32 +0300 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601151220.27198.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: I've already heard those arguments, however we _can't_ use std::vector in API, because it's implementation may differ between compliers (gcc and clang stdlibs, for example). But we can use some features that implemented in the same way (std::pair or std::exception). You can continue to say how bad QVector is (and it is) but it will not be thrown away in near future. Same is for std::optional. Are they compatible between clang and gcc? (and between different versions of gcc (std::unordered_map was not)) 2016-01-15 14:20 GMT+03:00 Marc Mutz : > On Friday 15 January 2016 03:58:12 Kevin Kofler wrote: > > Иван Комиссаров wrote: > > > Still, what about policy not to use std:: classes in Qt API? > > > > So why not just add a QOptional that works the same as std::optional? > > a) because we can't (we don't yet require the necessary language features) > b) because once introduced, people will add all kinds of Qt-specific stuff > to > it, making it impossible to replace it with std::optional down the road. > And > since it will be good enough for the low demands of Qt development, it > will > no longer see development and fall behind the state of the art. > > > Consider QVector: it has been Qt-ifed by both adding (technically) useless > duplicate Qt-ish API, CoW, and a Qt-specific type classification scheme > plus > corresponding optimisations that make it very hard to argue for std::vector > use instead. The Qt community had two decades where they could have > influenced > the direction std::vector would take so it could allow the same > optimisations > that QVector has, but the time and energy was instead put into re-writing > the > containers for every major release (yes, for Qt 5, too, and Thiago's Qt 6 > QVector again looks much different from the Qt 5 one). > > The CoW makes QVector slow and increase code size, leads to hidden detaches > that not even Qt experts regularly avoid in their daily work, and doesn't > even > work properly because you can take iterators into a QVector and, after > copying > the vector, change both copies through the iterator into the first. That > is a > conscious trade-off because making the container unsharable, as it must > become > once it hands out iterators, would make CoW fail to take effect _all the > time_. > But it leads to careless copying of QVectors that also doesn't really help > with porting to std::vector. > > All the while - and I don't believe I'm saying this - std::vector *blazes > the > trail* with move semantics, emplace_back and stateful allocators (making > QVarLengthArray all but useless). Does QVector use move semantics? No. Does > QVector have emplace_back? No. Does QVector have an allocator, even one > that, > citing Alexandrescu, actually deals with allocation? No. Does QVector, even > with Q_PRIMITIVE_TYPE payloads, expand to less code as std::vector? No: > https://codereview.qt-project.org/145587 (comment from 01-14 11:21). Does > QVector have a debug mode comparable to that of std::vector > implementations? > Nope. > > Or: The only reason I ever used std::list was to use its splice() feature. > Does QLinkedList have splice()? No, of course not. Because it _cannot_ > (it's > CoWed: how do you take ownership of nodes if the they are shared? By > copying > all other nodes in a detach()?). > > This is why we need to stop duplicating std API. It's not Qt's core > competency > to meddle with things we only have a half-interest in. It's fun to write > QOptional. Until it isn't anymore. And then the (Qt) world needs to live > with > the poor-man's std::optional for the next few decades. > > > Please, no. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dangelog at gmail.com Fri Jan 15 11:33:58 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Fri, 15 Jan 2016 11:33:58 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: On Fri, Jan 15, 2016 at 11:28 AM, Иван Комиссаров wrote: > I've already heard those arguments, however we _can't_ use std::vector in > API, because it's implementation may differ between compliers (gcc and > clang stdlibs, for example). We might reopen the case about why we should care at preserving binary compatibility amongs different standard libraries. Or preserving binary compatibility at all... -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo at vikingsoft.eu Fri Jan 15 12:40:05 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Fri, 15 Jan 2016 12:40:05 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601151220.27198.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: <5698DA95.90703@vikingsoft.eu> Den 15-01-2016 kl. 12:20 skrev Marc Mutz: > Consider QVector: it has been Qt-ifed by both adding (technically) useless > duplicate Qt-ish API, CoW, and a Qt-specific type classification scheme plus > corresponding optimisations that make it very hard to argue for std::vector > use instead. The Qt community had two decades where they could have influenced > the direction std::vector would take so it could allow the same optimisations > that QVector has, but the time and energy was instead put into re-writing the > containers for every major release (yes, for Qt 5, too, and Thiago's Qt 6 > QVector again looks much different from the Qt 5 one). > > The CoW makes QVector slow and increase code size, leads to hidden detaches > that not even Qt experts regularly avoid in their daily work, and doesn't even > work properly because you can take iterators into a QVector and, after copying > the vector, change both copies through the iterator into the first. That is a > conscious trade-off because making the container unsharable, as it must become > once it hands out iterators, would make CoW fail to take effect _all the time_. > But it leads to careless copying of QVectors that also doesn't really help > with porting to std::vector. > > All the while - and I don't believe I'm saying this - std::vector *blazes the > trail* with move semantics, emplace_back and stateful allocators (making > QVarLengthArray all but useless). Does QVector use move semantics? No. Does > QVector have emplace_back? No. Does QVector have an allocator, even one that, > citing Alexandrescu, actually deals with allocation? No. Does QVector, even > with Q_PRIMITIVE_TYPE payloads, expand to less code as std::vector? No: > https://codereview.qt-project.org/145587 (comment from 01-14 11:21). Does > QVector have a debug mode comparable to that of std::vector implementations? > Nope. We have seen this rant from you several times before. The way I see it is that I use QVector when I want the implicit sharing, std::vector when I need speed. Maybe I have a different focus, but I just don't see the need for raw speed very often. On embedded applications I'm very sensitive to it, of course. But on the Windows desktop, I have yet to see an application where the choice of QVector or std::vector makes any kind of difference to the user. Sure, they are there. And there are areas in the model of an application where we should consider speed always. But for the vast majority of the lines of code I write, it makes no difference at all. If it doesn't make a codewise difference, then obviously a faster framework class is better. However, my customers have developers that are a lot less experienced than us. And it's my observation that using the Qt classes over the std classes lead to fewer mistakes and faster applications. It seems much easier to shoot yourself in the foot with std. I don't know why this is, it's only what I observe when I look at code written by others. > This is why we need to stop duplicating std API. It's not Qt's core competency > to meddle with things we only have a half-interest in. It's fun to write > QOptional. Until it isn't anymore. And then the (Qt) world needs to live with > the poor-man's std::optional for the next few decades. Now this is where we completely agree, although probably for slightly different reasons. I would not mind removing some (maybe even most) of the Qt containers for Qt 6 or 7 and forcing people to learn the use std instead. Hash, map, set and linked list would be the first I'd get rid of. And I don't care for the binary compatibility with different compilers argument - just stop shipping binary builds on linux and let people with other compilers on Windows and Mac compile themselves. But there will be reasons why some of them should be here. Having CoW containers is very useful sometimes. And this is only about the containers, I would never support anyone trying to use the horrible abominations that are std::string or std::wstring. Or the std streams *shudder*. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From perezmeyer at gmail.com Fri Jan 15 15:39:53 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 15 Jan 2016 11:39:53 -0300 Subject: [Development] Avoiding segfaults with QML and video cards which do not support OpenGL 2.0 Message-ID: <2625131.X4iUGGqDSc@luna> Hi! With my Debian packager hat on, we are receiving bugs like [bug] in which applications using QML with video cards that do not support OpenGL 2.0 (yes, there are people using 15+ years old video cards out there) makes stuff crash. It is totally fine that QML requires at least OpenGL 2.0, but it would be really nice if apps could be made to not crash. It will also not surprise me if there is already a way to avoid this and what we package maintainers need to do is fill proper bugs to apps not using it. So questions are: - do we have a way to ensure we can do OpenGL 2.0 before loading/using QML? If the answer is yes, what should I look for to pass on to apps developers? - If answer is no: it would be possible to add it? - Can it become a default to check it? IE, not require a developer to do special code. [bug] Thanks in advance, Lisandro. -- 20:16 < Gerardo_Cabero> che me tengo que ir volando .. sino me matan.. esto de tener novia es tan complicacdo como instalar paketes sin internet Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From charleyb123 at gmail.com Fri Jan 15 16:08:52 2016 From: charleyb123 at gmail.com (charleyb123 .) Date: Fri, 15 Jan 2016 08:08:52 -0700 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <5698DA95.90703@vikingsoft.eu> References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> Message-ID: Apologies for "hijacking" the thread, but two points were raised that IMHO would be helpful if they were answered directly: (1) Future of Qt binary compatibility (2) Use of std:: containers (especially in context of (1)). We can take this to another thread as-needed. However, quick "recap": ===>PART (1), Future of Qt binary compatibility Marc sayeth: Notable quote (Marc): > , This is why we need to stop duplicating std API. It's not Qt's core > competency > to meddle with things we only have a half-interest in. It's fun to write > QOptional. Until it isn't anymore. And then the (Qt) world needs to live > with > the poor-man's std::optional for the next few decades. > In further support of (1), ... Иван Комиссаров sayeth: > >> I've already heard those arguments, however we _can't_ use std::vector in >> API, because it's implementation may differ between compliers (gcc and >> clang stdlibs, for example). > > Giuseppe D'Angelo respondeth: > We might reopen the case about why we should care at preserving binary > compatibility amongs different standard libraries. Or preserving binary > compatibility at all... > IMHO, "something is different" now that C++17 will provide features like "Modules". While "phase 1" might merely be something like a glorified "precompiled-header" bundle to speed compile-time, it's clear that "phase 2" is intended to approximate an ABI whereby a compiler could resolve these implementation-mappings across compiled-lib boundaries. This begs the question: Past Qt design decisions providing binary compatibility through *code* decisions (e.g., d-ptr and wrapper classes) might in the (not-too-distant-future) be otherwise resolved with new C++ language features. If this were true, how would Qt like to position itself? Specifically, IMHO Qt remains the best-in-class cross-platform framework. In part, this value came from its strong adherence to managing what nobody else was managing -- its interface binary compatibility. Going forward, Qt's value proposition might more appropriately focus on what it *is*: A rich cross-platform framework (whereby it might continue its ABI stability through C++ language advances, not through library conventions). ===>PART (2), Use of std:: containers This is a big topic, discussed on other Qt threads. However, from this thread: Bo sayeth: > , > However, my customers have developers that are a lot less experienced than > us. And it's my observation that using the Qt classes over the std classes > lead to fewer mistakes and faster applications. It seems much easier to > shoot yourself in the foot with std. I don't know why this is, it's only > what I observe when I look at code written by others. Agree. Completely. IMHO, this is because: std:: and friends: *- GOOD: ...are mathematically elegant, and complete, and fast (e.g., Stepanov's work, iterators, API and implementation evolves with C++ language advances). *- BAD: ...have really poor APIs that are error-prone, are often inconsistent, and incomplete, and dangerous, and unlike how most programmers "think" and designs "work", and are painfully volatile across C++ Language Standards versions. In our codebase, we've "wrapped" the std:: containers for stable-and-safe interfaces. Huge dividends. You can get (unsafe) direct access to the embedded std:: entity if you want. This is another option/mechanism for how we might evolve stable Qt interfaces, and work with std:: and friends. <===END THREAD HIJACK IMHO, the Qt community likely requires a long-term strategy for how it wants to address ABI and std:: in the face of very active advances in C++ Language Standards, libraries, and STL idioms. Also IMHO, these are big things that we can leverage to great Qt advantage. Specifically: (a) There is a reason programmers want to use std:: (b) There is a reason programmers have a hard time using std:: in any codebase (Qt can help with this) --charley -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Fri Jan 15 16:16:45 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 15 Jan 2016 10:16:45 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <5698DA95.90703@vikingsoft.eu> References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> Message-ID: On 2016-01-15 06:40, Bo Thorsen wrote: > I would not mind removing some (maybe even most) of the Qt containers > for Qt 6 or 7 and forcing people to learn the use std instead. Hash, > map, set and linked list would be the first I'd get rid of. Ugh... I *really* hate the idiotic insistence of std containers to insert pairs instead of key, value. (Let's not forget, either, niceties like QMap::value() and QHash::uniqueKeys() that JUST DON'T EXIST in STL.) Qt containers have a *MUCH* better API. Please don't take that away from us. -- Matthew From marc.mutz at kdab.com Fri Jan 15 18:18:09 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 15 Jan 2016 18:18:09 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: <201601151818.09329.marc.mutz@kdab.com> On Friday 15 January 2016 11:28:32 Иван Комиссаров wrote: > I've already heard those arguments, however we _can't_ use std::vector in > API, because it's implementation may differ between compliers (gcc and > clang stdlibs, for example). > But we can use some features that implemented in the same way (std::pair or > std::exception). > You can continue to say how bad QVector is (and it is) but it will not be > thrown away in near future. > Same is for std::optional. Are they compatible between clang and gcc? (and > between different versions of gcc (std::unordered_map was not)) The problem with std APIs is not only layout compatibility (which, indeed, is not a problem for std::pair), but, as Thiago has mentioned on this list before, that the names don't match. It's std::pair in one impl and std::__1::pair in the next... That's only a "problem" as long as you make it one, though. No other C++ library guarantees compat between apps compiled with one STL impl and a librar compiled with another. That also was never the guarantee that Qt gave until, by not having STL types in the API, it started to magically work when one impl moved to a different inline namespace. I find that an overly broad definition of binary compatibility and it does more harm than good. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Fri Jan 15 18:42:43 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 15 Jan 2016 18:42:43 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <5698DA95.90703@vikingsoft.eu> References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> Message-ID: <201601151842.43187.marc.mutz@kdab.com> Hi Bo, On Friday 15 January 2016 12:40:05 Bo Thorsen wrote: > We have seen this rant from you several times before. And you will see it over and over again until enough people are fixing premature pessimisations in existing Qt code. There's a notable increase already. But it takes a long time to turn a supertanker around... On Friday 15 January 2016 12:40:05 Bo Thorsen wrote: > Maybe I have a different focus, but I just don't see the need for raw > speed very often. On embedded applications I'm very sensitive to it, of > course. But on the Windows desktop, I have yet to see an application > where the choice of QVector or std::vector makes any kind of difference > to the user. This is the old difference: you think using std::vector is premature optimisation and I think that using QVector is premature pessimisation. Qt is still a C++ library. If it wasn't for the need for bare-metal speed, everyone would use Java instead. It's safer, more coherent, programmer productivity is higher and programmer cost is lower. But safe languages just don't cut it anymore, that's why C++ is still alive. But if a seemingly innocuous piece of code like for (const auto &e : qtContainer) funReturningQtContainer().first(); ... leads to a memory allocations, nay, a complete deep copy of the container, then this is simply *not acceptable* in C++. I wouldn't even be acceptable *in Java*. It's *orders of magnitude* slower than how an STL container would behave. Sure, if this is not a hot code path, you won't notice. But these things add up. There's a reason why we can't do much more now with the supercomputers that we have on our laps than we could do in the 90s on workstations. Compiling Qt, e.g. hasn't gotten any faster between Qt 1.x and 5.x... But I repeat myself... > Sure, they are there. And there are areas in the model of an application > where we should consider speed always. But for the vast majority of the > lines of code I write, it makes no difference at all. If it doesn't make > a codewise difference, then obviously a faster framework class is better. And why would you advocate learning *two* classes that do exactly the same thing if you need the fast one anyway (for when speed matters)? That surely isn't good API design. > However, my customers have developers that are a lot less experienced > than us. And it's my observation that using the Qt classes over the std > classes lead to fewer mistakes and faster applications. It seems much > easier to shoot yourself in the foot with std. I don't know why this is, > it's only what I observe when I look at code written by others. I don't buy that argument that the STL is less safe. You should teach your customers their STL debug mode. They will never look back at the Qt containers. And no, I cannot believe that using the Qt containers leads to faster applications. It may lead to applications faster, but not to faster applications. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From porten at froglogic.com Fri Jan 15 18:34:39 2016 From: porten at froglogic.com (Harri Porten) Date: Fri, 15 Jan 2016 18:34:39 +0100 (CET) Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601151842.43187.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> <201601151842.43187.marc.mutz@kdab.com> Message-ID: On Fri, 15 Jan 2016, Marc Mutz wrote: > And no, I cannot believe that using the Qt containers leads to faster > applications. It may lead to applications faster, but not to faster > applications. Amen! Now each side of the discussion please pick one of the above possible outcomes and be happy :) Harri. From thiago.macieira at intel.com Fri Jan 15 23:17:14 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 15 Jan 2016 14:17:14 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> Message-ID: <10844609.3zVhgUbpNr@tjmaciei-mobl4> On Friday 15 January 2016 08:08:52 charleyb123 . wrote: > In our codebase, we've "wrapped" the std:: containers for stable-and-safe > interfaces. Huge dividends. You can get (unsafe) direct access to the > embedded std:: entity if you want. This is another option/mechanism for > how we might evolve stable Qt interfaces, and work with std:: and friends. This might be something worth exploring, if you can share that code when the time comes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jan 15 23:20:20 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 15 Jan 2016 14:20:20 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601151842.43187.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> <201601151842.43187.marc.mutz@kdab.com> Message-ID: <39269570.93i4fJSI54@tjmaciei-mobl4> On Friday 15 January 2016 18:42:43 Marc Mutz wrote: > And you will see it over and over again until enough people are fixing > premature pessimisations in existing Qt code. There's a notable increase > already. But it takes a long time to turn a supertanker around... Some of us call them "trade-offs". Every trade-off is a pessimisation somewhere for an optimisation somewhere else. Often, they're not measured in the same units or not quantifiable at all. API quality and consistency fall under those definitions. > And no, I cannot believe that using the Qt containers leads to faster > applications. It may lead to applications faster, but not to faster > applications. Exactly. TTM is a significant factor and we all know Paretto's Law (80-20 rule). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Fri Jan 15 23:27:50 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 15 Jan 2016 23:27:50 +0100 Subject: [Development] Avoiding segfaults with QML and video cards which do not support OpenGL 2.0 References: <2625131.X4iUGGqDSc@luna> Message-ID: Hi Lisandro, Lisandro Damián Nicanor Pérez Meyer wrote: > Hi! With my Debian packager hat on, we are receiving bugs like [bug] in > which applications using QML with video cards that do not support OpenGL > 2.0 (yes, there are people using 15+ years old video cards out there) > makes stuff crash. > > It is totally fine that QML requires at least OpenGL 2.0, but it would be > really nice if apps could be made to not crash. > > It will also not surprise me if there is already a way to avoid this and > what we package maintainers need to do is fill proper bugs to apps not > using it. you just need to install this script: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/plain/10-qt5-check-opengl2.sh to: /etc/X11/xinit/xinitrc.d/10-qt5-check-opengl2.sh and depend on glx-utils, which provides the glxinfo command the script uses. I got the prerequisite environment variable (QT_XCB_FORCE_SOFTWARE_OPENGL) support added to Qt 5.3: https://codereview.qt-project.org/#/c/76992/ It has been in there ever since. (I also mentioned the needed script, but there was no interest in shipping this with Qt, unfortunately.) This is checked once at X11 startup because it is fairly expensive to check the available OpenGL version: You have to spawn an external process and ask Mesa for information there. If you initialize your own process with hardware OpenGL, it is too late to request LIBGL_ALWAYS_SOFTWARE. We have been shipping this solution in Fedora for around 2 years now. What I have not checked is how this interacts with Wayland. The glxconvenience code inside Qt where my QT_XCB_FORCE_SOFTWARE_OPENGL variable is actually implemented may or may not be used there. And xinitrc.d may or may not be run there. Don't ask me. Kevin Kofler From kevin.kofler at chello.at Sat Jan 16 00:44:22 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 16 Jan 2016 00:44:22 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > On Friday 15 January 2016 03:58:12 Kevin Kofler wrote: >> So why not just add a QOptional that works the same as std::optional? > > a) because we can't (we don't yet require the necessary language features) A QOptional that works with Qt's implicitly-shared data objects (such as QStringList, which is what it is wanted for here) only really needs this: T data; bool present; (I guess that order will give the better memory layout than the opposite order.) If present is false, you just put a default-constructed T into the (ignored) data field, which will simply have a null d-pointer and thus cost you almost no time to construct. I don't see what further language features are needed for us. > b) because once introduced, people will add all kinds of Qt-specific stuff > to it, making it impossible to replace it with std::optional down the > road. And since it will be good enough for the low demands of Qt > development, it will no longer see development and fall behind the state > of the art. So what? Qt users are not forced to use it, and I'm sure several will, maybe BECAUSE of the "all kinds of Qt-specific stuff" that people actually find convenient. > > Consider QVector: it has been Qt-ifed by both adding (technically) useless > duplicate Qt-ish API, CoW, and a Qt-specific type classification scheme > plus corresponding optimisations that make it very hard to argue for > std::vector use instead. The Qt community had two decades where they could > have influenced the direction std::vector would take so it could allow the > same optimisations that QVector has, but the time and energy was instead > put into re-writing the containers for every major release (yes, for Qt 5, > too, and Thiago's Qt 6 QVector again looks much different from the Qt 5 > one). But the Qt-ish API and the CoW are exactly what makes the Qt containers NICE to use, unlike the STL. I have found myself more than once using QtCore in a project solely and explicitly for the container classes! They are what makes C++ a nice-to-use language. > The CoW makes QVector slow and increase code size, leads to hidden > detaches that not even Qt experts regularly avoid in their daily work, and Well, I am well aware of the issue, and know to use e.g.: static_cast(vec).first() when needed. (I guess this is actually more efficient than the popular .at(0) workaround. It is definitely not less efficient.) But normally I will just always operate on const data structures (usually const references) when I'm not writing to them, so I don't have to cast anything. (And of course, when I'm writing to them, chances are the detach is exactly what I want or need.) > doesn't even work properly because you can take iterators into a QVector > and, after copying the vector, change both copies through the iterator > into the first. That is a conscious trade-off because making the container > unsharable, as it must become once it hands out iterators, would make CoW > fail to take effect _all the time_. But it leads to careless copying of > QVectors that also doesn't really help with porting to std::vector. So don't use iterators into QVector, use indexes, it's a random-access container. The non-const operator[] that you use then DOES detach when needed. (And of course, for read-only iteration, foreach works great.) The only container type where I found iterators to be truly useful is maps (QMap, QHash, etc.), where the iterator can give me both key and value at once and saves me the key lookup. > All the while - and I don't believe I'm saying this - std::vector *blazes > the trail* with move semantics, emplace_back and stateful allocators > (making QVarLengthArray all but useless). Does QVector use move semantics? > No. Move semantics are mainly an ugly way to avoid copies if you don't have CoW. With CoW data structures, all you save through move semantics is the reference counting. And move semantics make it easy to shoot yourself in the foot. (Either you leave behind an invitation for a use-after-free bug, or you end up swapping instead of assigning, which is also a pessimization.) > Does QVector have emplace_back? No. Just like the move semantics, this is also an ugly and complicated way to avoid a copy if you don't have CoW or merely save the reference counting if you do. > Does QVector have an allocator, even one that, citing Alexandrescu, > actually deals with allocation? No. For the average programmer, an allocator is just an obscure thing that shows up as a template parameter in all the error messages making them ugly and unreadable. The fact that Qt containers only have the template arguments that are intuitively templated on (e.g., QVector has only the contained type as a template parameter) is really a feature, not a bug. > Does QVector, even with Q_PRIMITIVE_TYPE payloads, expand to less code as > std::vector? No: https://codereview.qt-project.org/145587 (comment from > 01-14 11:21). So there is room for improvement there. But in the end, this is not going to be the deciding factor for which implementation to pick for most programmers. And in the end, you need to compare QVector with class libraries in programming languages that offer comparable convenience, not with the C++ STL. If you try to force programmers to use the STL, chances are they will rather just switch to some other programming language that offers the semantics they expect. > Does QVector have a debug mode comparable to that of std::vector > implementations? Nope. I never had any need for that. > Or: The only reason I ever used std::list was to use its splice() feature. > Does QLinkedList have splice()? No, of course not. Because it _cannot_ > (it's CoWed: how do you take ownership of nodes if the they are shared? By > copying all other nodes in a detach()?). Then use std::list if it suits your use case better. Just don't force everyone else to use it. Personally, I also don't normally have a use for QLinkedList, QList suits my needs just fine. :-p (In fact, QList was changed from the linked list it was in Qt 3 to an array of pointers in Qt 4 exactly BECAUSE that's the more efficient data structure in most practical applications.) And I simply find the Qt containers to be much nicer to work with as a whole. In fact, I recently had to use std::priority_queue for a (QtCore- based) project of mine, a container class that sadly is not implemented in Qt (*). After attempting to use it directly and cursing about it, I ended up implementing a Qt-style wrapper around it: * My data class simply multiple-inherits from public QSharedData, public std::priority_queue. * My public class contains a QSharedDataPointer of the above, renames the methods to names matching QQueue, and in particular adds a dequeue() method that does both top() and pop(). Null objects (null d-pointer) are also handled gracefully (the const methods fake an empty queue, the enqueue (= STL push) method allocates the d-pointer). So, a few lines of boilerplate, and suddenly the API becomes usable, and CoW just works. Incidentally, the CoW was also the only way I found to avoid a copy of the whole queue while initializing while keeping C++98 compatibility (so no move or swap): * I need to initialize my priority_queue from a list (actually a QList :-) but I would have the same issue with QVector or even std::vector). * There is no push method that takes a whole list of items. * So I can only: - either push every item one at a time, which sorts them less efficiently than a bulk insert, - or use the constructor that takes iterators, which then leaves me with a whole std::priority_queue to copy. My CoW wrapper avoids that copy. * And my API wrapper actually accepts the QList (or actually any list type with constBegin() and constEnd() methods) directly instead of requiring iterators. (*) I did find one third-party QPriorityQueue class, but it was just a wrapper around std::priority_queue that was neither CoW nor had API consistency with QQueue, so it was better to implement my own. > This is why we need to stop duplicating std API. It's not Qt's core > competency to meddle with things we only have a half-interest in. It's fun > to write QOptional. Until it isn't anymore. And then the (Qt) world needs > to live with the poor-man's std::optional for the next few decades. I think having more Qt containers would actually be a good thing, not something to be scared of. Kevin Kofler From kevin.kofler at chello.at Sat Jan 16 01:29:40 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 16 Jan 2016 01:29:40 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> <201601151842.43187.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > And you will see it over and over again until enough people are fixing > premature pessimisations in existing Qt code. There's a notable increase > already. But it takes a long time to turn a supertanker around... Well, if … > This is the old difference: you think using std::vector is premature > optimisation and I think that using QVector is premature pessimisation. … you think Qt code preferring Qt containers to STL ones is a pessimization, then you will always find "pessimizations". Even if I don't need the CoW in one place, I am still going to pick the Qt container for consistency. > Qt is still a C++ library. If it wasn't for the need for bare-metal speed, > everyone would use Java instead. It's safer, more coherent, programmer > productivity is higher and programmer cost is lower. The thing is, the Qt containers actually make C++ almost as easy to use as Java, yet much faster and more powerful. (And even when I find myself writing Java code, I miss the CoW semantics. Java's explicit sharing makes it easy to shoot yourself in the foot, you have to be careful to clone() in the right places, and "constants" are usually not really constant, a final object variable still allows writing to the object unless it was immutable to begin with. So I find it even EASIER to code in C++ with Qt containers than in Java.) > But safe languages just don't cut it anymore, that's why C++ is still > alive. Sure, speed is a big selling point of C++. I just don't see the Qt containers ruining it to the point you claim it does. > But if a seemingly innocuous piece of code like > > for (const auto &e : qtContainer) > funReturningQtContainer().first(); > ... > > leads to a memory allocations, nay, a complete deep copy of the container, > then this is simply *not acceptable* in C++. I wouldn't even be acceptable > *in Java*. It's *orders of magnitude* slower than how an STL container > would behave. Sure, if this is not a hot code path, you won't notice. But > these things add up. There's a reason why we can't do much more now with > the supercomputers that we have on our laps than we could do in the 90s on > workstations. Compiling Qt, e.g. hasn't gotten any faster between Qt 1.x > and 5.x... > > But I repeat myself... There is an easy fix/workaround in both cases: cast the container to a const reference, or assign it to a const reference variable. The first case can also be avoided by using Qt's foreach instead of the C++11 one. If you really want to avoid the second pitfall (where first() is really the one method this is usually encountered with), then either get a constFirst() added to Qt, or (even more effective) convince folks that first() should become const by default in Qt 6 and the non-const overload renamed to something like firstRef(). Now, what *I* find "simply *not acceptable*" is that "a seemingly innocuous piece of code like": std::vector foo1 = …; std::vector foo2 = foo1; // <- here "leads to a memory allocation, nay, a complete deep copy of the container". This is particularly problematic when you want to have methods that return an STL container, because returning a reference is a bad idea. (Of course you can return a pointer, but that opens its own can of worms, plenty of ways to shoot yourself in the foot there: the same issues with explicit sharing semantics as in Java, plus memory leaks and more.) > And why would you advocate learning *two* classes that do exactly the same > thing if you need the fast one anyway (for when speed matters)? That > surely isn't good API design. I never had to port my code from Qt containers to STL containers for speed, and it is really the last thing I'd try if everything else fails. > I don't buy that argument that the STL is less safe. You should teach your > customers their STL debug mode. They will never look back at the Qt > containers. It sure makes it easier to write inefficient code. The cases where STL containers deep-copy (simple variable assignment) are much more common than the corner cases where Qt containers deep-copy (incorrect use of C++11 for : instead of Qt foreach, accidental use of non-const first()). The class and method names are also a lot less intuitive. And even if you abstract the names, the API is less intuitive, e.g., std::queue and std::priority_queue have no method like QQueue::dequeue that pops an element and returns it, you have to first peek at the front element and then pop it (and to add insult to injury, the methods to peek at the front element don't even have the same name: std::queue::front vs. std::priority_queue::top, which puts us back to the naming issue). > And no, I cannot believe that using the Qt containers leads to faster > applications. It may lead to applications faster, but not to faster > applications. It does, because otherwise the applications would be written in Java or Python instead, surely not in STL C++. Kevin Kofler From Marco.Bubke at theqtcompany.com Sat Jan 16 02:40:02 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Sat, 16 Jan 2016 01:40:02 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: On January 16, 2016 00:44:57 Kevin Kofler wrote: > Marc Mutz wrote: > >> On Friday 15 January 2016 03:58:12 Kevin Kofler wrote: >>> So why not just add a QOptional that works the same as std::optional? >> >> a) because we can't (we don't yet require the necessary language features) > > A QOptional that works with Qt's implicitly-shared data objects (such as > QStringList, which is what it is wanted for here) only really needs this: > T data; > bool present; > (I guess that order will give the better memory layout than the opposite > order.) If present is false, you just put a default-constructed T into the > (ignored) data field, which will simply have a null d-pointer and thus cost > you almost no time to construct. I don't see what further language features > are needed for us. > >> b) because once introduced, people will add all kinds of Qt-specific stuff >> to it, making it impossible to replace it with std::optional down the >> road. And since it will be good enough for the low demands of Qt >> development, it will no longer see development and fall behind the state >> of the art. > > So what? Qt users are not forced to use it, and I'm sure several will, maybe > BECAUSE of the "all kinds of Qt-specific stuff" that people actually find > convenient. Actually this convince is hurting you if you need performance. I would prefer the convenience on top of lower level api. >> >> Consider QVector: it has been Qt-ifed by both adding (technically) useless >> duplicate Qt-ish API, CoW, and a Qt-specific type classification scheme >> plus corresponding optimisations that make it very hard to argue for >> std::vector use instead. The Qt community had two decades where they could >> have influenced the direction std::vector would take so it could allow the >> same optimisations that QVector has, but the time and energy was instead >> put into re-writing the containers for every major release (yes, for Qt 5, >> too, and Thiago's Qt 6 QVector again looks much different from the Qt 5 >> one). > > But the Qt-ish API and the CoW are exactly what makes the Qt containers NICE > to use, unlike the STL. I have found myself more than once using QtCore in a > project solely and explicitly for the container classes! They are what makes > C++ a nice-to-use language. It makes also easy to shoot yourself in the foot. The Qt containers love to malloc. ;-) I really prefer the the proposed ranges API. >> The CoW makes QVector slow and increase code size, leads to hidden >> detaches that not even Qt experts regularly avoid in their daily work, and > > Well, I am well aware of the issue, and know to use e.g.: > static_cast(vec).first() > when needed. (I guess this is actually more efficient than the popular > .at(0) workaround. It is definitely not less efficient.) But normally I will > just always operate on const data structures (usually const references) when > I'm not writing to them, so I don't have to cast anything. (And of course, > when I'm writing to them, chances are the detach is exactly what I want or > need.) > >> doesn't even work properly because you can take iterators into a QVector >> and, after copying the vector, change both copies through the iterator >> into the first. That is a conscious trade-off because making the container >> unsharable, as it must become once it hands out iterators, would make CoW >> fail to take effect _all the time_. But it leads to careless copying of >> QVectors that also doesn't really help with porting to std::vector. > > So don't use iterators into QVector, use indexes, it's a random-access > container. The non-const operator[] that you use then DOES detach when > needed. (And of course, for read-only iteration, foreach works great.) > The only container type where I found iterators to be truly useful is maps > (QMap, QHash, etc.), where the iterator can give me both key and value at > once and saves me the key lookup. I prefer algorithms which are based on iterators to handwritten loops. They are easier to parallise in the future too. >> All the while - and I don't believe I'm saying this - std::vector *blazes >> the trail* with move semantics, emplace_back and stateful allocators >> (making QVarLengthArray all but useless). Does QVector use move semantics? >> No. > > Move semantics are mainly an ugly way to avoid copies if you don't have CoW. > With CoW data structures, all you save through move semantics is the > reference counting. And move semantics make it easy to shoot yourself in the > foot. (Either you leave behind an invitation for a use-after-free bug, or > you end up swapping instead of assigning, which is also a pessimization.) In my opinion move semantics are about ownership. After using them for some time I really like them to manage resources. Atomics on the other side can produce strange performance bugs with false sharing. I don't believe they are the future in a many core environment where you share cache lines very often. >> Does QVector have emplace_back? No. > > Just like the move semantics, this is also an ugly and complicated way to > avoid a copy if you don't have CoW or merely save the reference counting if > you do. But how is cow working together with the prefetcher. If I have my data outlined in a continuous way like a struct in vector it will be much faster than a pointed array. I really like emplace. I construct objects in a vector which cannot be copied. So the vector is owning all the resources. >> Does QVector have an allocator, even one that, citing Alexandrescu, >> actually deals with allocation? No. > > For the average programmer, an allocator is just an obscure thing that shows > up as a template parameter in all the error messages making them ugly and > unreadable. > > The fact that Qt containers only have the template arguments that are > intuitively templated on (e.g., QVector has only the contained type as a > template parameter) is really a feature, not a bug. > >> Does QVector, even with Q_PRIMITIVE_TYPE payloads, expand to less code as >> std::vector? No: https://codereview.qt-project.org/145587 (comment from >> 01-14 11:21). > > So there is room for improvement there. But in the end, this is not going to > be the deciding factor for which implementation to pick for most > programmers. And in the end, you need to compare QVector with class > libraries in programming languages that offer comparable convenience, not > with the C++ STL. Hmm most other languages I know provide more convenience than Qt but are slower. I think you pick C++ in the context of speed. So we should provide a wrapper around std vector with cow. > If you try to force programmers to use the STL, chances are they will rather > just switch to some other programming language that offers the semantics > they expect. I know many C++ who avoid Qt because we user or own containers. It really depends not everybody has the same taste or needs. I think we should provide both levels. >> Does QVector have a debug mode comparable to that of std::vector >> implementations? Nope. > > I never had any need for that. > >> Or: The only reason I ever used std::list was to use its splice() feature. >> Does QLinkedList have splice()? No, of course not. Because it _cannot_ >> (it's CoWed: how do you take ownership of nodes if the they are shared? By >> copying all other nodes in a detach()?). > > Then use std::list if it suits your use case better. Just don't force > everyone else to use it. > > Personally, I also don't normally have a use for QLinkedList, QList suits my > needs just fine. :-p (In fact, QList was changed from the linked list it was > in Qt 3 to an array of pointers in Qt 4 exactly BECAUSE that's the more > efficient data structure in most practical applications.) QList is really a trap. struct Entry { QString text; bool isHtml; } ; QList list; Do you see the problem? > And I simply find the Qt containers to be much nicer to work with as a > whole. In fact, I recently had to use std::priority_queue for a (QtCore- > based) project of mine, a container class that sadly is not implemented in > Qt (*). After attempting to use it directly and cursing about it, I ended up > implementing a Qt-style wrapper around it: > * My data class simply multiple-inherits from public QSharedData, > public std::priority_queue. > * My public class contains a QSharedDataPointer of the above, renames the > methods to names matching QQueue, and in particular adds a dequeue() > method that does both top() and pop(). Null objects (null d-pointer) are > also handled gracefully (the const methods fake an empty queue, the > enqueue (= STL push) method allocates the d-pointer). > So, a few lines of boilerplate, and suddenly the API becomes usable, and CoW > just works. Incidentally, the CoW was also the only way I found to avoid a > copy of the whole queue while initializing while keeping C++98 compatibility > (so no move or swap): > * I need to initialize my priority_queue from a list (actually a QList :-) > but I would have the same issue with QVector or even std::vector). > * There is no push method that takes a whole list of items. > * So I can only: > - either push every item one at a time, which sorts them less efficiently > than a bulk insert, > - or use the constructor that takes iterators, which then leaves me with a > whole std::priority_queue to copy. My CoW wrapper avoids that copy. > * And my API wrapper actually accepts the QList (or actually any list type > with constBegin() and constEnd() methods) directly instead of requiring > iterators. > > (*) I did find one third-party QPriorityQueue class, but it was just a > wrapper around std::priority_queue that was neither CoW nor had API > consistency with QQueue, so it was better to implement my own. So why we force CoW on people. Most of the time I don't need it. And I don't need atomics if CoW is handy. We should provide a low level version too. >> This is why we need to stop duplicating std API. It's not Qt's core >> competency to meddle with things we only have a half-interest in. It's fun >> to write QOptional. Until it isn't anymore. And then the (Qt) world needs >> to live with the poor-man's std::optional for the next few decades. > > I think having more Qt containers would actually be a good thing, not > something to be scared of. It really depends what you want to do. I would prefer it we had a CoW wrapper around std vector. Best of both worlds. > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From kevin.kofler at chello.at Sat Jan 16 06:07:39 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 16 Jan 2016 06:07:39 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: Bubke Marco wrote: > Actually this convince is hurting you if you need performance. I would > prefer the convenience on top of lower level api. [and at the end:] > It really depends what you want to do. I would prefer it we had a CoW > wrapper around std vector. Best of both worlds. The question is whether such a wrapper would be able to support all functionality of the current QVector or whether it would run into some limitations. I suspect we would lose at least some optimizations from Q_DECLARE_TYPEINFO. There might also be some API that cannot be implemented, or at least not efficiently. (This could be even worse for other containers than QVector.) So, it sounds like a great idea in theory, but I wonder how practical it is in practice. I guess I would have to see a practical implementation to know for sure. What I know for sure is that my priority queue abstraction on top of std::priority_queue can support only a very limited API, and it would be the same if QQueue were to be implemented on top of std::queue: The current QQueue publicly inherits the underlying QList. The STL API, instead, wraps the underlying vector and only offers the queue primitives, a completely different philosophy that leads to a much more limited API. Of course, this could be worked around by wrapping std::vector directly (or maybe std::dequeue), or by simply keeping QQueue implemented on top of QList and only changing QList. But there might be other such API limitations in the STL. And QList might not be implementable at all on top of the STL, at least not the flexible way it is now (array of pointers, except when the type can be put in the place of the pointer). > I prefer algorithms which are based on iterators to handwritten loops. > They are easier to parallise in the future too. Well, then I have good news for you: some_algorithm(myQVector.begin(), myQVector.end()); is perfectly safe. If myQVector was shared, the begin() or end() call, whichever is executed first, will detach, and then some_algorithm will operate on a new deep copy of myQVector that nothing else can possibly have seen yet. If myQVector was not shared to begin with, then it is of course safe too and there is no detach in that case. The iterators are only problematic when you keep an iterator across an assignment, such as: QVector::iterator evil = myQVector.begin(); QVector broken = myQVector; *evil = 666; where "evil" will corrupt "broken". IMHO, this is simply a user error and a case of "don't do that then". This issue is explicitly warned about in the Qt documentation. If you really need a copy of myQVector at this place, then you can use this: QVector::iterator evil = myQVector.begin(); QVector unbroken = myQVector; unbroken.data(); // force detach *evil = 666; and everything will magically work again. > Atomics on the other side can produce strange performance bugs with false > sharing. I don't believe they are the future in a many core environment > where you share cache lines very often. Well, we could in principle do CoW without atomics (Qt 3 did them that way), but the drawback then is that we would lose thread-safety (which is of course why Qt 4 introduced atomic reference counts). > Hmm most other languages I know provide more convenience than Qt but are > slower. I think you pick C++ in the context of speed. So we should provide > a wrapper around std vector with cow. Well, most other languages I know provide *less* convenience than Qt but are slower. ;-) See also my rant about Java elsewhere in this thread. Its "everything is a reference" explicit sharing (which I have also seen in many other languages, even and especially ones marketed to beginners: Visual Basic, Python and many more) is a poor substitute for CoW. That sharing issue you can run into when using iterators on Qt containers (see above) is how those languages *always* work: If you do not explicitly clone the object, writing to any "copy" will actually affect them *all*. And even Java's "final" will not protect you, because it is only the equivalent of a Foo * const, not of a const Foo * or const Foo &. (That's why immutable objects are so popular in those programming languages, but those are of course a major performance issue if you need to make any modifications, because you are deep-copying all the time.) > QList is really a trap. > > struct Entry { > QString text; > bool isHtml; > } ; > > QList list; > > Do you see the problem? I see that this is going to create a vector of Entry * and so require a lot of allocations of size sizeof(void *) + 1 + padding. Congratulations, you found the worst case of QList. Now imagine a future version of your code changes your Entry to look like this: struct Entry { QString text; bool isHtml; int data[10000]; } ; and suddenly, the QList strategy will not be that bad an idea anymore, especially if you find yourself doing random inserts or removals. (Incidentally, they plan to change QString in Qt 6 with an alleged "optimization" that will actually make your struct look not all that different from that: They want to make QString big so that they can store small strings without an allocation. I call that the "small string pessimization". I strongly doubt the saved allocation is worth passing around huge blobs for a type as common as QString.) Good luck waiting for the memory move of your QVector or std::vector if you delete element 5000 out of a 10000-element vector of this new Entry type. Kevin Kofler From marc.mutz at kdab.com Sat Jan 16 14:13:23 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 16 Jan 2016 14:13:23 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <201601161413.24171.marc.mutz@kdab.com> On Saturday 16 January 2016 02:40:02 Bubke Marco wrote: > I would prefer it we had a CoW wrapper around std vector. > Best of both worlds. aka std::shared_ptr> -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Marco.Bubke at theqtcompany.com Sat Jan 16 13:06:33 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Sat, 16 Jan 2016 12:06:33 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: On January 16, 2016 06:08:14 Kevin Kofler wrote: > Bubke Marco wrote: >> Actually this convince is hurting you if you need performance. I would >> prefer the convenience on top of lower level api. > [and at the end:] >> It really depends what you want to do. I would prefer it we had a CoW >> wrapper around std vector. Best of both worlds. > > The question is whether such a wrapper would be able to support all > functionality of the current QVector or whether it would run into some > limitations. I suspect we would lose at least some optimizations from > Q_DECLARE_TYPEINFO. There might also be some API that cannot be implemented, > or at least not efficiently. (This could be even worse for other containers > than QVector.) So, it sounds like a great idea in theory, but I wonder how > practical it is in practice. I guess I would have to see a practical > implementation to know for sure. Is std::is_trivially_copyable amd other type traits are your friends. They make it still easier than the qt workaround. > > What I know for sure is that my priority queue abstraction on top of > std::priority_queue can support only a very limited API, and it would be the > same if QQueue were to be implemented on top of std::queue: The current > QQueue publicly inherits the underlying QList. The STL API, instead, wraps > the underlying vector and only offers the queue primitives, a completely > different philosophy that leads to a much more limited API. Of course, this > could be worked around by wrapping std::vector directly (or maybe > std::dequeue), or by simply keeping QQueue implemented on top of QList and > only changing QList. But there might be other such API limitations in the > STL. I would not change all types. The hash implementations of the stl are not that day to my knowledge. I care about interfaces and there you want to use a vector in the most cases. Maybe a flat unordered map on top of vector would be nice. I would be discourage the use of QList and promote vector instead. I don't use the extras features of QList so I think most people do but QList is can be very suboptimal if you use it with entries which are larger than a pointer. There are other pitfalls in the qt containers, e.g. if (container.contains(key)) auto value = container.value(key); auto iterator = container.find(key); if (iterator! = container.den()) auto value = iterator.value(); The first looks nice but leads to two lookups. And I have seen it very often. > And QList might not be implementable at all on top of the STL, at least not > the flexible way it is now (array of pointers, except when the type can be > put in the place of the pointer). > >> I prefer algorithms which are based on iterators to handwritten loops. >> They are easier to parallise in the future too. > > Well, then I have good news for you: > some_algorithm(myQVector.begin(), myQVector.end()); > is perfectly safe. If myQVector was shared, the begin() or end() call, > whichever is executed first, will detach, and then some_algorithm will > operate on a new deep copy of myQVector that nothing else can possibly have > seen yet. If myQVector was not shared to begin with, then it is of course > safe too and there is no detach in that case. > > The iterators are only problematic when you keep an iterator across an > assignment, such as: > QVector::iterator evil = myQVector.begin(); > QVector broken = myQVector; > *evil = 666; > where "evil" will corrupt "broken". I understand the problem. But my problem is more that I have the atomic pointer which can slow your code done unexpectedly. > IMHO, this is simply a user error and a case of "don't do that then". This > issue is explicitly warned about in the Qt documentation. I buy your argument but documentation is not the solution. You put the burden on the programmer to understand that his value semantic is not quite a value semantic. Do you look in the documentation all the time before you use a function? ;-) Sometimes 'lets document it' is an excuse for a interface with unexpected behavior. :-) > If you really need > a copy of myQVector at this place, then you can use this: > QVector::iterator evil = myQVector.begin(); > QVector unbroken = myQVector; > unbroken.data(); // force detach > *evil = 666; > and everything will magically work again. > >> Atomics on the other side can produce strange performance bugs with false >> sharing. I don't believe they are the future in a many core environment >> where you share cache lines very often. > > Well, we could in principle do CoW without atomics (Qt 3 did them that way), > but the drawback then is that we would lose thread-safety (which is of > course why Qt 4 introduced atomic reference counts). Hmm, isn't sharing of writeable cache lines between cores a bad idea anyway. I write cache lines because your cach lines are the atomic entities, not your data. And we go in the direction of more and more cores. So CoW is maybe not a good idea anymore. http://www.gotw.ca/publications/optimizations.htm >> Hmm most other languages I know provide more convenience than Qt but are >> slower. I think you pick C++ in the context of speed. So we should provide >> a wrapper around std vector with cow. > > Well, most other languages I know provide *less* convenience than Qt but are > slower. ;-) See also my rant about Java elsewhere in this thread. Its > "everything is a reference" explicit sharing (which I have also seen in many > other languages, even and especially ones marketed to beginners: Visual > Basic, Python and many more) is a poor substitute for CoW. That sharing > issue you can run into when using iterators on Qt containers (see above) is > how those languages *always* work: If you do not explicitly clone the > object, writing to any "copy" will actually affect them *all*. And even > Java's "final" will not protect you, because it is only the equivalent of a > Foo * const, not of a const Foo * or const Foo &. (That's why immutable > objects are so popular in those programming languages, but those are of > course a major performance issue if you need to make any modifications, > because you are deep-copying all the time.) I used that in small talk and python extensively and I like the idea to make copy explicit with a clone function. It is expensive and sold be done only explicitly. You have measured that immutable objects are a major performance obstacle? You can optimize them quite well. And with multicore environments they scale much better than CoW. >> QList is really a trap. >> >> struct Entry { >> QString text; >> bool isHtml; >> } ; >> >> QList list; >> >> Do you see the problem? > > I see that this is going to create a vector of Entry * and so require a lot > of allocations of size sizeof(void *) + 1 + padding. Congratulations, you > found the worst case of QList. Now imagine a future version of your code > changes your Entry to look like this: > struct Entry { > QString text; > bool isHtml; > int data[10000]; > } ; > and suddenly, the QList strategy will not be that bad an idea anymore, > especially if you find yourself doing random inserts or removals. > (Incidentally, they plan to change QString in Qt 6 with an alleged > "optimization" that will actually make your struct look not all that > different from that: They want to make QString big so that they can store > small strings without an allocation. I call that the "small string > pessimization". I strongly doubt the saved allocation is worth passing > around huge blobs for a type as common as QString.) Good luck waiting for > the memory move of your QVector or std::vector if you delete element 5000 > out of a 10000-element vector of this new Entry type. Short string optimization is five to ten times faster than malloc which is no surprise. And many syrings are small. And it would be still malloc with short string optimization because the entry is bigger than a pointer. ;-) If you provide data structures which are trivially copy able the simply could be moved in memory for a vector which is quite fast. I don't say that there is no use case for a pointed vector but I can always do Vector You mostly traverse this data structures very often and a pointed vectors are not that optimal because you get much more cach misses which are really expensive. Most structures are not that big so you optimize not for the common case and there are many measurements that show that your pointer can breaking the prefetcher. So maybe in theory of its faster but not in practice. Kevin, you come up with performance arguments but please show me your measurements because most I have seen show the opposite. And with my limited understanding of processors and memory it is reasonable understandable why it is so. ;-) Download something like google benchmark and do micro benchmarks. Then we have arguments which stands on a stable fundament. We can always look at the code to see what you are measure and find out what is happen. I think this argumentation should be productive. We should find a better solution but not fight for our 'optimal' solution. So a open discussion should be much more productive than the repetitions of the same arguments again and again. I think for that type of argumentation you have always to try to get in the context of the other. But like we know we are lazy so repetition is much easier. ;-) Why not search for a better solution and not spending too much energy in a trench fight for 'my solution'. > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From abbapoh at gmail.com Sat Jan 16 15:44:47 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sat, 16 Jan 2016 17:44:47 +0300 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: The question is not good COW or bad. The question is - can/should Qt use (for some reasons) it's own containers, or not. Yes, stl containers are complex, still *theoretically*, Qt can have standard-compatible QVector. About COW. On current work, we try to make all classes thread safe. Consider class Manager with a std::map in it. Map can be huge, so the easiest way to return std::shared_ptr to the map: class Manager { public: using Map = std::map; using MapConstPtr = std::shared_ptr; MapConstPtr getMap() const; }; However, in multithreaded app this won't work! Imagine, Manager will try to modify map while someone holds pointer to it. First, pointer should be protected with mutex both in getter and the place when manager modifies the map. Second, the map should be copied before modification. The alternative is to always copy map on each get() operation. 2016-01-16 15:06 GMT+03:00 Bubke Marco : > On January 16, 2016 06:08:14 Kevin Kofler wrote: > > > Bubke Marco wrote: > >> Actually this convince is hurting you if you need performance. I would > >> prefer the convenience on top of lower level api. > > [and at the end:] > >> It really depends what you want to do. I would prefer it we had a CoW > >> wrapper around std vector. Best of both worlds. > > > > The question is whether such a wrapper would be able to support all > > functionality of the current QVector or whether it would run into some > > limitations. I suspect we would lose at least some optimizations from > > Q_DECLARE_TYPEINFO. There might also be some API that cannot be > implemented, > > or at least not efficiently. (This could be even worse for other > containers > > than QVector.) So, it sounds like a great idea in theory, but I wonder > how > > practical it is in practice. I guess I would have to see a practical > > implementation to know for sure. > > Is std::is_trivially_copyable amd other type traits are your friends. They > make it still easier than the qt workaround. > > > > What I know for sure is that my priority queue abstraction on top of > > std::priority_queue can support only a very limited API, and it would be > the > > same if QQueue were to be implemented on top of std::queue: The current > > QQueue publicly inherits the underlying QList. The STL API, instead, > wraps > > the underlying vector and only offers the queue primitives, a completely > > different philosophy that leads to a much more limited API. Of course, > this > > could be worked around by wrapping std::vector directly (or maybe > > std::dequeue), or by simply keeping QQueue implemented on top of QList > and > > only changing QList. But there might be other such API limitations in the > > STL. > > I would not change all types. The hash implementations of the stl are not > that day to my knowledge. I care about interfaces and there you want to use > a vector in the most cases. Maybe a flat unordered map on top of vector > would be nice. > > I would be discourage the use of QList and promote vector instead. I don't > use the extras features of QList so I think most people do but QList is > can be very suboptimal if you use it with entries which are larger than a > pointer. > > There are other pitfalls in the qt containers, e.g. > > if (container.contains(key)) > auto value = container.value(key); > > auto iterator = container.find(key); > if (iterator! = container.den()) > auto value = iterator.value(); > > The first looks nice but leads to two lookups. And I have seen it very > often. > > > > And QList might not be implementable at all on top of the STL, at least > not > > the flexible way it is now (array of pointers, except when the type can > be > > put in the place of the pointer). > > > >> I prefer algorithms which are based on iterators to handwritten loops. > >> They are easier to parallise in the future too. > > > > Well, then I have good news for you: > > some_algorithm(myQVector.begin(), myQVector.end()); > > is perfectly safe. If myQVector was shared, the begin() or end() call, > > whichever is executed first, will detach, and then some_algorithm will > > operate on a new deep copy of myQVector that nothing else can possibly > have > > seen yet. If myQVector was not shared to begin with, then it is of course > > safe too and there is no detach in that case. > > > > The iterators are only problematic when you keep an iterator across an > > assignment, such as: > > QVector::iterator evil = myQVector.begin(); > > QVector broken = myQVector; > > *evil = 666; > > where "evil" will corrupt "broken". > > I understand the problem. But my problem is more that I have the atomic > pointer which can slow your code done unexpectedly. > > > IMHO, this is simply a user error and a case of "don't do that then". > This > > issue is explicitly warned about in the Qt documentation. > > I buy your argument but documentation is not the solution. You put the > burden on the programmer to understand that his value semantic is not quite > a value semantic. Do you look in the documentation all the time before you > use a function? ;-) Sometimes 'lets document it' is an excuse for a > interface with unexpected behavior. :-) > > > If you really need > > a copy of myQVector at this place, then you can use this: > > QVector::iterator evil = myQVector.begin(); > > QVector unbroken = myQVector; > > unbroken.data(); // force detach > > *evil = 666; > > and everything will magically work again. > > > >> Atomics on the other side can produce strange performance bugs with > false > >> sharing. I don't believe they are the future in a many core environment > >> where you share cache lines very often. > > > > Well, we could in principle do CoW without atomics (Qt 3 did them that > way), > > but the drawback then is that we would lose thread-safety (which is of > > course why Qt 4 introduced atomic reference counts). > > Hmm, isn't sharing of writeable cache lines between cores a bad idea > anyway. I write cache lines because your cach lines are the atomic > entities, not your data. And we go in the direction of more and more cores. > So CoW is maybe not a good idea anymore. > > http://www.gotw.ca/publications/optimizations.htm > > >> Hmm most other languages I know provide more convenience than Qt but > are > >> slower. I think you pick C++ in the context of speed. So we should > provide > >> a wrapper around std vector with cow. > > > > Well, most other languages I know provide *less* convenience than Qt but > are > > slower. ;-) See also my rant about Java elsewhere in this thread. Its > > "everything is a reference" explicit sharing (which I have also seen in > many > > other languages, even and especially ones marketed to beginners: Visual > > Basic, Python and many more) is a poor substitute for CoW. That sharing > > issue you can run into when using iterators on Qt containers (see above) > is > > how those languages *always* work: If you do not explicitly clone the > > object, writing to any "copy" will actually affect them *all*. And even > > Java's "final" will not protect you, because it is only the equivalent > of a > > Foo * const, not of a const Foo * or const Foo &. (That's why immutable > > objects are so popular in those programming languages, but those are of > > course a major performance issue if you need to make any modifications, > > because you are deep-copying all the time.) > > I used that in small talk and python extensively and I like the idea to > make copy explicit with a clone function. It is expensive and sold be done > only explicitly. > > You have measured that immutable objects are a major performance obstacle? > You can optimize them quite well. And with multicore environments they > scale much better than CoW. > > > >> QList is really a trap. > >> > >> struct Entry { > >> QString text; > >> bool isHtml; > >> } ; > >> > >> QList list; > >> > >> Do you see the problem? > > > > I see that this is going to create a vector of Entry * and so require a > lot > > of allocations of size sizeof(void *) + 1 + padding. Congratulations, you > > found the worst case of QList. Now imagine a future version of your code > > changes your Entry to look like this: > > struct Entry { > > QString text; > > bool isHtml; > > int data[10000]; > > } ; > > and suddenly, the QList strategy will not be that bad an idea anymore, > > especially if you find yourself doing random inserts or removals. > > (Incidentally, they plan to change QString in Qt 6 with an alleged > > "optimization" that will actually make your struct look not all that > > different from that: They want to make QString big so that they can store > > small strings without an allocation. I call that the "small string > > pessimization". I strongly doubt the saved allocation is worth passing > > around huge blobs for a type as common as QString.) Good luck waiting for > > the memory move of your QVector or std::vector if you delete element 5000 > > out of a 10000-element vector of this new Entry type. > > Short string optimization is five to ten times faster than malloc which > is no surprise. And many syrings are small. > > And it would be still malloc with short string optimization because the > entry is bigger than a pointer. ;-) > > If you provide data structures which are trivially copy able the simply > could be moved in memory for a vector which is quite fast. > > I don't say that there is no use case for a pointed vector but I can > always do > Vector > > You mostly traverse this data structures very often and a pointed vectors > are not that optimal because you get much more cach misses which are really > expensive. > > Most structures are not that big so you optimize not for the common case > and there are many measurements that show that your pointer can breaking > the prefetcher. So maybe in theory of its faster but not in practice. > > Kevin, you come up with performance arguments but please show me your > measurements because most I have seen show the opposite. And with my > limited understanding of processors and memory it is reasonable > understandable why it is so. ;-) > > Download something like google benchmark and do micro benchmarks. Then we > have arguments which stands on a stable fundament. We can always look at > the code to see what you are measure and find out what is happen. > > I think this argumentation should be productive. We should find a better > solution but not fight for our 'optimal' solution. So a open discussion > should be much more productive than the repetitions of the same arguments > again and again. I think for that type of argumentation you have always to > try to get in the context of the other. But like we know we are lazy so > repetition is much easier. ;-) > > Why not search for a better solution and not spending too much energy in a > trench fight for 'my solution'. > > > Kevin Kofler > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Sent from cellphone, sorry for the typos > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From perezmeyer at gmail.com Sat Jan 16 17:45:40 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Sat, 16 Jan 2016 13:45:40 -0300 Subject: [Development] Avoiding segfaults with QML and video cards which do not support OpenGL 2.0 In-Reply-To: References: <2625131.X4iUGGqDSc@luna> Message-ID: <8401337.VFbhVoZ7R9@luna> On Friday 15 January 2016 23:27:50 Kevin Kofler wrote: > Hi Lisandro, [snip] > you just need to install this script: > http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtbase.git/plain/10-qt5-check-op > engl2.sh to: > /etc/X11/xinit/xinitrc.d/10-qt5-check-opengl2.sh > and depend on glx-utils, which provides the glxinfo command the script uses. > > I got the prerequisite environment variable (QT_XCB_FORCE_SOFTWARE_OPENGL) > support added to Qt 5.3: > https://codereview.qt-project.org/#/c/76992/ > It has been in there ever since. (I also mentioned the needed script, but > there was no interest in shipping this with Qt, unfortunately.) This is > checked once at X11 startup because it is fairly expensive to check the > available OpenGL version: You have to spawn an external process and ask Mesa > for information there. If you initialize your own process with hardware > OpenGL, it is too late to request LIBGL_ALWAYS_SOFTWARE. Excellent! > We have been shipping this solution in Fedora for around 2 years now. And now that you mention it I remember having seen that commit (I'm actually listed as reviewer!) and even warning my team mates about this. The fact that we came to this two years later says a lot about people using old video cards I guess (plus the fact that we introduced KF5 some time later due to Debian Jessie's freeze). > What I have not checked is how this interacts with Wayland. The > glxconvenience code inside Qt where my QT_XCB_FORCE_SOFTWARE_OPENGL variable > is actually implemented may or may not be used there. And xinitrc.d may or > may not be run there. Don't ask me. ACK, I will add this to the script so we get note of it. Thanks a lot! -- 20:57 * m4rgin4l patento el proceso de invencion 20:57 < m4rgin4l> de aqui en mas cualquier inventor me tiene que pagar regalias por inventar algo 20:57 * m4rgin4l tiene la patente pendiente del metodo cientifico Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From marc.mutz at kdab.com Sat Jan 16 19:40:36 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 16 Jan 2016 19:40:36 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <201601161940.36706.marc.mutz@kdab.com> On Saturday 16 January 2016 15:44:47 Иван Комиссаров wrote: > However, in multithreaded app this won't work! Imagine, Manager will try to > modify map while someone holds pointer to it. First, pointer should be > protected with mutex both in getter and the place when manager modifies the > map. Second, the map should be copied before modification. > The alternative is to always copy map on each get() operation. You can lock a mutex in the function and unlock it in the shared_ptr's deleter. Of course, that means that no-one should hold on to those references for long, but they can always copy the map. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From mathias at taschenorakel.de Sun Jan 17 11:31:30 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Sun, 17 Jan 2016 11:31:30 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> <201601151842.43187.marc.mutz@kdab.com> Message-ID: <569B6D82.7000903@taschenorakel.de> Am 16.01.2016 um 01:29 schrieb Kevin Kofler: > Now, what *I* find "simply *not acceptable*" is that "a seemingly innocuous > piece of code like": > std::vector foo1 = …; > std::vector foo2 = foo1; // <- here > "leads to a memory allocation, nay, a complete deep copy of the container". > This is particularly problematic when you want to have methods that return > an STL container, because returning a reference is a bad idea. (Of course > you can return a pointer, but that opens its own can of worms, plenty of > ways to shoot yourself in the foot there: the same issues with explicit > sharing semantics as in Java, plus memory leaks and more.) Almost was going to confirm this example as most relevant use case for implicit sharing. Sadly, no luckily actually, modern C++ compilers just optimize this case. The calling method just keeps the callee's instance alive and reuses it. No constructors involved. Compilers have been smart enough to do that for a long time. C++11 sanctified that litle trick. http://stackoverflow.com/questions/4986673/c11-rvalues-and-move-semantics-confusion-return-statement/4986802#4986802 Still in general I agree that time-to-market usually is much more important like code purity: We are doing products, not religion. Ciao, Mathias From marc.mutz at kdab.com Sun Jan 17 13:55:54 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 17 Jan 2016 13:55:54 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151842.43187.marc.mutz@kdab.com> Message-ID: <201601171355.54557.marc.mutz@kdab.com> On Saturday 16 January 2016 01:29:40 Kevin Kofler wrote: > Now, what I find "simply *not acceptable*" is that "a seemingly innocuous > piece of code like": > std::vector foo1 = …; > std::vector foo2 = foo1; // <- here > "leads to a memory allocation, nay, a complete deep copy of the > container". This is particularly problematic when you want to have > methods that return an STL container, because returning a reference is a > bad idea. (Of course you can return a pointer, but that opens its own can > of worms, plenty of ways to shoot yourself in the foot there: the same > issues with explicit sharing semantics as in Java, plus memory leaks and > more.) It's perfectly acceptable, because that is what C++ defaults to. If you return a struct containing 10 ints, you get those 10 ints copied. If you don't want that, you return some form of reference (&, const-&, std::reference_wrapper, shared_ptr, ...). Why should a vector (or a QPen, even) behave differently? You can always add reference semantics to a value type (e.g. by forming a shared_ptr to it), but never the other way around. It follows that C++ types should have proper value semantics, so users can selectively add reference semantics _where needed_. The same issue applies to Q_FOREACH. It, too, by default copies the container. You never know whether that copy is necessary. It makes it harder to reason about the code. If I see a range-for, or a classical iterator-based for-loop, I know that the container cannot possibly be modified while iterating, unless I see it in the for loop body directly, adjusting the iterator, and then it's almost always a performance bug (a big-O one!). Always using Q_FOREACH makes it very hard to see what's going on. Another argument against CoW is that it creates non-local dependencies. In that, it's like having global variables. With pretty much the same problems, cf. the QStringLiteral-in-unloaded-plugins problems. Not to mention that the rest of the world is quickly moving away from CoW, everywhere, because it's no longer an optimisation in today's multi-core world. Only Qt knows better. The hubris of it! And please don't forget that I'm here always talking about the Qt implementation. You can do in your projects whatever you want. In Qt, the taking of such liberties equals a profound ignorance of our user's needs. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From gunnar.roth at gmx.de Sun Jan 17 19:13:44 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Sun, 17 Jan 2016 19:13:44 +0100 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range Message-ID: Hi, I saw quite some changes like https://codereview.qt-project.org/#/c/145961/ Replace QStringLiteral with QLatin1String in QFileSelector. I also read about the problem of QStringLiteral concerning plugins, but what is the idea behind these changes ? There is also a lot of replacing foreach with range for loops? What is the idea behind this? Any links to read? Regards, Gunnar Roth -------------- next part -------------- An HTML attachment was scrubbed... URL: From olivier at woboq.com Sun Jan 17 19:31:54 2016 From: olivier at woboq.com (Olivier Goffart) Date: Sun, 17 Jan 2016 19:31:54 +0100 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: References: Message-ID: <2561021.biMNWK3yRy@finn> On Sonntag, 17. Januar 2016 19:13:44 CET Gunnar Roth wrote: > Hi, > I saw quite some changes like https://codereview.qt-project.org/#/c/145961/ > Replace QStringLiteral with QLatin1String in QFileSelector. I also read > about the problem of QStringLiteral concerning plugins, but what is the idea > behind these changes ? > > There is also a lot of replacing foreach with range for loops? What is the > idea behind this? Any links to read? About QStringLiteral: As explained here: https://woboq.com/blog/qstringliteral.html QStringLiteral can avoid malloc and conversion to QString. But there is an operator==(const QString&,QLatin1String) which also don't do allocations or conversion. In that case QLatin1String is slightly better because it takes twice as less space in the binary (UTF-16 vs. ASCII) As for foreach and range for loops: the foreach macro does a bit more by doing a copy of the container and call the non const begin and end functions. That's a very small costs for qt containers (a few atomic operations) but it saves code space. All of this is probably negligible, but it helps reducing the size of the library. -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From thiago.macieira at intel.com Sun Jan 17 20:36:41 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 17 Jan 2016 11:36:41 -0800 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: References: Message-ID: <10845826.W58dRlntbG@tjmaciei-mobl4> On Sunday 17 January 2016 19:13:44 Gunnar Roth wrote: > Hi, > I saw quite some changes like https://codereview.qt-project.org/#/c/145961/ > Replace QStringLiteral > with QLatin1String in QFileSelector. I also read about the problem of > QStringLiteral concerning plugins, but what is the idea behind these > changes ? QLatin1String is more efficient if you're calling a method that has a QLatin1String overload, like most methods in QString itself. As for the plugin problem, it's what happens when you refer to global variables in plugins that get unloded. > There is also a lot of replacing foreach with range for loops? What is the > idea behind this? Any links to read? foreach copies; ranged for doesn't. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sun Jan 17 20:41:29 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 17 Jan 2016 11:41:29 -0800 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <2561021.biMNWK3yRy@finn> References: <2561021.biMNWK3yRy@finn> Message-ID: <1896571.2Pf7L883cX@tjmaciei-mobl4> On Sunday 17 January 2016 19:31:54 Olivier Goffart wrote: > As explained here: https://woboq.com/blog/qstringliteral.html > QStringLiteral can avoid malloc and conversion to QString. But there is an > operator==(const QString&,QLatin1String) which also don't do allocations or > conversion. In that case QLatin1String is slightly better because it takes > twice as less space in the binary (UTF-16 vs. ASCII) Technically, it's "less than half the space". For any string of N Latin-1 characters, QLatin1String occupies N+1 bytes and QStringLiteral occupies 2*(N+1)+24. And this is assuming the compiler didn't do common tail merging of strings (most don't). If that happens, then the size of two QLatin1Strings of M and N characters could be less than M+N+2. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From gunnar.roth at gmx.de Sun Jan 17 22:22:39 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Sun, 17 Jan 2016 22:22:39 +0100 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <10845826.W58dRlntbG@tjmaciei-mobl4> References: <10845826.W58dRlntbG@tjmaciei-mobl4> Message-ID: Hi, thanks for answering, but > Am 17.01.2016 um 20:36 schrieb Thiago Macieira : > > On Sunday 17 January 2016 19:13:44 Gunnar Roth wrote: >> Hi, >> I saw quite some changes like https://codereview.qt-project.org/#/c/145961/ >> Replace QStringLiteral >> with QLatin1String in QFileSelector. I also read about the problem of >> QStringLiteral concerning plugins, but what is the idea behind these >> changes ? > > QLatin1String is more efficient if you're calling a method that has a > QLatin1String overload, like most methods in QString itself. > why is QLatin1String more efficient than QLiteralString in this case? both strings being uft16 seems to be faster for, you could use size_t chunks for comparison for example. Regards, Gunnar -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Jan 18 00:28:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 17 Jan 2016 15:28:13 -0800 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: References: <10845826.W58dRlntbG@tjmaciei-mobl4> Message-ID: <1929252.o679PxHBMt@tjmaciei-mobl4> On Sunday 17 January 2016 22:22:39 Gunnar Roth wrote: > why is QLatin1String more efficient than QLiteralString in this case? both > strings being uft16 seems to be faster for, you could use size_t chunks > for comparison for example. Your premise is wrong. The QLatin1String is not stored as UTF-16. It's stored as Latin1. If you're asking about runtime performance, it's because we have algorithms to perform the operation without converting in the common case scenario. Take the equality operator and QString::compare: sure it's more efficient to do binary compares of two QChars, especially if you can unroll the loop and do SIMD (like we do, see [1]). But if your initial data is Latin1, you'd need to incur a performance penalty to allocate memory and then convert from Latin1 to UTF-16 before doing the comparison. So QString has a UTF-16-to-Latin1 comparison, which is quite efficient (and also SIMD-enabled, see [2]). Maybe in some cases the UTF16-to-Latin1 operation is slower than pure UTF-16, but is almost always faster than the combined malloc+convert+operate+free. In this particular case, the ucstrncmp for uchar is either as fast as the QChar one, or in the case of AVX2, possibly even faster in longer strings (less memory being read). [1] https://code.woboq.org/qt5/qtbase/src/corelib/tools/qstring.cpp.html#_ZL9ucstrncmpPK5QCharS1_i [2] https://code.woboq.org/qt5/qtbase/src/corelib/tools/qstring.cpp.html#_ZL9ucstrncmpPK5QCharPKhi -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Mon Jan 18 11:02:35 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 18 Jan 2016 11:02:35 +0100 Subject: [Development] extending QtMacExtras? Message-ID: <28505033.zKFNZO87e7@patux> Hi, Mostly to have an idea about likelihoods and timescales: How easy (or not) is it to get extensions for QtMacExtras accepted, and how likely that such extensions actually become available in an upcoming release? One thing that's really missing from Qt at the moment is a way for an application that is not the foreground application to post a window in the foreground (cf. also my thread on extending QProcess). To my knowledge this can only be done by forcing the application to the foreground using the same technique also used by the QCocoaIntegration ctor. Crude, but sometimes required. A variant could take a WId and activate the application owning the corresponding window or widget. I'm not sure to what extent that would be trivial or even possible to implement (Jake? Morten?). It would allow to simulate things that can currently be done (only?) on Unix/X11: 1) hand off a request from a foreground application ("A") to a background process or daemon ("D"), providing it a target WId 2) from "D", post a dialog using that WId from "A" as the parent widget, ensuring that the dialog actually appears in "A"'s window layer 3) process the data from the dialog in "D", and return the result to "A" which never ceased being the foreground application. Doing this on OS X would require bringing "D" to the foreground because "D" cannot get any useful information from a WId owned by another application. Not making "D" foreground would mean the dialog will most likely remain hidden behind any number of other windows. In order to achieve 3), "D" would then have to use the WId to make "A" the foreground application again. Are there other platforms where WIds cannot be used in a cross-application context? If so this functionality could very well suit the QDesktopServices class, but I guess that wouldn't speed up the deployment timescale ... Regards, René From rdieter at math.unl.edu Mon Jan 18 15:31:01 2016 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 18 Jan 2016 08:31:01 -0600 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 Message-ID: I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run into a build failure in qtdeclarative, make[2]: Entering directory `/builddir/build/BUILD/qtdeclarative-opensource- src-5.6.0-beta/x86_64-redhat-linux-gnu/tools/qmlimportscanner' g++ -c -pipe -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions - fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -std=c++0x - fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_MTDEV -DQT_NO_TSLIB - DQT_NO_LIBINPUT -DQT_NO_CAST_TO_ASCII -DQT_NO_CAST_FROM_ASCII - DQT_USE_QSTRINGBUILDER -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE - D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_QMLDEVTOOLS_LIB -DQT_CORE_LIB - I/builddir/build/BUILD/qtdeclarative-opensource-src-5.6.0- beta/tools/qmlimportscanner -I. -I/builddir/build/BUILD/qtdeclarative- opensource-src-5.6.0-beta/include -I/builddir/build/BUILD/qtdeclarative- opensource-src-5.6.0-beta/include/QtQmlDevTools - I/builddir/build/BUILD/qtdeclarative-opensource-src-5.6.0- beta/include/QtQmlDevTools/5.6.0 -I/builddir/build/BUILD/qtdeclarative- opensource-src-5.6.0-beta/include/QtQmlDevTools/5.6.0/QtQmlDevTools - I../../include -I../../include/QtQmlDevTools -I/usr/include/qt5 - I/usr/include/qt5/QtCore -I.moc -I/usr/lib64/qt5/mkspecs/linux-g++ -o .obj/main.o /builddir/build/BUILD/qtdeclarative-opensource-src-5.6.0- beta/tools/qmlimportscanner/main.cpp /builddir/build/BUILD/qtdeclarative-opensource-src-5.6.0- beta/tools/qmlimportscanner/main.cpp: In function 'QVariantList findQmlImportsInDirectory(const QString&)': /builddir/build/BUILD/qtdeclarative-opensource-src-5.6.0- beta/tools/qmlimportscanner/main.cpp:376: error: no matching function for call to 'find_if(QList::const_iterator, QList::const_iterator, findQmlImportsInDirectory(const QString&)::isMetainfo)' /builddir/build/BUILD/qtdeclarative-opensource-src-5.6.0- beta/tools/qmlimportscanner/main.cpp:381: error: no matching function for call to 'find_if(QList::const_iterator, QList::const_iterator, findQmlImportsInDirectory(const QString&)::pathStartsWith)' Is this some platform/compiler issue? fwiw, using gcc-4.4.7-16.el6. full build log here, https://copr-be.cloud.fedoraproject.org/results/rdieter/Qt5-scratch/epel-6-x86_64/00154070-qt5-qtdeclarative/build.log.gz -- Rex From ahartmetz at gmail.com Mon Jan 18 15:48:54 2016 From: ahartmetz at gmail.com (Andreas Hartmetz) Date: Mon, 18 Jan 2016 15:48:54 +0100 Subject: [Development] API review and API quality Message-ID: <14982660.RFZjYkf8mA@rechenplan> Hello, Due to a recent problem I had with an API addition (solved while writing the E-Mail about it, the rubber duck technique worked!) I noticed, not for the first time, something missing... the Trolltech API review process. The thing that ensured that (almost) all new API made sense to humans semi-informed about the subject matter the API deals with. I don't know how it was done - I recall some rumors about people getting into a room and reviewing API on a projector or something. Nowadays, API not contributed by TQtC is not-really-reviewed on Gerrit. Gerrit is somehow much more detail-oriented, and criticizing "too subjective" stuff is frowned upon. There's a fine line between annoying people for no good enough reason and being too lenient and letting bad code / API slip through. For API, due to its somewhat subjective nature, I would argue that the level of strictness required to achieve a good result is already more strict than what is perceived as annoying people for no good reason. It doesn't help that the strictest and most nitpicky reviewers generally care the least about API. So yeah, I came with a problem and no good suggestion for a solution. I would be fine with TQtC doing API reviews at some point well before release and telling everyone the results in time to improve their code additions for that release, but that's just my opinion. I suspect that a room full of "dude, that API sucks, you can't ship that" makes more of an impression on perpetrators of subpar API than one or two -1 for "only" soft reasons on Gerrit. At an API review meeting, there *will* be a sufficiently large number people to achieve that effect. On Gerrit, well, most people prefer doing something else, like micro-optimizing something. Nobody can argue with contributions like that. But they are perhaps not as important as ensuring API quality. Everything I have written about API applies to documentation as well. It seems like whatever the implementor writes is accepted and that is that. AFAIU that was not exactly how it used to be done at Trolltech when it was still called Trolltech? tl;dr: API quality is not something people work on casually and voluntarily, it seems like it needs more / more suitable process to achieve. (Also, nobody likes process.) Now what? Cheers, Andreas From rdieter at math.unl.edu Mon Jan 18 16:03:31 2016 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 18 Jan 2016 09:03:31 -0600 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 References: Message-ID: Rex Dieter wrote: > I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run > into a build failure in qtdeclarative, ... > Is this some platform/compiler issue? > > fwiw, using gcc-4.4.7-16.el6. It would appear that http://doc.qt.io/QtSupportedPlatforms/index.html references a newer compiler, part of https://www.softwarecollections.org/en/scls/rhscl/devtoolset-3/ Is that required for rhel6 support now? -- Rex From olivier at woboq.com Mon Jan 18 16:26:05 2016 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 18 Jan 2016 16:26:05 +0100 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 In-Reply-To: References: Message-ID: <2718327.vc9pWrFWa0@finn> On Montag, 18. Januar 2016 08:31:01 CET Rex Dieter wrote: > I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run > into a build failure in qtdeclarative, > beta/tools/qmlimportscanner/main.cpp:376: error: no matching function for > call to 'find_if(QList::const_iterator, std::find_if is new in C++11 And it was used in https://codereview.qt-project.org/125853/ in the 5.6 which still does not require C++11. Apparently the CI does not try to build this with non-c++11 enabled compilers? -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From mitch.curtis at theqtcompany.com Mon Jan 18 16:57:27 2016 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Mon, 18 Jan 2016 15:57:27 +0000 Subject: [Development] API review and API quality In-Reply-To: <14982660.RFZjYkf8mA@rechenplan> References: <14982660.RFZjYkf8mA@rechenplan> Message-ID: I don't really understand the question you're asking. :D > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf Of > Andreas Hartmetz > Sent: Monday, 18 January 2016 3:49 PM > To: qt-dev > Subject: [Development] API review and API quality > [snip] > Nowadays, API not contributed by TQtC is not-really-reviewed on Gerrit. Can you share an example of this? > Everything I have written about API applies to documentation as well. It > seems like whatever the implementor writes is accepted and that is that. > AFAIU that was not exactly how it used to be done at Trolltech when it was > still called Trolltech? Here as well? From Simon.Hausmann at theqtcompany.com Mon Jan 18 16:58:09 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Mon, 18 Jan 2016 15:58:09 +0000 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 In-Reply-To: <2718327.vc9pWrFWa0@finn> References: ,<2718327.vc9pWrFWa0@finn> Message-ID: <20160118155808.31227989.52878.55962@theqtcompany.com> I'm surprised as well that this slipped through. Looks like MSVC 2010 supports this bit as well. It is true however that we require devtoolset 3 for RHEL 6. Does anyone remember the reason? Simon Original Message From: Olivier Goffart Sent: Monday, January 18, 2016 16:26 To: development at qt-project.org Cc: Rex Dieter Subject: Re: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 On Montag, 18. Januar 2016 08:31:01 CET Rex Dieter wrote: > I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run > into a build failure in qtdeclarative, > beta/tools/qmlimportscanner/main.cpp:376: error: no matching function for > call to 'find_if(QList::const_iterator, std::find_if is new in C++11 And it was used in https://codereview.qt-project.org/125853/ in the 5.6 which still does not require C++11. Apparently the CI does not try to build this with non-c++11 enabled compilers? -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From oswald.buddenhagen at theqtcompany.com Mon Jan 18 17:41:38 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Mon, 18 Jan 2016 17:41:38 +0100 Subject: [Development] API review and API quality In-Reply-To: <14982660.RFZjYkf8mA@rechenplan> References: <14982660.RFZjYkf8mA@rechenplan> Message-ID: <20160118164138.GB1505@troll08.it.local> On Mon, Jan 18, 2016 at 03:48:54PM +0100, Andreas Hartmetz wrote: > Gerrit is somehow much more detail-oriented, and criticizing "too > subjective" stuff is frowned upon. > anyone who complains about such aspects of a review clearly didn't quite get https://wiki.qt.io/Qt_Contribution_Guidelines - "Our API Design Principles aim for perfection." it's also point 1.2 of https://wiki.qt.io/Commit_Policy > Now what? > we actually already decided some months ago that TQtC sets up an api review task force at pre-release time. we've yet to see how that will work out in practice in the longer run. From mwoehlke.floss at gmail.com Mon Jan 18 18:09:23 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 18 Jan 2016 12:09:23 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601171355.54557.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601151842.43187.marc.mutz@kdab.com> <201601171355.54557.marc.mutz@kdab.com> Message-ID: On 2016-01-17 07:55, Marc Mutz wrote: > Another argument against CoW is that it creates non-local dependencies. In > that, it's like having global variables. With pretty much the same problems, > cf. the QStringLiteral-in-unloaded-plugins problems. Ah... no? The problem with QStringLiteral is that it forms a reference to a module *data segment* which can potentially go away. CoW does no such thing. (I don't consider the case of containing pointers to objects in a data segment; that's the fault of the item type, not the container itself, and STL containers would have the exact same problem in such a case.) At least, last I checked, Qt containers cannot live in program data segments. (I do acknowledge there have been some mutterings about constexpr STL containers, which presumably could thus live in data segments. AFAIK there isn't the requisite constexpr memory allocation yet, though.) > Not to mention that the rest of the world is quickly moving away from CoW, > everywhere, because it's no longer an optimisation in today's multi-core > world. Only Qt knows better. The hubris of it! I still haven't figured out how deep-copy of megabytes of memory and/or hundreds of complex copy ctor invocations is supposed to outperform a single atomic operation... Even on modern architectures. Sure, CoW for a few dozen or maybe even hundred bytes, with trivial copy ctors, may be a loss. I don't buy that it's a loss in all cases, however. -- Matthew From mwoehlke.floss at gmail.com Mon Jan 18 18:24:50 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 18 Jan 2016 12:24:50 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: On 2016-01-16 00:07, Kevin Kofler wrote: > I suspect we would lose at least some optimizations from > Q_DECLARE_TYPEINFO C++ desperately needs something like this. There was talk a while back about destructive moves, but I don't believe it ever materialized into a proposal. I'd rather see the good parts of Qt containers being pushed to STL (maybe as part of STL2) than just being lost. > The iterators are only problematic when you keep an iterator across an > assignment I also feel like I fixed this - not in an actual Qt container, but in my own container that also had CoW - once upon a time, though it requires that the iterators not be "just pointers". (IIRC the iterator is able to detect that a detach occurred, and must reseat itself on first subsequent access. So it's "safe", but not exactly efficient.) -- Matthew From ahartmetz at gmail.com Mon Jan 18 18:36:32 2016 From: ahartmetz at gmail.com (Andreas Hartmetz) Date: Mon, 18 Jan 2016 18:36:32 +0100 Subject: [Development] API review and API quality In-Reply-To: <20160118164138.GB1505@troll08.it.local> References: <14982660.RFZjYkf8mA@rechenplan> <20160118164138.GB1505@troll08.it.local> Message-ID: <1586158.cLyJ3KJpgZ@z25> On Montag, 18. Januar 2016 17:41:38 CET Oswald Buddenhagen wrote: > On Mon, Jan 18, 2016 at 03:48:54PM +0100, Andreas Hartmetz wrote: > > Gerrit is somehow much more detail-oriented, and criticizing "too > > subjective" stuff is frowned upon. > > anyone who complains about such aspects of a review clearly didn't > quite get https://wiki.qt.io/Qt_Contribution_Guidelines - > > "Our API Design Principles aim for perfection." > > it's also point 1.2 of https://wiki.qt.io/Commit_Policy > It is a mixed blessing that I didn't remember that :P My impression is still that API is not taken as seriously as more technical issues in the typical review, by both reviewers and submitters of changes. > > Now what? > > we actually already decided some months ago that TQtC sets up an api > review task force at pre-release time. > we've yet to see how that will work out in practice in the longer run. Oh! That is nice. Was that announced somewhere? I've mentioned vague intentions to write the e-mail about API reviews to some coworkers who didn't seem to know about that, and I also didn't find anything in a quick search of the mailing list archive and the wiki now. From dangelog at gmail.com Mon Jan 18 18:47:30 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Mon, 18 Jan 2016 18:47:30 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151842.43187.marc.mutz@kdab.com> <201601171355.54557.marc.mutz@kdab.com> Message-ID: On Mon, Jan 18, 2016 at 6:09 PM, Matthew Woehlke wrote: > On 2016-01-17 07:55, Marc Mutz wrote: > > Another argument against CoW is that it creates non-local dependencies. > In > > that, it's like having global variables. With pretty much the same > problems, > > cf. the QStringLiteral-in-unloaded-plugins problems. > > Ah... no? The problem with QStringLiteral is that it forms a reference > to a module *data segment* which can potentially go away. CoW does no > such thing. (I don't consider the case of containing pointers to objects > in a data segment; that's the fault of the item type, not the container > itself, and STL containers would have the exact same problem in such a > case.) > QStringLiteral is *exactly* a pointer to an object (QStringData) living in a data segment... that's what you get when you have a value type with reference semantics, such as all the CoW types you find in Qt. > > At least, last I checked, Qt containers cannot live in program data > segments. (I do acknowledge there have been some mutterings about > constexpr STL containers, which presumably could thus live in data > segments. AFAIK there isn't the requisite constexpr memory allocation > yet, though.) > How you do you get a hold on them? Because if you have a reference/pointer/smart/weak pointer to them, then you immediately see the problem of ownership. If you have a value, you don't see it, and kaboom > > > Not to mention that the rest of the world is quickly moving away from > CoW, > > everywhere, because it's no longer an optimisation in today's multi-core > > world. Only Qt knows better. The hubris of it! > > I still haven't figured out how deep-copy of megabytes of memory and/or > hundreds of complex copy ctor invocations is supposed to outperform a > single atomic operation... Even on modern architectures. > > Sure, CoW for a few dozen or maybe even hundred bytes, with trivial copy > ctors, may be a loss. I don't buy that it's a loss in all cases, however. > That's not the point, the point is that atomic operations still add their hidden costs everywhere (which you pay all the time) and scale less efficiently (because now we have multi core systems and these atomic operations trigger barriers which are expensive), than reasoning on the ownership of a data structure and actually copying it only when it's absolutely needed. And note that if you're willing to pay the price of the convenient you can always create a "shared version" of an "unshared container" (shared_ptr>, etc.), but you can't remove CoW from Qt :\ Cheers, -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Mon Jan 18 18:47:42 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 18 Jan 2016 12:47:42 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: On 2016-01-16 07:06, Bubke Marco wrote: > On January 16, 2016 06:08:14 Kevin Kofler wrote: >> I suspect we would lose at least some optimizations from >> Q_DECLARE_TYPEINFO. > > std::is_trivially_copyable and other type traits are your friends. Not really. There is a huge difference between a relocatable type (many, if not most), and a trivially copyable type (a lot fewer). Operations such as growing the buffer can be vastly more expensive if the item type is not relocatable vs. if it is. However, C++ itself currently does not provide any support for relocation. I want to say e.g. std::string is relocatable, but it is certainly not trivially copyable. Now, imagine a std::vector where both the vector and strings are very large. When the vector needs to resize, it will have to do a deep copy of ever single item, allocating and freeing lots of memory in the process. Compare to QVector (assume Q_DECLARE_TYPEINFO declares std::string relocatable), which... will do a realloc(). Worst case, that's 1 alloc, 1 free, and 1 block copy... and 0 ctor/dtor calls. That's a *significant* difference. (Even using QString instead of std::string does not help much... the QVector still just does a realloc, while std::vector must perform 2*N atomic operations.) ...and then there's QList, which just does a realloc(), *always*. > There are other pitfalls in the qt containers, e.g. > > if (container.contains(key)) > auto value = container.value(key); > > auto iterator = container.find(key); > if (iterator! = container.den()) > auto value = iterator.value(); > > The first looks nice but leads to two lookups. And I have seen it very often. Probably because a) it's easier / clearer to read, b) it's MUCH easier to write, and c) most of the time the performance doesn't matter enough to justify the ugliness of the latter. Specifically, I know I have written code like that *in full knowledge* that it's inefficient, simply because I don't judge it sufficiently inefficient to justify the ugly and obtuse STL syntax. That said, the *correct* fix is: auto value = container.maybe_at(key); if (value) do_something(*value); (...using std::optional or similar) This is easy to read, easy to write, *and* efficient. > I understand the problem. But my problem is more that I have the > atomic pointer which can slow your code done unexpectedly. Compared to what? The pointer only kicks in during a copy or destroy. At the point of the copy, the question is if a deep copy is slower than an atomic operation. At the point of destruction, you are probably slow anyway, though if it's just a dereference, you have potentially saved a heap free. > If you provide data structures which are trivially copy able the > simply could be moved in memory for a vector which is quite fast. ...except not nearly so many data structures are trivially copyable as you would like to think. Many are *relocatable* (a concept that does not yet exist in C++ proper), but *not* trivially copyable. Even move semantics are less efficient than relocation (usually not by much, but still by some). > I don't say that there is no use case for a pointed vector but I can always do > Vector No, you can't. At best, you'd have to do vector>, and you'd still have a leaky abstraction problems. Having the indirection built into the container shields you from this. At best, this seems like an argument that QList should act like QVector for relocatable types up to a certain size (said size being greater than a single pointer, as is currently the case). (I'd be inclined to agree with such an argument, incidentally.) -- Matthew From mwoehlke.floss at gmail.com Mon Jan 18 19:06:36 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 18 Jan 2016 13:06:36 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151842.43187.marc.mutz@kdab.com> <201601171355.54557.marc.mutz@kdab.com> Message-ID: On 2016-01-18 12:47, Giuseppe D'Angelo wrote: > On Mon, Jan 18, 2016 at 6:09 PM, Matthew Woehlke wrote: >> On 2016-01-17 07:55, Marc Mutz wrote: >>> Another argument against CoW is that it creates non-local >>> dependencies. In that, it's like having global variables. With >>> pretty much the same problems, cf. the >>> QStringLiteral-in-unloaded-plugins problems. >> >> Ah... no? The problem with QStringLiteral is that it forms a reference >> to a module *data segment* which can potentially go away. CoW does no >> such thing. (I don't consider the case of containing pointers to objects >> in a data segment; that's the fault of the item type, not the container >> itself, and STL containers would have the exact same problem in such a >> case.) > > QStringLiteral is *exactly* a pointer to an object (QStringData) living in > a data segment... Riiiight... > that's what you get when you have a value type with > reference semantics, such as all the CoW types you find in Qt. Again, no? How does a container contain a pointer to a data segment? Heap, yes. Stack, maybe. Data segment? No. How does "reference" suddenly magically equate to "reference to data segment"? >> At least, last I checked, Qt containers cannot live in program data >> segments. > > How you do you get a hold on them? Because if you have a > reference/pointer/smart/weak pointer to them, then you immediately see the > problem of ownership. If you have a value, you don't see it, and kaboom I honestly have *no* idea what you are talking about. CoW means shared ownership. If a module holding a reference to some container goes away while the main program also holds a reference, then... the module reference goes away and the main program is left with one fewer shared reference. Where is the problem? String literals (whether QStringLiteral or char const*) are a problem because the *actual data* lives in a module data segment. It is not (currently) possible for a Qt container's internal state to be stored in a data segment. (If it ever becomes possible, it will almost certainly be possible for STL containers *first*.) Maybe you are trying to argue a completely different point? Yes, CoW can muddy the waters ownership-wise. I'm not saying there aren't drawbacks. What I *am* saying is that it does NOT do is cause your program to crash because the module that originally created a container which is now shared has been unloaded. That is, I am specifically objecting to the statement that CoW has "the same problems [as] QStringLiteral-in-unloaded-plugins". It doesn't. The problem with QStringLiteral in unloaded plugins is totally different and is not an inherent problem with CoW. Accordingly, that statement is a gross and unfair misrepresentation. -- Matthew From dangelog at gmail.com Mon Jan 18 19:35:35 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Mon, 18 Jan 2016 19:35:35 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: On Mon, Jan 18, 2016 at 6:47 PM, Matthew Woehlke wrote: > > Now, imagine a std::vector where both > the vector and strings are very large. When the vector needs to resize, > it will have to do a deep copy of ever single item, allocating and > freeing lots of memory in the process. Nitpicking: not really, because std::string::string(string &&) is noexcept, so it can be already optimized in a mass-move construction plus a mass-dtor. Sure, still way more expensive than it could be. -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marco.Bubke at theqtcompany.com Mon Jan 18 19:40:02 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Mon, 18 Jan 2016 18:40:02 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: Hi Matthew, Your whole point was relocation but my point was traversing. Relocation can be easily fixed by reserve but if traversing is slow it is much harder to remove the convenience structures. I don't say we should not provide them, I only say they should be on top. On January 18, 2016 18:48:07 Matthew Woehlke wrote: > On 2016-01-16 07:06, Bubke Marco wrote: >> On January 16, 2016 06:08:14 Kevin Kofler wrote: >>> I suspect we would lose at least some optimizations from >>> Q_DECLARE_TYPEINFO. >> >> std::is_trivially_copyable and other type traits are your friends. > > Not really. There is a huge difference between a relocatable type (many, > if not most), and a trivially copyable type (a lot fewer). Operations > such as growing the buffer can be vastly more expensive if the item type > is not relocatable vs. if it is. However, C++ itself currently does not > provide any support for relocation. So how many people define there objects as relocatable? Anyway for large vectors I use always reserve which is a quite common optimization. For pattern were you are holding references in the vector you have to do it anyway. > I want to say e.g. std::string is relocatable, but it is certainly not > trivially copyable. Now, imagine a std::vector where both > the vector and strings are very large. When the vector needs to resize, > it will have to do a deep copy of ever single item, allocating and > freeing lots of memory in the process. Compare to QVector > (assume Q_DECLARE_TYPEINFO declares std::string relocatable), which... > will do a realloc(). Worst case, that's 1 alloc, 1 free, and 1 block > copy... and 0 ctor/dtor calls. > > That's a *significant* difference. > > (Even using QString instead of std::string does not help much... the > QVector still just does a realloc, while std::vector must perform 2*N > atomic operations.) > > ...and then there's QList, which just does a realloc(), *always*. So you optimized the container for growing with allocations. I don't think it is the most common case. Having cache misses in traversing the container can be much worse and is much harder to fix than a reserve. > >> There are other pitfalls in the qt containers, e.g. >> >> if (container.contains(key)) >> auto value = container.value(key); >> >> auto iterator = container.find(key); >> if (iterator! = container.den()) >> auto value = iterator.value(); >> >> The first looks nice but leads to two lookups. And I have seen it very often. > > Probably because a) it's easier / clearer to read, b) it's MUCH easier > to write, and c) most of the time the performance doesn't matter enough > to justify the ugliness of the latter. Specifically, I know I have > written code like that *in full knowledge* that it's inefficient, simply > because I don't judge it sufficiently inefficient to justify the ugly > and obtuse STL syntax. I don't think it's is so obscure. In Qt we have many obscure patters too but you adapt to it. As I was coming from python I found Qt ugly but it changed with time. ;-) > That said, the *correct* fix is: > > auto value = container.maybe_at(key); > if (value) > do_something(*value); > > (...using std::optional or similar) > > This is easy to read, easy to write, *and* efficient. I would prefer ranges. I think the next big step is easy writable parallel algorithms and hand written code like that is in my opinion not that maintainable. But we will see. >> I understand the problem. But my problem is more that I have the >> atomic pointer which can slow your code done unexpectedly. > > Compared to what? The pointer only kicks in during a copy or destroy. At > the point of the copy, the question is if a deep copy is slower than an > atomic operation. At the point of destruction, you are probably slow > anyway, though if it's just a dereference, you have potentially saved a > heap free. What about begin? Sorry, why are many other moving away from CoW for small data structures? Do we know something what they are not knowing? Atomics with multi cores can slow down your code considerable so copying can be smarter in that case. >> If you provide data structures which are trivially copy able the >> simply could be moved in memory for a vector which is quite fast. > > ...except not nearly so many data structures are trivially copyable as > you would like to think. Many are *relocatable* (a concept that does not > yet exist in C++ proper), but *not* trivially copyable. Actually many of my demanding structures are trivially copyable. ;-) > Even move semantics are less efficient than relocation (usually not by > much, but still by some). > >> I don't say that there is no use case for a pointed vector but I can always do >> Vector > > No, you can't. At best, you'd have to do vector>, and > you'd still have a leaky abstraction problems. Having the indirection > built into the container shields you from this. > > At best, this seems like an argument that QList should act like QVector > for relocatable types up to a certain size (said size being greater than > a single pointer, as is currently the case). Actually I don't like that magic. You optimising a data structure for one use cases which is in many cases easily fixable. I don't think relocation is the most common problem. > (I'd be inclined to agree with such an argument, incidentally.) > > -- > Matthew > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From mwoehlke.floss at gmail.com Mon Jan 18 19:57:23 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Mon, 18 Jan 2016 13:57:23 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: On 2016-01-18 13:40, Bubke Marco wrote: >> On 2016-01-16 07:06, Bubke Marco wrote: >>> std::is_trivially_copyable and other type traits are your friends. >> >> Not really. There is a huge difference between a relocatable type (many, >> if not most), and a trivially copyable type (a lot fewer). Operations >> such as growing the buffer can be vastly more expensive if the item type >> is not relocatable vs. if it is. However, C++ itself currently does not >> provide any support for relocation. > > So how many people define there objects as relocatable? Only Qt users. C++ proper doesn't have such a concept (yet) :'(. > Anyway for large vectors I use always reserve which is a quite common optimization. This of course assumes that a) you know in advance how large your vector needs to be, and b) that it will actually be that large, or that the cost of possibly unused memory is low. I'll still assert that C++ needs relocatability :-). >> auto value = container.maybe_at(key); >> if (value) >> do_something(*value); >> >> (...using std::optional or similar) >> >> This is easy to read, easy to write, *and* efficient. > > I would prefer ranges. How do ranges solve the problem of doing something with an element iff it exists in the container? > I think the next big step is easy writable parallel algorithms and > hand written code like that is in my opinion not that maintainable. I'm not sure what you mean by "hand written code"? How *else* would you write something like the above? -- Matthew From Marco.Bubke at theqtcompany.com Mon Jan 18 20:17:25 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Mon, 18 Jan 2016 19:17:25 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: On January 18, 2016 19:57:48 Matthew Woehlke wrote: > On 2016-01-18 13:40, Bubke Marco wrote: >>> On 2016-01-16 07:06, Bubke Marco wrote: >>>> std::is_trivially_copyable and other type traits are your friends. >>> >>> Not really. There is a huge difference between a relocatable type (many, >>> if not most), and a trivially copyable type (a lot fewer). Operations >>> such as growing the buffer can be vastly more expensive if the item type >>> is not relocatable vs. if it is. However, C++ itself currently does not >>> provide any support for relocation. >> >> So how many people define there objects as relocatable? > > Only Qt users. C++ proper doesn't have such a concept (yet) :'(. I mean how many Qt users using that feature. ;-) >> Anyway for large vectors I use always reserve which is a quite common optimization. > > This of course assumes that a) you know in advance how large your vector > needs to be, and b) that it will actually be that large, or that the > cost of possibly unused memory is low. Unused memory for big chunkd is not that expensive in many cases because of overcommitment. > I'll still assert that C++ needs relocatability :-). I believe that to. It would be nice if there would be a zero move constructor optimization too. So if your move it sets you memory to zero so whole range would be simply memsetted. So you can simply copy that span and than memset the old area to zero. Building a structure which defaults to zero is not that hard in many cases. >>> auto value = container.maybe_at(key); >>> if (value) >>> do_something(*value); >>> >>> (...using std::optional or similar) >>> >>> This is easy to read, easy to write, *and* efficient. >> >> I would prefer ranges. > > How do ranges solve the problem of doing something with an element iff > it exists in the container? > >> I think the next big step is easy writable parallel algorithms and >> hand written code like that is in my opinion not that maintainable. > > I'm not sure what you mean by "hand written code"? How *else* would you > write something like the above? I mean it is more functional. But for that cases you have to know the context. > -- > Matthew > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From thiago.macieira at intel.com Mon Jan 18 20:28:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 18 Jan 2016 11:28:16 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <1836879.pmvQycA224@tjmaciei-mobl4> On Monday 18 January 2016 13:57:23 Matthew Woehlke wrote: > I'll still assert that C++ needs relocatability :-). The discussion on std-proposals was quite favourable to adding the concept. Just note that it mutated from "relocatable" to "destructive move", which isn't the same thing. Here's what a vector could when resizing do for: a) regular type allocate new block, copy-construct then destroy each element, free old block b) regular type with move constructor ditto, but move-construct instead c) regular type with noexcept move constructor ditto, but like Peppe said, it can be done in a mass operation that cannot throw. TBH, I don't see how this implementation would differ from b. In fact, the code would be the same as a and b and I'd rely on the compiler optimising the rollback code away. d) destructive movable allocate the new block, move-destroy each element (old element is discarded), free old block e) relocatable realloc Relocatable would be an extension to the destructive move: trivially destructible movable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Jan 18 20:32:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 18 Jan 2016 11:32 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <4142115.SlU5WW81Hy@tjmaciei-mobl4> On Monday 18 January 2016 19:17:25 Bubke Marco wrote: > >> So how many people define there objects as relocatable? > > > > Only Qt users. C++ proper doesn't have such a concept (yet) :'(. > > I mean how many Qt users using that feature. ;-) That depends. Do you include people who use the feature without knowing they do, by using Qt containers of Qt types that are declared in our headers are relocatable? If so, then the answer is "all of them". > > I'll still assert that C++ needs relocatability :-). > > I believe that to. It would be nice if there would be a zero move > constructor optimization too. So if your move it sets you memory to zero > so whole range would be simply memsetted. So you can simply copy that span > and than memset the old area to zero. Indeed, that's another trait that would be useful to have. Note that types for which any bit pattern is valid already have a name: trivially constructible. > Building a structure which defaults to zero is not that hard in many cases. No, and memsetting to zero is very fast and efficient (any one 64-bit pattern, actually). It's possible that the processor even optimises zero-memsetting. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From dangelog at gmail.com Mon Jan 18 20:45:32 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Mon, 18 Jan 2016 20:45:32 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <1836879.pmvQycA224@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <1836879.pmvQycA224@tjmaciei-mobl4> Message-ID: On Mon, Jan 18, 2016 at 8:28 PM, Thiago Macieira wrote: > > Here's what a vector could when resizing do for: > > a) regular type > allocate new block, copy-construct then destroy each element, free old > block > > b) regular type with move constructor > ditto, but move-construct instead > > c) regular type with noexcept move constructor > ditto, but like Peppe said, it can be done in a mass operation that cannot > throw. TBH, I don't see how this implementation would differ from b. In > fact, > the code would be the same as a and b and I'd rely on the compiler > optimising > the rollback code away. > I don't think b) can possibly exist if you want a container to offer the strong guarantee. Once you start moving elements out of the original block, if a move throws, you end up in a broken state. You can't move the already-moved elements back into the original block because that may cause further exceptions. It should be really either a) or c) (i.e. "apply std::move_if_noexcept"). Cheers, -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Mon Jan 18 23:11:14 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 18 Jan 2016 23:11:14 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <201601182311.14867.marc.mutz@kdab.com> On Monday 18 January 2016 19:06:36 Matthew Woehlke wrote: > On 2016-01-18 12:47, Giuseppe D'Angelo wrote: > > On Mon, Jan 18, 2016 at 6:09 PM, Matthew Woehlke wrote: > >> On 2016-01-17 07:55, Marc Mutz wrote: > >>> Another argument against CoW is that it creates non-local > >>> dependencies. In that, it's like having global variables. With > >>> pretty much the same problems, cf. the > >>> QStringLiteral-in-unloaded-plugins problems. > >> > >> Ah... no? The problem with QStringLiteral is that it forms a reference > >> to a module *data segment* which can potentially go away. CoW does no > >> such thing. (I don't consider the case of containing pointers to objects > >> in a data segment; that's the fault of the item type, not the container > >> itself, and STL containers would have the exact same problem in such a > >> case.) > > > > QStringLiteral is *exactly* a pointer to an object (QStringData) living > > in a data segment... > > Riiiight... > > > that's what you get when you have a value type with > > reference semantics, such as all the CoW types you find in Qt. > > Again, no? How does a container contain a pointer to a data segment? > Heap, yes. Stack, maybe. Data segment? No. How does "reference" suddenly > magically equate to "reference to data segment"? > > >> At least, last I checked, Qt containers cannot live in program data > >> segments. > > > > How you do you get a hold on them? Because if you have a > > reference/pointer/smart/weak pointer to them, then you immediately see > > the problem of ownership. If you have a value, you don't see it, and > > kaboom > > I honestly have *no* idea what you are talking about. CoW means shared > ownership. If a module holding a reference to some container goes away > while the main program also holds a reference, then... the module > reference goes away and the main program is left with one fewer shared > reference. Where is the problem? QString foo() { return QStringLiteral("foo"); } QString bar() { return Q3DeepCopy(QStringLiteral("foo")); } You will _never_ have the plugin-unloading problem with 'bar', only with 'foo', and the reason is CoW: suggesting value semantics where there aren't any. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Mon Jan 18 23:43:37 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 18 Jan 2016 23:43:37 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <201601182343.38142.marc.mutz@kdab.com> On Monday 18 January 2016 18:47:42 Matthew Woehlke wrote: > Not really. There is a huge difference between a relocatable type (many, > if not most), and a trivially copyable type (a lot fewer). Operations > such as growing the buffer can be vastly more expensive if the item type > is not relocatable vs. if it is. However, C++ itself currently does not > provide any support for relocation. > > I want to say e.g. std::string is relocatable, but it is certainly not > trivially copyable. Now, imagine a std::vector where both > the vector and strings are very large. When the vector needs to resize, > it will have to do a deep copy of ever single item, allocating and > freeing lots of memory in the process. Compare to QVector > (assume Q_DECLARE_TYPEINFO declares std::string relocatable), which... > will do a realloc(). Worst case, that's 1 alloc, 1 free, and 1 block > copy... and 0 ctor/dtor calls. > > That's a significant difference. > > (Even using QString instead of std::string does not help much... the > QVector still just does a realloc, while std::vector must perform 2*N > atomic operations.) a) std::string is not a movable type (at least I get a heap corruption when marking it as such in GCC 5.3) b) #include #include int main() { QVector l; int oldC = l.capacity(); for (int i = 0; i < 10000000; ++i) { char buf[std::numeric_limits::digits + 1]; sprintf(buf, "%d", i); l.push_back(buf); int newC = l.capacity(); if (newC != oldC) qDebug("%d", newC); oldC = newC; } } $ time ./test real 0m1.598s user 0m1.400s sys 0m0.192s #include #include int main() { std::vector l; int oldC = l.capacity(); for (int i = 0; i < 10000000; ++i) { char buf[std::numeric_limits::digits + 1]; sprintf(buf, "%d", i); l.push_back(buf); int newC = l.capacity(); if (newC != oldC) qDebug("%d", newC); oldC = newC; } } $ time ./test real 0m1.481s user 0m1.264s sys 0m0.212s #include #include int main() { QVector l; int oldC = l.capacity(); for (int i = 0; i < 10000000; ++i) { char buf[std::numeric_limits::digits + 1]; sprintf(buf, "%d", i); l.push_back(buf); int newC = l.capacity(); if (newC != oldC) qDebug("%d", newC); oldC = newC; } } $ time ./test real 0m1.769s user 0m1.572s sys 0m0.192s best of three runs, core i7-2720QM, GCC 5.3 HTH, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Tue Jan 19 00:39:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 18 Jan 2016 15:39:11 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601182343.38142.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601182343.38142.marc.mutz@kdab.com> Message-ID: <1765644.KkMGsNm1Av@tjmaciei-mobl4> On Monday 18 January 2016 23:43:37 Marc Mutz wrote: > a) std::string is not a movable type (at least I get a heap corruption when > marking it as such in GCC 5.3) It used to be in C++98 and it is with libc++. The new C++11 std::string from libstdc++ is not relocatable. They implemented SSO by storing the "begin" pointer pointing to itself, so that the common operation of getting the begin pointer does not need a conditional. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jan 19 00:41:35 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 18 Jan 2016 15:41:35 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601182311.14867.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601182311.14867.marc.mutz@kdab.com> Message-ID: <6824449.TyanUDe9rY@tjmaciei-mobl4> On Monday 18 January 2016 23:11:14 Marc Mutz wrote: > QString foo() { return QStringLiteral("foo"); } > QString bar() { return Q3DeepCopy(QStringLiteral("foo")); } > > You will _never_ have the plugin-unloading problem with 'bar', only with > 'foo', and the reason is CoW: suggesting value semantics where there aren't > any. That doesn't mean types without CoW are immune from the problem. There are lots of discussion in the std mailing lists about constexpr data, so in the future a const std::string could potentially point to .rodata and thus be affected by this problem too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jan 19 00:47:19 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 18 Jan 2016 15:47:19 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <1765644.KkMGsNm1Av@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <201601182343.38142.marc.mutz@kdab.com> <1765644.KkMGsNm1Av@tjmaciei-mobl4> Message-ID: <4130397.BEnAfWvY8e@tjmaciei-mobl4> On Monday 18 January 2016 15:39:11 Thiago Macieira wrote: > On Monday 18 January 2016 23:43:37 Marc Mutz wrote: > > a) std::string is not a movable type (at least I get a heap corruption > > when > > marking it as such in GCC 5.3) > > It used to be in C++98 and it is with libc++. The new C++11 std::string from > libstdc++ is not relocatable. They implemented SSO by storing the "begin" > pointer pointing to itself, so that the common operation of getting the > begin pointer does not need a conditional. Note that this is exactly how Qt 4's QString knew whether the data was allocated by itself or it was fromRawData. The Qt 5 one doesn't store the pointer, but an offset from the data would be, so offset == 0 means "allocated". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kalle.viironen at theqtcompany.com Tue Jan 19 08:22:54 2016 From: kalle.viironen at theqtcompany.com (Viironen Kalle) Date: Tue, 19 Jan 2016 07:22:54 +0000 Subject: [Development] Qt Virtual Keyboard (New KDE Free Qt Foundation Agreement and Changes) Message-ID: Hi, As Lars mentioned in his email about KDE Free Qt foundation agreement and changes, we’re pushing sources of Qt Virtual Keyboard to codereview. I’d like to propose the Qt Virtual Keyboard module to be taken as part of Qt add-on modules,it has been part of commercial Qt releases for some time now. I also propose Mitch Curtis to be named as maintainer for the Qt Virtual Keyboard module. Br, Kalle Viironen -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Tue Jan 19 10:07:43 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 10:07:43 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <6824449.TyanUDe9rY@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <201601182311.14867.marc.mutz@kdab.com> <6824449.TyanUDe9rY@tjmaciei-mobl4> Message-ID: <201601191007.43865.marc.mutz@kdab.com> On Tuesday 19 January 2016 00:41:35 Thiago Macieira wrote: > On Monday 18 January 2016 23:11:14 Marc Mutz wrote: > > QString foo() { return QStringLiteral("foo"); } > > QString bar() { return Q3DeepCopy(QStringLiteral("foo")); } > > > > You will _never_ have the plugin-unloading problem with 'bar', only with > > 'foo', and the reason is CoW: suggesting value semantics where there > > aren't any. > > That doesn't mean types without CoW are immune from the problem. There are > lots of discussion in the std mailing lists about constexpr data, so in the > future a const std::string could potentially point to .rodata and thus be > affected by this problem too. But only _locally_. As soon as you copy the std::string, you're insulated from that problem, unlike in CoW, where it can strike anywhere the string happens to be copied to. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Tue Jan 19 10:10:16 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 10:10:16 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601182343.38142.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601182343.38142.marc.mutz@kdab.com> Message-ID: <201601191010.16463.marc.mutz@kdab.com> On Monday 18 January 2016 23:43:37 Marc Mutz wrote: > a) std::string is not a movable type (at least I get a heap corruption > when marking it as such in GCC 5.3) For the sake of clarity: I mean movable as in trivially relocatable, ie. Q_MOVABLE_TYPE, not as in "has move special member functions", which it obviously has. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Lars.Knoll at theqtcompany.com Tue Jan 19 09:39:02 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 19 Jan 2016 08:39:02 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <39269570.93i4fJSI54@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> <201601151842.43187.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> Message-ID: <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> On 15/01/16 23:20, "Development on behalf of Thiago Macieira" wrote: >On Friday 15 January 2016 18:42:43 Marc Mutz wrote: >> And you will see it over and over again until enough people are fixing >> premature pessimisations in existing Qt code. There's a notable increase >> already. But it takes a long time to turn a supertanker around... > >Some of us call them "trade-offs". Every trade-off is a pessimisation >somewhere for an optimisation somewhere else. Often, they're not measured in >the same units or not quantifiable at all. > >API quality and consistency fall under those definitions. Exactly this. > >> And no, I cannot believe that using the Qt containers leads to faster >> applications. It may lead to applications faster, but not to faster >> applications. > >Exactly. TTM is a significant factor and we all know Paretto's Law (80-20 >rule). And this. Let’s not forget to ask ourselves the question why many developers use Qt in C++ development, often even in the case where they don’t need a UI. For the past 20 years a lot of our focus has been on making development easy, and creating APIs that serve that goal. This means that we are in many case optimising for TTM more than for ultimate speed. I think we agree that std containers are in many cases faster than the Qt containers. But they are harder to use and especially developers that come from other languages often appreciate the ease of use of the Qt containers. The main question IMO is how we can bring these two worlds closer together for Qt 6 (or maybe even to some extent in Qt 5.x). Cheers, Lars From gunnar.roth at gmx.de Tue Jan 19 09:50:37 2016 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Tue, 19 Jan 2016 09:50:37 +0100 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <1929252.o679PxHBMt@tjmaciei-mobl4> References: <10845826.W58dRlntbG@tjmaciei-mobl4> , <1929252.o679PxHBMt@tjmaciei-mobl4> Message-ID: An HTML attachment was scrubbed... URL: From Marco.Bubke at theqtcompany.com Tue Jan 19 10:29:22 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Tue, 19 Jan 2016 09:29:22 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> References: <201601051352.06816.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> <201601151842.43187.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> Message-ID: On January 19, 2016 09:39:17 Knoll Lars wrote: > On 15/01/16 23:20, "Development on behalf of Thiago Macieira" wrote: > >>On Friday 15 January 2016 18:42:43 Marc Mutz wrote: >>> And you will see it over and over again until enough people are fixing >>> premature pessimisations in existing Qt code. There's a notable increase >>> already. But it takes a long time to turn a supertanker around... >> >>Some of us call them "trade-offs". Every trade-off is a pessimisation >>somewhere for an optimisation somewhere else. Often, they're not measured in >>the same units or not quantifiable at all. >> >>API quality and consistency fall under those definitions. > > Exactly this. > >> >>> And no, I cannot believe that using the Qt containers leads to faster >>> applications. It may lead to applications faster, but not to faster >>> applications. >> >>Exactly. TTM is a significant factor and we all know Paretto's Law (80-20 >>rule). > > And this. Let’s not forget to ask ourselves the question why many developers use Qt in C++ development, often even in the case where they don’t need a UI. For the past 20 years a lot of our focus has been on making development easy, and creating APIs that serve that goal. This means that we are in many case optimising for TTM more than for ultimate speed. > > I think we agree that std containers are in many cases faster than the Qt containers. But they are harder to use and especially developers that come from other languages often appreciate the ease of use of the Qt containers. > > The main question IMO is how we can bring these two worlds closer together for Qt 6 (or maybe even to some extent in Qt 5.x). I think we should start minimal and try to layer QVector over std::vector. If you want performance you use in many cases a vector. The second important item would be IMHO benchmarks, maybe we use google benchmark which has some nice threading feature. Without benchmarking discussions get IMHO easily non substantial. > Cheers, > Lars > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From marc.mutz at kdab.com Tue Jan 19 11:51:42 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 11:51:42 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601182343.38142.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601182343.38142.marc.mutz@kdab.com> Message-ID: <201601191151.42545.marc.mutz@kdab.com> I missed one: On Monday 18 January 2016 23:43:37 Marc Mutz wrote: > #include > #include > > int main() { > > QVector l; > int oldC = l.capacity(); > for (int i = 0; i < 10000000; ++i) { > char buf[std::numeric_limits::digits + 1]; > sprintf(buf, "%d", i); > l.push_back(buf); > int newC = l.capacity(); > if (newC != oldC) > qDebug("%d", newC); > oldC = newC; > } > > } > > $ time ./test > > real 0m1.769s > user 0m1.572s > sys 0m0.192s Same with std::vector: real 0m1.776s user 0m1.616s sys 0m0.156s > best of three runs, core i7-2720QM, GCC 5.3 Ditto. So... is realloc actually the optimisation everyone (incl. me) expected it to be? -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Tue Jan 19 11:52:05 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 11:52:05 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> References: <201601051352.06816.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> Message-ID: <201601191152.06015.marc.mutz@kdab.com> On Tuesday 19 January 2016 09:39:02 Knoll Lars wrote: > On 15/01/16 23:20, "Development on behalf of Thiago Macieira" wrote: > >On Friday 15 January 2016 18:42:43 Marc Mutz wrote: > >> And you will see it over and over again until enough people are fixing > >> premature pessimisations in existing Qt code. There's a notable increase > >> already. But it takes a long time to turn a supertanker around... > > > >Some of us call them "trade-offs". Every trade-off is a pessimisation > >somewhere for an optimisation somewhere else. Often, they're not measured > >in the same units or not quantifiable at all. > > > >API quality and consistency fall under those definitions. > > Exactly this. > > >> And no, I cannot believe that using the Qt containers leads to faster > >> applications. It may lead to applications faster, but not to faster > >> applications. > > > >Exactly. TTM is a significant factor and we all know Paretto's Law (80-20 > >rule). > > And this. Let’s not forget to ask ourselves the question why many > developers use Qt in C++ development, often even in the case where they > don’t need a UI. For the past 20 years a lot of our focus has been on > making development easy, and creating APIs that serve that goal. This > means that we are in many case optimising for TTM more than for ultimate > speed. > > I think we agree that std containers are in many cases faster than the Qt > containers. But they are harder to use and especially developers that come > from other languages often appreciate the ease of use of the Qt > containers. I always cringe when I hear this. What, specifically, do you mean by "easier to use"? No-one, not even experts understand QList, really. So it may appear to be easy to use, but is actually a container only absolute experst should use. And a QVector provides exactly the same guarantees as a std::vector. How come one is easier to use than the other? Because QVector has indexOf()? And what about those cases where the user wants to find an element by just a field? They will write for loops, most likely, and not use algorithms. The crucial point here is that there's no "better" Qt API for this than what exists on std::vector. Instead, there's a much more complicated API by sheer volume and duplication, without being near extensive enough for even very simple tasks. At some point, the question must be asked whether CoW and append() vs. push_back() do not become more of a burden than a merit. And whether we need three names for size(). > The main question IMO is how we can bring these two worlds closer together > for Qt 6 (or maybe even to some extent in Qt 5.x). My answer would be to use std containers exclusively, and write a wagonload full of Qt-level docs about them, ie. integrate them into the Qt docs. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From tuukka.turunen at theqtcompany.com Tue Jan 19 11:00:26 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Tue, 19 Jan 2016 10:00:26 +0000 Subject: [Development] Qt Virtual Keyboard (New KDE Free Qt Foundation Agreement and Changes) In-Reply-To: References: Message-ID: +1 From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Viironen Kalle Sent: tiistaina 19. tammikuuta 2016 9.23 To: development at qt-project.org Subject: [Development] Qt Virtual Keyboard (New KDE Free Qt Foundation Agreement and Changes) Hi, As Lars mentioned in his email about KDE Free Qt foundation agreement and changes, we’re pushing sources of Qt Virtual Keyboard to codereview. I’d like to propose the Qt Virtual Keyboard module to be taken as part of Qt add-on modules,it has been part of commercial Qt releases for some time now. I also propose Mitch Curtis to be named as maintainer for the Qt Virtual Keyboard module. Br, Kalle Viironen -------------- next part -------------- An HTML attachment was scrubbed... URL: From porten at froglogic.com Tue Jan 19 11:13:16 2016 From: porten at froglogic.com (Harri Porten) Date: Tue, 19 Jan 2016 11:13:16 +0100 (CET) Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191152.06015.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> <201601191152.06015.marc.mutz@kdab.com> Message-ID: On Tue, 19 Jan 2016, Marc Mutz wrote: >> I think we agree that std containers are in many cases faster than the Qt >> containers. But they are harder to use and especially developers that come >> from other languages often appreciate the ease of use of the Qt >> containers. > > I always cringe when I hear this. What, specifically, do you mean by "easier to > use"? > > No-one, not even experts understand QList, really. So it may appear to be easy > to use, but is actually a container only absolute experst should use. What kind of 'understanding' are you expecting? I'd say that every Qt beginner, the biggest greenhorns, 'understand' absolutely enough to use the class. And yes: that view might be incomplete and non-optimal in regards to performance or in some extreme cases. And anyone coming from a Java, JavaScript or whatever background easily finds such Qt classes documented next to the others. And appreciates e.g. a consistent API style. You may not personally like it but this individual matter of tastes cannot be fully fulfilled in a project with that many contributors and users. Harri. From milian.wolff at kdab.com Tue Jan 19 11:15:43 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Tue, 19 Jan 2016 11:15:43 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191151.42545.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601182343.38142.marc.mutz@kdab.com> <201601191151.42545.marc.mutz@kdab.com> Message-ID: <2119145.JenKLMHALe@agathebauer> On Dienstag, 19. Januar 2016 11:51:42 CET Marc Mutz wrote: > I missed one: > > On Monday 18 January 2016 23:43:37 Marc Mutz wrote: > > #include > > #include > > > > int main() { > > > > QVector l; > > int oldC = l.capacity(); > > for (int i = 0; i < 10000000; ++i) { > > > > char buf[std::numeric_limits::digits + 1]; > > sprintf(buf, "%d", i); > > l.push_back(buf); > > int newC = l.capacity(); > > if (newC != oldC) > > > > qDebug("%d", newC); > > > > oldC = newC; > > > > } > > > > } > > > > $ time ./test > > > > real 0m1.769s > > user 0m1.572s > > sys 0m0.192s > > Same with std::vector: > > real 0m1.776s > user 0m1.616s > sys 0m0.156s > > > best of three runs, core i7-2720QM, GCC 5.3 > > Ditto. > > So... is realloc actually the optimisation everyone (incl. me) expected it > to be? Did you run it through a profiler? Where is the time actually spent? -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From kenya888 at gmail.com Tue Jan 19 11:35:39 2016 From: kenya888 at gmail.com (Takahiro Hashimoto) Date: Tue, 19 Jan 2016 19:35:39 +0900 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 In-Reply-To: <20160118155808.31227989.52878.55962@theqtcompany.com> References: <2718327.vc9pWrFWa0@finn> <20160118155808.31227989.52878.55962@theqtcompany.com> Message-ID: <6253453.Zl7NJyuHHX@xps13> Hi. Sorry I don't have any info about C++11 code in 5.6 branch. I'd like to comment for Simon's question about devltoolset requirement. According to this thread [1] maybe the binary distribution of Qt 5 requires newer(4.7?) libstdc++ than the one which is provided by RHEL/CentOS 6.(4.4.7) This might lead updating wiki article of building qt5 to add this workaround. The Red Hat Developer Toolset has been released 4 times for RHEL5/6 release (1.0 to 3.0) and currently only 3.0 is supported on RHEL6. [2] I think These are reason why for this requirement. And I don't know if the older version of Qt5(5.0,5.1..) could be built with gcc 4.4... By the way, RHEL6 is now at second half of its 10 years support life cycle. [3] I think it would be better to start to consider about Qt5 support for RHEL7. As RHEL7 has gcc 4.8, the devtoolset is not needed. [1] http://forum.qt.io/topic/30140/solved-qt-creator-could-not-find-or-load-the-qt-platform-plugin-xcb/ [2] https://access.redhat.com/support/policy/updates/dts [3] https://access.redhat.com/support/policy/updates/errata Regards. Takahiro On 2016年1月18日月曜日 15時58分09秒 JST Hausmann Simon wrote: > I'm surprised as well that this slipped through. Looks like MSVC 2010 > supports this bit as well. > > It is true however that we require devtoolset 3 for RHEL 6. Does anyone > remember the reason? > > > Simon > > Original Message > From: Olivier Goffart > Sent: Monday, January 18, 2016 16:26 > To: development at qt-project.org > Cc: Rex Dieter > Subject: Re: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 > > On Montag, 18. Januar 2016 08:31:01 CET Rex Dieter wrote: > > I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run > > into a build failure in qtdeclarative, > > > > > beta/tools/qmlimportscanner/main.cpp:376: error: no matching function for > > call to 'find_if(QList::const_iterator, > > std::find_if is new in C++11 > And it was used in https://codereview.qt-project.org/125853/ in the 5.6 > which still does not require C++11. > > Apparently the CI does not try to build this with non-c++11 enabled > compilers? > > -- > 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 > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Martin.Smith at theqtcompany.com Tue Jan 19 11:44:44 2016 From: Martin.Smith at theqtcompany.com (Smith Martin) Date: Tue, 19 Jan 2016 10:44:44 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191152.06015.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com>, <201601191152.06015.marc.mutz@kdab.com> Message-ID: >No-one, not even experts understand QList, really. So it may appear to be easy >to use, but is actually a container only absolute experst should use. Marc, you are still conflating optimal runtime efficiency with algorithmic correctness. QList is easy to use correctly in algorithms. It is almost hard to make a mistake. That is all "easy to use" means. It doesn't mean "easy to use while achieving optimal runtime efficiency." You can't judge all programmers using your encyclopaedic knowledge as the standard. There is a lot to be learned by doing things correctly the easy way. It even makes learning to do the same things with optimal runtime efficiency more meaningful. martin ________________________________________ From: Development on behalf of Marc Mutz Sent: Tuesday, January 19, 2016 11:52 AM To: development at qt-project.org Subject: Re: [Development] Question about QCoreApplicationData::*_libpaths On Tuesday 19 January 2016 09:39:02 Knoll Lars wrote: > On 15/01/16 23:20, "Development on behalf of Thiago Macieira" wrote: > >On Friday 15 January 2016 18:42:43 Marc Mutz wrote: > >> And you will see it over and over again until enough people are fixing > >> premature pessimisations in existing Qt code. There's a notable increase > >> already. But it takes a long time to turn a supertanker around... > > > >Some of us call them "trade-offs". Every trade-off is a pessimisation > >somewhere for an optimisation somewhere else. Often, they're not measured > >in the same units or not quantifiable at all. > > > >API quality and consistency fall under those definitions. > > Exactly this. > > >> And no, I cannot believe that using the Qt containers leads to faster > >> applications. It may lead to applications faster, but not to faster > >> applications. > > > >Exactly. TTM is a significant factor and we all know Paretto's Law (80-20 > >rule). > > And this. Let’s not forget to ask ourselves the question why many > developers use Qt in C++ development, often even in the case where they > don’t need a UI. For the past 20 years a lot of our focus has been on > making development easy, and creating APIs that serve that goal. This > means that we are in many case optimising for TTM more than for ultimate > speed. > > I think we agree that std containers are in many cases faster than the Qt > containers. But they are harder to use and especially developers that come > from other languages often appreciate the ease of use of the Qt > containers. I always cringe when I hear this. What, specifically, do you mean by "easier to use"? No-one, not even experts understand QList, really. So it may appear to be easy to use, but is actually a container only absolute experst should use. And a QVector provides exactly the same guarantees as a std::vector. How come one is easier to use than the other? Because QVector has indexOf()? And what about those cases where the user wants to find an element by just a field? They will write for loops, most likely, and not use algorithms. The crucial point here is that there's no "better" Qt API for this than what exists on std::vector. Instead, there's a much more complicated API by sheer volume and duplication, without being near extensive enough for even very simple tasks. At some point, the question must be asked whether CoW and append() vs. push_back() do not become more of a burden than a merit. And whether we need three names for size(). > The main question IMO is how we can bring these two worlds closer together > for Qt 6 (or maybe even to some extent in Qt 5.x). My answer would be to use std containers exclusively, and write a wagonload full of Qt-level docs about them, ie. integrate them into the Qt docs. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at theqtcompany.com Tue Jan 19 11:47:29 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 19 Jan 2016 10:47:29 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191152.06015.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> <201601191152.06015.marc.mutz@kdab.com> Message-ID: <9C5D8E1F-36A1-4D3A-99E1-B343C3A4BDA5@theqtcompany.com> On 19/01/16 11:52, "Development on behalf of Marc Mutz" wrote: >On Tuesday 19 January 2016 09:39:02 Knoll Lars wrote: >> On 15/01/16 23:20, "Development on behalf of Thiago Macieira" bounces at qt-project.org on behalf of thiago.macieira at intel.com> wrote: >> >On Friday 15 January 2016 18:42:43 Marc Mutz wrote: >> >> And you will see it over and over again until enough people are fixing >> >> premature pessimisations in existing Qt code. There's a notable increase >> >> already. But it takes a long time to turn a supertanker around... >> > >> >Some of us call them "trade-offs". Every trade-off is a pessimisation >> >somewhere for an optimisation somewhere else. Often, they're not measured >> >in the same units or not quantifiable at all. >> > >> >API quality and consistency fall under those definitions. >> >> Exactly this. >> >> >> And no, I cannot believe that using the Qt containers leads to faster >> >> applications. It may lead to applications faster, but not to faster >> >> applications. >> > >> >Exactly. TTM is a significant factor and we all know Paretto's Law (80-20 >> >rule). >> >> And this. Let’s not forget to ask ourselves the question why many >> developers use Qt in C++ development, often even in the case where they >> don’t need a UI. For the past 20 years a lot of our focus has been on >> making development easy, and creating APIs that serve that goal. This >> means that we are in many case optimising for TTM more than for ultimate >> speed. >> >> I think we agree that std containers are in many cases faster than the Qt >> containers. But they are harder to use and especially developers that come >> from other languages often appreciate the ease of use of the Qt >> containers. > >I always cringe when I hear this. What, specifically, do you mean by "easier to >use"? > >No-one, not even experts understand QList, really. So it may appear to be easy >to use, but is actually a container only absolute experst should use. Let’s stop arguing about QList, please. We all agree that this class has larger problems. > >And a QVector provides exactly the same guarantees as a std::vector. How come >one is easier to use than the other? Because QVector has indexOf()? And what >about those cases where the user wants to find an element by just a field? They >will write for loops, most likely, and not use algorithms. > >The crucial point here is that there's no "better" Qt API for this than what >exists on std::vector. Instead, there's a much more complicated API by sheer >volume and duplication, without being near extensive enough for even very >simple tasks. Come on. All of us use the Qt containers and he APIs do cover most of the common use cases. Yes, there is some duplication, and one can argue whether we for example need constBegin(). On the other hand I still find it a lot more readable than the STL cbegin(). >At some point, the question must be asked whether CoW and >append() vs. push_back() do not become more of a burden than a merit. And >whether we need three names for size(). I have not seen many people having problems with those. > >> The main question IMO is how we can bring these two worlds closer together >> for Qt 6 (or maybe even to some extent in Qt 5.x). > >My answer would be to use std containers exclusively, and write a wagonload >full of Qt-level docs about them, ie. integrate them into the Qt docs. Something I would probably support if we started a new toolkit from scratch today (even though I still don’t like some of the API naming decisions of the STL). But we have these classes, and there are probably hundreds of millions of lines of code out there using them. So removing them and breaking all that code is simply not an option. Cheers, Lars From marc.mutz at kdab.com Tue Jan 19 13:15:18 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 13:15:18 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> Message-ID: <201601191315.18737.marc.mutz@kdab.com> On Tuesday 19 January 2016 11:13:16 Harri Porten wrote: > On Tue, 19 Jan 2016, Marc Mutz wrote: > >> I think we agree that std containers are in many cases faster than the > >> Qt containers. But they are harder to use and especially developers > >> that come from other languages often appreciate the ease of use of the > >> Qt containers. > > > > I always cringe when I hear this. What, specifically, do you mean by > > "easier to use"? > > > > No-one, not even experts understand QList, really. So it may appear to be > > easy to use, but is actually a container only absolute experst should > > use. > > What kind of 'understanding' are you expecting? I'd say that every Qt > beginner, the biggest greenhorns, 'understand' absolutely enough to use > the class. And yes: that view might be incomplete and non-optimal in > regards to performance or in some extreme cases. > > And anyone coming from a Java, JavaScript or whatever background easily > finds such Qt classes documented next to the others. And appreciates e.g. > a consistent API style. You may not personally like it but this individual > matter of tastes cannot be fully fulfilled in a project with that many > contributors and users. I was referring to the fact that references into the container either do get invalidated upon, say, appending, or they are not, depending on the memory layout. That is a very important (to know about, not to have) property of a container. One that should be either true or false, and not, as for QList, depend on, among other things, the processor's word width. ETOOSUBTLE. The STL also has a consistent API style. But that wasn't my point here. But since you've mentioned it: no, I definitely don't see a need for first() and last() if there's front() and back(). Or count() instead of size(). Actually, count() is against Qt API design guidelines, because it is also a verb, and nothing is counted here. That would be an O(N) operation. And if API consistency makes QVector have a prepend(), and QHash::iterator have it + n, something got out of hand... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Tue Jan 19 13:16:18 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 13:16:18 +0100 Subject: [Development] Qt Virtual Keyboard (New KDE Free Qt Foundation Agreement and Changes) In-Reply-To: References: Message-ID: <201601191316.18720.marc.mutz@kdab.com> On Tuesday 19 January 2016 08:22:54 Viironen Kalle wrote: > Hi, > > As Lars mentioned in his email about KDE Free Qt foundation agreement and > changes, we’re pushing sources of Qt Virtual Keyboard to codereview. > > I’d like to propose the Qt Virtual Keyboard module to be taken as part of > Qt add-on modules,it has been part of commercial Qt releases for some time > now. +1 > I also propose Mitch Curtis to be named as maintainer for the Qt > Virtual Keyboard module. +1 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Tue Jan 19 13:23:08 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 13:23:08 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> Message-ID: <201601191323.08837.marc.mutz@kdab.com> On Tuesday 19 January 2016 11:44:44 Smith Martin wrote: > Marc, you are still conflating optimal runtime efficiency with algorithmic > correctness. QList is easy to use correctly in algorithms. It is almost > hard to make a mistake. That is all "easy to use" means. It doesn't mean > "easy to use while achieving optimal runtime efficiency." See my reply to Harri. I disagree that an easy-to-use class has any business providing completly opposing semantics for QList, simply based on whether you compile for 64-bits or 32. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Martin.Smith at theqtcompany.com Tue Jan 19 12:34:29 2016 From: Martin.Smith at theqtcompany.com (Smith Martin) Date: Tue, 19 Jan 2016 11:34:29 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191323.08837.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> , <201601191323.08837.marc.mutz@kdab.com> Message-ID: >I disagree that an easy-to-use class has any business >providing completly opposing semantics for QList, simply based on >whether you compile for 64-bits or 32. It doesn't, but it doesn't make QList less easy to use either. ________________________________________ From: marc at kdab.com on behalf of Marc Mutz Sent: Tuesday, January 19, 2016 1:23 PM To: Smith Martin Cc: development at qt-project.org Subject: Re: [Development] Question about QCoreApplicationData::*_libpaths On Tuesday 19 January 2016 11:44:44 Smith Martin wrote: > Marc, you are still conflating optimal runtime efficiency with algorithmic > correctness. QList is easy to use correctly in algorithms. It is almost > hard to make a mistake. That is all "easy to use" means. It doesn't mean > "easy to use while achieving optimal runtime efficiency." See my reply to Harri. I disagree that an easy-to-use class has any business providing completly opposing semantics for QList, simply based on whether you compile for 64-bits or 32. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From tony.sarajarvi at theqtcompany.com Tue Jan 19 12:40:58 2016 From: tony.sarajarvi at theqtcompany.com (=?utf-8?B?U2FyYWrDpHJ2aSBUb255?=) Date: Tue, 19 Jan 2016 11:40:58 +0000 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 In-Reply-To: <6253453.Zl7NJyuHHX@xps13> References: <2718327.vc9pWrFWa0@finn> <20160118155808.31227989.52878.55962@theqtcompany.com> <6253453.Zl7NJyuHHX@xps13> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On > Behalf Of Takahiro Hashimoto > Sent: 19. tammikuuta 2016 12:36 > To: development at qt-project.org > Cc: Rex Dieter > Subject: Re: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 > > Hi. > > Sorry I don't have any info about C++11 code in 5.6 branch. I'd like to > comment for Simon's question about devltoolset requirement. > > According to this thread [1] maybe the binary distribution of Qt 5 requires > newer(4.7?) libstdc++ than the one which is provided by RHEL/CentOS > 6.(4.4.7) Yes that and also GCC gets updated when we install devtoolset. > This might lead updating wiki article of building qt5 to add this workaround. > > The Red Hat Developer Toolset has been released 4 times for RHEL5/6 > release > (1.0 to 3.0) and currently only 3.0 is supported on RHEL6. [2] > > I think These are reason why for this requirement. > And I don't know if the older version of Qt5(5.0,5.1..) could be built with > gcc 4.4... > > By the way, RHEL6 is now at second half of its 10 years support life cycle. > [3] I think it would be better to start to consider about Qt5 support for > RHEL7. As RHEL7 has gcc 4.8, the devtoolset is not needed. > > > [1] http://forum.qt.io/topic/30140/solved-qt-creator-could-not-find-or-load- > the-qt-platform-plugin-xcb/ > > [2] https://access.redhat.com/support/policy/updates/dts > [3] https://access.redhat.com/support/policy/updates/errata > > > Regards. > Takahiro > > > On 2016年1月18日月曜日 15時58分09秒 JST Hausmann Simon wrote: > > I'm surprised as well that this slipped through. Looks like MSVC 2010 > > supports this bit as well. > > > > It is true however that we require devtoolset 3 for RHEL 6. Does anyone > > remember the reason? > > > > > > Simon > > > > Original Message > > From: Olivier Goffart > > Sent: Monday, January 18, 2016 16:26 > > To: development at qt-project.org > > Cc: Rex Dieter > > Subject: Re: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 > > > > On Montag, 18. Januar 2016 08:31:01 CET Rex Dieter wrote: > > > I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run > > > into a build failure in qtdeclarative, > > > > > > > > > beta/tools/qmlimportscanner/main.cpp:376: error: no matching function > for > > > call to 'find_if(QList::const_iterator, > > > > std::find_if is new in C++11 > > And it was used in https://codereview.qt-project.org/125853/ in the 5.6 > > which still does not require C++11. > > > > Apparently the CI does not try to build this with non-c++11 enabled > > compilers? > > > > -- > > 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 > > _______________________________________________ > > 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 Tue Jan 19 13:50:53 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 13:50:53 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <9C5D8E1F-36A1-4D3A-99E1-B343C3A4BDA5@theqtcompany.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> <9C5D8E1F-36A1-4D3A-99E1-B343C3A4BDA5@theqtcompany.com> Message-ID: <201601191350.53878.marc.mutz@kdab.com> On Tuesday 19 January 2016 11:47:29 Knoll Lars wrote: > >My answer would be to use std containers exclusively, and write a > >wagonload full of Qt-level docs about them, ie. integrate them into the > >Qt docs. > > Something I would probably support if we started a new toolkit from scratch > today (even though I still don’t like some of the API naming decisions of > the STL). But we have these classes, and there are probably hundreds of > millions of lines of code out there using them. So removing them and > breaking all that code is simply not an option. So ... that means we're stuck with them until eternity? If so, let me suggest that you put some dev force behind the containers again. They have seriously fallen behind the std ones (I remember a time when QVector outperformed std::vector, ok on SunCC without stlport, but still). Apparently, no-one from the community bothers enough about this (me included, even though I hack them a bit here and there). Status quo in libraries equals bit-rot. The containers are _not_ "good enough". E.g. QVector seriously needs to support move-only types (like unique_ptr) in a C++11 world. Oops... it never will... it's CoWed... I have nothing against a *superior* Qt replacement for std classes, with proper interop. Like QString. I don't like *inferior* solutions that not much more than internal classes which are forced onto users because they are touted as superior in the docs and unavoidable by way of being ubiquitously used in other Qt API. For every user that uses Qt because of the containers, you will probably find ten that don't/wouldn't use it for the same reason. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Tue Jan 19 13:51:56 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 13:51:56 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <2119145.JenKLMHALe@agathebauer> References: <201601051352.06816.marc.mutz@kdab.com> <201601191151.42545.marc.mutz@kdab.com> <2119145.JenKLMHALe@agathebauer> Message-ID: <201601191351.57428.marc.mutz@kdab.com> On Tuesday 19 January 2016 11:15:43 Milian Wolff wrote: > On Dienstag, 19. Januar 2016 11:51:42 CET Marc Mutz wrote: > > I missed one: > > > > On Monday 18 January 2016 23:43:37 Marc Mutz wrote: > > > #include > > > #include > > > > > > int main() { > > > > > > QVector l; > > > int oldC = l.capacity(); > > > for (int i = 0; i < 10000000; ++i) { > > > > > > char buf[std::numeric_limits::digits + 1]; > > > sprintf(buf, "%d", i); > > > l.push_back(buf); > > > int newC = l.capacity(); > > > if (newC != oldC) > > > > > > qDebug("%d", newC); > > > > > > oldC = newC; > > > > > > } > > > > > > } > > > > > > $ time ./test > > > > > > real 0m1.769s > > > user 0m1.572s > > > sys 0m0.192s > > > > Same with std::vector: > > > > real 0m1.776s > > user 0m1.616s > > sys 0m0.156s > > > > > best of three runs, core i7-2720QM, GCC 5.3 > > > > Ditto. > > > > So... is realloc actually the optimisation everyone (incl. me) expected > > it to be? > > Did you run it through a profiler? Where is the time actually spent? No. It's not the IO, though. Removing the qDebug() and capacity tracking, it performs the same, within error margins. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From jpnurmi at theqtcompany.com Tue Jan 19 12:46:40 2016 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Tue, 19 Jan 2016 11:46:40 +0000 Subject: [Development] Qt Virtual Keyboard (New KDE Free Qt Foundation Agreement and Changes) In-Reply-To: References: Message-ID: > On 19 Jan 2016, at 08:22, Viironen Kalle wrote: > > Hi, > > As Lars mentioned in his email about KDE Free Qt foundation agreement and changes, we’re pushing sources of Qt Virtual Keyboard to codereview. > > I’d like to propose the Qt Virtual Keyboard module to be taken as part of Qt add-on modules,it has been part of commercial Qt releases for some time now. I also propose Mitch Curtis to be named as maintainer for the Qt Virtual Keyboard module. +1 -- J-P Nurmi From andre at familiesomers.nl Tue Jan 19 12:53:35 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Tue, 19 Jan 2016 12:53:35 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191315.18737.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> <201601191315.18737.marc.mutz@kdab.com> Message-ID: <569E23BF.9050905@familiesomers.nl> Op 19/01/2016 om 13:15 schreef Marc Mutz: > On Tuesday 19 January 2016 11:13:16 Harri Porten wrote: >> On Tue, 19 Jan 2016, Marc Mutz wrote: >>>> I think we agree that std containers are in many cases faster than the >>>> Qt containers. But they are harder to use and especially developers >>>> that come from other languages often appreciate the ease of use of the >>>> Qt containers. >>> I always cringe when I hear this. What, specifically, do you mean by >>> "easier to use"? >>> >>> No-one, not even experts understand QList, really. So it may appear to be >>> easy to use, but is actually a container only absolute experst should >>> use. >> What kind of 'understanding' are you expecting? I'd say that every Qt >> beginner, the biggest greenhorns, 'understand' absolutely enough to use >> the class. And yes: that view might be incomplete and non-optimal in >> regards to performance or in some extreme cases. >> >> And anyone coming from a Java, JavaScript or whatever background easily >> finds such Qt classes documented next to the others. And appreciates e.g. >> a consistent API style. You may not personally like it but this individual >> matter of tastes cannot be fully fulfilled in a project with that many >> contributors and users. > I was referring to the fact that references into the container either do get > invalidated upon, say, appending, or they are not, depending on the memory > layout. That is a very important (to know about, not to have) property of a > container. One that should be either true or false, and not, as for QList, > depend on, among other things, the processor's word width. ETOOSUBTLE. Yet many developers, even green ones, have managed to write some pretty nice software using the container. Perhaps that feature is not used as much as you think it is? Or only by people who actually understand the class at your level of understanding or something close to it, while for all others it works just fine? I am not denying that there are issues with the Qt containers, and with QList in particular. I think you made some very valid points on that front. I just wonder if the problem is really so big that it needs taking down the complete Qt container library and the massive source breakage that will cause. > > The STL also has a consistent API style. But that wasn't my point here. But > since you've mentioned it: no, I definitely don't see a need for first() and > last() if there's front() and back(). Or count() instead of size(). Actually, > count() is against Qt API design guidelines, because it is also a verb, and > nothing is counted here. That would be an O(N) operation. > > And if API consistency makes QVector have a prepend(), and QHash::iterator > have it + n, something got out of hand... > Why shouldn't QVector have a prepend? Because it is not very fast to do that? André From Lars.Knoll at theqtcompany.com Tue Jan 19 13:02:12 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 19 Jan 2016 12:02:12 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191350.53878.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> <9C5D8E1F-36A1-4D3A-99E1-B343C3A4BDA5@theqtcompany.com> <201601191350.53878.marc.mutz@kdab.com> Message-ID: <25528BEF-504A-48E7-96A7-4B0FACC0AC38@theqtcompany.com> On 19/01/16 13:50, "Development on behalf of Marc Mutz" wrote: >On Tuesday 19 January 2016 11:47:29 Knoll Lars wrote: >> >My answer would be to use std containers exclusively, and write a >> >wagonload full of Qt-level docs about them, ie. integrate them into the >> >Qt docs. >> >> Something I would probably support if we started a new toolkit from scratch >> today (even though I still don’t like some of the API naming decisions of >> the STL). But we have these classes, and there are probably hundreds of >> millions of lines of code out there using them. So removing them and >> breaking all that code is simply not an option. > >So ... that means we're stuck with them until eternity? Things are not just black and white. But we can’t do a Qt6 that simply removes all of them completely. We’d leave most of our users behind on Qt 5 forever. So we have to find better, and maybe more incremental, ways to handle this. With a radical 'let’s throw them all away' approach we will leave all our current users behind. > >If so, let me suggest that you put some dev force behind the containers again. >They have seriously fallen behind the std ones (I remember a time when QVector >outperformed std::vector, ok on SunCC without stlport, but still). Apparently, >no-one from the community bothers enough about this (me included, even though >I hack them a bit here and there). > >Status quo in libraries equals bit-rot. The containers are _not_ "good >enough". E.g. QVector seriously needs to support move-only types (like >unique_ptr) in a C++11 world. Oops... it never will... it's CoWed... > >I have nothing against a *superior* Qt replacement for std classes, with >proper interop. Like QString. I don't like *inferior* solutions that not much >more than internal classes which are forced onto users because they are touted >as superior in the docs and unavoidable by way of being ubiquitously used in >other Qt API. Now that’s being polemic. They have been designed as public classes. You might not like them, and some parts we would certainly do differently today. But when they got written for Qt 4.0, we did put thoughts behind them and aimed to make them as good and versatile as possible. > >For every user that uses Qt because of the containers, you will probably find >ten that don't/wouldn't use it for the same reason. I doubt that. I am convinced that for most people that have a real product to create, the most important thing is to get the product out. For many use cases, Qt makes that easier than any other solution on C++. Cheers, Lars From Lars.Knoll at theqtcompany.com Tue Jan 19 13:32:37 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 19 Jan 2016 12:32:37 +0000 Subject: [Development] Qt Virtual Keyboard (New KDE Free Qt Foundation Agreement and Changes) In-Reply-To: <201601191316.18720.marc.mutz@kdab.com> References: <201601191316.18720.marc.mutz@kdab.com> Message-ID: <378513F5-76C7-4A1C-9735-072310BD8422@theqtcompany.com> +1 and +1 from me as well :) Cheers, Lars On 19/01/16 13:16, "Development on behalf of Marc Mutz" wrote: >On Tuesday 19 January 2016 08:22:54 Viironen Kalle wrote: >> Hi, >> >> As Lars mentioned in his email about KDE Free Qt foundation agreement and >> changes, we’re pushing sources of Qt Virtual Keyboard to codereview. >> >> I’d like to propose the Qt Virtual Keyboard module to be taken as part of >> Qt add-on modules,it has been part of commercial Qt releases for some time >> now. > >+1 > >> I also propose Mitch Curtis to be named as maintainer for the Qt >> Virtual Keyboard module. > >+1 > >-- >Marc Mutz | Senior Software Engineer >KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company >Tel: +49-30-521325470 >KDAB - The Qt Experts >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From rdieter at math.unl.edu Tue Jan 19 13:39:39 2016 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 19 Jan 2016 06:39:39 -0600 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 References: <2718327.vc9pWrFWa0@finn> <20160118155808.31227989.52878.55962@theqtcompany.com> <6253453.Zl7NJyuHHX@xps13> Message-ID: Takahiro Hashimoto wrote: > And I don't know if the older version of Qt5(5.0,5.1..) could be built > with gcc 4.4... They could, including Qt 5.5.x. I am currently providing RHEL 6/7 Qt5 packages via https://fedoraproject.org/wiki/EPEL I started this thread because EPEL by policy doesn't allow dependencies outside of RHEL to be used, and so EPEL (for RHEL6) can no longer support Qt 5.6 and newer. -- Rex From olivier at woboq.com Tue Jan 19 13:42:16 2016 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 19 Jan 2016 13:42:16 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <25528BEF-504A-48E7-96A7-4B0FACC0AC38@theqtcompany.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601191350.53878.marc.mutz@kdab.com> <25528BEF-504A-48E7-96A7-4B0FACC0AC38@theqtcompany.com> Message-ID: <2487962.d1As7ZZxxf@finn> On Dienstag, 19. Januar 2016 12:02:12 CET Knoll Lars wrote: > Things are not just black and white. But we can’t do a Qt6 that simply > removes all of them completely. We’d leave most of our users behind on Qt 5 > forever. So we have to find better, and maybe more incremental, ways to > handle this. With a radical 'let’s throw them all away' approach we will > leave all our current users behind. Just an idea: We deprecate them, so all our api use std::vector and such. We add a qt5support library which contains classes like: template class QVector : public std::vector { QVector(std::vector); // implicit conversion from std::vector /* All the Qt API goes here */ }; I believe this should be mostly source compatible. This also assume we can use std in our ABI (which i think we should allow) Marc Mutz wrote: > > E.g. QVector seriously needs to support move-only types (like > > unique_ptr) in a C++11 world. Oops... it never will... it's CoWed... Actually, it might be possible, using SFINAE, to disable the copy constructor of QVector when the T is not copyable. (and we also do not call detach for such T since it cannot be copyed and therefore cannot be shared) -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From marc.mutz at kdab.com Tue Jan 19 15:00:33 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 15:00:33 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <569E23BF.9050905@familiesomers.nl> References: <201601051352.06816.marc.mutz@kdab.com> <201601191315.18737.marc.mutz@kdab.com> <569E23BF.9050905@familiesomers.nl> Message-ID: <201601191500.34358.marc.mutz@kdab.com> On Tuesday 19 January 2016 12:53:35 André Somers wrote: > Op 19/01/2016 om 13:15 schreef Marc Mutz: > > On Tuesday 19 January 2016 11:13:16 Harri Porten wrote: > >> On Tue, 19 Jan 2016, Marc Mutz wrote: > >>>> I think we agree that std containers are in many cases faster than the > >>>> Qt containers. But they are harder to use and especially developers > >>>> that come from other languages often appreciate the ease of use of the > >>>> Qt containers. > >>> > >>> I always cringe when I hear this. What, specifically, do you mean by > >>> "easier to use"? > >>> > >>> No-one, not even experts understand QList, really. So it may appear to > >>> be easy to use, but is actually a container only absolute experst > >>> should use. > >> > >> What kind of 'understanding' are you expecting? I'd say that every Qt > >> beginner, the biggest greenhorns, 'understand' absolutely enough to use > >> the class. And yes: that view might be incomplete and non-optimal in > >> regards to performance or in some extreme cases. > >> > >> And anyone coming from a Java, JavaScript or whatever background easily > >> finds such Qt classes documented next to the others. And appreciates > >> e.g. a consistent API style. You may not personally like it but this > >> individual matter of tastes cannot be fully fulfilled in a project with > >> that many contributors and users. > > > > I was referring to the fact that references into the container either do > > get invalidated upon, say, appending, or they are not, depending on the > > memory layout. That is a very important (to know about, not to have) > > property of a container. One that should be either true or false, and > > not, as for QList, depend on, among other things, the processor's word > > width. ETOOSUBTLE. > > Yet many developers, even green ones, have managed to write some pretty > nice software using the container. And the same is true for std::vector. > Perhaps that feature is not used as > much as you think it is? Or only by people who actually understand the > class at your level of understanding or something close to it, while for > all others it works just fine? My point is that the Qt containers try to "fix" easy-to-understand, local problems (iterator invalidation, deep copies) of the std containers with hard- to-understand, non-local ones (Q_FOREACH, QList, CoW with its problems: iterators into shared containers, hidden detaches, move-only types). That doesn't help the programmer. It flattens the learning curve in the beginning, sure, but leads to a very high learning curve at the intermediate level. All the while providing the same API as the STL containers, meaning many of the problems come back, too, like iterator invalidation. > I am not denying that there are issues with the Qt containers, and with > QList in particular. I think you made some very valid points on that > front. I just wonder if the problem is really so big that it needs > taking down the complete Qt container library and the massive source > breakage that will cause. And I'm wondering: with TQC not investing in the containers, at some point will they bit-rot to smithereens? C++ now provides the means to ease the transition: Now: 1. Tell people to use auto when receiving Qt containers returned from a function. 2. Tell people to stick to the std-compatible API subset. 3. Deprecate Q_FOREACH and recommend range-for (+ qAsConst(), where needed). In Qt 6: 1. Implement the containers on top of std ones, dropping CoW, providing simple, fast (when moving), conversion between std and Qt containers. 2. Deprecate the std-incompatible API subset 3. Remove Q_FOREACH 4. Deprecate qAsConst() In Qt 7: 1. Drop all Qt container API use from the library, use only std ones. 2. Keep the Qt ones around as deprecated, in a separate compat library. 3. Drop qAsConst() In Qt 8: Remove the Qt ones. That easily spans 10-15 years, but at least we'd have an exit strategy. If, otoh, by Qt 6, we'd still continue doing nothing, as before, we'll lose another four years. > > The STL also has a consistent API style. But that wasn't my point here. > > But since you've mentioned it: no, I definitely don't see a need for > > first() and last() if there's front() and back(). Or count() instead of > > size(). Actually, count() is against Qt API design guidelines, because > > it is also a verb, and nothing is counted here. That would be an O(N) > > operation. > > > > And if API consistency makes QVector have a prepend(), and > > QHash::iterator have it + n, something got out of hand... > > Why shouldn't QVector have a prepend? Because it is not very fast to do > that? s/not very fast/prohibitively expensive/ You can always say v.insert(v.begin(), e) if you really, really, want to. But the STL carefully does not provide inefficient operations. In a way, that's more user-friendly than the "convenience" of QVector::prepend(). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From kenya888 at gmail.com Tue Jan 19 13:57:28 2016 From: kenya888 at gmail.com (Takahiro Hashimoto) Date: Tue, 19 Jan 2016 21:57:28 +0900 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 In-Reply-To: References: <6253453.Zl7NJyuHHX@xps13> Message-ID: <2128766.IPpfj7XhjX@xps13> Just information, the devtoolset4 has been released. GCC version is 5.2.1. RHEL6/7 user can install both gcc4.9.2(devtoolset3) and gcc5.2.1(devtoolset4). [1] http://developerblog.redhat.com/2015/11/17/gcc-5-developer-toolset-4-generally-available/ Regards. Takahiro On 2016年1月19日火曜日 11時40分58秒 JST Sarajärvi Tony wrote: > > -----Original Message----- > > From: Development [mailto:development-bounces at qt-project.org] On > > Behalf Of Takahiro Hashimoto > > Sent: 19. tammikuuta 2016 12:36 > > To: development at qt-project.org > > Cc: Rex Dieter > > Subject: Re: [Development] qtdeclarative-5.6.0-beta build failure on > > rhel6 > > > > Hi. > > > > Sorry I don't have any info about C++11 code in 5.6 branch. I'd like to > > comment for Simon's question about devltoolset requirement. > > > > According to this thread [1] maybe the binary distribution of Qt 5 > > requires newer(4.7?) libstdc++ than the one which is provided by > > RHEL/CentOS 6.(4.4.7) > > > Yes that and also GCC gets updated when we install devtoolset. > > > > This might lead updating wiki article of building qt5 to add this > > workaround. > > The Red Hat Developer Toolset has been released 4 times for RHEL5/6 > > release > > (1.0 to 3.0) and currently only 3.0 is supported on RHEL6. [2] > > > > I think These are reason why for this requirement. > > And I don't know if the older version of Qt5(5.0,5.1..) could be built > > with gcc 4.4... > > > > By the way, RHEL6 is now at second half of its 10 years support life > > cycle. [3] I think it would be better to start to consider about Qt5 > > support for RHEL7. As RHEL7 has gcc 4.8, the devtoolset is not needed. > > > > > > [1] > > http://forum.qt.io/topic/30140/solved-qt-creator-could-not-find-or-load-> > the-qt-platform-plugin-xcb/ > > > > [2] https://access.redhat.com/support/policy/updates/dts > > [3] https://access.redhat.com/support/policy/updates/errata > > > > > > Regards. > > Takahiro > > > > > > On 2016年1月18日月曜日 15時58分09秒 JST Hausmann Simon wrote: > > > > > I'm surprised as well that this slipped through. Looks like MSVC 2010 > > > supports this bit as well. > > > > > > > > > > > > It is true however that we require devtoolset 3 for RHEL 6. Does anyone > > > remember the reason? > > > > > > > > > > > > > > > Simon > > > > > > > > > > > > Original Message > > > > > > From: Olivier Goffart > > > Sent: Monday, January 18, 2016 16:26 > > > To: development at qt-project.org > > > Cc: Rex Dieter > > > Subject: Re: [Development] qtdeclarative-5.6.0-beta build failure on > > > rhel6 > > > > > > > > > > > > On Montag, 18. Januar 2016 08:31:01 CET Rex Dieter wrote: > > > > > > > I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have > > > > run > > > > into a build failure in qtdeclarative, > > > > > > > > > > > > > > > > > > > > > > > > > beta/tools/qmlimportscanner/main.cpp:376: error: no matching function > > > > for > > > > > > call to 'find_if(QList::const_iterator, > > > > > > > > > > > > std::find_if is new in C++11 > > > And it was used in https://codereview.qt-project.org/125853/ in the 5.6 > > > which still does not require C++11. > > > > > > > > > > > > Apparently the CI does not try to build this with non-c++11 enabled > > > compilers? > > > > > > > > > > > > -- > > > 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 > > > _______________________________________________ > > > 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 Tue Jan 19 15:07:58 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 15:07:58 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <2487962.d1As7ZZxxf@finn> References: <201601051352.06816.marc.mutz@kdab.com> <25528BEF-504A-48E7-96A7-4B0FACC0AC38@theqtcompany.com> <2487962.d1As7ZZxxf@finn> Message-ID: <201601191507.58630.marc.mutz@kdab.com> On Tuesday 19 January 2016 13:42:16 Olivier Goffart wrote: > On Dienstag, 19. Januar 2016 12:02:12 CET Knoll Lars wrote: > > Things are not just black and white. But we can’t do a Qt6 that simply > > removes all of them completely. We’d leave most of our users behind on Qt > > 5 forever. So we have to find better, and maybe more incremental, ways > > to handle this. With a radical 'let’s throw them all away' approach we > > will leave all our current users behind. > > Just an idea: > > We deprecate them, so all our api use std::vector and such. > We add a qt5support library which contains classes like: > > template class QVector : public std::vector > { > QVector(std::vector); // implicit conversion from std::vector > /* All the Qt API goes here */ > }; > > I believe this should be mostly source compatible. I'd aggregate the std container instead of inheriting it, but yes, that's a good idea. I just wrote a mail suggesting essentially the same, only slower. But I'd have nothing against going all-in, either. > This also assume we can use std in our ABI (which i think we should allow) +1 > Marc Mutz wrote: > > > E.g. QVector seriously needs to support move-only types (like > > > unique_ptr) in a C++11 world. Oops... it never will... it's CoWed... > > Actually, it might be possible, using SFINAE, to disable the copy > constructor of QVector when the T is not copyable. (and we also do not > call detach for such T since it cannot be copyed and therefore cannot be > shared) It may, yes. With the current speed of Qt container development, though, I don't see this coming to fruition. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From stephen.kelly at ableton.com Tue Jan 19 14:17:17 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Tue, 19 Jan 2016 14:17:17 +0100 Subject: [Development] Binding evaluation during ListView delegate remove animation Message-ID: <569E375D.4080709@ableton.com> Hi, I have uploaded a testcase to https://github.com/ske-ableton/public_sscce/tree/master/delegate_data which demonstrates a problem that can occur with ListView delegates that can be animated away on removal. This seems to me to be a design bug in the QML ListView. It seems to be a simple enough case (and easy enough to hit) that it should be easy to do correctly without the client needing to implement workarounds for it. I have some ideas on how to implement a fix for this, so that the ListView caches data it retrieves from the model. Before I implement a patch to implement caching, I wonder if anyone has any better/alternative ideas for how to fix this, or if you think this is 'not a bug' or any other thoughts you have. Some concerns could be behavior backward compatibility, API, new behavior in a new QtQuick 2.x version of the ListView etc. Thanks, Steve. -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 From Marco.Bubke at theqtcompany.com Tue Jan 19 14:23:33 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Tue, 19 Jan 2016 13:23:33 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <2487962.d1As7ZZxxf@finn> References: <201601051352.06816.marc.mutz@kdab.com> <201601191350.53878.marc.mutz@kdab.com> <25528BEF-504A-48E7-96A7-4B0FACC0AC38@theqtcompany.com> <2487962.d1As7ZZxxf@finn> Message-ID: On January 19, 2016 13:42:33 Olivier Goffart wrote: > On Dienstag, 19. Januar 2016 12:02:12 CET Knoll Lars wrote: >> Things are not just black and white. But we can’t do a Qt6 that simply >> removes all of them completely. We’d leave most of our users behind on Qt 5 >> forever. So we have to find better, and maybe more incremental, ways to >> handle this. With a radical 'let’s throw them all away' approach we will >> leave all our current users behind. > > Just an idea: > > We deprecate them, so all our api use std::vector and such. > We add a qt5support library which contains classes like: > > template class QVector : public std::vector > { > QVector(std::vector); // implicit conversion from std::vector > /* All the Qt API goes here */ > }; > > I believe this should be mostly source compatible. But it is a behavior change which are the worst of all. You get no clear feedback what is wrong but your code is suddenly slow. We should have a version with CoW too. > This also assume we can use std in our ABI (which i think we should allow) > > Marc Mutz wrote: >> > E.g. QVector seriously needs to support move-only types (like >> > unique_ptr) in a C++11 world. Oops... it never will... it's CoWed... > > Actually, it might be possible, using SFINAE, to disable the copy constructor > of QVector when the T is not copyable. (and we also do not call detach for > such T since it cannot be copyed and therefore cannot be shared) > > -- > 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 -- Sent from cellphone, sorry for the typos From dangelog at gmail.com Tue Jan 19 14:33:46 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Tue, 19 Jan 2016 14:33:46 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191507.58630.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <25528BEF-504A-48E7-96A7-4B0FACC0AC38@theqtcompany.com> <2487962.d1As7ZZxxf@finn> <201601191507.58630.marc.mutz@kdab.com> Message-ID: On Tue, Jan 19, 2016 at 3:07 PM, Marc Mutz wrote: > I'd aggregate the std container instead of inheriting it, but yes, that's a > good idea. I just wrote a mail suggesting essentially the same, only > slower. > But I'd have nothing against going all-in, either. We can't "suddenly" break CoW, though. Who's going to review the millions of lines of code where copies where happily taken assuming they were cheap? My 2 c, -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From Uwe.Rathmann at tigertal.de Tue Jan 19 14:40:39 2016 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 19 Jan 2016 13:40:39 +0000 (UTC) Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> <201601151842.43187.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> Message-ID: On Tue, 19 Jan 2016 08:39:02 +0000, Knoll Lars wrote: > The main question IMO is how we can bring these two worlds closer > together for Qt 6 (or maybe even to some extent in Qt 5.x). Why - ending up with an inconsistent and undecided API ? To me the API design is the most valuable asset of the Qt classes. To make it worse because of corner case performance consideration, or to make some of your developers happy - sounds just wrong to me. >From my point of view ( being an application developer ) the most important thing is, that I can make APIs like: - Vector interpolated( const Vector & ) because it leads to more readable code than: - void interpolated( const Vector &in, Vector &out ). Looking back on the Qt projects I've been working for over the years the vast majority of use cases for QVector/QList are for lists below 100 elements, that are not changed often. Performance bottlenecks usually are because of using the wrong type of container ( algorithm ) - not the implementation of the container itself. As long as someone finds examples in the Qt code itself, where a migration from Qt containers to STL containers has a relevant effect, I don't understand this discussion at all. ciao, Uwe From marc.mutz at kdab.com Tue Jan 19 16:09:48 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 16:09:48 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601191507.58630.marc.mutz@kdab.com> Message-ID: <201601191609.48882.marc.mutz@kdab.com> On Tuesday 19 January 2016 14:33:46 Giuseppe D'Angelo wrote: > On Tue, Jan 19, 2016 at 3:07 PM, Marc Mutz wrote: > > I'd aggregate the std container instead of inheriting it, but yes, that's > > a good idea. I just wrote a mail suggesting essentially the same, only > > slower. > > But I'd have nothing against going all-in, either. > > We can't "suddenly" break CoW, though. Who's going to review the millions > of lines of code where copies where happily taken assuming they were cheap? Who's reviewing the millions of lines of code where hidden detaches are happily incurred even though they are not cheap? I'd say that if you took copies in a tight loop, you'll notice and the profiler will find it for you. And the rest don't matter, or they will be found by Clazy. I doubt many people actively use the fact that Qt containers are cheap to copy. But yes, Qt API needs to be reviewed with an eye towards this. Then again, Non-Qt C++ would be horribly slow if copying containers was so prohibitly expensive. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From giuseppe.dangelo at kdab.com Tue Jan 19 15:02:17 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 19 Jan 2016 15:02:17 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <5698DA95.90703@vikingsoft.eu> <201601151842.43187.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> Message-ID: <569E41E9.2040909@kdab.com> Il 19/01/2016 14:40, Uwe Rathmann ha scritto: > As long as someone finds examples in the Qt code itself, where a > migration from Qt containers to STL containers has a relevant effect, I > don't understand this discussion at all. Marc has been doing exactly this for the past weeks, just run a git log on qtbase/dev. The result is that we're now having faster and smaller libraries in QtCore (and more maintainable code). Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From marc.mutz at kdab.com Tue Jan 19 16:11:40 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 16:11:40 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191500.34358.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <569E23BF.9050905@familiesomers.nl> <201601191500.34358.marc.mutz@kdab.com> Message-ID: <201601191611.40954.marc.mutz@kdab.com> On Tuesday 19 January 2016 15:00:33 Marc Mutz wrote: > Now: > 1. Tell people to use auto when receiving Qt containers returned from a > function. > 2. Tell people to stick to the std-compatible API subset. > 3. Deprecate Q_FOREACH and recommend range-for (+ qAsConst(), where > needed). 4. Port as many internal containers (those that are not exposed in API) to std ones. > In Qt 6: > 1. Implement the containers on top of std ones, dropping CoW, providing > simple, fast (when moving), conversion between std and Qt containers. > 2. Deprecate the std-incompatible API subset > 3. Remove Q_FOREACH > 4. Deprecate qAsConst() 5. Use Qt containers only in the interface, not the implementation. > In Qt 7: > 1. Drop all Qt container API use from the library, use only std ones. > 2. Keep the Qt ones around as deprecated, in a separate compat library. > 3. Drop qAsConst() > > In Qt 8: > Remove the Qt ones. > > That easily spans 10-15 years, but at least we'd have an exit strategy. > > If, otoh, by Qt 6, we'd still continue doing nothing, as before, we'll > lose another four years. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From bo at vikingsoft.eu Tue Jan 19 15:05:15 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Tue, 19 Jan 2016 15:05:15 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191500.34358.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601191315.18737.marc.mutz@kdab.com> <569E23BF.9050905@familiesomers.nl> <201601191500.34358.marc.mutz@kdab.com> Message-ID: <569E429B.2080604@vikingsoft.eu> Den 19-01-2016 kl. 15:00 skrev Marc Mutz: > In Qt 6: > 1. ... dropping CoW ... I'm against any change that does this. I know you hate and loathe them. I don't. I think this alone makes Qt containers worth while. And it doesn't matter what arguments you give, I already know and understand them. The pros of CoW to me outweigh the cons. We disagree on this, and that's perfectly okay. However, there are also things in this argument where I agree with you. I do think there are more containers in Qt than necessary. It's not necessarily the case that Qt needs to have all types of lists, for example. And I would like to see Qt offer the use of std:: containers in the API. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From kenya888 at gmail.com Tue Jan 19 15:08:16 2016 From: kenya888 at gmail.com (Takahiro Hashimoto) Date: Tue, 19 Jan 2016 23:08:16 +0900 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 In-Reply-To: References: <6253453.Zl7NJyuHHX@xps13> Message-ID: <2360436.skxr4n9hl5@xps13> Rex, thank you for your pointer to EPEL. And your nice work at EPEL:) On 2016年1月19日火曜日 6時39分39秒 JST Rex Dieter wrote: > Takahiro Hashimoto wrote: > > And I don't know if the older version of Qt5(5.0,5.1..) could be built > > with gcc 4.4... > > They could, including Qt 5.5.x. I am currently providing RHEL 6/7 Qt5 > packages via > https://fedoraproject.org/wiki/EPEL > > I started this thread because EPEL by policy doesn't allow dependencies > outside of RHEL to be used, and so EPEL (for RHEL6) can no longer support Qt > 5.6 and newer. > > -- Rex > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development I think we have two points for discussion. Please let me write for clarify them. 1. c++11 code in Qt 5.6 I think you can patch qtdeclarative source locally for EPEL, of course you know. But as far as you experienced the cause of build failure is the use of c ++11 code(std::find_if and others) which isn't allowed in Qt 5.6 LTS policy(?) We should discuss wheather it should be removed or not. 2. Officially supported platform for Qt 5.6 Despite existence of c++11 code, now supported gcc version for Linux 32/64 is at least 4.6.3 or later (see Ubuntu section) [1] If EPEL is independent of it, we can approach some work(like local patch) for support Qt5.6 in EPEL in RHEL6. I have no good thought whether the minimum supported gcc version in Qt 5.6 should be changed to gcc 4.4.7 for RHEL6 or not... I personally think it would be better to concentrate on RHEL7 support...:D This is my opinion. Guys, I'm happy for your comment about them. [1] http://doc.qt.io/QtSupportedPlatforms/index.html Regards. Takahiro From milian.wolff at kdab.com Tue Jan 19 15:13:57 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Tue, 19 Jan 2016 15:13:57 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> Message-ID: <1815028.k8YBZiF5PC@agathebauer> On Dienstag, 19. Januar 2016 13:40:39 CET Uwe Rathmann wrote: > On Tue, 19 Jan 2016 08:39:02 +0000, Knoll Lars wrote: > > The main question IMO is how we can bring these two worlds closer > > together for Qt 6 (or maybe even to some extent in Qt 5.x). > > Why - ending up with an inconsistent and undecided API ? > > To me the API design is the most valuable asset of the Qt classes. To > make it worse because of corner case performance consideration, or to > make some of your developers happy - sounds just wrong to me. > > >From my point of view ( being an application developer ) the most > > important thing is, that I can make APIs like: > > - Vector interpolated( const Vector & ) > > because it leads to more readable code than: > > - void interpolated( const Vector &in, Vector &out ). With C++11 move semantics, you can, and should, do the first options even for large vectors, also if Vector == std::vector. So this point is moot. -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From milian.wolff at kdab.com Tue Jan 19 15:19:55 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Tue, 19 Jan 2016 15:19:55 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191609.48882.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601191609.48882.marc.mutz@kdab.com> Message-ID: <1568431.M4bc1goitB@agathebauer> On Dienstag, 19. Januar 2016 16:09:48 CET Marc Mutz wrote: > On Tuesday 19 January 2016 14:33:46 Giuseppe D'Angelo wrote: > > On Tue, Jan 19, 2016 at 3:07 PM, Marc Mutz wrote: > > > I'd aggregate the std container instead of inheriting it, but yes, > > > that's > > > a good idea. I just wrote a mail suggesting essentially the same, only > > > slower. > > > But I'd have nothing against going all-in, either. > > > > We can't "suddenly" break CoW, though. Who's going to review the millions > > of lines of code where copies where happily taken assuming they were > > cheap? > > Who's reviewing the millions of lines of code where hidden detaches are > happily incurred even though they are not cheap? > > I'd say that if you took copies in a tight loop, you'll notice and the > profiler will find it for you. And the rest don't matter, or they will be > found by Clazy. > > I doubt many people actively use the fact that Qt containers are cheap to > copy. But yes, Qt API needs to be reviewed with an eye towards this. Then > again, Non-Qt C++ would be horribly slow if copying containers was so > prohibitly expensive. I completely agree with Marc here. But I think him mentioning Clazy is an important point: Thanks to Clang, it is possible to write tools that automatically convert code from one version to another, taking the semantics into account. So another option is to write such a tool for Qt 6 that checks where copies are made and then notify the user about it so he can investigate it. -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From Eike.Ziller at theqtcompany.com Tue Jan 19 15:21:57 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Tue, 19 Jan 2016 14:21:57 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191609.48882.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601191507.58630.marc.mutz@kdab.com> <201601191609.48882.marc.mutz@kdab.com> Message-ID: <8EA8AC75-5623-42CD-B0B7-5408CF384672@digia.com> > On Jan 19, 2016, at 16:09, Marc Mutz wrote: > > On Tuesday 19 January 2016 14:33:46 Giuseppe D'Angelo wrote: >> On Tue, Jan 19, 2016 at 3:07 PM, Marc Mutz wrote: >>> I'd aggregate the std container instead of inheriting it, but yes, that's >>> a good idea. I just wrote a mail suggesting essentially the same, only >>> slower. >>> But I'd have nothing against going all-in, either. >> >> We can't "suddenly" break CoW, though. Who's going to review the millions >> of lines of code where copies where happily taken assuming they were cheap? > > Who's reviewing the millions of lines of code where hidden detaches are > happily incurred even though they are not cheap? > > I'd say that if you took copies in a tight loop, you'll notice and the profiler > will find it for you. And the rest don't matter, or they will be found by > Clazy. > > I doubt many people actively use the fact that Qt containers are cheap to > copy. Each and every developer that uses Qt uses the fact that Qt containers are cheap to “copy" class A { public: QVector something() const; private: QVector m_something; }; QVector A::something() const { return m_something; } Br, Eike > But yes, Qt API needs to be reviewed with an eye towards this. Then > again, Non-Qt C++ would be horribly slow if copying containers was so > prohibitly expensive. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Uwe.Rathmann at tigertal.de Tue Jan 19 15:53:43 2016 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Tue, 19 Jan 2016 14:53:43 +0000 (UTC) Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601191315.18737.marc.mutz@kdab.com> <569E23BF.9050905@familiesomers.nl> <201601191500.34358.marc.mutz@kdab.com> <569E429B.2080604@vikingsoft.eu> Message-ID: On Tue, 19 Jan 2016 15:05:15 +0100, Bo Thorsen wrote: > And I would like to see Qt offer the use of std:: containers in > the API. This would exactly end up as an "undecided and inconsistent" API. Once one API returns an std:: container you need other APIs, where you can forward the result to. In the worst case you end up with duplicating the APIs for both types of containers. Uwe From gmaxera at gmail.com Tue Jan 19 15:58:11 2016 From: gmaxera at gmail.com (Gian Maxera) Date: Tue, 19 Jan 2016 14:58:11 +0000 Subject: [Development] QtAndroidMediaPlayer not playing remote HTTP files Message-ID: Hello, I’ve just opened a bugs on QtAndroidMediaPlayer … I hope it's just me doing something wrong :-) https://bugreports.qt.io/browse/QTBUG-50539 Ciao, Gianluca. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charleyb123 at gmail.com Tue Jan 19 16:29:03 2016 From: charleyb123 at gmail.com (charleyb123 .) Date: Tue, 19 Jan 2016 07:29:03 -0800 Subject: [Development] Qt Virtual Keyboard (New KDE Free Qt Foundation Agreement and Changes) In-Reply-To: <378513F5-76C7-4A1C-9735-072310BD8422@theqtcompany.com> References: <201601191316.18720.marc.mutz@kdab.com> <378513F5-76C7-4A1C-9735-072310BD8422@theqtcompany.com> Message-ID: +1 On Tue, Jan 19, 2016 at 4:32 AM, Knoll Lars wrote: > +1 and +1 from me as well :) > > Cheers, > Lars > > > > > On 19/01/16 13:16, "Development on behalf of Marc Mutz" < > development-bounces at qt-project.org on behalf of marc.mutz at kdab.com> wrote: > > >On Tuesday 19 January 2016 08:22:54 Viironen Kalle wrote: > >> Hi, > >> > >> As Lars mentioned in his email about KDE Free Qt foundation agreement > and > >> changes, we’re pushing sources of Qt Virtual Keyboard to codereview. > >> > >> I’d like to propose the Qt Virtual Keyboard module to be taken as part > of > >> Qt add-on modules,it has been part of commercial Qt releases for some > time > >> now. > > > >+1 > > > >> I also propose Mitch Curtis to be named as maintainer for the Qt > >> Virtual Keyboard module. > > > >+1 > > > >-- > >Marc Mutz | Senior Software Engineer > >KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > >Tel: +49-30-521325470 > >KDAB - The Qt Experts > >_______________________________________________ > >Development mailing list > >Development at qt-project.org > >http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > 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 Jan 19 16:48:07 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 07:48:07 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> Message-ID: <4659851.qNACLQFNjs@tjmaciei-mobl4> On Tuesday 19 January 2016 09:29:22 Bubke Marco wrote: > I think we should start minimal and try to layer QVector over std::vector. We can only do that efficiently if we drop CoW. Creating an adapting API is easy; making sure we don't do unnecessary copies because we've lost CoW is the hard part. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jan 19 17:00:35 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 08:00:35 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191507.58630.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <2487962.d1As7ZZxxf@finn> <201601191507.58630.marc.mutz@kdab.com> Message-ID: <14830867.NDFji9s2sU@tjmaciei-mobl4> On Tuesday 19 January 2016 15:07:58 Marc Mutz wrote: > It may, yes. With the current speed of Qt container development, though, I > don't see this coming to fruition. The current speed of development is limited by the availability of major releases. Most of what I want to do cannot be done until Qt 6. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jan 19 17:07:12 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 08:07:12 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191007.43865.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <6824449.TyanUDe9rY@tjmaciei-mobl4> <201601191007.43865.marc.mutz@kdab.com> Message-ID: <1511154.5h8suNsMih@tjmaciei-mobl4> On Tuesday 19 January 2016 10:07:43 Marc Mutz wrote: > > That doesn't mean types without CoW are immune from the problem. There are > > lots of discussion in the std mailing lists about constexpr data, so in > > the > > future a const std::string could potentially point to .rodata and thus be > > affected by this problem too. > > But only _locally_. As soon as you copy the std::string, you're insulated > from that problem, unlike in CoW, where it can strike anywhere the string > happens to be copied to. I am not sure. This is of course speculative since such code does not exist. But it's entirely possible that std::string's move constructor could propagate the reference to that .rodata. std::string someString() { return constexpr_string("foo"); } std::string g_string; void f() { // move-construction static std::string s_string = someString(); // causes move-assignment operator to be called g_string = someString(); } Also, people using deep-copy types tend to keep references more often than people using cheap CoW types. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jan 19 17:13:48 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 08:13:48 -0800 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: References: <1929252.o679PxHBMt@tjmaciei-mobl4> Message-ID: <1554685.7rdozgZpn9@tjmaciei-mobl4> On Tuesday 19 January 2016 09:50:37 Gunnar Roth wrote: > Thank you Thiago. > > Actually I meant ucomparing a QString with a QStringLiteral when i said > " both strings being uft16 seems to be faster ". > So what i learned now on an x85 with avx support is should be no performance > problem. We also have SSE2 code which should provide similar performance, but not better since the unpacking code is more expensive than the one AVX2 instruction that loads and zero-extends. > But what about a wec2013 with arm, as qt does not support neon for > wec2013. I don't do benchmarks for ARM. That said, Erik and Allan have been re-writing some of my vector code from SSE2 to Neon and are contributing the code to the dev branch. Some of the functionality is possible only in AArch64 due to the lack of one single instruction corresponding to SSE2's PMOVMSKB in 32-bit mode. That includes the string-compare code. > Qt does not even support sse2 for wec because configureap.cpp does > always reset sse2 to no, even if i pass it to configure. Probably because whoever wrote that part of configureapp.cpp assumed that it would always be ARM. > Same as the > openssl problem, which was solved in dev > branch. https://codereview.qt-project.org/#/c/122437/ Right. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From stephen.kelly at ableton.com Tue Jan 19 17:13:50 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Tue, 19 Jan 2016 17:13:50 +0100 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: <569E375D.4080709@ableton.com> References: <569E375D.4080709@ableton.com> Message-ID: <569E60BE.2020804@ableton.com> On 19/01/16 14:17, Stephen Kelly wrote: > > Hi, > > I have uploaded a testcase to > > https://github.com/ske-ableton/public_sscce/tree/master/delegate_data > > which demonstrates a problem that can occur with ListView delegates > that can be animated away on removal. > I got feedback that what is happening here may not be described clearly enough. So, I made a bug report too: https://bugreports.qt.io/browse/QTBUG-50542 The remove animation happens as a result of the QAbstractItemModel::rowsRemoved signal, so there is a 'tension' between the requirements: 1. An attempt in the delegate to access the data while it fades out. 2. The row in the model providing access to that data has just been removed. The solution could be to cache data retrieved from the model. This seems to me to be a design bug in the QML ListView. It seems to be a simple enough case (and easy enough to hit) that it should be easy to do correctly without the client needing to implement workarounds for it. I have some ideas on how to implement a fix for this, so that the ListView caches data it retrieves from the model. Before I implement a patch to implement caching, I wonder if anyone has any better/alternative ideas for how to fix this, or if you think this is 'not a bug' or any other thoughts you have. Some concerns could be behavior backward compatibility, API, new behavior in a new QtQuick 2.x version of the ListView etc. Thanks, Steve. -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Jan 19 17:16:00 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 08:16 -0800 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 In-Reply-To: <2718327.vc9pWrFWa0@finn> References: <2718327.vc9pWrFWa0@finn> Message-ID: <2818418.JsPNMqg9mn@tjmaciei-mobl4> On Monday 18 January 2016 16:26:05 Olivier Goffart wrote: > On Montag, 18. Januar 2016 08:31:01 CET Rex Dieter wrote: > > I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run > > into a build failure in qtdeclarative, > > > > > beta/tools/qmlimportscanner/main.cpp:376: error: no matching function for > > call to 'find_if(QList::const_iterator, > > std::find_if is new in C++11 > And it was used in https://codereview.qt-project.org/125853/ in the 5.6 > which still does not require C++11. > > Apparently the CI does not try to build this with non-c++11 enabled > compilers? We do build in -no-c++11, but apparently libstdc++ does not disable its C++11 functionality in C++98 mode. This should be reverted and rewritten using a simple loop. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Tue Jan 19 18:50:15 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 18:50:15 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <1511154.5h8suNsMih@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <201601191007.43865.marc.mutz@kdab.com> <1511154.5h8suNsMih@tjmaciei-mobl4> Message-ID: <201601191850.16434.marc.mutz@kdab.com> On Tuesday 19 January 2016 17:07:12 Thiago Macieira wrote: > On Tuesday 19 January 2016 10:07:43 Marc Mutz wrote: > > > That doesn't mean types without CoW are immune from the problem. There > > > are lots of discussion in the std mailing lists about constexpr data, > > > so in the > > > future a const std::string could potentially point to .rodata and thus > > > be affected by this problem too. > > > > But only _locally_. As soon as you copy the std::string, you're insulated > > from that problem, unlike in CoW, where it can strike anywhere the string > > happens to be copied to. > > I am not sure. This is of course speculative since such code does not > exist. But it's entirely possible that std::string's move constructor > could propagate the reference to that .rodata. > > std::string someString() > { > return constexpr_string("foo"); > } It is speculative, but I don't think this example would propagate the reference, because you cannot move from a const object. > std::string g_string; > void f() > { > // move-construction > static std::string s_string = someString(); > > // causes move-assignment operator to be called > g_string = someString(); > } > > Also, people using deep-copy types tend to keep references more often than > people using cheap CoW types. Yes. Or they form shared_ptrs to it. But then the syntax makes it glaringly obvious that a reference is manipulated (as opposed to a value). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From mwoehlke.floss at gmail.com Tue Jan 19 17:43:59 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 19 Jan 2016 11:43:59 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191151.42545.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601182343.38142.marc.mutz@kdab.com> <201601191151.42545.marc.mutz@kdab.com> Message-ID: On 2016-01-19 05:51, Marc Mutz wrote: > So... is realloc actually the optimisation everyone (incl. me) expected it to > be? It really *ought* to be, at least in the right cases. Let's say I have a type that stores a buffer, which, for whatever reason, is not movable (i.e. no move-ctor or swap¹), but *is* relocatable. Resizing a vector of such types involves allocating the new block, doing a single block memcpy, and releasing the old block. Resizing if they were *not* relocatable involves a copy ctor for each, which involves allocating a new memory block, copying the data, and releasing the old block *per item*, plus the two memory operations If 2*N heap operations plus N block copies of "large" blocks are comparably expensive to a single block copy of N*sizeof(void*), I would be very surprised :-). (¹ Keep in mind also that the move/swap quite possibly must also be noexcept or it can't be used anyway.) Maybe we're looking at bad examples, or there are fewer such instances than expected where it is significantly better. (In particular, I suspect neither string nor QByteArray are "good examples". Try with a type that always allocates memory?) -- Matthew From dangelog at gmail.com Tue Jan 19 17:48:48 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Tue, 19 Jan 2016 17:48:48 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <1511154.5h8suNsMih@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <6824449.TyanUDe9rY@tjmaciei-mobl4> <201601191007.43865.marc.mutz@kdab.com> <1511154.5h8suNsMih@tjmaciei-mobl4> Message-ID: On Tue, Jan 19, 2016 at 5:07 PM, Thiago Macieira wrote: > > std::string someString() > { > return constexpr_string("foo"); > } > "constexpr_string" should very likely return a const std::string, so this will copy and not move... > std::string g_string; > void f() > { > // move-construction > static std::string s_string = someString(); > > // causes move-assignment operator to be called > g_string = someString(); > } ... otherwise, how is (for instance) g_string.begin() going to work since it's noexcept? Cheers, -- Giuseppe D'Angelo -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Tue Jan 19 17:59:12 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 19 Jan 2016 11:59:12 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191350.53878.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> <9C5D8E1F-36A1-4D3A-99E1-B343C3A4BDA5@theqtcompany.com> <201601191350.53878.marc.mutz@kdab.com> Message-ID: On 2016-01-19 07:50, Marc Mutz wrote: > Status quo in libraries equals bit-rot. The containers are _not_ "good > enough". E.g. QVector seriously needs to support move-only types (like > unique_ptr) in a C++11 world. Oops... it never will... it's CoWed... How do STL containers deal with this? I guess they just can't be copied? Why can't Qt containers do likewise? -- Matthew From mwoehlke.floss at gmail.com Tue Jan 19 18:00:09 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 19 Jan 2016 12:00:09 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191152.06015.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> <201601191152.06015.marc.mutz@kdab.com> Message-ID: On 2016-01-19 05:52, Marc Mutz wrote: > And a QVector provides exactly the same guarantees as a std::vector. How come > one is easier to use than the other? Because QVector has indexOf()? append, back, first, front, indexOf, insert(index), last, lastIndexOf, mid, pop_front, prepend, remove, removeAll, removeOne, takeAt, takeFirst, takeLast, value(index, default), operator+, operator+=... did I miss any? That's... not exactly a short list. Qt containers in general show a similar pattern as the above. Which is exactly why I love Qt containers and hate STL ones. -- Matthew From marc.mutz at kdab.com Tue Jan 19 19:16:25 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 19:16:25 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <14830867.NDFji9s2sU@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <201601191507.58630.marc.mutz@kdab.com> <14830867.NDFji9s2sU@tjmaciei-mobl4> Message-ID: <201601191916.25565.marc.mutz@kdab.com> On Tuesday 19 January 2016 17:00:35 Thiago Macieira wrote: > On Tuesday 19 January 2016 15:07:58 Marc Mutz wrote: > > It may, yes. With the current speed of Qt container development, though, > > I don't see this coming to fruition. > > The current speed of development is limited by the availability of major > releases. It's laudable that you're doing work on the containers, however I don't share that sentiment. > Most of what I want to do cannot be done until Qt 6. That may be so. But most of what is _missing_ is implementable in Qt 5: - equal_range on hashed containers - range inserts, ctors, assignments - exception safety guarantees - move semantics on realloc / insertions - emplace (with Q_COMPILER_UNIFORM_INIT ifdef) - not requiring op= / default ctor in QVector - move-only payload types (hard with CoW) - splicing in node-based containers (hard with CoW) - atomic operations on QSharedPointer - alias ctors for QSharedPointer - changing iterator → const_iterator in insert / erase arguments (hampered by QT_STRICT_ITERATORS preventing iterator → const_iterator implicit conversions, otherwise one could write erase loops over node-based containers that only detach when actually removing an element) - ... Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Tue Jan 19 18:34:48 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 09:34:48 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191916.25565.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <14830867.NDFji9s2sU@tjmaciei-mobl4> <201601191916.25565.marc.mutz@kdab.com> Message-ID: <14111079.XHVplpXGYF@tjmaciei-mobl4> On Tuesday 19 January 2016 19:16:25 Marc Mutz wrote: > That may be so. But most of what is _missing_ is implementable in Qt 5: > > - equal_range on hashed containers No idea what that is. > - range inserts, ctors, assignments Already done for QVector for Qt6. However, since I wrote this on top of QGenericArray, I can't push it to Qt 5. > - exception safety guarantees Done since Qt 5.0 by João, but missed the release deadline. It's QGenericArray using QArrayDataPointer and QArrayDataOps. Also, we changed our policy towards exception-safety since 5.0 and this work is no longer needed. > - move semantics on realloc / insertions This is easy to implement in QArrayDataOps. However, due to CoW, we'd have to duplicate the code paths depending on whether the refcount was 1 or not. That's a runtime decision, so I don't think this is worth it. > - emplace (with Q_COMPILER_UNIFORM_INIT ifdef) Done in QGenericArray, but not really relevant since we don't support move- only types. > - not requiring op= / default ctor in QVector Not interesting to me. > - move-only payload types (hard with CoW) Ditto. > - splicing in node-based containers (hard with CoW) Ditto and no one has asked this in 10 years that QLinkedList has existed. > - atomic operations on QSharedPointer Explain more, please. > - alias ctors for QSharedPointer Ditto. > - changing iterator → const_iterator in insert / erase argumentsis > (hampered by QT_STRICT_ITERATORS preventing iterator → const_iterator > implicit conversions, otherwise one could write erase loops over > node-based containers that only detach when actually removing an element) Sounds like a Qt 6 change. Adding overloads is possible. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jan 19 18:36:03 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 09:36:03 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601191350.53878.marc.mutz@kdab.com> Message-ID: <2461025.b5KsyrvKyt@tjmaciei-mobl4> On Tuesday 19 January 2016 11:59:12 Matthew Woehlke wrote: > On 2016-01-19 07:50, Marc Mutz wrote: > > Status quo in libraries equals bit-rot. The containers are _not_ "good > > enough". E.g. QVector seriously needs to support move-only types (like > > unique_ptr) in a C++11 world. Oops... it never will... it's CoWed... > > How do STL containers deal with this? I guess they just can't be copied? > Why can't Qt containers do likewise? Because move-only types didn't exist when our containers were written, so we didn't support them. And now we've never investigated what would be required to do it. It's possible, but requires some tricky template magic that I fear will make MSVC stumble. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Jan 19 18:37:39 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 09:37:39 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <1511154.5h8suNsMih@tjmaciei-mobl4> Message-ID: <4571990.RWVZgVEVvP@tjmaciei-mobl4> On Tuesday 19 January 2016 17:48:48 Giuseppe D'Angelo wrote: > On Tue, Jan 19, 2016 at 5:07 PM, Thiago Macieira > wrote: > > std::string someString() > > { > > return constexpr_string("foo"); > > } > > "constexpr_string" should very likely return a const std::string, so this > will copy and not move... Right, which would make the entire thing pointless. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Tue Jan 19 19:00:46 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Tue, 19 Jan 2016 13:00:46 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <14111079.XHVplpXGYF@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <14830867.NDFji9s2sU@tjmaciei-mobl4> <201601191916.25565.marc.mutz@kdab.com> <14111079.XHVplpXGYF@tjmaciei-mobl4> Message-ID: On 2016-01-19 12:34, Thiago Macieira wrote: > On Tuesday 19 January 2016 19:16:25 Marc Mutz wrote: >> - emplace (with Q_COMPILER_UNIFORM_INIT ifdef) > > Done in QGenericArray, but not really relevant since we don't support move- > only types. I'd somewhat disagree; it can still be more efficient. But you say it's done already¹, so... cool :-). (¹ Yes, yes, *in QGenericArray*, which is not in Qt5...) >> - not requiring op= / default ctor in QVector > > Not interesting to me. What about immutable types? I think this is worthwhile... I know I've sometimes had to use STL containers due to move-only objects. I feel like I've also run into this at least once. >> - move-only payload types (hard with CoW) > > Ditto. Per above, I would *definitely* like to see this in Qt. (Also, movable QScopedPointer...) -- Matthew From marc.mutz at kdab.com Tue Jan 19 20:29:54 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 20:29:54 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601191151.42545.marc.mutz@kdab.com> Message-ID: <201601192029.55317.marc.mutz@kdab.com> On Tuesday 19 January 2016 17:43:59 Matthew Woehlke wrote: > On 2016-01-19 05:51, Marc Mutz wrote: > > So... is realloc actually the optimisation everyone (incl. me) expected > > it to be? > > It really *ought* to be, at least in the right cases. > > Let's say I have a type that stores a buffer, which, for whatever > reason, is not movable (i.e. no move-ctor or swap¹), but *is* > relocatable. Resizing a vector of such types involves allocating the new > block, doing a single block memcpy, and releasing the old block. > > Resizing if they were *not* relocatable involves a copy ctor for each, > which involves allocating a new memory block, copying the data, and > releasing the old block *per item*, plus the two memory operations > > If 2*N heap operations plus N block copies of "large" blocks are > comparably expensive to a single block copy of N*sizeof(void*), I would > be very surprised :-). > > (¹ Keep in mind also that the move/swap quite possibly must also be > noexcept or it can't be used anyway.) > > Maybe we're looking at bad examples, or there are fewer such instances > than expected where it is significantly better. (In particular, I > suspect neither string nor QByteArray are "good examples". Try with a > type that always allocates memory?) 0.736s for QVector 0.787s for std::vector 0.682s for QVector with reserve() called 0.670s for std::vector with reserve() called Which means that the realloc()s cost 54ms and the re-allocations + moves cost 117ms. Meaning 2×. It also means that if you can reserve(), all that optimisation gains you ... nothing. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From mathias at taschenorakel.de Tue Jan 19 19:56:38 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Tue, 19 Jan 2016 19:56:38 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <8EA8AC75-5623-42CD-B0B7-5408CF384672@digia.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601191507.58630.marc.mutz@kdab.com> <201601191609.48882.marc.mutz@kdab.com> <8EA8AC75-5623-42CD-B0B7-5408CF384672@digia.com> Message-ID: <569E86E6.8010104@taschenorakel.de> Am 19.01.2016 um 15:21 schrieb Ziller Eike: > >> On Jan 19, 2016, at 16:09, Marc Mutz wrote: >> I doubt many people actively use the fact that Qt containers are cheap to >> copy. > > Each and every developer that uses Qt uses the fact that Qt containers are cheap to “copy" > > class A > { > public: > QVector something() const; > private: > QVector m_something; > }; > > QVector A::something() const > { > return m_something; > } Good point Eike, thank you. Marc, wow would one avoid invocation of the copy constructor here? Without handing out pointers or references. Of course. Ciao, Mathias From thiago.macieira at intel.com Tue Jan 19 20:13:26 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 11:13:26 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <14111079.XHVplpXGYF@tjmaciei-mobl4> Message-ID: <4487310.cgOLTDhpWu@tjmaciei-mobl4> On Tuesday 19 January 2016 13:00:46 Matthew Woehlke wrote: > >> - not requiring op= / default ctor in QVector > > > > Not interesting to me. > > What about immutable types? I think this is worthwhile... I don't. It's possible, but I don't have an interest in supporting this. > >> - move-only payload types (hard with CoW) > > > > Ditto. > > Per above, I would *definitely* like to see this in Qt. (Also, movable > QScopedPointer...) Use unique_ptr instead. QScopedPointer should not leave the scope, as its name implies. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Tue Jan 19 20:58:42 2016 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Tue, 19 Jan 2016 20:58:42 +0100 Subject: [Development] API review and API quality In-Reply-To: <20160118164138.GB1505@troll08.it.local> References: <14982660.RFZjYkf8mA@rechenplan> <20160118164138.GB1505@troll08.it.local> Message-ID: <20160119195842.GA2435@klara.mpi.htwm.de> On Mon, Jan 18, 2016 at 05:41:38PM +0100, Oswald Buddenhagen wrote: > On Mon, Jan 18, 2016 at 03:48:54PM +0100, Andreas Hartmetz wrote: > > Gerrit is somehow much more detail-oriented, and criticizing "too > > subjective" stuff is frowned upon. > > > anyone who complains about such aspects of a review clearly didn't quite > get https://wiki.qt.io/Qt_Contribution_Guidelines - > > "Our API Design Principles aim for perfection." > > it's also point 1.2 of https://wiki.qt.io/Commit_Policy > > > Now what? > > > we actually already decided some months ago that TQtC sets up an api > review task force at pre-release time. > we've yet to see how that will work out in practice in the longer run. Right, *that* jury is still out. But to be honest, I am pessimistic here, beyond my usual self. 1. There are always good reasons to not touch code (e.g. for fixing "wrong" API) "just before the release". This can be as mundane as "CI got the phase of the moon wrong", up to "I am busy" or "I don't want to start yet another discussion about the color of bike sheds" producing a bias towards leaving stuff as-is, especially if it looks only mildly wrong. This is in stark contrast to the setup Andreas refers to when you'd *first* get a virtual nod from Mr B on the correct use of names and *then* started to create a patch. 2. Any two out of 200+ approvers can add stuff but there is practically no means to fix mistakes due to some compatibility promises once a minor release is out. Even if one firmly closes eyes and imagines a world where all those people agreed at least on basic ideas like "API consistency is an asset" or "experiments are better done in toy projects, not in the library", have no personal agenda etc etc there is still a big chance that (a) real mistakes happen, and more importantly (b) even those benevolent people would still produce inconsistent result because there's lways a subjective component when applying rules, no matter how strict they are. Solutions? Obviously no silver bullet, but: - API review task force before releases is a step forward to help to iron out obvious mistakes, but it's not a full solution as happens too late in the process and "running out of time" works against it. API review needs to block before things happen. We already have bots on gerrit for things like string changes, having something similar for stuff that'll fall under BC/SC promises doesn't seem infeasible. - There must be a means to stop people handling core parts of the project as playground for self-realisation. - It would be helpful if there was way to undo mistakes before the next major release happens (and that should not be the equivalent of dropping whole modules). Andre' From marc.mutz at kdab.com Tue Jan 19 22:40:40 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 22:40:40 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <569E86E6.8010104@taschenorakel.de> References: <201601051352.06816.marc.mutz@kdab.com> <8EA8AC75-5623-42CD-B0B7-5408CF384672@digia.com> <569E86E6.8010104@taschenorakel.de> Message-ID: <201601192240.40519.marc.mutz@kdab.com> On Tuesday 19 January 2016 19:56:38 Mathias Hasselmann wrote: > Am 19.01.2016 um 15:21 schrieb Ziller Eike: > >> On Jan 19, 2016, at 16:09, Marc Mutz wrote: > >> I doubt many people actively use the fact that Qt containers are cheap > >> to copy. > > > > Each and every developer that uses Qt uses the fact that Qt containers > > are cheap to “copy" > > > > class A > > { > > > > public: > > QVector something() const; > > > > private: > > QVector m_something; > > > > }; > > > > QVector A::something() const > > { > > > > return m_something; > > > > } > > Good point Eike, thank you. > > Marc, wow would one avoid invocation of the copy constructor here? > Without handing out pointers or references. Of course. It's funny how the same people who think nothing of the per-element memory allocation of QList suddenly become vehement performance critics when it comes to CoW :) It likely just doesn't matter, the rest of the C++ community has been working with containers that don't do CoW for the past 20 years and have survived. In those cases where it does matter, you'd return by const-&. Or an array_view. And no, that doesn't restrict your freedom to implement the function in any meaningful way, because you can always keep a caching mutable member to hold the result for the next call to the function (memoisation or however it's called), without any loss except the space required for the member. What about non-arrays? By the time we get around to all this, there will be no containers other than array-compatible ones left, because nothing else will provide the required speed. And if there are, you can write a _view for those, too. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Tue Jan 19 23:43:40 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 19 Jan 2016 23:43:40 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <14111079.XHVplpXGYF@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <201601191916.25565.marc.mutz@kdab.com> <14111079.XHVplpXGYF@tjmaciei-mobl4> Message-ID: <201601192343.40538.marc.mutz@kdab.com> On Tuesday 19 January 2016 18:34:48 Thiago Macieira wrote: > On Tuesday 19 January 2016 19:16:25 Marc Mutz wrote: > > That may be so. But most of what is _missing_ is implementable in Qt 5: > > > > - equal_range on hashed containers > > No idea what that is. http://en.cppreference.com/w/cpp/container/unordered_map/equal_range It's the correct way to find all values matching a given key (as opposed to QHash::values(const Key &), which forces a QList down your throat). > > - range inserts, ctors, assignments > > Already done for QVector for Qt6. However, since I wrote this on top of > QGenericArray, I can't push it to Qt 5. I don't understand this. It can clearly be implemented in Qt 5, so what you're saying is that you implemented it in a Qt 5-incompatible fashion and _won't_ (as opposed to "can't") backport? > > - exception safety guarantees > > Done since Qt 5.0 by João, but missed the release deadline. It's > QGenericArray using QArrayDataPointer and QArrayDataOps. > > Also, we changed our policy towards exception-safety since 5.0 and this > work is no longer needed. Sending your user's needs to /dev/null is a very easy way to fix it, yes. This is what I meant and what Lars called me polemic for. *Qt* doesn't need this → we don't care. But please, everyone, use our super-cool containers and not the shitty STL ones, because we use camelCase and they use underhanded_names. Argh... BTW: here and in the following, I'm not saying *you* should implement all this. I'm just picking on you because a) I know you can take it and b) it exemplifies very well what started this thread (back when this was still about std::optional and why QOptional would be a bad idea). > > - move semantics on realloc / insertions > > This is easy to implement in QArrayDataOps. However, due to CoW, we'd have > to duplicate the code paths depending on whether the refcount was 1 or > not. That's a runtime decision, so I don't think this is worth it. Oh, CoW again... Howard Hinnant has reported a 10x (or was it 100x?) slowdown on std::vector reallocation, depending on whether the std::string move ctor was marked as noexcept (std::vector refuses to move during reallocations when the type isn't nothrow_move_constructible). So, very much worth it, I think. > > - emplace (with Q_COMPILER_UNIFORM_INIT ifdef) > > Done in QGenericArray, but not really relevant since we don't support move- > only types. emplace is not about move-only types. move-only types can be appended with push_back(T&&). emplace is about constructing into the final place. Without any move or copy ctor called. As Alexandrescu put it: no work is less work than some work. > > - not requiring op= / default ctor in QVector > > Not interesting to me. That wouldn't be a problem if it would be interesting to *anyone*. Again, development stopped half-way. And this is a very annoying one. When porting from QList (which doesn't require default ctors), you end up adding an artificial default ctor to the payload type, which, surprisingly often, doesn't have one. Well, or you skip QVector and go directly to std::vector and save that nonsense. > > - move-only payload types (hard with CoW) > > Ditto. Which means QVector will not be able to hold unique_ptrs or std::threads. Well done. > > - splicing in node-based containers (hard with CoW) > > Ditto and no one has asked this in 10 years that QLinkedList has existed. Because no-one uses that container. In 100% of cases _I_ used std::list, it was because it had splice(): nothrow move from one std::list to the next in C++98: https://code.woboq.org/kde/kdepim/kleopatra/smartcard/readerstatus.cpp.html#509 peeling off one object from a std::list without so much as resetting four pointers: https://code.woboq.org/kde/kdepim/kleopatra/smartcard/readerstatus.cpp.html#554 I later learned that Herb Sutter calls this idiom an "acceptable poor man's concurrent queue". And again: *Qt* doesn't need this → we don't care. > > - atomic operations on QSharedPointer > > Explain more, please. You can CAS on a shared_ptr instance, as if it was a normal pointer: http://en.cppreference.com/w/cpp/memory/shared_ptr/atomic > > - alias ctors for QSharedPointer > > Ditto. http://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr ctor #8 > > - changing iterator → const_iterator in insert / erase argumentsis > > > > (hampered by QT_STRICT_ITERATORS preventing iterator → const_iterator > > implicit conversions, otherwise one could write erase loops over > > > > node-based containers that only detach when actually removing an element) > > Sounds like a Qt 6 change. Adding overloads is possible. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Tue Jan 19 22:56:57 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 13:56:57 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601192343.40538.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <14111079.XHVplpXGYF@tjmaciei-mobl4> <201601192343.40538.marc.mutz@kdab.com> Message-ID: <5791833.FQuMaqAkCA@tjmaciei-mobl4> On Tuesday 19 January 2016 23:43:40 Marc Mutz wrote: > > > - equal_range on hashed containers > > > > No idea what that is. > > http://en.cppreference.com/w/cpp/container/unordered_map/equal_range > > It's the correct way to find all values matching a given key (as opposed to > QHash::values(const Key &), which forces a QList down your throat). Thanks. > > > - range inserts, ctors, assignments > > > > Already done for QVector for Qt6. However, since I wrote this on top of > > QGenericArray, I can't push it to Qt 5. > > I don't understand this. It can clearly be implemented in Qt 5, so what > you're saying is that you implemented it in a Qt 5-incompatible fashion and > _won't_ (as opposed to "can't") backport? I *won't* backport to QVector, therefore I can't push those features. I implemented them in 2012. I've only been maintaining them alive for the last 3.5 years. > > > - exception safety guarantees > > > > Done since Qt 5.0 by João, but missed the release deadline. It's > > QGenericArray using QArrayDataPointer and QArrayDataOps. > > > > Also, we changed our policy towards exception-safety since 5.0 and this > > work is no longer needed. > > Sending your user's needs to /dev/null is a very easy way to fix it, yes. Well, the policy was agreed upon by the whole mailing list. We decided we don't care about exceptions, not even in containers. > This is what I meant and what Lars called me polemic for. *Qt* doesn't need > this → we don't care. But please, everyone, use our super-cool containers > and not the shitty STL ones, because we use camelCase and they use > underhanded_names. Engineer's motto: use the right tool for the right job. If you need performance or to squeeze the last bit of performance, use the Standard Library containers. If you need to work quickly, the Qt containers are better. > BTW: here and in the following, I'm not saying *you* should implement all > this. I'm just picking on you because a) I know you can take it and b) it > exemplifies very well what started this thread (back when this was still > about std::optional and why QOptional would be a bad idea). And note: I am against QOptional. I'd rather make people wait for the Standard Library, unless we really need something ourselves (like qAsConst). > > > - move semantics on realloc / insertions > > > > This is easy to implement in QArrayDataOps. However, due to CoW, we'd have > > to duplicate the code paths depending on whether the refcount was 1 or > > not. That's a runtime decision, so I don't think this is worth it. > > Oh, CoW again... > > Howard Hinnant has reported a 10x (or was it 100x?) slowdown on > std::vector reallocation, depending on whether the std::string > move ctor was marked as noexcept (std::vector refuses to move during > reallocations when the type isn't nothrow_move_constructible). > > So, very much worth it, I think. Not if the element type is CoW. Then the copies are cheap. Moreover, we have relocatable types, while the Standard Library doesn't yet. > > > - emplace (with Q_COMPILER_UNIFORM_INIT ifdef) > > > > Done in QGenericArray, but not really relevant since we don't support > > move- > > only types. > > emplace is not about move-only types. move-only types can be appended with > push_back(T&&). emplace is about constructing into the final place. Without > any move or copy ctor called. As Alexandrescu put it: no work is less work > than some work. While true, the benefit is small. > > > - not requiring op= / default ctor in QVector > > > > Not interesting to me. > > That wouldn't be a problem if it would be interesting to *anyone*. Again, > development stopped half-way. > > And this is a very annoying one. When porting from QList (which doesn't > require default ctors), you end up adding an artificial default ctor to the > payload type, which, surprisingly often, doesn't have one. Actually, I misread the proposal. You're talking about the *default* constructor, which is actually something I agree on and should fix. I had read as the *copy* constructor (i.e., move-only types). Note: if it's already fixed in QGenericArray, then my motivation to have a fix in Qt 5 drops considerably. > > > - move-only payload types (hard with CoW) > > > > Ditto. > > Which means QVector will not be able to hold unique_ptrs or std::threads. > Well done. Right. It hasn't been able to hold QObjects since Qt 2 and not many people have complained. > > > - atomic operations on QSharedPointer > > > > Explain more, please. > > You can CAS on a shared_ptr instance, as if it was a normal pointer: > > http://en.cppreference.com/w/cpp/memory/shared_ptr/atomic Interesting. Well, std::atomic> should just work. If it doesn't, you get to blame your Standard Library. I don't think we should extend our atomics to other types. Our classes are QAtomicInteger and QAtomicPointer. > > > - alias ctors for QSharedPointer > > > > Ditto. > > http://en.cppreference.com/w/cpp/memory/shared_ptr/shared_ptr > > ctor #8 That's easy to implement. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andrew.den.exter at qinetic.com.au Wed Jan 20 01:23:10 2016 From: andrew.den.exter at qinetic.com.au (Andrew den Exter) Date: Wed, 20 Jan 2016 10:23:10 +1000 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: <569E60BE.2020804@ableton.com> References: <569E375D.4080709@ableton.com> <569E60BE.2020804@ableton.com> Message-ID: On Wed, Jan 20, 2016 at 2:13 AM, Stephen Kelly wrote: > > > https://bugreports.qt.io/browse/QTBUG-50542 > > The remove animation happens as a result of the > QAbstractItemModel::rowsRemoved signal, so there is a 'tension' between the > requirements: > > 1. An attempt in the delegate to access the data while it fades out. > 2. The row in the model providing access to that data has just been > removed. > > The solution could be to cache data retrieved from the model. > That's a more complex solution than you might think. It's a pretty popular pattern to populate a model with QObjects for example and with a naive cache of QVariants what was an admittedly annoying binding evaluation error becomes a much more severe dereference of a dangling pointer. And there are the obvious runtime costs to building and maintaining a cache that is of little or no use to most people most of the time, which is I think a strong argument for it being an off by default feature if implemented. If you do have this problem, right now the solution is to bind the model value to a property in your delegate and use the property in your binding. The property binding will only be re-evaluated when the model data changes so it won't ever try and access the model after the row has been removed. It is an issue and by all means investigate a solution, but there is a simple means to deal with it at a user level and I'm personally wary of the complexity and repercussions of fixing it in the views. Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Wed Jan 20 05:05:23 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 05:05:23 +0100 Subject: [Development] QtWebEngine on x86 without SSE2 Message-ID: Hi, distribution packagers may be interested in this experimental patch: http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qtwebengine-opensource-src-5.6.0-beta-no-sse2.patch which should make QtWebEngine work on 32-bit x86 (i686) CPUs without SSE2 (and also without MMX nor SSE 1), while detecting SSE2 (and SSE 1 and MMX) at runtime wherever possible. V8 is built as a shared library, twice (once with the x87 backend and once with the SSE2 one), and the GNU/Linux ld.so feature where it will automatically look under an sse2 subdirectory of the rpath for a SSE2-enabled library on SSE2 machines is taken advantage of. The floating-point issues in the media player that made Chromium upstream require SSE2 should already be worked around by this upstream commit: https://crrev.com/d2c745b13c93ecff5108bed57d8e052126715492 so x87 should really be fine again. If not, the fix would be to build individual parts of the code with -ffloat-store. I verified that this builds on GNU/Linux on i686, on x86_64 (where SSE2 is part of the baseline and can thus be assumed safely) and on ARM (where SSE2 does not exist at all and so the patch should have no effect). I have not done runtime testing yet. I did not try other platforms yet. The dual V8 trick will not work on platforms that do not have the same ld.so SSE2 feature, and my code that handles the V8 trick also hardcodes the .so extension. So you would probably have to remove those parts and just live with x87 V8. Unfortunately, since this is an override of a deliberate upstream Chromium decision and partly a cumulative revert of several upstream Chromium commits, I do not expect this to be accepted upstream, ever. Kevin Kofler From kevin.kofler at chello.at Wed Jan 20 05:16:49 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 05:16:49 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601161413.24171.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > On Saturday 16 January 2016 02:40:02 Bubke Marco wrote: >> I would prefer it we had a CoW wrapper around std vector. >> Best of both worlds. > > aka std::shared_ptr> std::shared_ptr is NOT CoW = implicitly shared, it is explicitly shared. There is no detaching, so where do you see a copy on write? A CoW wrapper around std::vector needs to at least be a QSharedDataPointer > where class VectorData : public QSharedData, public std::vector. Kevin Kofler From kevin.kofler at chello.at Wed Jan 20 05:20:36 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 05:20:36 +0100 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range References: <10845826.W58dRlntbG@tjmaciei-mobl4> Message-ID: Thiago Macieira wrote: > foreach copies; ranged for doesn't. … unless you try to use it on a non-const Qt container with usage count >1, then it will even deep-copy (detach) it! (I know you know this, but you should warn people about it.) So you need to be very careful about what you pass to ranged for. Kevin Kofler From randy.oreilly at Colorado.EDU Wed Jan 20 05:29:47 2016 From: randy.oreilly at Colorado.EDU (Randall O'Reilly) Date: Tue, 19 Jan 2016 21:29:47 -0700 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191611.40954.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <569E23BF.9050905@familiesomers.nl> <201601191500.34358.marc.mutz@kdab.com> <201601191611.40954.marc.mutz@kdab.com> Message-ID: <21CAE61F-5FAA-420D-8AAE-06977BF7B437@colorado.edu> I’m confused about how it would even be possible to contemplate abandoning the implicit sharing paradigm given how deeply embedded it is within *all* of Qt, going well beyond the container classes: http://doc.qt.io/qt-5/implicit-sharing.html Seems like Qt has adopted a core design principle here (which has proven it’s value and is simple enough to understand) and it is simply not up for discussion changing such a thing? A Qt using a completely different design principle for the containers vs. everything else would be thoroughly confusing to say the least. - Randy > On Jan 19, 2016, at 8:11 AM, Marc Mutz wrote: > > On Tuesday 19 January 2016 15:00:33 Marc Mutz wrote: >> Now: >> 1. Tell people to use auto when receiving Qt containers returned from a >> function. >> 2. Tell people to stick to the std-compatible API subset. >> 3. Deprecate Q_FOREACH and recommend range-for (+ qAsConst(), where >> needed). > > 4. Port as many internal containers (those that are not exposed in API) to std > ones. > >> In Qt 6: >> 1. Implement the containers on top of std ones, dropping CoW, providing >> simple, fast (when moving), conversion between std and Qt containers. >> 2. Deprecate the std-incompatible API subset >> 3. Remove Q_FOREACH >> 4. Deprecate qAsConst() > > 5. Use Qt containers only in the interface, not the implementation. > >> In Qt 7: >> 1. Drop all Qt container API use from the library, use only std ones. >> 2. Keep the Qt ones around as deprecated, in a separate compat library. >> 3. Drop qAsConst() >> >> In Qt 8: >> Remove the Qt ones. >> >> That easily spans 10-15 years, but at least we'd have an exit strategy. >> >> If, otoh, by Qt 6, we'd still continue doing nothing, as before, we'll >> lose another four years. > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Jan 20 06:38:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 21:38:04 -0800 Subject: [Development] QtWebEngine on x86 without SSE2 In-Reply-To: References: Message-ID: <4572177.cpkADTWvzX@tjmaciei-mobl4> On Wednesday 20 January 2016 05:05:23 Kevin Kofler wrote: > I did not try other platforms yet. The dual V8 trick will not work on > platforms that do not have the same ld.so SSE2 feature, and my code that > handles the V8 trick also hardcodes the .so extension. So you would probably > have to remove those parts and just live with x87 V8. That should not be a problem. There's no OS X without SSE2 support and on any other OS besides Linux, if you're targetting such an old computer you'll probably have to build stuff from sources anyway. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 20 06:47:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 21:47:38 -0800 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: References: <10845826.W58dRlntbG@tjmaciei-mobl4> Message-ID: <2791534.90sFzptICJ@tjmaciei-mobl4> On Wednesday 20 January 2016 05:20:36 Kevin Kofler wrote: > Thiago Macieira wrote: > > foreach copies; ranged for doesn't. > > … unless you try to use it on a non-const Qt container with usage count >1, > then it will even deep-copy (detach) it! (I know you know this, but you > should warn people about it.) So you need to be very careful about what you > pass to ranged for. Indeed. But his is the argument that convinced me: with foreach and Qt containers, you usually get the runtime performance you want, but it costs in dead code since the deep-copy code will be present (at least until we can get rid of the unsharable flag). With ranged for plus qAsConst, there's no copy code generated. So instead of: foreach (auto x, container) You'll write: for (auto x : qAsConst(container)) or if you know it's already const, you can skip the qAsConst part. This is no more and no less readable, but is more explicit about what it does. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Wed Jan 20 08:12:58 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 20 Jan 2016 08:12:58 +0100 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <2791534.90sFzptICJ@tjmaciei-mobl4> References: <10845826.W58dRlntbG@tjmaciei-mobl4> <2791534.90sFzptICJ@tjmaciei-mobl4> Message-ID: <569F337A.5010605@familiesomers.nl> Op 20/01/2016 om 06:47 schreef Thiago Macieira: > On Wednesday 20 January 2016 05:20:36 Kevin Kofler wrote: >> Thiago Macieira wrote: >>> foreach copies; ranged for doesn't. >> … unless you try to use it on a non-const Qt container with usage count >1, >> then it will even deep-copy (detach) it! (I know you know this, but you >> should warn people about it.) So you need to be very careful about what you >> pass to ranged for. > Indeed. > > But his is the argument that convinced me: with foreach and Qt containers, you > usually get the runtime performance you want, but it costs in dead code since > the deep-copy code will be present (at least until we can get rid of the > unsharable flag). With ranged for plus qAsConst, there's no copy code > generated. > > So instead of: > > foreach (auto x, container) > > You'll write: > > for (auto x : qAsConst(container)) > > or if you know it's already const, you can skip the qAsConst part. > > This is no more and no less readable, but is more explicit about what it does. Where is this qAsConst coming from? When was it introduced? Where is it documented? I can't find it in my Qt documentation. André From Lars.Knoll at theqtcompany.com Wed Jan 20 08:18:51 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 20 Jan 2016 07:18:51 +0000 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <569F337A.5010605@familiesomers.nl> References: <10845826.W58dRlntbG@tjmaciei-mobl4> <2791534.90sFzptICJ@tjmaciei-mobl4> <569F337A.5010605@familiesomers.nl> Message-ID: <3FD246E9-A9EC-450C-9277-D36BA817871C@theqtcompany.com> On 20/01/16 08:12, "Development on behalf of André Somers" wrote: > > >Op 20/01/2016 om 06:47 schreef Thiago Macieira: >> On Wednesday 20 January 2016 05:20:36 Kevin Kofler wrote: >>> Thiago Macieira wrote: >>>> foreach copies; ranged for doesn't. >>> … unless you try to use it on a non-const Qt container with usage count >1, >>> then it will even deep-copy (detach) it! (I know you know this, but you >>> should warn people about it.) So you need to be very careful about what you >>> pass to ranged for. >> Indeed. >> >> But his is the argument that convinced me: with foreach and Qt containers, you >> usually get the runtime performance you want, but it costs in dead code since >> the deep-copy code will be present (at least until we can get rid of the >> unsharable flag). With ranged for plus qAsConst, there's no copy code >> generated. >> >> So instead of: >> >> foreach (auto x, container) >> >> You'll write: >> >> for (auto x : qAsConst(container)) >> >> or if you know it's already const, you can skip the qAsConst part. >> >> This is no more and no less readable, but is more explicit about what it does. >Where is this qAsConst coming from? When was it introduced? Where is it >documented? > >I can't find it in my Qt documentation. It just got added some weeks ago, after we realised that range-for would lead to our containers detaching. So it'll be in 5.7. In general, I'm very much in favour of getting rid of foreach in favour of range-for. Cheers, Lars From thiago.macieira at intel.com Wed Jan 20 08:19:04 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 23:19:04 -0800 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <569F337A.5010605@familiesomers.nl> References: <2791534.90sFzptICJ@tjmaciei-mobl4> <569F337A.5010605@familiesomers.nl> Message-ID: <2111402.6qRAad35I6@tjmaciei-mobl4> On Wednesday 20 January 2016 08:12:58 André Somers wrote: > Where is this qAsConst coming from? When was it introduced? Where is it > documented? Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Wed Jan 20 08:37:45 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 20 Jan 2016 08:37:45 +0100 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <3FD246E9-A9EC-450C-9277-D36BA817871C@theqtcompany.com> References: <10845826.W58dRlntbG@tjmaciei-mobl4> <2791534.90sFzptICJ@tjmaciei-mobl4> <569F337A.5010605@familiesomers.nl> <3FD246E9-A9EC-450C-9277-D36BA817871C@theqtcompany.com> Message-ID: <569F3949.5060809@familiesomers.nl> Op 20/01/2016 om 08:18 schreef Knoll Lars: >> Where is this qAsConst coming from? When was it introduced? Where is it >> documented? >> >> I can't find it in my Qt documentation. > It just got added some weeks ago, after we realised that range-for would lead to our containers detaching. So it'll be in 5.7. > > In general, I'm very much in favour of getting rid of foreach in favour of range-for. Perhaps in the meantime the foreach macro could just be changed to actually expand to a range-for? André From thiago.macieira at intel.com Wed Jan 20 08:47:16 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 19 Jan 2016 23:47:16 -0800 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <569F3949.5060809@familiesomers.nl> References: <3FD246E9-A9EC-450C-9277-D36BA817871C@theqtcompany.com> <569F3949.5060809@familiesomers.nl> Message-ID: <1889522.X5K43Sqozy@tjmaciei-mobl4> On Wednesday 20 January 2016 08:37:45 André Somers wrote: > Op 20/01/2016 om 08:18 schreef Knoll Lars: > >> Where is this qAsConst coming from? When was it introduced? Where is it > >> documented? > >> > >> I can't find it in my Qt documentation. > > > > It just got added some weeks ago, after we realised that range-for would > > lead to our containers detaching. So it'll be in 5.7. > > > > In general, I'm very much in favour of getting rid of foreach in favour of > > range-for. > Perhaps in the meantime the foreach macro could just be changed to > actually expand to a range-for? It can't. I tried a few years ago and it's not compatible. Ranged for requires that the first part (before the colon) be a declaration. Foreach allows an existing variable. Foreach also requires creating a copy and that causes the dangling reference issue we discussed before. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Wed Jan 20 11:58:59 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 20 Jan 2016 11:58:59 +0100 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <2111402.6qRAad35I6@tjmaciei-mobl4> References: <569F337A.5010605@familiesomers.nl> <2111402.6qRAad35I6@tjmaciei-mobl4> Message-ID: <201601201158.59836.marc.mutz@kdab.com> On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote: > On Wednesday 20 January 2016 08:12:58 André Somers wrote: > > Where is this qAsConst coming from? When was it introduced? Where is it > > documented? > > Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs. It was intended as private API for use within Qt. If the sentiment is that it should be public, I'll add proper docs. If the sentiment is also that we should start to discourage the use of Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + range-for. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Eike.Ziller at theqtcompany.com Wed Jan 20 11:08:16 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Wed, 20 Jan 2016 10:08:16 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601192240.40519.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <8EA8AC75-5623-42CD-B0B7-5408CF384672@digia.com> <569E86E6.8010104@taschenorakel.de> <201601192240.40519.marc.mutz@kdab.com> Message-ID: <4F40F6A1-9A22-4D23-99BC-69CCEAC56965@theqtcompany.com> > On Jan 19, 2016, at 10:40 PM, Marc Mutz wrote: > > On Tuesday 19 January 2016 19:56:38 Mathias Hasselmann wrote: >> Am 19.01.2016 um 15:21 schrieb Ziller Eike: >>>> On Jan 19, 2016, at 16:09, Marc Mutz wrote: >>>> I doubt many people actively use the fact that Qt containers are cheap >>>> to copy. >>> >>> Each and every developer that uses Qt uses the fact that Qt containers >>> are cheap to “copy" >>> >>> class A >>> { >>> >>> public: >>> QVector something() const; >>> >>> private: >>> QVector m_something; >>> >>> }; >>> >>> QVector A::something() const >>> { >>> >>> return m_something; >>> >>> } >> >> Good point Eike, thank you. >> >> Marc, wow would one avoid invocation of the copy constructor here? >> Without handing out pointers or references. Of course. > > It's funny how the same people who think nothing of the per-element memory > allocation of QList suddenly become vehement performance critics when it comes > to CoW :) Well, passing around a list and doing something based on its elements happens a lot more than actually constructing lists. But the point is not that you cannot write efficient code with std containers, but that changing from CoW to non-CoW _will_ potentially effect basically all existing Qt based code. Even if only N% of the uses are actually noticeably effected, these still need to be found and fixed. Any fix in the API will require investigating and potentially fixing the callers of that API. If a Qt-based product is a library, that responsibility is then pushed to Qt’s customers’ customers. We still haven’t even managed to automatically test for performance regressions in _Qt_, afaik? I think that the argument that people will notice performance issues that matter and fix them, and the rest don’t matter or will be found by some tool, is too optimistic. > It likely just doesn't matter, the rest of the C++ community has been working > with containers that don't do CoW for the past 20 years and have survived. > > In those cases where it does matter, you'd return by const-&. Or an > array_view. And no, that doesn't restrict your freedom to implement the > function in any meaningful way, because you can always keep a caching mutable > member to hold the result for the next call to the function (memoisation or > however it's called), without any loss except the space required for the > member. That awfully sounds like re-implementing CoW logic by hand everywhere where someone providing an API thinks it might be worth the effort. > What about non-arrays? By the time we get around to all this, there will be no > containers other than array-compatible ones left, because nothing else will > provide the required speed. And if there are, you can write a _view for those, > too. > > -- > Marc Mutz > | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Martin.Smith at theqtcompany.com Wed Jan 20 11:16:57 2016 From: Martin.Smith at theqtcompany.com (Smith Martin) Date: Wed, 20 Jan 2016 10:16:57 +0000 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <201601201158.59836.marc.mutz@kdab.com> References: <569F337A.5010605@familiesomers.nl> <2111402.6qRAad35I6@tjmaciei-mobl4>, <201601201158.59836.marc.mutz@kdab.com> Message-ID: Here is a JIRA task for it: https://bugreports.qt.io/browse/QTBUG-50548 ________________________________________ From: Development on behalf of Marc Mutz Sent: Wednesday, January 20, 2016 11:58 AM To: development at qt-project.org Subject: Re: [Development] QStringLiteral vs QLatin1String , foreach vs for range On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote: > On Wednesday 20 January 2016 08:12:58 André Somers wrote: > > Where is this qAsConst coming from? When was it introduced? Where is it > > documented? > > Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs. It was intended as private API for use within Qt. If the sentiment is that it should be public, I'll add proper docs. If the sentiment is also that we should start to discourage the use of Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + range-for. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at theqtcompany.com Wed Jan 20 11:17:02 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 20 Jan 2016 10:17:02 +0000 Subject: [Development] QStringLiteral vs QLatin1String , foreach vs for range In-Reply-To: <201601201158.59836.marc.mutz@kdab.com> References: <569F337A.5010605@familiesomers.nl> <2111402.6qRAad35I6@tjmaciei-mobl4> <201601201158.59836.marc.mutz@kdab.com> Message-ID: <01C34874-6C72-43B7-8CD9-2926F1C1ED86@theqtcompany.com> On 20/01/16 11:58, "Development on behalf of Marc Mutz" wrote: >On Wednesday 20 January 2016 08:19:04 Thiago Macieira wrote: >> On Wednesday 20 January 2016 08:12:58 André Somers wrote: >> > Where is this qAsConst coming from? When was it introduced? Where is it >> > documented? >> >> Commit 264c72837d6ff717a248dd180c2dfb45391c6aab, in dev. No api docs. > >It was intended as private API for use within Qt. If the sentiment is that it >should be public, I'll add proper docs. > >If the sentiment is also that we should start to discourage the use of >Q_FOREACH, then I'll add a \note to its docs pointing at qAsConst + range-for. +1 to both. Let's encourage people to use range-for and qAsConst instead of foreach. Cheers, Lars From milian.wolff at kdab.com Wed Jan 20 11:46:05 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Wed, 20 Jan 2016 11:46:05 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <4571990.RWVZgVEVvP@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <4571990.RWVZgVEVvP@tjmaciei-mobl4> Message-ID: <5173998.qhkvRx402d@milian-kdab2> On Tuesday, January 19, 2016 9:37:39 AM CET Thiago Macieira wrote: > On Tuesday 19 January 2016 17:48:48 Giuseppe D'Angelo wrote: > > On Tue, Jan 19, 2016 at 5:07 PM, Thiago Macieira > > > > > wrote: > > > std::string someString() > > > { > > > > > > return constexpr_string("foo"); > > > > > > } > > > > "constexpr_string" should very likely return a const std::string, so this > > > > will copy and not move... > > Right, which would make the entire thing pointless. It should remove a `const std::string&` and then it is not pointless. -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts From Marco.Bubke at theqtcompany.com Wed Jan 20 11:48:20 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Wed, 20 Jan 2016 10:48:20 +0000 Subject: [Development] What kind of airplane we want to build? Message-ID: Hello After the exciting discussions in the last time with all the energy spend on them I want to try to make a short summary. Maybe we can transform the heat on some steam to progress further. ;-) I think many feel that C++ is rapidly changing. With C++ 17 on the horizon there is some excitement but also fear that Qt will not stay relevant if we not adapt. But there are arguments too about existing users who would be left in the cold we we change to much. So let use an airplane as metaphor. We built a fine piston engine airplane on that little bit cumbersome piston engine called C++. But now we see Jet engines coming up but all our technology is built the old piston engine technology so the adaption of jet engines is not that cheap. The jet engines are different but we are not sure about their advantages but we are sure it would be a big investment to change to them. So people propose different designs. Some say we should minimize investments and only apapt slowly other proposed to build a hyper mach airplane. The metaphor is not perfect but I hope it is productive enough. I think the big elephant is the massive move of the processing technology to multi cores, massive multi cores formerly known as GPUs and the new parallel mechanism which are proposed to utilize them. Resumable functions, ranges, parallel stl and how they all are called. This will change how C++ looks but how can we change Qt in that picture to utilize this new technologies. I think it would be productive for the discussion to build story of what we want to do. A story of the big picture. Maybe as a first step we can show how we tackle problems with Qt 5 and what are the proposed technologies in the future C++ standard. Maybewe see that we don't have to change so much. Maybe we find out the change would be so massive that we cannot call it Qt 6 anymore. There are many maybes because the future is uncertain but we handled uncertainty in the past so why we should not do it in the future? I really believe that before we make little changes like the containers etc. we have to find a story. A story how the future Qt should look, a story for the long run. In my opinion we have to build the story TOGETHER and this story should be build on actual experience and measured facts. We should be careful about emotions like doubt, fear or excitement. I think we should be stay calm. So we can try now this new C++ prototypes, find out how they fit with our technology like signal/slots, CoW etc.. And later if they are getting momentum we can provide our magic sauce on top to make our users more productive. And if we want change Qt much we have to provide a technology to make the adaptation of our users easy and reliable. So the gain should be bigger than the cost. I think Clang based technologies provide us some possible tools but we have to find out. It is not only about providing the tool kit for new shine projects but for existing ones too. Some maybe they don't want to change and that is a respectable decision but for the user who want and need to adapt we should make it easy. I know this sounds like common sense but after all the discussions in last time I think we should step back and get a bigger picture before starting detailed discussions again. So lets go out, start prototypes, gain experience and come back to fruitful discussions. ;-) -- Sent from cellphone, sorry for the typos From marc.mutz at kdab.com Wed Jan 20 15:12:48 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 20 Jan 2016 15:12:48 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: Message-ID: <201601201512.48597.marc.mutz@kdab.com> On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote: > I think it would be productive for the discussion to build story of what we > want to do. A story of the big picture. Maybe as a first step we can show > how we tackle problems with Qt 5 and what are the proposed technologies in > the future C++ standard. For me, Qt always was "the C++ standard library that C++ lacked". Ever since Qt 3, it also integrated pretty well with the rest of the standard library. That was easy, because pretty much the only thing that the standard library had and Qt didn't were the algorithms, and Qt and the STL algorithms integrated well. And there were conversion functions for pretty much everything to/from std. We even deprecated our algorithms when we started requiring full C++98 support in 5.0. We used to roll our own atomics, but dropped them in 5.7 when we required partial C++11 support. We rolled our own foreach, and now it looks like we're dropping it in favour of range-for. I would like that trend to continue. The likely next candidates are threads, futures and locks. Now that C++ punches out a new standard every three years, I would change that into "Qt is the part of the C++ standard library that C++ sill lacks". I would like Qt to continue to integrate well with the standard library and phase out its own solutions as the standard library catches up. We have been doing that in the past. It's just as C++ standardisation accelerates, so will the need to phase out Qt features that got superseded. I perceive, however, that for many people, Qt is what makes them forget they're working on C++, a language they would not otherwise poke at with a long stick. They probably also cannot tolerate writing std::sort(v.begin(), v.end()) instead of qSort(v). But Qt is available in D and Python, too, so ... why do they use C++ if they so hate it? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From tor.arne.vestbo at theqtcompany.com Wed Jan 20 15:03:04 2016 From: tor.arne.vestbo at theqtcompany.com (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Wed, 20 Jan 2016 15:03:04 +0100 Subject: [Development] OS X SDK set via configure is not used during build (dev branch) In-Reply-To: References: <1459106.uDgAvuznkS@tjmaciei-mobl4> Message-ID: <569F9398.5060609@theqtcompany.com> Host tools will build with the latest SDK you have, regardless of what you pass to -sdk, which may explain what you're seeing. You don't need to pass an explicit -sdk macosx10.11 though, just skip the -sdk argument entirely and make sure your .qmake.* files are wiped. We should really just remove the -sdk argument and always build with the latest SDK. Is there any reason not to? tor arne On 13/01/16 02:14, Mikkel Krautz wrote: > On Wed, Jan 13, 2016 at 12:55 AM, Thiago Macieira > wrote: >> On Wednesday 13 January 2016 00:36:14 Mikkel Krautz wrote: >>> Hi, >>> >>> I'm currently on 10.10, Yosemite, using Xcode 7.1.1 (as of this writing). >>> >>> This version of Xcode only ships with the 10.11 SDK. But I am on 10.10. >>> >>> When I built Qt (dev branch), by passing -sdk macosx10.11 -- the only >>> SDK I have -- to configure, I get build failures. >>> >>> Inspecting the compiler flags, I see that the OS X 10.10 SDK is being >>> used (-isysroot, etc.). >> >> Remove all .qmake.{cache,super} files you may have. The build stores the >> version of the SDK it found when you first ran qmake and won't check again. >> This wasn't a problem in the past because Apple used to provide the same SDK >> for more than one version of Xcode, so you were unlikely to upgrade and lose >> the SDK you last had. > > I am pretty sure I had the files cleaned before trying this, so I tried again: > > $ cd qt5 > $ git submodule foreach --recursive git clean -dfx -f > $ find . | grep qmake.cache > ./qtbase/qmake/cachekeys.h > ./qtbase/tests/auto/tools/qmake/testdata/export_across_file_boundaries/.qmake.cache > $ find . | grep qmake.super > $ > > Building: > > $ cd qtbase > $ OPENSSL_LIBS="-L${MUMBLE_PREFIX}/lib -lssl -lcrypto" ./configure > -developer-build -opensource -nomake examples -sdk macosx10.11 -I > ${MUMBLE_PREFIX}/include -openssl-linked > $ make > > Full output at https://gist.github.com/mkrautz/2041003a8aeb63a792b8 > > Initially, I had MAKEFLAGS set to -j8. > > When I did that, I observed that *some* clang++ invocations correctly > used the 10.11 SDK. > > Here's me running "make -j8", right after I ran "make": > > https://gist.github.com/mkrautz/d96d5329807addf8abc2 > > So, some things are using the correct sysroot. > From bo at vikingsoft.eu Wed Jan 20 15:25:03 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Wed, 20 Jan 2016 15:25:03 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <201601201512.48597.marc.mutz@kdab.com> References: <201601201512.48597.marc.mutz@kdab.com> Message-ID: <569F98BF.50604@vikingsoft.eu> Den 20-01-2016 kl. 15:12 skrev Marc Mutz: > On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote: >> I think it would be productive for the discussion to build story of what we >> want to do. A story of the big picture. Maybe as a first step we can show >> how we tackle problems with Qt 5 and what are the proposed technologies in >> the future C++ standard. > > For me, Qt always was "the C++ standard library that C++ lacked". Ever since > Qt 3, it also integrated pretty well with the rest of the standard library. > That was easy, because pretty much the only thing that the standard library > had and Qt didn't were the algorithms, and Qt and the STL algorithms > integrated well. And there were conversion functions for pretty much > everything to/from std. > > We even deprecated our algorithms when we started requiring full C++98 support > in 5.0. > > We used to roll our own atomics, but dropped them in 5.7 when we required > partial C++11 support. We rolled our own foreach, and now it looks like we're > dropping it in favour of range-for. > > I would like that trend to continue. The likely next candidates are threads, > futures and locks. It sounds like everyone completely agrees on this. But that doesn't mean it has to happen for every single class that might be implemented in STL. > Now that C++ punches out a new standard every three years, I would change that > into "Qt is the part of the C++ standard library that C++ sill lacks". I would > like Qt to continue to integrate well with the standard library and phase out > its own solutions as the standard library catches up. > > We have been doing that in the past. It's just as C++ standardisation > accelerates, so will the need to phase out Qt features that got superseded. I agree with this, but there might be problems with the release cycle of Qt here. It's impossible to keep backwards compatibility while we switch to new C++ versions. So either the Qt major releases will start happening more often, or there are features that will just have to wait. Thiagos list of things he has already implemented for Qt 6 is a good example of this. > I perceive, however, that for many people, Qt is what makes them forget > they're working on C++, a language they would not otherwise poke at with a > long stick. They probably also cannot tolerate writing std::sort(v.begin(), > v.end()) instead of qSort(v). But Qt is available in D and Python, too, so ... > why do they use C++ if they so hate it? Why do you think people hate C++? I love C++ but I hate the string classes. I like some part of the std containers, I don't like their API. In the same category of argument, I love Qt, but I hate that we don't use exceptions. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From Morten.Sorvig at theqtcompany.com Wed Jan 20 15:43:13 2016 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Wed, 20 Jan 2016 14:43:13 +0000 Subject: [Development] extending QtMacExtras? In-Reply-To: <28505033.zKFNZO87e7@patux> References: <28505033.zKFNZO87e7@patux> Message-ID: <5569B468-B537-47F3-9E0A-801418E1A738@digia.com> > On 18 Jan 2016, at 11:02, René J.V. Bertin wrote: > > > One thing that's really missing from Qt at the moment is a way for an application that is not the foreground application to post a window in the foreground (cf. also my thread on extending QProcess). To my knowledge this can only be done by forcing the application to the foreground using the same technique also used by the QCocoaIntegration ctor. Crude, but sometimes required. I still don’t understand what the general-purpose API in Qt would do. Perhaps you should just write a prototype implementation? Though I’m skeptical about adding a complex solution for this issue to Qt. I don’t want to launch a background process. > > A variant could take a WId and activate the application owning the corresponding window or widget. I'm not sure to what extent that would be trivial or even possible to implement (Jake? Morten?). It would allow to simulate things that can currently be done (only?) on Unix/X11: > 1) hand off a request from a foreground application ("A") to a background process or daemon ("D"), providing it a target WId But if WIds can’t be used in cross-application contexts (which is true for Qt on OS X, they are NSView pointers), then you can’t send them to a background process either. (?) Regards, Morten From Eike.Ziller at theqtcompany.com Wed Jan 20 15:48:58 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Wed, 20 Jan 2016 14:48:58 +0000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <201601201512.48597.marc.mutz@kdab.com> References: <201601201512.48597.marc.mutz@kdab.com> Message-ID: <5DE56EBC-DBE4-44C6-988A-235267FF7749@theqtcompany.com> > On Jan 20, 2016, at 3:12 PM, Marc Mutz wrote: > > On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote: >> I think it would be productive for the discussion to build story of what we >> want to do. A story of the big picture. Maybe as a first step we can show >> how we tackle problems with Qt 5 and what are the proposed technologies in >> the future C++ standard. > > For me, Qt always was "the C++ standard library that C++ lacked". Ever since > Qt 3, it also integrated pretty well with the rest of the standard library. > That was easy, because pretty much the only thing that the standard library > had and Qt didn't were the algorithms, and Qt and the STL algorithms > integrated well. And there were conversion functions for pretty much > everything to/from std. > > We even deprecated our algorithms when we started requiring full C++98 support > in 5.0. > > We used to roll our own atomics, but dropped them in 5.7 when we required > partial C++11 support. We rolled our own foreach, and now it looks like we're > dropping it in favour of range-for. > > I would like that trend to continue. The likely next candidates are threads, > futures and locks. +1 > Now that C++ punches out a new standard every three years, I would change that > into "Qt is the part of the C++ standard library that C++ sill lacks". I would > like Qt to continue to integrate well with the standard library and phase out > its own solutions as the standard library catches up. > > We have been doing that in the past. It's just as C++ standardisation > accelerates, so will the need to phase out Qt features that got superseded. > > I perceive, however, that for many people, Qt is what makes them forget > they're working on C++, a language they would not otherwise poke at with a > long stick. They probably also cannot tolerate writing std::sort(v.begin(), > v.end()) instead of qSort(v). I find it much nicer and more readable if I can just write sort(v). Or "const List foos = transformed(myThings, &Thing::foo);" instead of "List foos; std::transform(myThings.begin(), myThings.end(), std::back_inserter(foos), std::mem_fn(&Thing::foo));” (notice that “foos” is also not const in the “pure" std version) We started some experiments with convenience wrappers for std algorithms for use in Qt Creator when we started requiring C++11: http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h > But Qt is available in D and Python, too, so ... > why do they use C++ if they so hate it? Maybe they don’t hate it, but still wished it had a less verbose API if you don’t need the verbosity. Br, Eike -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From jedrzej.nowacki at theqtcompany.com Wed Jan 20 16:03:00 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Wed, 20 Jan 2016 16:03:00 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601191351.57428.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <2119145.JenKLMHALe@agathebauer> <201601191351.57428.marc.mutz@kdab.com> Message-ID: <8785650.BTg5crU00k@42> On Tuesday 19 of January 2016 13:51:56 Marc Mutz wrote: > On Tuesday 19 January 2016 11:15:43 Milian Wolff wrote: > > On Dienstag, 19. Januar 2016 11:51:42 CET Marc Mutz wrote: > > > I missed one: > > > > > > On Monday 18 January 2016 23:43:37 Marc Mutz wrote: > > > > #include > > > > #include > > > > > > > > int main() { > > > > > > > > QVector l; > > > > int oldC = l.capacity(); > > > > for (int i = 0; i < 10000000; ++i) { > > > > > > > > char buf[std::numeric_limits::digits + 1]; > > > > sprintf(buf, "%d", i); > > > > l.push_back(buf); > > > > int newC = l.capacity(); > > > > if (newC != oldC) > > > > > > > > qDebug("%d", newC); > > > > > > > > oldC = newC; > > > > > > > > } > > > > > > > > } > > > > > > > > $ time ./test > > > > > > > > real 0m1.769s > > > > user 0m1.572s > > > > sys 0m0.192s > > > > > > Same with std::vector: > > > > > > real 0m1.776s > > > user 0m1.616s > > > sys 0m0.156s > > > > > > > best of three runs, core i7-2720QM, GCC 5.3 > > > > > > Ditto. > > > > > > So... is realloc actually the optimisation everyone (incl. me) expected > > > it to be? > > > > Did you run it through a profiler? Where is the time actually spent? > > No. It's not the IO, though. Removing the qDebug() and capacity tracking, it > performs the same, within error margins. Hi, I can not reproduce the numbers on gcc version 5.3.1 20151219 (Debian 5.3.1-4). But there is a bug in the benchmark, std::vector and QVector have different grow model, at least I do not see the same count of qDebug messages. In addition I think the benchmark may be affected by heap allocation executed on each l.push_back. The feature is also used in QVariant which tries to avoid allocations. That was confirmed as important optimization. Cheers, Jędrek From andre at familiesomers.nl Wed Jan 20 16:03:17 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Wed, 20 Jan 2016 16:03:17 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <5DE56EBC-DBE4-44C6-988A-235267FF7749@theqtcompany.com> References: <201601201512.48597.marc.mutz@kdab.com> <5DE56EBC-DBE4-44C6-988A-235267FF7749@theqtcompany.com> Message-ID: <569FA1B5.9090007@familiesomers.nl> Op 20/01/2016 om 15:48 schreef Ziller Eike: >> On Jan 20, 2016, at 3:12 PM, Marc Mutz wrote: >> >> On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote: >>> I think it would be productive for the discussion to build story of what we >>> want to do. A story of the big picture. Maybe as a first step we can show >>> how we tackle problems with Qt 5 and what are the proposed technologies in >>> the future C++ standard. >> For me, Qt always was "the C++ standard library that C++ lacked". Ever since >> Qt 3, it also integrated pretty well with the rest of the standard library. >> That was easy, because pretty much the only thing that the standard library >> had and Qt didn't were the algorithms, and Qt and the STL algorithms >> integrated well. And there were conversion functions for pretty much >> everything to/from std. >> >> We even deprecated our algorithms when we started requiring full C++98 support >> in 5.0. >> >> We used to roll our own atomics, but dropped them in 5.7 when we required >> partial C++11 support. We rolled our own foreach, and now it looks like we're >> dropping it in favour of range-for. >> >> I would like that trend to continue. The likely next candidates are threads, >> futures and locks. > +1 > >> Now that C++ punches out a new standard every three years, I would change that >> into "Qt is the part of the C++ standard library that C++ sill lacks". I would >> like Qt to continue to integrate well with the standard library and phase out >> its own solutions as the standard library catches up. >> >> We have been doing that in the past. It's just as C++ standardisation >> accelerates, so will the need to phase out Qt features that got superseded. >> >> I perceive, however, that for many people, Qt is what makes them forget >> they're working on C++, a language they would not otherwise poke at with a >> long stick. They probably also cannot tolerate writing std::sort(v.begin(), >> v.end()) instead of qSort(v). > I find it much nicer and more readable if I can just write sort(v). > > Or "const List foos = transformed(myThings, &Thing::foo);" > instead of "List foos; std::transform(myThings.begin(), myThings.end(), std::back_inserter(foos), std::mem_fn(&Thing::foo));” > (notice that “foos” is also not const in the “pure" std version) > > We started some experiments with convenience wrappers for std algorithms for use in Qt Creator when we started requiring C++11: > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h Nice, thanks for the link. At a previous job, I ended up defining a macro called all (and a constAll) that just expanded to begin(v), end(v). That already helped in how verbose the calls to algorithms looked. std::sort(all(v)) vs std::sort(begin(v), end(v)); Sure, a macro is ugly, but it did the trick. When you need more control, you can specify begin and end explicitly, of course. > >> But Qt is available in D and Python, too, so ... >> why do they use C++ if they so hate it? > Maybe they don’t hate it, but still wished it had a less verbose API if you don’t need the verbosity. Indeed. After watching some courses by Stephanov, I actually learned to appreciate it. But I stil dislike the API in many places. C++11 makes much of the std easier to digest though. André From lkorbel at milosolutions.com Wed Jan 20 16:47:34 2016 From: lkorbel at milosolutions.com (=?UTF-8?Q?=C5=81ukasz_Korbel?=) Date: Wed, 20 Jan 2016 16:47:34 +0100 Subject: [Development] Qt3d: Scene32d framebuffer size Message-ID: Hi! I'm not sure of the source of problem so first quick introduction: 1. I want to set Camera properly to show object in Scene3d which is smaller then QWindow. 2. I want to make proper mapping between qml view 2d coordinates and scene 3d coordinates (for example place some 3d object at location pointed by mouse click). I've solved those two issue in example qml code attached to the message. This example lead to my actual question: It looks like Scene3d frame buffer is somehow bound to dimension of QWindow. So If I set Scene3d to be smaller it shows only fragment of framebuffer. More precisely its part cut from left-bottom corner of buffer matching scene size. Does it expected behaviour for this class? It leads to few "funny", additional computations in order to set camera properly. If I making some mistake by mentioning frame bufffer in this context then I apologize. Still hope that my example explains what is a problem. I guess it is worth discussing with someone involved in development and maybe its not a bug, so I've raised topic here. Regards, *Łukasz Korbel * Senior Software Developer Email: lkorbel at milosolutions.com Skype: lukasz_korbel *Milo Solutions* www.milosolutions.com | Facebook | Twitter Disclaimer: This e-mail and any attachments contain information that may be privileged or confidential and is the property of Milo Solutions. If you are not the intended recipient, please notify me immediately by replying to this e-mail, and then delete it. Any unauthorised dissemination, distribution, copying or use of this communication is strictly prohibited. The contents of an attachment to this e-mail may contain software viruses, which could damage your own computer system. Although this e-mail and any files attached to it may have been checked with virus detection software before transmission you should carry out your own virus checks before opening the attachment. No liability can be accepted for any damage which you may sustain as a result of software viruses. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.qml Type: text/x-qml Size: 3295 bytes Desc: not available URL: From stephen.kelly at ableton.com Wed Jan 20 17:11:45 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Wed, 20 Jan 2016 17:11:45 +0100 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: References: <569E375D.4080709@ableton.com> <569E60BE.2020804@ableton.com> Message-ID: <569FB1C1.3080601@ableton.com> On 20/01/16 01:23, Andrew den Exter wrote: > On Wed, Jan 20, 2016 at 2:13 AM, Stephen Kelly > > wrote: > > The solution could be to cache data retrieved from the model. > > > That's a more complex solution than you might think. It's a pretty > popular pattern to populate a model with QObjects for example and with > a naive cache of QVariants what was an admittedly annoying binding > evaluation error becomes a much more severe dereference of a dangling > pointer. > Indeed. What I have been considering is limiting the types which are cached to those which can directly be put into a user interface element - built in types like strings, numbers, colors etc. Maybe even any gadget. It could be possible to special case model data which is-a OQbject pointer (QMetaType has API for that) and cache that too, but then we'd just be caching null pointers, so thinking this through leads me to think that's not useful. That's the kind of design discussion that I would like to have in this thread though (as it is easier in email than in gerrit), so thanks for that. > And there are the obvious runtime costs to building and maintaining a > cache that is of little or no use to most people most of the time, > which is I think a strong argument for it being an off by default > feature if implemented. > I think the cost would need to be measured before letting it influence design decisions. We are not talking about monstrous amounts of data. > If you do have this problem, right now the solution is to bind the > model value to a property in your delegate and use the property in > your binding. Indeed. That is an ad-hoc cache that a client can implement. It doesn't really scale well as a design, or as guidance for a team of developers. > The property binding will only be re-evaluated when the model data > changes so it won't ever try and access the model after the row has > been removed. > Yes, semantically this is quite similar to what I propose, but is not scalable. > It is an issue and by all means investigate a solution, but there is a > simple means to deal with it at a user level and I'm personally wary > of the complexity and repercussions of fixing it in the views. I don't think that solution is * intuitive * maintainable in a changing team * easy to get right/hard to get wrong so I don't really agree that it is 'simple'. Thanks, Steve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Jan 20 18:47:15 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 20 Jan 2016 18:47:15 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <569FA1B5.9090007@familiesomers.nl> References: <5DE56EBC-DBE4-44C6-988A-235267FF7749@theqtcompany.com> <569FA1B5.9090007@familiesomers.nl> Message-ID: <201601201847.16374.marc.mutz@kdab.com> On Wednesday 20 January 2016 16:03:17 André Somers wrote: > Op 20/01/2016 om 15:48 schreef Ziller Eike: > >> On Jan 20, 2016, at 3:12 PM, Marc Mutz wrote: > >> > >> On Wednesday 20 January 2016 11:48:20 Bubke Marco wrote: > >>> I think it would be productive for the discussion to build story of > >>> what we want to do. A story of the big picture. Maybe as a first step > >>> we can show how we tackle problems with Qt 5 and what are the proposed > >>> technologies in the future C++ standard. > >> > >> For me, Qt always was "the C++ standard library that C++ lacked". Ever > >> since Qt 3, it also integrated pretty well with the rest of the > >> standard library. That was easy, because pretty much the only thing > >> that the standard library had and Qt didn't were the algorithms, and Qt > >> and the STL algorithms integrated well. And there were conversion > >> functions for pretty much everything to/from std. > >> > >> We even deprecated our algorithms when we started requiring full C++98 > >> support in 5.0. > >> > >> We used to roll our own atomics, but dropped them in 5.7 when we > >> required partial C++11 support. We rolled our own foreach, and now it > >> looks like we're dropping it in favour of range-for. > >> > >> I would like that trend to continue. The likely next candidates are > >> threads, futures and locks. > > > > +1 > > > >> Now that C++ punches out a new standard every three years, I would > >> change that into "Qt is the part of the C++ standard library that C++ > >> sill lacks". I would like Qt to continue to integrate well with the > >> standard library and phase out its own solutions as the standard > >> library catches up. > >> > >> We have been doing that in the past. It's just as C++ standardisation > >> accelerates, so will the need to phase out Qt features that got > >> superseded. > >> > >> I perceive, however, that for many people, Qt is what makes them forget > >> they're working on C++, a language they would not otherwise poke at with > >> a long stick. They probably also cannot tolerate writing > >> std::sort(v.begin(), v.end()) instead of qSort(v). > > > > I find it much nicer and more readable if I can just write sort(v). > > > > Or "const List foos = transformed(myThings, &Thing::foo);" > > instead of "List foos; std::transform(myThings.begin(), myThings.end(), > > std::back_inserter(foos), std::mem_fn(&Thing::foo));” (notice that > > “foos” is also not const in the “pure" std version) > > > > We started some experiments with convenience wrappers for std algorithms > > for use in Qt Creator when we started requiring C++11: > > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/alg > > orithm.h > > Nice, thanks for the link. > > At a previous job, I ended up defining a macro called all (and a > constAll) that just expanded to begin(v), end(v). That already helped in > how verbose the calls to algorithms looked. > > std::sort(all(v)) > > vs > > std::sort(begin(v), end(v)); > > Sure, a macro is ugly, but it did the trick. When you need more control, > you can specify begin and end explicitly, of course. > > >> But Qt is available in D and Python, too, so ... > >> > >> why do they use C++ if they so hate it? > > > > Maybe they don’t hate it, but still wished it had a less verbose API if > > you don’t need the verbosity. > > Indeed. After watching some courses by Stephanov, I actually learned to > appreciate it. But I stil dislike the API in many places. C++11 makes > much of the std easier to digest though. Then now is the time to chime in on the C++ ranges proposal and voice your opinion(s). "Let him speak now or forever hold his peace" :) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Wed Jan 20 18:56:32 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 20 Jan 2016 18:56:32 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <8785650.BTg5crU00k@42> References: <201601051352.06816.marc.mutz@kdab.com> <201601191351.57428.marc.mutz@kdab.com> <8785650.BTg5crU00k@42> Message-ID: <201601201856.33182.marc.mutz@kdab.com> On Wednesday 20 January 2016 16:03:00 Jędrzej Nowacki wrote: > On Tuesday 19 of January 2016 13:51:56 Marc Mutz wrote: > > On Tuesday 19 January 2016 11:15:43 Milian Wolff wrote: > > > On Dienstag, 19. Januar 2016 11:51:42 CET Marc Mutz wrote: > > > > I missed one: > > > > > > > > On Monday 18 January 2016 23:43:37 Marc Mutz wrote: > > > > > #include > > > > > #include > > > > > > > > > > int main() { > > > > > > > > > > QVector l; > > > > > int oldC = l.capacity(); > > > > > for (int i = 0; i < 10000000; ++i) { > > > > > > > > > > char buf[std::numeric_limits::digits + 1]; > > > > > sprintf(buf, "%d", i); > > > > > l.push_back(buf); > > > > > int newC = l.capacity(); > > > > > if (newC != oldC) > > > > > > > > > > qDebug("%d", newC); > > > > > > > > > > oldC = newC; > > > > > > > > > > } > > > > > > > > > > } > > > > > > > > > > $ time ./test > > > > > > > > > > real 0m1.769s > > > > > user 0m1.572s > > > > > sys 0m0.192s > > > > > > > > Same with std::vector: > > > > > > > > real 0m1.776s > > > > user 0m1.616s > > > > sys 0m0.156s > > > > > > > > > best of three runs, core i7-2720QM, GCC 5.3 > > > > > > > > Ditto. > > > > > > > > So... is realloc actually the optimisation everyone (incl. me) > > > > expected it to be? > > > > > > Did you run it through a profiler? Where is the time actually spent? > > > > No. It's not the IO, though. Removing the qDebug() and capacity tracking, > > it performs the same, within error margins. > > Hi, > > I can not reproduce the numbers on gcc version 5.3.1 20151219 (Debian > 5.3.1-4). But there is a bug in the benchmark, std::vector and QVector have > different grow model, at least I do not see the same count of qDebug > messages. In addition I think the benchmark may be affected by heap > allocation executed on each l.push_back. That's weird. qAllocMore() uses 2^N-const, const > 0, in my tests, while std::vector uses 2^N. I specifically used a count that is a power of 10 so that this difference would not cause a different number of reallocations: 1 3 7 15 31 63 127 255 511 1023 2047 4095 8191 16383 32767 65535 131071 262143 524287 1048575 2097151 4194303 8388607 16777215 (for QVector with a movable std::string) 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 65536 131072 262144 524288 1048576 2097152 4194304 8388608 16777216 (for std::vector) > The feature is also used in QVariant which tries to avoid allocations. > That was confirmed as important optimization. Well, halving the time spent on reallocation is an optimisation, I guess. It's just that that particular problem is easily worked around with reserve(). QVariant is a different matter, indeed. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From kde at carewolf.com Wed Jan 20 18:09:24 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Wed, 20 Jan 2016 18:09:24 +0100 Subject: [Development] QtWebEngine on x86 without SSE2 In-Reply-To: References: Message-ID: <201601201809.25023.kde@carewolf.com> On Wednesday 20 January 2016, Kevin Kofler wrote: > Hi, > > distribution packagers may be interested in this experimental patch: > http://pkgs.fedoraproject.org/cgit/rpms/qt5-qtwebengine.git/tree/qtwebengin > e-opensource-src-5.6.0-beta-no-sse2.patch which should make QtWebEngine > work on 32-bit x86 (i686) CPUs without SSE2 (and also without MMX nor SSE > 1), while detecting SSE2 (and SSE 1 and MMX) at runtime wherever possible. > V8 is built as a shared library, twice (once with the x87 backend and once > with the SSE2 one), and the GNU/Linux ld.so feature where it will > automatically look under an sse2 subdirectory of the rpath for a > SSE2-enabled library on SSE2 machines is taken advantage of. > > The floating-point issues in the media player that made Chromium upstream > require SSE2 should already be worked around by this upstream commit: > https://crrev.com/d2c745b13c93ecff5108bed57d8e052126715492 > so x87 should really be fine again. If not, the fix would be to build > individual parts of the code with -ffloat-store. > > I verified that this builds on GNU/Linux on i686, on x86_64 (where SSE2 is > part of the baseline and can thus be assumed safely) and on ARM (where SSE2 > does not exist at all and so the patch should have no effect). I have not > done runtime testing yet. > > I did not try other platforms yet. The dual V8 trick will not work on > platforms that do not have the same ld.so SSE2 feature, and my code that > handles the V8 trick also hardcodes the .so extension. So you would > probably have to remove those parts and just live with x87 V8. > > Unfortunately, since this is an override of a deliberate upstream Chromium > decision and partly a cumulative revert of several upstream Chromium > commits, I do not expect this to be accepted upstream, ever. > We made the same decision in Qt to not use X86 without SSE2 by default. That it is linux only also doesn't bother me, SSE2 are already a hard requirements for the OSX and Windows platforms we support. This is really only an issue for Linux distros that have outdated minimum requirements. Of course it might be might be easier to keep it as a distro patch only since it looks like an original chromium patch ported to qtwebengine. Best regards `Allan Jensen From thiago.macieira at intel.com Wed Jan 20 18:48:49 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 09:48:49 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: Message-ID: <2043319.215n4IGm6I@tjmaciei-mobl4> On Wednesday 20 January 2016 10:48:20 Bubke Marco wrote: > So let use an airplane as metaphor. We built a fine piston engine airplane > on that little bit cumbersome piston engine called C++. But now we see Jet > engines coming up but all our technology is built the old piston engine > technology so the adaption of jet engines is not that cheap. The jet > engines are different but we are not sure about their advantages but we are > sure it would be a big investment to change to them. So people propose > different designs. Some say we should minimize investments and only apapt > slowly other proposed to build a hyper mach airplane. Let me continue that metaphor. We build a piston engine airplane while everyone is working on jet engines. It's not that you can't use a jet engine on our airplanes, but if you do you have to do some conversion wiring and fuel pumps to adapt. However, while everyone delivers an empty airframe, with no bulkheads or seats, our airplanes come with customiseable bulkheads, multiple options of seats that you can install and a high quality entertainment system. No one else delivers that. So no, I don't think we risk becoming irrelevant against other airplane makers anytime soon. Our competitor are those transatlantic heavyweight ships (HTML5). That is not to say we should stick to piston engines forever. We should discuss improving what we have. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Wed Jan 20 19:40:22 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 19:40:22 +0100 Subject: [Development] QtWebEngine on x86 without SSE2 References: <201601201809.25023.kde@carewolf.com> Message-ID: Allan Sandfeld Jensen wrote: > We made the same decision in Qt to not use X86 without SSE2 by default. I know. Fedora builds Qt with -no-sse2, and portions where it is important are built twice the same way I'm doing with V8 (e.g., QtDeclarative and QtWebKit to take advantage of the V4 resp. JSCore JIT, which both require SSE2). > That it is linux only also doesn't bother me, SSE2 are already a hard > requirements for the OSX and Windows platforms we support. This is really > only an issue for Linux distros that have outdated minimum requirements. > > Of course it might be might be easier to keep it as a distro patch only > since it looks like an original chromium patch ported to qtwebengine. Yes, to be honest, I don't expect you to carry this in Qt. It touches mostly Chromium code, where you are trying to keep the delta minimal. (But if you're willing to do so, I can submit it in the appropriate way.) I developed my patch for QtWebEngine specifically, but about half of it is a cumulative revert of upstream Chromium patches, and most of it can be reused for Chromium packages. (Obviously, the changes to .pro/.pri files are QtWebEngine-specific.) Kevin Kofler From kevin.kofler at chello.at Wed Jan 20 20:05:08 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 20:05:08 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> <4659851.qNACLQFNjs@tjmaciei-mobl4> Message-ID: Thiago Macieira wrote: > We can only do that efficiently if we drop CoW. Creating an adapting API > is easy; making sure we don't do unnecessary copies because we've lost CoW > is the hard part. Would it be possible to wrap a QSharedDataPointer >, where class VectorData : public QSharedData, public std::vector? That would still be layered above std::vector (and d.data() would give you something that is-a std::vector) yet CoW. Or are there reasons why such an approach would not be workable for std::vector? Now I think the current QVector implementation is fine, but I'm also not convinced wrapping std::vector requires dropping CoW. The problems would probably show up somewhere else. Kevin Kofler From charleyb123 at gmail.com Wed Jan 20 20:16:45 2016 From: charleyb123 at gmail.com (charleyb123 .) Date: Wed, 20 Jan 2016 11:16:45 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <2043319.215n4IGm6I@tjmaciei-mobl4> References: <2043319.215n4IGm6I@tjmaciei-mobl4> Message-ID: Thiago sayeth: > So no, I don't think we risk becoming irrelevant against other airplane > makers > anytime soon. Our competitor are those transatlantic heavyweight ships > (HTML5). > , LOL!!! That's actually a very good point (in addition to the fact that I really did Laugh-Out-Loud). C++ is growing, and native-client apps are growing (mobile, embedded, desktop, cloud). The Qt value-proposition gets you native on that platform better than anything else, including the C++ Standard (which is merely a language standard, and not a technology platform). We would likely get quite a few blank stares when walking into a bar for programmers (do those exist?) and shouting, "C++ is easily approachable!" However, we'd get many nods-of-agreement saying the same about Qt. --charley -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.kofler at chello.at Wed Jan 20 20:34:18 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 20:34:18 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601191315.18737.marc.mutz@kdab.com> <569E23BF.9050905@familiesomers.nl> <201601191500.34358.marc.mutz@kdab.com> <569E429B.2080604@vikingsoft.eu> Message-ID: Bo Thorsen wrote: > Den 19-01-2016 kl. 15:00 skrev Marc Mutz: >> In Qt 6: >> 1. ... dropping CoW ... > > I'm against any change that does this. > > I know you hate and loathe them. I don't. I think this alone makes Qt > containers worth while. And it doesn't matter what arguments you give, I > already know and understand them. The pros of CoW to me outweigh the > cons. We disagree on this, and that's perfectly okay. So far, we completely agree (and I disagree with Marc Mutz). > However, there are also things in this argument where I agree with you. > I do think there are more containers in Qt than necessary. It's not > necessarily the case that Qt needs to have all types of lists, for > example. And I would like to see Qt offer the use of std:: containers in > the API. But there, I don't follow: * To the user, this would effectively remove CoW support for the containers you want to drop from Qt. * The API would also result in an inconsistent mess. Kevin Kofler From kevin.kofler at chello.at Wed Jan 20 20:48:42 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 20:48:42 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> <201601191315.18737.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > And if API consistency makes QVector have a prepend(), and QHash::iterator > have it + n, something got out of hand... I appreciate that Qt makes those operations possible (without having to code them by hand). I know that operations such as QVector::prepend are not efficient. That's clearly documented, and follows directly from even the roughest description of how the class is implemented. (That said, for the particular case of QVector::prepend, that could easily be fixed with the same trick used in QList.) Sometimes, a given container is clearly the most efficient for the parts of the application that run 99% of the time, having a single O(n) operation in the remaining 1% is not going to hurt overall efficiency. As for adding n to a QHash::iterator, sure, most people won't use it, but then it doesn't really hurt to have it there. And there may even be use cases where it makes sense. (For example, to divide a hash table into n hash tables minimizing the hash collisions. Taking every n-th element sounds like a reasonable approach there.) I consider STL's inconsistent APIs from one container to the other to be a major annoyance. And it is not even always about efficiency: e.g., std::queue and std::priority_queue are implemented in the SAME header , both are queues, yet std::queue calls its head element front(), std::priority_queue calls it top(). Kevin Kofler From pgquiles at elpauer.org Wed Jan 20 21:08:07 2016 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Wed, 20 Jan 2016 21:08:07 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <569F98BF.50604@vikingsoft.eu> References: <201601201512.48597.marc.mutz@kdab.com> <569F98BF.50604@vikingsoft.eu> Message-ID: On Wed, Jan 20, 2016 at 3:25 PM, Bo Thorsen wrote: > > Why do you think people hate C++? I love C++ but I hate the string > classes. I like some part of the std containers, I don't like their API. > > Spot on. People run scared from Boost-like C++. That kind of code is very performant but it's neither easy to write, understand or, in many cases, figure out. On the other hand, Qt is usually love at first sight. Makes C++ look doable. Even easy. Sure, some people who have spent a lot of time writing C++ move on from Qt and like Boost-like code the better but that kind of code, those APIs, are to blame for the very bad opinion many people have on C++. They hurt C++ jobs. Replacing QThread with std::thread? Please don't. -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwoehlke.floss at gmail.com Wed Jan 20 21:28:12 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Wed, 20 Jan 2016 15:28:12 -0500 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <201601201512.48597.marc.mutz@kdab.com> <569F98BF.50604@vikingsoft.eu> Message-ID: On 2016-01-20 15:08, Pau Garcia i Quiles wrote: > Replacing QThread with std::thread? Please don't. Uh... that had *better* not happen, come to think of it. QThread is a QObject, which means it has signals/slots and an event loop. It is a LOT more featureful than std::thread, which is (mostly) just a handle. (That said... having a QThread member to *get* the std::thread may be a good idea...) Mutexes and the like are another matter. -- Matthew From Marco.Bubke at theqtcompany.com Wed Jan 20 21:36:10 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Wed, 20 Jan 2016 20:36:10 +0000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <201601201512.48597.marc.mutz@kdab.com> <569F98BF.50604@vikingsoft.eu> Message-ID: On January 20, 2016 21:08:50 Pau Garcia i Quiles wrote: > On Wed, Jan 20, 2016 at 3:25 PM, Bo Thorsen > wrote: > > > Why do you think people hate C++? I love C++ but I hate the string classes. I like some part of the std containers, I don't like their API. > I really think professional developers are not driven by their emotions but by reason and arguments. I think as a productive developer you should always train your ability to get in a new context. > > Spot on. > > People run scared from Boost-like C++. That kind of code is very performant but it's neither easy to write, understand or, in many cases, figure out. Yes but with const expressions and concepts the code gets readable again. > On the other hand, Qt is usually love at first sight. Makes C++ look doable. Even easy. Sure, some people who have spent a lot of time writing C++ move on from Qt and like Boost-like code the better but that kind of code, those APIs, are to blame for the very bad opinion many people have on C++. They hurt C++ jobs. It really depends, not everything in boost its bad. The futures are nice. And the big problem are templates but concept should make templates easier to program. > Replacing QThread with std::thread? Please don't. I think it is more a question of maintenance. I prefer std::tread because it is quite simple. > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) -- Sent from cellphone, sorry for the typos From corentin.jabot at gmail.com Wed Jan 20 21:44:12 2016 From: corentin.jabot at gmail.com (Corentin Jabot) Date: Wed, 20 Jan 2016 21:44:12 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <2043319.215n4IGm6I@tjmaciei-mobl4> Message-ID: First of, it should be ensured future planes fit on the tarmac and that people now how to fly these things. Major breakage are a huge pain. Unavoidable minor breakage are painful enough, we always seem to underestimate the cost of any stack change. The plane metaphor still holds. You need to rebuild your production line, teach your staff, assert the damn thing and then you spend the next tens year working all the kinks. It's easier for Qt, but still a cost. That being said... The Qt framework, the whole KDE environment and all the app using Qt are a massive part of the C++ ecosystem. And yet there is this great divide between Qt and the rest of the C++ world. It funnily goes both ways. It would be great if the Qt community was more involved with C++, whether by participating in the standardization process, conferences and such. And maybe that would in turn help the greater C++ community have a better understanding of Qt ? A few days ago I learned KDAB was a member of the vulkan group. how cool is that ? But when I think about it, it's nothing but the logical move. Then, there is moc. I observed C++ devs outside of the Qt community will often use moc as an argument in favor of not using Qt. It seems more of an ideological argument that anything else. Whereas where I stand, moc is what make Qt great. Of course I which moc was more flexible and more easily integrated with a foreign build system but still. I don't think C++ will ever have half of the introspection Qt provides. And don't even get me started on CopperSpice. Ugh. On the other hand, qmake should probably not be recommended way to build a Qt app in the future. I cannot point to specific apis or pain points because again, I value a smooth / pragmatic evolution. Take QSharedPointer. it really do not have a reason to be beside the fact removing it will do nothing but cost thousands of hours to get rid of across the industry. Overall, the current approach of allowing idiomatic C++ apis when doable is quite good. Qt do age quite well. Maybe using the std in example/snippets more ? The Standard has great engines. Qt has comfy seats. Lets have a plane with great engines and comfy seats. 2016-01-20 20:16 GMT+01:00 charleyb123 . : > Thiago sayeth: > > >> So no, I don't think we risk becoming irrelevant against other airplane >> makers >> anytime soon. Our competitor are those transatlantic heavyweight ships >> (HTML5). >> > , > > LOL!!! > > That's actually a very good point (in addition to the fact that I really > did Laugh-Out-Loud). > > C++ is growing, and native-client apps are growing (mobile, embedded, > desktop, cloud). > > The Qt value-proposition gets you native on that platform better than > anything else, including the C++ Standard (which is merely a language > standard, and not a technology platform). > > We would likely get quite a few blank stares when walking into a bar for > programmers (do those exist?) and shouting, "C++ is easily approachable!" > However, we'd get many nods-of-agreement saying the same about Qt. > > --charley > > > _______________________________________________ > 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 Wed Jan 20 21:52:49 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 12:52:49 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <569F98BF.50604@vikingsoft.eu> Message-ID: <5424998.eRg1SWZi7Y@tjmaciei-mobl4> On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote: > Replacing QThread with std::thread? Please don't. Unlike the containers or even futures/promises vs QtConcurrent, we can easily argue that QThread provides a lot more functionality than std::thread. In just one word: signals. We should provide QThread::makeThread() taking a lambda and some other niceties, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Wed Jan 20 23:04:17 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 20 Jan 2016 23:04:17 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601191315.18737.marc.mutz@kdab.com> Message-ID: <201601202304.17574.marc.mutz@kdab.com> On Wednesday 20 January 2016 20:48:42 Kevin Kofler wrote: > I consider STL's inconsistent APIs from one container to the other to be a > major annoyance. And it is not even always about efficiency: e.g., > std::queue and std::priority_queue are implemented in the SAME header > , both are queues, yet std::queue calls its head element front(), > std::priority_queue calls it top(). He's standing at the front[1] of the queue This item has top priority. Get it? I guess you'll also find these terms in text books. [1] Yes, "head". I guess Alex Stepanov can be excused for picking this one "wrong". With head(), the other-end function would have had to be tail() and that's just wrong for a person, as he was, coming from Lisp. A list's tail is the rest of the list, after the head. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Wed Jan 20 22:17:35 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 13:17:35 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <4659851.qNACLQFNjs@tjmaciei-mobl4> Message-ID: <1765894.mEXQjmQEhr@tjmaciei-mobl4> On Wednesday 20 January 2016 20:05:08 Kevin Kofler wrote: > Thiago Macieira wrote: > > We can only do that efficiently if we drop CoW. Creating an adapting API > > is easy; making sure we don't do unnecessary copies because we've lost CoW > > is the hard part. > > Would it be possible to wrap a QSharedDataPointer >, where > class VectorData : public QSharedData, public std::vector? That would > still be layered above std::vector (and d.data() would give you something > that is-a std::vector) yet CoW. Or are there reasons why such an approach > would not be workable for std::vector? This causes double indirection to the data, something we've worked hard to avoid. The most common operation you do on a vector is access an element, so that should be fast. Here's what the begin() const functions look like: libc++: return __make_iter(this->__begin_); libstdc++: return const_iterator(this->_M_impl._M_start); QVector: return d->constBegin(); -> return data(); -> return static_cast(QArrayData::data()); -> return reinterpret_cast(this) + offset; (all inline) or in my implementation, QArrayDataPointer::data() does: return ptr; The important thing to note is that there's exactly one pointer dereferenced at all: this. Current QVector already loses a little by having QArrayData::offset added. But if we did what you suggest, then here's what QVector::begin() const would look like: typename std::vector::const_iterator begin() const { return this->d->begin(); } Now we needed to dereference this *and* the d pointer. This means potentially two cachelines being read from and there's a data dependency, which in turn means potential pipeline stall. > Now I think the current QVector implementation is fine, but I'm also not > convinced wrapping std::vector requires dropping CoW. The problems would > probably show up somewhere else. The options are: a) accept the extra dereferencing b) not wrap std::vector, but continue with our own array management c) drop CoW As I told Lars last night / this morning over IRC, what I would love to have is an improved version of Qt 5's unsharable containers mode: template using QVector = QtTools::Vector; using QString = QtTools::String; where QtTools::Vector can do both CoW and non-CoW modes. You'd be able to write code like: QString foo() { QtTools::String s(size, Qt::Uninitialized); fill(s.data(), size); // no useless detach() emitted! foreach (auto ch : s) // ditto process(ch); return s; // move-construction "steals" buffer } QtTools::String s = foo(); // move-construction attempts to steal The Unsharable modes for the containers would have the same complexity and behaviour as the Standard Library counterparts. But they'd do more, since they'd interoperate with the CoW containers too. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 20 22:19:09 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 13:19:09 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601191315.18737.marc.mutz@kdab.com> Message-ID: <2525284.7hD2LvBfkY@tjmaciei-mobl4> On Wednesday 20 January 2016 20:48:42 Kevin Kofler wrote: > (That said, for the > particular case of QVector::prepend, that could easily be fixed with the > same trick used in QList.) In Qt 6. Due to the way QArrayData is currently designed, you cannot reserve space at the beginning without making the container (QString, QByteArray, QVector) think that they're operating on foreign data (fromRawData). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Jan 20 22:25:08 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 13:25:08 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <1765894.mEXQjmQEhr@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <1765894.mEXQjmQEhr@tjmaciei-mobl4> Message-ID: <2001222.veu2PLmOFF@tjmaciei-mobl4> On Wednesday 20 January 2016 13:17:35 Thiago Macieira wrote: > return s; // move-construction > "steals" buffer } > > QtTools::String s = foo(); // move-construction attempts to > steal And in case the consequence isn't clear from the comment: the *stealing* prevents us from using actual std::vector for being the backend of our containers, not without having the double indirection the first part of the email talked about. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Wed Jan 20 22:25:27 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 22:25:27 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> <201601191152.06015.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > No-one, not even experts understand QList, really. So it may appear to be > easy to use, but is actually a container only absolute experst should use. QList gives people who just don't care about the internals something closer to optimal than any of the containers optimized for a specific use case. The worst case for QList operations is O(n+m) (for a list of n elements of size ≤ m each), rather than O(n m) as for QVector or std::vector (with the obvious exception of sorting, which, assuming that 2 elements can be compared in O(1), is O(m n log(n)) for QVector and std::vector and only O(n log n) for QList). So I think it is a GOOD class for beginners to use. Of course one can use a std::vector, but then you lose the value semantics. > And a QVector provides exactly the same guarantees as a std::vector. How > come one is easier to use than the other? Because QVector has indexOf()? > And what about those cases where the user wants to find an element by just > a field? They will write for loops, most likely, and not use algorithms. Sure, algorithms are more flexible in theory, but they are also less intuitive than a straightforward API such as indexOf. That's the very reason people are tempted to write loops rather than using algorithms. There's nothing preventing people from using algorithms on QVector, is there? The indexOf method surely isn't it. > The crucial point here is that there's no "better" Qt API for this than > what exists on std::vector. Instead, there's a much more complicated API > by sheer volume and duplication, without being near extensive enough for > even very simple tasks. At some point, the question must be asked whether > CoW and append() vs. push_back() do not become more of a burden than a > merit. And whether we need three names for size(). What you call "volume", I call "completeness". And most of the "duplication" is compatibility with the ugly STL names (source compatibility, template algorithm compatibility). So it's the STL's fault that we have duplication. Just don't use the ugly STL names, ever. (push_back does not even comply to Qt naming guidelines. Always use append/prepend/removeLast/removeFirst instead of push_back/push_front/pop_back/pop_front. And Qt also has a real pop unlike the misleadingly-named STL one: takeLast/takeFirst.) And the reason the STL API is horrible is not only the incompleteness, but also the terse, inconsistent (e.g., std::queue::front vs. std::priority_queue::top) and misleading (e.g., pop* methods that do not return the popped element) names. >> The main question IMO is how we can bring these two worlds closer >> together for Qt 6 (or maybe even to some extent in Qt 5.x). > > My answer would be to use std containers exclusively, and write a > wagonload full of Qt-level docs about them, ie. integrate them into the Qt > docs. And my answer would be to ban the std containers from Qt entirely and restore support for QT_NO_STL. Kevin Kofler From kevin.kofler at chello.at Wed Jan 20 22:31:32 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 22:31:32 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601191507.58630.marc.mutz@kdab.com> <201601191609.48882.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > I doubt many people actively use the fact that Qt containers are cheap to > copy. Count me as a person who does (and not only for the obvious return value case, where compiler optimizations or move semantics might possibly help). For example, I have written a parser where the whole sharing of parse subtrees is based on implicitly-shared data structures. Kevin Kofler From thiago.macieira at intel.com Wed Jan 20 22:37:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 13:37:50 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> Message-ID: <3042581.uBeHb1CvAO@tjmaciei-mobl4> On Wednesday 20 January 2016 22:25:27 Kevin Kofler wrote: > And Qt also has a real > pop unlike the misleadingly-named STL one: takeLast/takeFirst. In the Standard Library's defence: the pop() function does not return the element due to exception-safety. Example: value_type takeLast() { value_type v = last(); remove(size() - 1); return v; } The copy constructor is called once, then the move constructor. If value_type's move constructor is not noexcept, then it may throw after the container resized. You could add this overload to solve it: void pop(value_type &where) { where = back(); pop(); } But then your code looks like: Element e; // may throw, allocate resources, etc. v.pop(e); instead of: Element e = v.back(); // move-constructed v.pop(); Also note that this overload would keep the integrity of the container, but not necessarily your data. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Wed Jan 20 22:50:43 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 22:50:43 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <8EA8AC75-5623-42CD-B0B7-5408CF384672@digia.com> <569E86E6.8010104@taschenorakel.de> <201601192240.40519.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > In those cases where it does matter, you'd return by const-&. Or an > array_view. And no, that doesn't restrict your freedom to implement the > function in any meaningful way, because you can always keep a caching > mutable member to hold the result for the next call to the function > (memoisation or however it's called), without any loss except the space > required for the member. All these are horrible and error-prone hacks that have obvious lifetime issues. You are complaining about Qt containers because the detaching can invalidate iterators. Well, the lifetime issues you introduce with the above proposed solutions are much worse! And a caching mutable member also destroys thread-safety (in addition to the obvious lifetime issue that the next call surprisingly invalidates your existing reference). > What about non-arrays? By the time we get around to all this, there will > be no containers other than array-compatible ones left, because nothing > else will provide the required speed. Sorry, but that is just utter nonsense. Replacing a hash table with an array will NOT make your code more efficient. Replacing a linked list with an array can also make your code slower if you do enough insertions/removals. In the end, your real issue is not with the containers, but with the slowness of the malloc you use. Which means we need faster allocations, not containers that minimize allocations at all costs, including worse asymptotic algorithmic complexity. Kevin Kofler From kevin.kofler at chello.at Wed Jan 20 23:15:24 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 20 Jan 2016 23:15:24 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601182311.14867.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > QString foo() { return QStringLiteral("foo"); } > QString bar() { return Q3DeepCopy(QStringLiteral("foo")); } > > You will _never_ have the plugin-unloading problem with 'bar', only with > 'foo', and the reason is CoW: suggesting value semantics where there > aren't any. No, the issue is with the specific (ab)use of CoW by QStringLiteral, that inserts a pointer to a data segment (rather than to the heap as normal) into the CoW container. Kevin Kofler From giuseppe.dangelo at kdab.com Wed Jan 20 23:43:07 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Wed, 20 Jan 2016 23:43:07 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> <201601191152.06015.marc.mutz@kdab.com> Message-ID: <56A00D7B.6040701@kdab.com> Il 20/01/2016 22:25, Kevin Kofler ha scritto: > Marc Mutz wrote: >> No-one, not even experts understand QList, really. So it may appear to be >> easy to use, but is actually a container only absolute experst should use. > > QList gives people who just don't care about the internals something closer > to optimal than any of the containers optimized for a specific use case. The > worst case for QList operations is O(n+m) (for a list of n elements of size > ≤ m each), rather than O(n m) as for QVector or std::vector (with the > obvious exception of sorting, which, assuming that 2 elements can be > compared in O(1), is O(m n log(n)) for QVector and std::vector and only > O(n log n) for QList). So I think it is a GOOD class for beginners to use. > This kind of measurement is way too approximative for the real world. You should measure quantities that actually make a difference, for instance: how many cache misses do you get when doing these various operations? How many allocations/deallocations? How big is each allocation? >> And a QVector provides exactly the same guarantees as a std::vector. How >> come one is easier to use than the other? Because QVector has indexOf()? >> And what about those cases where the user wants to find an element by just >> a field? They will write for loops, most likely, and not use algorithms. > > Sure, algorithms are more flexible in theory, but they are also less > intuitive than a straightforward API such as indexOf. That's the very reason > people are tempted to write loops rather than using algorithms. There's > nothing preventing people from using algorithms on QVector, is there? The > indexOf method surely isn't it. This poses further questions down the line, such as whether it's "ok" having an index API based on signed integers. (It is for convenience, it is not for correctness, but I guess that's all the topic here, isn't it? :)) >> The crucial point here is that there's no "better" Qt API for this than >> what exists on std::vector. Instead, there's a much more complicated API >> by sheer volume and duplication, without being near extensive enough for >> even very simple tasks. At some point, the question must be asked whether >> CoW and append() vs. push_back() do not become more of a burden than a >> merit. And whether we need three names for size(). > > What you call "volume", I call "completeness". And most of the "duplication" > is compatibility with the ugly STL names (source compatibility, template > algorithm compatibility). So it's the STL's fault that we have duplication. > Just don't use the ugly STL names, ever. (push_back does not even comply to > Qt naming guidelines. Always use append/prepend/removeLast/removeFirst > instead of push_back/push_front/pop_back/pop_front. And Qt also has a real > pop unlike the misleadingly-named STL one: takeLast/takeFirst.) > > And the reason the STL API is horrible is not only the incompleteness, but > also the terse, inconsistent (e.g., std::queue::front vs. > std::priority_queue::top) and misleading (e.g., pop* methods that do not > return the popped element) names. Renaming a function is not a big deal (heck, we could even provide a std::vector subclass with convenience functions! Would that make everyone happy?). Having "a real pop" is the consequence of Qt not being exception safe. Since you can't build an exception-safe pop that returns the popped value, the STL (which cares about exception safety and wants containers with the strong guarantee) does not provide pop-and-return functions. So, seeing the glass half empty: Qt containers are unsound for general-purpose storage. >>> The main question IMO is how we can bring these two worlds closer >>> together for Qt 6 (or maybe even to some extent in Qt 5.x). >> >> My answer would be to use std containers exclusively, and write a >> wagonload full of Qt-level docs about them, ie. integrate them into the Qt >> docs. > > And my answer would be to ban the std containers from Qt entirely and > restore support for QT_NO_STL. Which is never going to happen since the STL containers are superior in performance and code size and we want to use them extensively inside Qt. If/how/when expose STL types in our APIs is all to be seen... ... can we go back thinking about that? Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Thu Jan 21 00:30:02 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 15:30:02 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601192240.40519.marc.mutz@kdab.com> Message-ID: <2488623.7N35ou38xW@tjmaciei-mobl4> On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote: > In the end, your real issue is not with the containers, but with the > slowness of the malloc you use. Which means we need faster allocations, not > containers that minimize allocations at all costs, including worse > asymptotic algorithmic complexity. Adding a slice allocator was part of João's plans back in 2012. That's why QArrayData::deallocate receives the object size. (the alignment is for another reason) We never got that far. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Jan 21 00:34:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 15:34:50 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <56A00D7B.6040701@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <56A00D7B.6040701@kdab.com> Message-ID: <2876493.2ceYDTIrqA@tjmaciei-mobl4> On Wednesday 20 January 2016 23:43:07 Giuseppe D'Angelo wrote: > This poses further questions down the line, such as whether it's "ok" > having an index API based on signed integers. (It is for convenience, it > is not for correctness, but I guess that's all the topic here, isn't it? :)) Current guidance from the standards committee is that you should use signed integers unless you specifically need modulo-2 overflow. > > And my answer would be to ban the std containers from Qt entirely and > > restore support for QT_NO_STL. > > Which is never going to happen since the STL containers are superior in > performance and code size and we want to use them extensively inside Qt. > If/how/when expose STL types in our APIs is all to be seen... > > ... can we go back thinking about that? We can't get QT_NO_STL for more reasons than this. We've deprecated our algorithms library, for good reason. With C++11, there are some things you just cannot do without the Standard Library, like and . And yes, we're using the Standard Library containers in our own code. However, let me also say that our source code is product, so we need to have readable code. We *will* trade some performance off for more readable code, where "more readable" means Qt-like code that users of our API will understand. So whenever I see a std::erase with nested std::remove_if, I cringe. It's highly efficient, but a sore in the eye. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andrew.den.exter at qinetic.com.au Thu Jan 21 00:45:02 2016 From: andrew.den.exter at qinetic.com.au (Andrew den Exter) Date: Thu, 21 Jan 2016 09:45:02 +1000 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: <569FB1C1.3080601@ableton.com> References: <569E375D.4080709@ableton.com> <569E60BE.2020804@ableton.com> <569FB1C1.3080601@ableton.com> Message-ID: On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly wrote: > > And there are the obvious runtime costs to building and maintaining a > cache that is of little or no use to most people most of the time, which is > I think a strong argument for it being an off by default feature if > implemented. > > > I think the cost would need to be measured before letting it influence > design decisions. We are not talking about monstrous amounts of data. > Famous last words. I have to assume any cache is going to be pre-populated with data from every role provided by the model and refreshed every time dataChanged is emitted for that row, because the views have no knowledge about what roles a delegate queries until after the fact, and any binding with a conditional statement in it opens up the possibility that a role won't be accessed until after the row is removed making on access caching a flaky solution. How third parties implement their models and delegates is a big factor in the potential cost of an effective cache, a model with many roles and costly access to some of those but with a delegate that only accesses a few in bindings may work fine now, but be absolutely hammered by an aggressive cache. And I obviously don't want to see views which don't hit this relatively rare combination of circumstances pay that cost. Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Thu Jan 21 02:37:43 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 21 Jan 2016 02:37:43 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <5424998.eRg1SWZi7Y@tjmaciei-mobl4> References: <5424998.eRg1SWZi7Y@tjmaciei-mobl4> Message-ID: <201601210237.43792.marc.mutz@kdab.com> On Wednesday 20 January 2016 21:52:49 Thiago Macieira wrote: > On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote: > > Replacing QThread with std::thread? Please don't. > > Unlike the containers or even futures/promises vs QtConcurrent, we can > easily argue that QThread provides a lot more functionality than > std::thread. In just one word: signals. What happened to "you're doing it wrong!"? :) AFAIU that blog post, you're supposed to use the signals of QObjects living in that thread, not the QThread itself. And that's perfectly possible with std::thread, too: auto po = new ProcessingObject(); connect(po, ...); po->moveToThread(nullptr); // enable "pulling" moveToThread() auto t = std::thread([po, gui = QThread::currentThread()]() { QEventLoop loop; po->moveToThread(QThread::currentThread()); connect(po, ..., &loop, &QEventLoop::quit); loop.exec(); po->moveToThread(gui); // or: delete po; } Am I missing something? > We should provide QThread::makeThread() taking a lambda and some other > niceties, though. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Thu Jan 21 03:03:41 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 21 Jan 2016 03:03:41 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601192240.40519.marc.mutz@kdab.com> Message-ID: <201601210303.42302.marc.mutz@kdab.com> On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote: > Marc Mutz wrote: > > In those cases where it does matter, you'd return by const-&. Or an > > array_view. And no, that doesn't restrict your freedom to implement the > > function in any meaningful way, because you can always keep a caching > > mutable member to hold the result for the next call to the function > > (memoisation or however it's called), without any loss except the space > > required for the member. > > All these are horrible and error-prone hacks that have obvious lifetime > issues. You are complaining about Qt containers because the detaching can > invalidate iterators. Well, the lifetime issues you introduce with the > above proposed solutions are much worse! And a caching mutable member also > destroys thread-safety (in addition to the obvious lifetime issue that the > next call surprisingly invalidates your existing reference). One word: QModelIndex. > > What about non-arrays? By the time we get around to all this, there will > > be no containers other than array-compatible ones left, because nothing > > else will provide the required speed. > > Sorry, but that is just utter nonsense. Replacing a hash table with an > array will NOT make your code more efficient. Replacing a linked list with > an array can also make your code slower if you do enough > insertions/removals. In 90s text books, yes. In reality, no. The factors are so large these days that big-O complexity is only valid for really, really large containers. The vast majority of containers never grow big enough to offset that factor. find_if even beats lower_bound on a vector, for a large range of sizes (and a cheap comparator). Even in the 90s, Effective STL and Alex Stepanov recommended to use vector unless the profiler tells you otherwise. In the past 20 years, the gap has only widened. > In the end, your real issue is not with the containers, but with the > slowness of the malloc you use. Which means we need faster allocations, not > containers that minimize allocations at all costs, including worse > asymptotic algorithmic complexity. QLinkedList ll = generateRandomLL(); ll.sort(); // no more memory allocs beyond this point QElapsedTimer timer; timer.start(); for (int i = 0; i < 1000; ++i) for (int e : ll) some cheap payload processing.... timer.elapsed(); Then do the same benchmark with a QVector. If you don't understand why this is slow _as hell_ I suggest you run it on a cache profiler. Or monitor https://www.youtube.com/user/MeetingCPP/playlists for http://meetingcpp.com/index.php/vl15/items/10.html to become available. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Thu Jan 21 02:02:11 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 17:02:11 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <201601210237.43792.marc.mutz@kdab.com> References: <5424998.eRg1SWZi7Y@tjmaciei-mobl4> <201601210237.43792.marc.mutz@kdab.com> Message-ID: <1858041.Py4cDg8Sz4@tjmaciei-mobl4> On Thursday 21 January 2016 02:37:43 Marc Mutz wrote: > On Wednesday 20 January 2016 21:52:49 Thiago Macieira wrote: > > On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote: > > > Replacing QThread with std::thread? Please don't. > > > > Unlike the containers or even futures/promises vs QtConcurrent, we can > > easily argue that QThread provides a lot more functionality than > > std::thread. In just one word: signals. > > What happened to "you're doing it wrong!"? :) AFAIU that blog post, you're > supposed to use the signals of QObjects living in that thread, not the > QThread itself. You can use the signals and the slots of the QThread itself. The wrong part was deriving from QThread, adding slots to it and then doing moveToThread(this) so those slots got called in the thread that it manages. Other uses of QThread are fine. You can derive from it and override run. You can even add more signals to it. It's new slots that are suspicious. > And that's perfectly possible with std::thread, too: > > auto po = new ProcessingObject(); > connect(po, ...); > po->moveToThread(nullptr); // enable "pulling" moveToThread() > auto t = std::thread([po, gui = QThread::currentThread()]() { > QEventLoop loop; > po->moveToThread(QThread::currentThread()); > connect(po, ..., &loop, &QEventLoop::quit); > loop.exec(); > po->moveToThread(gui); > // or: delete po; > } > > Am I missing something? How do you interrupt the event loop from outside (QThread::quit)? You can't create that QEventLoop before the lambda because it would live in the wrong thread. You could use this: po->thread()->quit(); but note how you used QThread. If you're going to use QThread anyway, you may as well use it to start the thread. Even if you didn't do this, your example uses QThread (QThread::currentThread(), which returns a QAdoptedThread pointer). And even if you didn't moveToThread(), you created a QObject in that thread (the QEventLoop), which will create the QThreadData and the event dispatcher machinery. At that point, QThread is a simple wrapper full of convenience functions. > > We should provide QThread::makeThread() taking a lambda and some other > > niceties, though. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Thu Jan 21 05:17:35 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 21 Jan 2016 05:17:35 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601191315.18737.marc.mutz@kdab.com> <201601202304.17574.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > He's standing at the front[1] of the queue > > This item has top priority. > > Get it? The item has top priority, which makes is stand at the front of the priority queue and be the head of the priority queue. :-) Sure, I understand where "top" comes from. It still does not fit the queue metaphor. Kevin Kofler From kevin.kofler at chello.at Thu Jan 21 05:24:35 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 21 Jan 2016 05:24:35 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601192240.40519.marc.mutz@kdab.com> <201601210303.42302.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote: >> All these are horrible and error-prone hacks that have obvious lifetime >> issues. You are complaining about Qt containers because the detaching can >> invalidate iterators. Well, the lifetime issues you introduce with the >> above proposed solutions are much worse! And a caching mutable member >> also destroys thread-safety (in addition to the obvious lifetime issue >> that the next call surprisingly invalidates your existing reference). > > One word: QModelIndex. And that class is the source of innumerable bugs. The fact that one Qt class has such broken semantics is no excuse for putting them everywhere. Kevin Kofler From kevin.kofler at chello.at Thu Jan 21 05:27:50 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 21 Jan 2016 05:27:50 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> <3042581.uBeHb1CvAO@tjmaciei-mobl4> Message-ID: Thiago Macieira wrote: > The copy constructor is called once, then the move constructor. If > value_type's move constructor is not noexcept, then it may throw after the > container resized. Throwing an exception in a move constructor is really, really horrible. I can see why a copy constructor would throw (out of memory, failure to duplicate some other resource), but a move? Kevin Kofler From kevin.kofler at chello.at Thu Jan 21 05:33:51 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 21 Jan 2016 05:33:51 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601161940.36706.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > You can lock a mutex in the function and unlock it in the shared_ptr's > deleter. How can that possibly be faster than atomic reference counting? You have the same cross-thread dependence plus a potential wait for the thread to actually do its work. Not to mention that mutexes can cause deadlocks, atomic reference counts can't. Kevin Kofler From thiago.macieira at intel.com Thu Jan 21 05:35:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 20:35:58 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <3042581.uBeHb1CvAO@tjmaciei-mobl4> Message-ID: <3464653.Gn6Y02gMP5@tjmaciei-mobl4> On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote: > Thiago Macieira wrote: > > The copy constructor is called once, then the move constructor. If > > value_type's move constructor is not noexcept, then it may throw after the > > container resized. > > Throwing an exception in a move constructor is really, really horrible. I > can see why a copy constructor would throw (out of memory, failure to > duplicate some other resource), but a move? Indeed. But the class in question may not have a move constructor. In the absence of one, the copy constructor gets called. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Thu Jan 21 05:44:05 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 21 Jan 2016 05:44:05 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: Bubke Marco wrote: > So you optimized the container for growing with allocations. I don't think > it is the most common case. Having cache misses in traversing the > container can be much worse and is much harder to fix than a reserve. Almost all my containers grow with allocations. How should I know in advance how much memory to reserve? It'd just waste an arbitrary amount of memory and then still end up reallocating because it'll inevitably be exceeded at some point. Variable-size containers are variable-size for a reason. I consider reserve() to be a technical detail and a micro-optimization I really should not have to bother with in 99+% of the cases. Kevin Kofler From kevin.kofler at chello.at Thu Jan 21 05:49:55 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 21 Jan 2016 05:49:55 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601182343.38142.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > best of three runs, core i7-2720QM, GCC 5.3 What OS and C library are you running those benchmarks on? The performance of realloc is vastly different between operating systems, so this is important information. Kevin Kofler From thiago.macieira at intel.com Thu Jan 21 06:01:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 20 Jan 2016 21:01:13 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601161940.36706.marc.mutz@kdab.com> Message-ID: <1843980.uNekxLJMvP@tjmaciei-mobl4> On Thursday 21 January 2016 05:33:51 Kevin Kofler wrote: > Marc Mutz wrote: > > You can lock a mutex in the function and unlock it in the shared_ptr's > > deleter. > > How can that possibly be faster than atomic reference counting? You have the > same cross-thread dependence plus a potential wait for the thread to > actually do its work. Not to mention that mutexes can cause deadlocks, > atomic reference counts can't. It can't be because the simplest mutex lock operation is equivalent to an atomic operation, ditto for unlock. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Jan 21 08:00:39 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 21 Jan 2016 08:00:39 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601210303.42302.marc.mutz@kdab.com> Message-ID: <201601210800.40363.marc.mutz@kdab.com> On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote: > Marc Mutz wrote: > > On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote: > >> All these are horrible and error-prone hacks that have obvious lifetime > >> issues. You are complaining about Qt containers because the detaching > >> can invalidate iterators. Well, the lifetime issues you introduce with > >> the above proposed solutions are much worse! And a caching mutable > >> member also destroys thread-safety (in addition to the obvious lifetime > >> issue that the next call surprisingly invalidates your existing > >> reference). > > > > One word: QModelIndex. > > And that class is the source of innumerable bugs. The fact that one Qt > class has such broken semantics is no excuse for putting them everywhere. So how would you have designed it, then? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From andre at familiesomers.nl Thu Jan 21 07:10:27 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 21 Jan 2016 07:10:27 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601210800.40363.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601210303.42302.marc.mutz@kdab.com> <201601210800.40363.marc.mutz@kdab.com> Message-ID: <56A07653.5020305@familiesomers.nl> Op 21/01/2016 om 08:00 schreef Marc Mutz: > On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote: >> Marc Mutz wrote: >>> On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote: >>>> All these are horrible and error-prone hacks that have obvious lifetime >>>> issues. You are complaining about Qt containers because the detaching >>>> can invalidate iterators. Well, the lifetime issues you introduce with >>>> the above proposed solutions are much worse! And a caching mutable >>>> member also destroys thread-safety (in addition to the obvious lifetime >>>> issue that the next call surprisingly invalidates your existing >>>> reference). >>> One word: QModelIndex. >> And that class is the source of innumerable bugs. The fact that one Qt >> class has such broken semantics is no excuse for putting them everywhere. Indeed, it is. You will find cases where QModelIndex is stored somewhere in many places, also in code writen by people who should know better. > So how would you have designed it, then? > I would have designed something that stays valid. But that's another discussion for another thread. André From andre at familiesomers.nl Thu Jan 21 07:25:21 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 21 Jan 2016 07:25:21 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <3464653.Gn6Y02gMP5@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <3042581.uBeHb1CvAO@tjmaciei-mobl4> <3464653.Gn6Y02gMP5@tjmaciei-mobl4> Message-ID: <56A079D1.9090501@familiesomers.nl> Op 21/01/2016 om 05:35 schreef Thiago Macieira: > On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote: >> Thiago Macieira wrote: >>> The copy constructor is called once, then the move constructor. If >>> value_type's move constructor is not noexcept, then it may throw after the >>> container resized. >> Throwing an exception in a move constructor is really, really horrible. I >> can see why a copy constructor would throw (out of memory, failure to >> duplicate some other resource), but a move? > Indeed. > > But the class in question may not have a move constructor. In the absence of > one, the copy constructor gets called. > I generally don't care. If I can't copy anymore due to running out of memory, I'm pretty much done anyway. No reliable way to recover from that. Might as well terminate the program. André From mathias at taschenorakel.de Thu Jan 21 07:59:18 2016 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Thu, 21 Jan 2016 07:59:18 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601210800.40363.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601210303.42302.marc.mutz@kdab.com> <201601210800.40363.marc.mutz@kdab.com> Message-ID: <56A081C6.40104@taschenorakel.de> Am 21.01.2016 um 08:00 schrieb Marc Mutz: > On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote: >> Marc Mutz wrote: >>> On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote: >>>> All these are horrible and error-prone hacks that have obvious lifetime >>>> issues. You are complaining about Qt containers because the detaching >>>> can invalidate iterators. Well, the lifetime issues you introduce with >>>> the above proposed solutions are much worse! And a caching mutable >>>> member also destroys thread-safety (in addition to the obvious lifetime >>>> issue that the next call surprisingly invalidates your existing >>>> reference). >>> >>> One word: QModelIndex. Sorry Marc, no. Really. QModelIndex is entirely unrelated to the problem Eike raised. I highly reward your expertise and what you are doing for Qt, and I really don't want my high opinion of you being spoiled. So please grab fine cup of tea, take a comfortable seat and spent some time on understanding, why this discussion took such dramatic shift away from its initial topic, why you are receiving such heat. Also please take some time to recall what other properties but performance are important when designing general purpose libraries. >> And that class is the source of innumerable bugs. The fact that one Qt >> class has such broken semantics is no excuse for putting them everywhere. > > So how would you have designed it, then? One other widespread toolkit actually has tried to implement a long-lived model index. This is what those guys came up with: https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-row-reference-new https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-path-new https://developer.gnome.org/gtk3/stable/GtkTreeModel.html#gtk-tree-model-get-iter And no, let's not follow that example. Dealing with GtkTreeModel is just painful. QModelIndex is perfectly fine if you use it as intended, as short lived reference into a tree model. Ciao, Mathias From andre at familiesomers.nl Thu Jan 21 08:12:59 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 21 Jan 2016 08:12:59 +0100 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: References: <569E375D.4080709@ableton.com> <569E60BE.2020804@ableton.com> <569FB1C1.3080601@ableton.com> Message-ID: <56A084FB.9080902@familiesomers.nl> Op 21/01/2016 om 00:45 schreef Andrew den Exter: > > > On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly > > wrote: > > >> And there are the obvious runtime costs to building and >> maintaining a cache that is of little or no use to most people >> most of the time, which is I think a strong argument for it being >> an off by default feature if implemented. >> > > I think the cost would need to be measured before letting it > influence design decisions. We are not talking about monstrous > amounts of data. > > > Famous last words. I have to assume any cache is going to be > pre-populated with data from every role provided by the model and > refreshed every time dataChanged is emitted for that row, because the > views have no knowledge about what roles a delegate queries until > after the fact, and any binding with a conditional statement in it > opens up the possibility that a role won't be accessed until after the > row is removed making on access caching a flaky solution. How third > parties implement their models and delegates is a big factor in the > potential cost of an effective cache, a model with many roles and > costly access to some of those but with a delegate that only accesses > a few in bindings may work fine now, but be absolutely hammered by an > aggressive cache. And I obviously don't want to see views which > don't hit this relatively rare combination of circumstances pay that cost. > Actually, I think it would not need to be quite as bad. For starters, you really only need to cache the actual items being removed. At the moment the model emits the AboutToBeRemoved signal, the data should still be there in any well-behaved model, right? _That_ is the moment you do your caching. While it is possible that because of conditionals in the binding roles are accessed only during the removing, it does not sound very likely. One could provide an API to specifically add roles to the caching manually, but otherwise only cache roles that have been accessed already. Or just only set the roles manually and use that as the on/off switch for the whole feature that Andrew requested. Realistically, for most models, this would be something like perhaps an image and a couple of strings for an item. And these would only need to live for a short time, because once the remove animation is done, the data can be removed again. I think it is certainly worthwhile to investigate. André -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Thu Jan 21 10:02:41 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 21 Jan 2016 10:02:41 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <1858041.Py4cDg8Sz4@tjmaciei-mobl4> References: <201601210237.43792.marc.mutz@kdab.com> <1858041.Py4cDg8Sz4@tjmaciei-mobl4> Message-ID: <201601211002.42064.marc.mutz@kdab.com> On Thursday 21 January 2016 02:02:11 Thiago Macieira wrote: > On Thursday 21 January 2016 02:37:43 Marc Mutz wrote: > > On Wednesday 20 January 2016 21:52:49 Thiago Macieira wrote: > > > On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote: > > > > Replacing QThread with std::thread? Please don't. > > > > > > Unlike the containers or even futures/promises vs QtConcurrent, we can > > > easily argue that QThread provides a lot more functionality than > > > std::thread. In just one word: signals. > > > > What happened to "you're doing it wrong!"? :) AFAIU that blog post, > > you're supposed to use the signals of QObjects living in that thread, > > not the QThread itself. > > You can use the signals and the slots of the QThread itself. The wrong part > was deriving from QThread, adding slots to it and then doing > moveToThread(this) so those slots got called in the thread that it manages. > > Other uses of QThread are fine. You can derive from it and override run. > You can even add more signals to it. It's new slots that are suspicious. Having had to teach this stuff to customers when this came out in Qt 4, I can tell you this distinction will not register with most Qt-newbies. Allowing such ease of wrong API use is against my reading Qt's own design principles ("make it hard to use an API incorrectly"). That QThread is a QObject is a bug, not a featuee. It would be better as a non-QObject, adding QThreadWatcher a la QFutureWatcher to enable singals. In that case, QThread can be replaced with std::thread without much loss of generality. > > And that's perfectly possible with std::thread, too: > > auto po = new ProcessingObject(); > > connect(po, ...); > > po->moveToThread(nullptr); // enable "pulling" moveToThread() > > auto t = std::thread([po, gui = QThread::currentThread()]() { > > > > QEventLoop loop; > > po->moveToThread(QThread::currentThread()); > > connect(po, ..., &loop, &QEventLoop::quit); > > loop.exec(); > > po->moveToThread(gui); > > // or: delete po; > > > > } > > > > Am I missing something? > > How do you interrupt the event loop from outside (QThread::quit)? You can't > create that QEventLoop before the lambda because it would live in the wrong > thread. You could use this: > > po->thread()->quit(); That's racy. You could pass a shared_ptr by reference and use event posting to avoid the race. I'm not saying we don't need new API should we replace QThread with std::thead. I'm saying that all the hard, impressive, work is already done. It seems to be mostly a question of API now. > but note how you used QThread. If you're going to use QThread anyway, you > may as well use it to start the thread. > Even if you didn't do this, your example uses QThread > (QThread::currentThread(), which returns a QAdoptedThread pointer). And > even if you didn't moveToThread(), you created a QObject in that thread > (the QEventLoop), which will create the QThreadData and the event > dispatcher machinery. > > At that point, QThread is a simple wrapper full of convenience functions. > I've used current API on purpose to show that it's possible already. All that event loop, cross-thread signal/slots and event handling already works for std::threads. How we'd represent a thread if QThread was dropped is a different question, but easily resolved once we get there (QThreadHandle, or even re-using QThread, but not as a QObject subclass). Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From andre at familiesomers.nl Thu Jan 21 09:14:58 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 21 Jan 2016 09:14:58 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <201601211002.42064.marc.mutz@kdab.com> References: <201601210237.43792.marc.mutz@kdab.com> <1858041.Py4cDg8Sz4@tjmaciei-mobl4> <201601211002.42064.marc.mutz@kdab.com> Message-ID: <56A09382.7050101@familiesomers.nl> Op 21/01/2016 om 10:02 schreef Marc Mutz: > I'm not saying we don't need new API should we replace QThread with > std::thead. I'm saying that all the hard, impressive, work is already done. It > seems to be mostly a question of API now. Sorry, but I think API design _is_ the hard work. Not the part that is/should be the afterthought. And I think that that very thought has been the basis of the succes of Qt over the years. André From marc.mutz at kdab.com Thu Jan 21 11:03:08 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 21 Jan 2016 11:03:08 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <56A081C6.40104@taschenorakel.de> References: <201601051352.06816.marc.mutz@kdab.com> <201601210800.40363.marc.mutz@kdab.com> <56A081C6.40104@taschenorakel.de> Message-ID: <201601211103.08815.marc.mutz@kdab.com> On Thursday 21 January 2016 07:59:18 Mathias Hasselmann wrote: > Am 21.01.2016 um 08:00 schrieb Marc Mutz: > > On Thursday 21 January 2016 05:24:35 Kevin Kofler wrote: > >> Marc Mutz wrote: > >>> On Wednesday 20 January 2016 22:50:43 Kevin Kofler wrote: > >>>> All these are horrible and error-prone hacks that have obvious > >>>> lifetime issues. You are complaining about Qt containers because the > >>>> detaching can invalidate iterators. Well, the lifetime issues you > >>>> introduce with the above proposed solutions are much worse! And a > >>>> caching mutable member also destroys thread-safety (in addition to > >>>> the obvious lifetime issue that the next call surprisingly > >>>> invalidates your existing reference). > >>> > >>> One word: QModelIndex. > > Sorry Marc, no. Really. > > QModelIndex is entirely unrelated to the problem Eike raised. I was replying to Kevin. QModelIndex exactly fits his complaints about const-&: It's a reference used in interfaces. As soon as you store it, though, it may become stale at the next opportunity (like when calling a virtual function). You're supposed to store them in QPersistentModelIndex in that case. But QPMI is extremely expensive. Compare that to: const std::vector & foos(); You can either assign the result to a const-& (=QModelIndex case), get max performance, but suffer from possible invalidation if you call out to unknown code. Or you store it in a copy, incurring the copy, but insulating yourself from changes to the original object (=QPersistentModelIndex case). They really are two instances of the same class of problem: dangling references. And you cannot escape that problem. Not in C++, and not in other imperative languages, either. If you replaced QMI with an int, as you could, for QAbstractListModels, then you'd have exactly the same problems of invalidation (who updates your int if the row it points to gets removed?). > I highly reward your expertise and what you are doing for Qt, and I > really don't want my high opinion of you being spoiled. So please grab > fine cup of tea, take a comfortable seat and spent some time on > understanding, why this discussion took such dramatic shift away from > its initial topic, why you are receiving such heat. Also please take > some time to recall what other properties but performance are important > when designing general purpose libraries. If I have given the impression that it's just about speed, I'm sorry. Speed is one argument, yes. If the Qt class had that much more (useful, to avoid counting indexOf() as a feature) features than the std counterpart, I would be the last to talk about replacing it. QString e.g. has superior Unicode handling. We can discuss how it should be laid out (CoW or not, say), but no-one challenges the very right of QString to exist. But if a Qt class has only half the feature of its std counterpart and at the same time performs worse, then the question needs to be asked whether that class really needs to be in Qt. So yes, I cannot shake the deeply-ingrained C++ principle of "don't pay for what you don't use". It's what keeps C++ relevant these days, despite its rough edges. But speed is not the only reason: I don't like Q_FOREACH not just because it performs badly, which it really doesn't, usually, for Qt types, but because it makes it hard to reason about the code (why is a copy taken? Is is needed?). I don't like QThread being a QObject because it makes misusing the API all too easy. I don't like QList because only experts can tell which guarantees it provides for any given type (can I keep references into the container across appends?). It's also the only container in the C++ world where iterator and reference validity are not synonyms: An append where capacity() == size() invalidates iterators in both QList modes, but only invalidates references in vector-with- padding mode. I don't like CoW because it creates long-range effects that are also the underlying reason we don't like global variables. It also makes any complexity specifications moot, because you never know whether you will incur that extra O(N) detach. I don't like QSharedPointer because it does nothing better, and lot of things worse, than shared_ptr and was only added (long after boost::shared_ptr and tr1::shared_ptr came into existence) because of an overly strict sense of BC that extends beyond the Qt libraries (aka "we can't use boost/std in our APIs"). As for why I am receiving such heat: I don't. It's the same couple of persons every time that troll around. I should get better at not feeding them, sure. The people that matter in Qt development, however, take this constructively, even when they disagree about the whens and hows. I take the extreme pov in these discussions, because someone has to. The wider C++ community ignores Qt, and I feel that's to the detriment of both. Some try to fork the project. I prefer to work within it, as someone who was but a consumer of Qt API for (still) most of his professional career, but who also "gets" boost and std. One reason why Effective Qt doesn't really get off the ground is that it's often easier to just fix the problem at the root instead of writing about it. > QModelIndex is perfectly fine if you use it as intended, as > short lived reference into a tree model. Exactly.. And my point is: quote =~ s/QModelIndex/const-&/; quote =~ s/tree model/object/; Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Thu Jan 21 11:06:13 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 21 Jan 2016 11:06:13 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601161940.36706.marc.mutz@kdab.com> Message-ID: <201601211106.14451.marc.mutz@kdab.com> On Thursday 21 January 2016 05:33:51 Kevin Kofler wrote: > Marc Mutz wrote: > > You can lock a mutex in the function and unlock it in the shared_ptr's > > deleter. > > How can that possibly be faster than atomic reference counting? You have > the same cross-thread dependence plus a potential wait for the thread to > actually do its work. Not to mention that mutexes can cause deadlocks, > atomic reference counts can't. Ivan was talking about thread-safe classes. You need to lock a mutex to take the copy. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Thu Jan 21 11:09:03 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 21 Jan 2016 11:09:03 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601182343.38142.marc.mutz@kdab.com> Message-ID: <201601211109.04264.marc.mutz@kdab.com> On Thursday 21 January 2016 05:49:55 Kevin Kofler wrote: > Marc Mutz wrote: > > best of three runs, core i7-2720QM, GCC 5.3 > > What OS and C library are you running those benchmarks on? The performance > of realloc is vastly different between operating systems, so this is > important information. Debian Wheezy. kernel: 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u1 x86_64 GNU/Linux libc6: 2.13-38+deb7u8 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Thu Jan 21 11:17:24 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 21 Jan 2016 11:17:24 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <56A09382.7050101@familiesomers.nl> References: <201601211002.42064.marc.mutz@kdab.com> <56A09382.7050101@familiesomers.nl> Message-ID: <201601211117.24885.marc.mutz@kdab.com> On Thursday 21 January 2016 09:14:58 André Somers wrote: > Op 21/01/2016 om 10:02 schreef Marc Mutz: > > I'm not saying we don't need new API should we replace QThread with > > std::thead. I'm saying that all the hard, impressive, work is already > > done. It seems to be mostly a question of API now. > > Sorry, but I think API design _is_ the hard work. Not the part that > is/should be the afterthought. And I think that that very thought has > been the basis of the succes of Qt over the years. I disagree. For anything related to multithreading (and that's what we're talking about here), implementation is orders of magnitude harder than API. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Marco.Bubke at theqtcompany.com Thu Jan 21 10:37:36 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Thu, 21 Jan 2016 09:37:36 +0000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <201601210237.43792.marc.mutz@kdab.com> References: <5424998.eRg1SWZi7Y@tjmaciei-mobl4> <201601210237.43792.marc.mutz@kdab.com> Message-ID: On January 21, 2016 1:28:58 AM Marc Mutz wrote: > On Wednesday 20 January 2016 21:52:49 Thiago Macieira wrote: >> On Wednesday 20 January 2016 21:08:07 Pau Garcia i Quiles wrote: >> > Replacing QThread with std::thread? Please don't. >> >> Unlike the containers or even futures/promises vs QtConcurrent, we can >> easily argue that QThread provides a lot more functionality than >> std::thread. In just one word: signals. > > What happened to "you're doing it wrong!"? :) AFAIU that blog post, you're > supposed to use the signals of QObjects living in that thread, not the QThread > itself. > > And that's perfectly possible with std::thread, too: > > auto po = new ProcessingObject(); > connect(po, ...); > po->moveToThread(nullptr); // enable "pulling" moveToThread() > auto t = std::thread([po, gui = QThread::currentThread()]() { > QEventLoop loop; > po->moveToThread(QThread::currentThread()); > connect(po, ..., &loop, &QEventLoop::quit); > loop.exec(); > po->moveToThread(gui); > // or: delete po; > } > > Am I missing something? The question is if you really want an event loop here. Mostly I want a command queue where I can prioritize and merge the commands. I want to poll for cancel commands without much overhead and it should support move only types. I really think we should step back and look at the broader picture before we apply our tools. >> We should provide QThread::makeThread() taking a lambda and some other >> niceties, though. > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From andre at familiesomers.nl Thu Jan 21 10:41:40 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 21 Jan 2016 10:41:40 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <201601211117.24885.marc.mutz@kdab.com> References: <201601211002.42064.marc.mutz@kdab.com> <56A09382.7050101@familiesomers.nl> <201601211117.24885.marc.mutz@kdab.com> Message-ID: <56A0A7D4.7000708@familiesomers.nl> Op 21/01/2016 om 11:17 schreef Marc Mutz: > On Thursday 21 January 2016 09:14:58 André Somers wrote: >> Op 21/01/2016 om 10:02 schreef Marc Mutz: >>> I'm not saying we don't need new API should we replace QThread with >>> std::thead. I'm saying that all the hard, impressive, work is already >>> done. It seems to be mostly a question of API now. >> Sorry, but I think API design _is_ the hard work. Not the part that >> is/should be the afterthought. And I think that that very thought has >> been the basis of the succes of Qt over the years. > I disagree. For anything related to multithreading (and that's what we're > talking about here), implementation is orders of magnitude harder than API. > I beg to differ. QThread being a good example. So many people got it wrong when using it, it is obvious the API is just not right. The thing worked ok, but it turns out it hard to use it right. You may call the implementation orders of magitudes harder, but it was the API that was screwed up, not so much the implementation. André From Jukka.Jokiniva at theqtcompany.com Thu Jan 21 11:27:06 2016 From: Jukka.Jokiniva at theqtcompany.com (Jokiniva Jukka) Date: Thu, 21 Jan 2016 10:27:06 +0000 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: Message-ID: Maintenance break is over and systems are back online. Use your unified Qt Account credentials to login from now on. If you find bugs, please report them here: https://bugreports.qt.io/browse/QTJIRA -Jukka From: Jokiniva Jukka > Date: Monday 21 December 2015 10:48 To: "development at qt-project.org" > Subject: Heads up for Qt Bug Report & Code Review users Hi, Some months ago we asked all Qt users to provide us input on ideas to further improve the Qt developer experience. You spoke. We listened. It was overwhelmingly clear that single sign-on for all Qt Services was at the top of desired features and functionality. Since then, we have been working toward providing this to you. As part of this effort, you will now have common credentials for all of the following Qt services: · Qt Account web portal for license management, downloads and commercial support · Qt Forum · Qt Wiki · Qt Bug Tracker (NEW) · Qt Code Review (NEW) Note: There will be a maintenance break on Tuesday 12 January 2016 from 07:00-11:00 a.m. (CET) when we unify the login for Qt Bug Tracker (https://bugreports.qt.io) and Qt Code Review (https://codereview.qt-project.org). IMPORTANT The email address that you currently use to log into Bug Tracker and Code Review will be associated with Qt account credentials. · If you don't already have Qt credentials, all you need to do is register at https://login.qt.io/register* using the same email address you currently use for Bug Tracker and Code Review. If you want to change to a different email address for your unified login credentials, you should first update the email address in Bug Tracker** to ensure the logins will be merged. · If you already have Qt account credentials, but use different email addresses for each account, you should ensure that your Bug Tracker email address is the same as in your Qt account profile so that all your account credentials will be merged. * Please be sure to complete the email verification process, which will be explained to you in the email sent upon registering. ** To edit your Bug Reports email address, go to https://bugreports.qt.io/secure/ViewProfile.jspa profile settings and select the pen icon. We hope you will enjoy this improvement. We will also continue to work toward adding more of features and functionality that you all asked for. Best regards, The Qt Company www.qt.io |Qt Blog: http://blog.qt.io/ | Twitter: @Qtproject | Facebook: www.facebook.com/qt -------------- next part -------------- An HTML attachment was scrubbed... URL: From milian.wolff at kdab.com Thu Jan 21 14:15:49 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 21 Jan 2016 14:15:49 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <1661788.SK9YD6j98i@agathebauer> On Donnerstag, 21. Januar 2016 05:44:05 CET Kevin Kofler wrote: > Bubke Marco wrote: > > So you optimized the container for growing with allocations. I don't think > > it is the most common case. Having cache misses in traversing the > > container can be much worse and is much harder to fix than a reserve. > > Almost all my containers grow with allocations. How should I know in advance > how much memory to reserve? It'd just waste an arbitrary amount of memory > and then still end up reallocating because it'll inevitably be exceeded at > some point. Variable-size containers are variable-size for a reason. > > I consider reserve() to be a technical detail and a micro-optimization I > really should not have to bother with in 99+% of the cases. This is very wrong. In my experience with profiling applications, the most hotspots can be fixed by adding reserve to loops where the size is known or can be guessed. This has a tremendous effect on runtime speed, also for QVector using realloc (remember: not doing something will always be faster than something, even if it's fast). If you have code that adds elements from time to time and you cannot estimate the size, then I claim the speed of these operations is irrelevant anyways. Also note how calling reserve with an estimated value ("this vector usually has about N elements") fits into the usual memory/speed trade off: You may waste memory (improve your estimate!), but it's also much faster. Bye -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From stephen.kelly at ableton.com Thu Jan 21 14:56:42 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Thu, 21 Jan 2016 14:56:42 +0100 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: References: <569E375D.4080709@ableton.com> <569E60BE.2020804@ableton.com> <569FB1C1.3080601@ableton.com> Message-ID: <56A0E39A.90609@ableton.com> On 21/01/16 00:45, Andrew den Exter wrote: > > > On Thu, Jan 21, 2016 at 2:11 AM, Stephen Kelly > > wrote: > > >> And there are the obvious runtime costs to building and >> maintaining a cache that is of little or no use to most people >> most of the time, which is I think a strong argument for it being >> an off by default feature if implemented. >> > > I think the cost would need to be measured before letting it > influence design decisions. We are not talking about monstrous > amounts of data. > > > Famous last words. I have to assume any cache is going to be > pre-populated with data from every role Wow, that sounds bad indeed. My idea is to cache when the data is first requested in a memoizing design. All of those requests go through the same classes in the QML implementation. > any binding with a conditional statement in it opens up the > possibility that a role won't be accessed until after the row is removed So you are thinking of QML code like this in a delegate: Text { text: someCondition ? model.someRole : model.otherRole } Is that correct? In that scenario, if someCondition is always true, then my memoization will cache the data for someRole, but not for otherRole. Then, the row for that delegate gets removed and it gets animated away. While it is animated away, someCondition becomes false, and the entire binding gets re-evaluated. Because the corresponding row is already gone, and because otherRole was never accessed while it was still there, the data for otherRole is not memoized, and we end up again with the a bug similar to what I posted on github with 'undefined' in the text field. Thanks for pointing that out. It is a limitation of my proposal that conditionally accessed data can still cause artifacts. So here's a summary of approaches possible for this class of bug: * Cheap memoization * Very expensive up-front cache population * Somehow inspect bindings in delegates to find out what roles they could use * Something else For data which is conditionally accessed, the memoization does not fix everything, but up-front caching could. For data which is not conditionally accessed, the memoization is enough. We can try to decide what makes sense for QML to do. Thanks, Steve. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bo at vikingsoft.eu Thu Jan 21 15:50:50 2016 From: bo at vikingsoft.eu (Bo Thorsen) Date: Thu, 21 Jan 2016 15:50:50 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <1661788.SK9YD6j98i@agathebauer> References: <201601051352.06816.marc.mutz@kdab.com> <1661788.SK9YD6j98i@agathebauer> Message-ID: <56A0F04A.8080209@vikingsoft.eu> Den 21-01-2016 kl. 14:15 skrev Milian Wolff: > On Donnerstag, 21. Januar 2016 05:44:05 CET Kevin Kofler wrote: >> I consider reserve() to be a technical detail and a micro-optimization I >> really should not have to bother with in 99+% of the cases. That's how it should be. > This is very wrong. In my experience with profiling applications, the most > hotspots can be fixed by adding reserve to loops where the size is known or > can be guessed. This has a tremendous effect on runtime speed, also for > QVector using realloc And this is how it is. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From stephen.kelly at ableton.com Thu Jan 21 15:50:57 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Thu, 21 Jan 2016 15:50:57 +0100 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: <56A084FB.9080902@familiesomers.nl> References: <569E375D.4080709@ableton.com> <569E60BE.2020804@ableton.com> <569FB1C1.3080601@ableton.com> <56A084FB.9080902@familiesomers.nl> Message-ID: <56A0F051.5010807@ableton.com> On 21/01/16 08:12, André Somers wrote: > > Actually, I think it would not need to be quite as bad. > For starters, you really only need to cache the actual items being > removed. At the moment the model emits the AboutToBeRemoved signal, > the data should still be there in any well-behaved model, right? > _That_ is the moment you do your caching. > Even 'reasonable' qaim implementations might not still be able to give you data in a handler of rowsAboutToBeRemoved. Consider for example a qaim which models a filesystem. If the data() method is written to look at the filesystem, and QFSWatcher is used as a trigger to signal removal of rows, then by the time the rowsAboutToBeRemoved signal is emitted, the file is already gone from the filesystem. QFileSystemModel solves that with an internal cache of QFileInfo instances, but you can imagine reasonable models which don't have an internal cache like that. However, requiring models to have such a cache for exactly that reason could be reasonable. It is already kind of an implicit requirement of the use case you mention. It would become a more-explicit requirement if QML relied on it like that. > While it is possible that because of conditionals in the binding roles > are accessed only during the removing, it does not sound very likely. > One could provide an API to specifically add roles to the caching > manually, but otherwise only cache roles that have been accessed > already. Or just only set the roles manually and use that as the > on/off switch for the whole feature that Andrew requested. > Realistically, for most models, this would be something like perhaps > an image and a couple of strings for an item. And these would only > need to live for a short time, because once the remove animation is > done, the data can be removed again. > > I think it is certainly worthwhile to investigate. That's good. I think we should really try to make sure there is no API needed to enable working behavior. 'Working' should be the default. Thanks, Steve. -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From stephen.kelly at ableton.com Thu Jan 21 16:13:15 2016 From: stephen.kelly at ableton.com (Stephen Kelly) Date: Thu, 21 Jan 2016 16:13:15 +0100 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: <56A0E39A.90609@ableton.com> References: <569E375D.4080709@ableton.com> <569E60BE.2020804@ableton.com> <569FB1C1.3080601@ableton.com> <56A0E39A.90609@ableton.com> Message-ID: <56A0F58B.6020508@ableton.com> On 21/01/16 14:56, Stephen Kelly wrote: > > * Something else As Andre wrote, 'something else' could be 'populate a "memory structure" for all roles for the specific rows being removed in response to rowsAboutToBeRemoved'. -- Ableton AG, Schoenhauser Allee 6-7, 10119 Berlin, Germany Management Board: Gerhard Behles, Jan Bohl Chair of the Supervisory Board: Uwe Struck Registered Office: Berlin, Amtsgericht Berlin-Charlottenburg, HRB 72838 From andre at familiesomers.nl Thu Jan 21 16:43:49 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 21 Jan 2016 16:43:49 +0100 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: <56A0F58B.6020508@ableton.com> References: <569E375D.4080709@ableton.com> <569E60BE.2020804@ableton.com> <569FB1C1.3080601@ableton.com> <56A0E39A.90609@ableton.com> <56A0F58B.6020508@ableton.com> Message-ID: <56A0FCB5.7010006@familiesomers.nl> Op 21/01/2016 om 16:13 schreef Stephen Kelly: > > On 21/01/16 14:56, Stephen Kelly wrote: >> >> * Something else > > As Andre wrote, 'something else' could be 'populate a "memory > structure" for all roles for the specific rows being removed in > response to rowsAboutToBeRemoved'. > I would not use all roles, or at least make it tweakable in some way. Some models may have a huge number of roles, or roles that are quite expensive to get and are simply not needed for the delegate. So if you insist in having this "on" by default, perhaps a property you can set can have a default signifying "all roles" while you can also set it to a set of specific roles (or simply no roles at all). I was wondering: how do you know when to drop the cached data again? André From dangelog at gmail.com Thu Jan 21 16:55:59 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Thu, 21 Jan 2016 16:55:59 +0100 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: <56A0FCB5.7010006@familiesomers.nl> References: <569E375D.4080709@ableton.com> <569E60BE.2020804@ableton.com> <569FB1C1.3080601@ableton.com> <56A0E39A.90609@ableton.com> <56A0F58B.6020508@ableton.com> <56A0FCB5.7010006@familiesomers.nl> Message-ID: On Thu, Jan 21, 2016 at 4:43 PM, André Somers wrote: > I was wondering: how do you know when to drop the cached data again? When the corresponding delegate gets evicted by ListView at the end of the removal animation. Cheers, -- Giuseppe D'Angelo From frederik.gladhorn at theqtcompany.com Thu Jan 21 16:56:56 2016 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Thu, 21 Jan 2016 16:56:56 +0100 Subject: [Development] Qt 5.6.0 header diff In-Reply-To: <3323145.M7YjbZse3O@frederik-thinkcentre-m93p> References: <3323145.M7YjbZse3O@frederik-thinkcentre-m93p> Message-ID: <10618104.JO1si2AGgf@frederik-thinkcentre-m93p> Hello, this is an update, the final header diff. Since we all agree that email is not the perfect medium for the header review (I see some open questions in the old thread), I'd thought I'll go for an attempt at pushing the diffs to gerrit. I'm not quite satisfied with the outcome, ideas for improvement are welcome (as long as they don't mean lots of work for me ;)) Here is a change containing all the different diffs: https://codereview.qt-project.org/#/c/146876/ Cheers, Frederik On Thursday, September 17, 2015 12:29:27 PM Frederik Gladhorn wrote: > Hi all, > > we are getting close to the Qt 5.6 beta and it's time for the header diff. > > >From this point on we should be very careful in adding/changing newly > > introduced API. > > I'll send the actual header diffs as attachments in follow-up mails, it will > probably take a few hours until they actually get sent. > As an addition to the previous process, we'll have new headers in existing > modules included, so that we don't accidentally ship new classes that > somehow slipped through the cracks earlier. > > For entirely new modules, I don't think that this will work though, so let's > start one thread for each module that will be added to Qt 5.6 (even for > tech previews) so that everyone interested in the module is aware of it and > can chime in to the discussion. For the new modules, use https://code.qt.io > or git to do the review. > > For Enginio, I just checked manually - there is no change in any headers in > the 1.2.1 branch vs 5.6. > > Cheers, > Frederik > > qtsdk/packaging-tools/header-diff.pl origin/5.5.1..origin/5.6 > > Found module Qt3DCollision in ./qt3d/src/collision/collision.pro > - Module has 7 public headers now > - No changes! > Found module Qt3DCore in ./qt3d/src/core/core.pro > - Module has 45 public headers now > - Qt3DCore.diff created > - New header: src/core/nodes/qabstractnodefactory.h > Found module Qt3DInput in ./qt3d/src/input/input.pro > - Module has 9 public headers now > - No changes! > Found module Qt3DLogic in ./qt3d/src/logic/logic.pro > - Module has 3 public headers now > - No changes! > Found module Qt3DRenderer in ./qt3d/src/render/render.pro > - Module has 88 public headers now > - Qt3DRenderer.diff created > - New header: src/render/frontend/qcylindergeometry.h > Found module QtAndroidExtras in > ./qtandroidextras/src/androidextras/androidextras.pro > - No public headers for module QtAndroidExtras > Found module QtConcurrent in ./qtbase/src/concurrent/concurrent.pro > - Module has 15 public headers now > - No changes! > Found module QtCore in ./qtbase/src/corelib/corelib.pro > - Module has 193 public headers now > - QtCore.diff created > - New header: src/corelib/tools/qhashfunctions.h > - New header: src/corelib/tools/qversionnumber.h > Found module QtDBus in ./qtbase/src/dbus/dbus.pro > - Module has 19 public headers now > - QtDBus.diff created > Found module QtGui in ./qtbase/src/gui/gui.pro > - Module has 130 public headers now > - QtGui.diff created > - New header: src/gui/opengl/qopenglextrafunctions.h > - New header: src/gui/painting/qrgba64.h > Found module QtNetwork in ./qtbase/src/network/network.pro > - Module has 34 public headers now > - QtNetwork.diff created > Found module QtOpenGL in ./qtbase/src/opengl/opengl.pro > - Module has 8 public headers now > - QtOpenGL.diff created > Found module QtOpenGLExtensions in > ./qtbase/src/openglextensions/openglextensions.pro > - Module has 1 public headers now > - No changes! > Found module QtPlatformSupport in > ./qtbase/src/platformsupport/platformsupport.pro > - Module has 4 public headers now > - No changes! > Found module QtPrintSupport in ./qtbase/src/printsupport/printsupport.pro > - Module has 9 public headers now > - QtPrintSupport.diff created > Found module QtSql in ./qtbase/src/sql/sql.pro > - Module has 14 public headers now > - QtSql.diff created > Found module QtTest in ./qtbase/src/testlib/testlib.pro > - Module has 18 public headers now > - QtTest.diff created > Found module QtWidgets in ./qtbase/src/widgets/widgets.pro > - Module has 135 public headers now > - QtWidgets.diff created > - New header: src/widgets/accessible/complexwidgets.h > - New header: src/widgets/accessible/itemviews.h > - New header: src/widgets/accessible/qaccessiblemenu.h > - New header: src/widgets/accessible/qaccessiblewidgets.h > - New header: src/widgets/accessible/rangecontrols.h > - New header: src/widgets/accessible/simplewidgets.h > Found module qtmain in ./qtbase/src/winmain/winmain.pro > - No public headers for module qtmain > Found module QtXml in ./qtbase/src/xml/xml.pro > - Module has 3 public headers now > - QtXml.diff created > Found module QtBluetooth in ./qtconnectivity/src/bluetooth/bluetooth.pro > - Module has 19 public headers now > - QtBluetooth.diff created > Found module QtNfc in ./qtconnectivity/src/nfc/nfc.pro > - Module has 12 public headers now > - No changes! > Found module QtQuickParticles in ./qtdeclarative/src/particles/particles.pro > - No public headers for module QtQuickParticles > Found module QtQml in ./qtdeclarative/src/qml/qml.pro > - Module has 27 public headers now > - QtQml.diff created > Found module QtQmlDevTools in > ./qtdeclarative/src/qmldevtools/qmldevtools.pro - No public headers for > module QtQmlDevTools > Found module QtQuickTest in ./qtdeclarative/src/qmltest/qmltest.pro > - Module has 2 public headers now > - QtQuickTest.diff created > Found module QtQuick in ./qtdeclarative/src/quick/quick.pro > - Module has 23 public headers now > - QtQuick.diff created > Found module QtQuickWidgets in > ./qtdeclarative/src/quickwidgets/quickwidgets.pro > - Module has 2 public headers now > - QtQuickWidgets.diff created > Found module Enginio in ./qtenginio/src/enginio_client/enginio_client.pro > - Module has 10 public headers now > fatal: bad revision 'origin/5.5.1..origin/5.6' > - Git failed, skipping > fatal: bad revision 'origin/5.5.1..origin/5.6' > Found module enginioplugin in > ./qtenginio/src/enginio_plugin/enginio_plugin.pro > - No public headers for module enginioplugin > Found module QtLocation in ./qtlocation/src/location/location.pro > - Module has 42 public headers now > - QtLocation.diff created > Found module QtPositioning in ./qtlocation/src/positioning/positioning.pro > - Module has 15 public headers now > - QtPositioning.diff created > Found module QtMacExtras in ./qtmacextras/src/macextras/macextras.pro > - No public headers for module QtMacExtras > Found module qgsttools_p in ./qtmultimedia/src/gsttools/gsttools.pro > - No public headers for module qgsttools_p > Found module QtMultimedia in ./qtmultimedia/src/multimedia/multimedia.pro > - Module has 80 public headers now > - QtMultimedia.diff created > - New header: src/multimedia/controls/qaudiorolecontrol.h > Found module QtMultimediaWidgets in > ./qtmultimedia/src/multimediawidgets/multimediawidgets.pro > - Module has 5 public headers now > - No changes! > Found module QtMultimediaQuick_p in > ./qtmultimedia/src/qtmultimediaquicktools/qtmultimediaquicktools.pro > - Module has 3 public headers now > - No changes! > Found module qtquickcontrolsplugin in > ./qtquickcontrols/src/controls/controls.pro > - No public headers for module qtquickcontrolsplugin > Found module dialogplugin in ./qtquickcontrols/src/dialogs/dialogs.pro > - No public headers for module dialogplugin > Found module qtquickextrasplugin in ./qtquickcontrols/src/extras/extras.pro > - No public headers for module qtquickextrasplugin > Found module qquicklayoutsplugin in > ./qtquickcontrols/src/layouts/layouts.pro - No public headers for module > qquicklayoutsplugin > Found module widgetsplugin in ./qtquickcontrols/src/widgets/widgets.pro > - No public headers for module widgetsplugin > Found module QtQuickTemplates in > ./qtquickcontrols2/src/templates/templates.pro > - No public headers for module QtQuickTemplates > Found module QtScript in ./qtscript/src/script/script.pro > - Module has 14 public headers now > - No changes! > Found module QtScriptTools in ./qtscript/src/scripttools/scripttools.pro > - Module has 1 public headers now > - No changes! > Found module QtSensors in ./qtsensors/src/sensors/sensors.pro > - Module has 26 public headers now > - No changes! > Found module QtSerialPort in ./qtserialport/src/serialport/serialport.pro > - Module has 3 public headers now > - QtSerialPort.diff created > Found module QtSvg in ./qtsvg/src/svg/svg.pro > - Module has 5 public headers now > - No changes! > Found module QtWaylandClient in ./qtwayland/src/client/client.pro > - No public headers for module QtWaylandClient > Found module QtCompositor in ./qtwayland/src/compositor/compositor.pro > - No public headers for module QtCompositor > Found module QtWebChannel in ./qtwebchannel/src/webchannel/webchannel.pro > - Module has 4 public headers now > - QtWebChannel.diff created > Found module QtWebEngine in ./qtwebengine/src/webengine/webengine.pro > - Module has 1 public headers now > - No changes! > Found module QtWebEngineWidgets in > ./qtwebengine/src/webenginewidgets/webenginewidgets.pro > - Module has 10 public headers now > - QtWebEngineWidgets.diff created > Found module QtWebSockets in ./qtwebsockets/src/websockets/websockets.pro > - Module has 6 public headers now > - QtWebSockets.diff created > Found module declarative_webview in ./qtwebview/src/imports/imports.pro > - No public headers for module declarative_webview > Found module QtAndroidWebView in ./qtwebview/src/jar/bundledjar.pro > - No public headers for module QtAndroidWebView > Found module QtAndroidWebView in ./qtwebview/src/jar/distributedjar.pro > - No public headers for module QtAndroidWebView > Found module QtWebView in ./qtwebview/src/webview/webview.pro > - No public headers for module QtWebView > Found module QtWinExtras in ./qtwinextras/src/winextras/winextras.pro > - No public headers for module QtWinExtras > Found module QtX11Extras in ./qtx11extras/src/x11extras/x11extras.pro > - Module has 2 public headers now > - No changes! > Found module QtXmlPatterns in > ./qtxmlpatterns/src/xmlpatterns/xmlpatterns.pro - Module has 15 public > headers now > - No changes! > > Results > Modules with no public headers: > QtAndroidExtras > QtAndroidWebView > QtAndroidWebView > QtCompositor > QtMacExtras > QtQmlDevTools > QtQuickParticles > QtQuickTemplates > QtWaylandClient > QtWebView > QtWinExtras > declarative_webview > dialogplugin > enginioplugin > qgsttools_p > qquicklayoutsplugin > qtmain > qtquickcontrolsplugin > qtquickextrasplugin > widgetsplugin > Modules with no changes to public headers: > Qt3DCollision > Qt3DInput > Qt3DLogic > QtConcurrent > QtMultimediaQuick_p > QtMultimediaWidgets > QtNfc > QtOpenGLExtensions > QtPlatformSupport > QtScript > QtScriptTools > QtSensors > QtSvg > QtWebEngine > QtX11Extras > QtXmlPatterns > Modules with new public headers: > Qt3DCore > Qt3DRenderer > QtCore > QtGui > QtMultimedia > QtWidgets > Modules for which Git failed to retrieve changes: > Enginio > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From andre at familiesomers.nl Thu Jan 21 17:01:03 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 21 Jan 2016 17:01:03 +0100 Subject: [Development] Binding evaluation during ListView delegate remove animation In-Reply-To: References: <569E375D.4080709@ableton.com> <569E60BE.2020804@ableton.com> <569FB1C1.3080601@ableton.com> <56A0E39A.90609@ableton.com> <56A0F58B.6020508@ableton.com> <56A0FCB5.7010006@familiesomers.nl> Message-ID: <56A100BF.1010800@familiesomers.nl> Op 21/01/2016 om 16:55 schreef Giuseppe D'Angelo: > On Thu, Jan 21, 2016 at 4:43 PM, André Somers wrote: >> I was wondering: how do you know when to drop the cached data again? > When the corresponding delegate gets evicted by ListView at the end of > the removal animation. Of course. Good point. André From Marco.Bubke at theqtcompany.com Thu Jan 21 17:06:33 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Thu, 21 Jan 2016 16:06:33 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <56A0F04A.8080209@vikingsoft.eu> References: <201601051352.06816.marc.mutz@kdab.com> <1661788.SK9YD6j98i@agathebauer> <56A0F04A.8080209@vikingsoft.eu> Message-ID: On January 21, 2016 3:51:09 PM Bo Thorsen wrote: > Den 21-01-2016 kl. 14:15 skrev Milian Wolff: >> On Donnerstag, 21. Januar 2016 05:44:05 CET Kevin Kofler wrote: >>> I consider reserve() to be a technical detail and a micro-optimization I >>> really should not have to bother with in 99+% of the cases. > > That's how it should be. > >> This is very wrong. In my experience with profiling applications, the most >> hotspots can be fixed by adding reserve to loops where the size is known or >> can be guessed. This has a tremendous effect on runtime speed, also for >> QVector using realloc > > And this is how it is. > make my_work_as_I_am_going_home I tried it in camel case but that was not working. :-p > Bo Thorsen, > Director, Viking Software. > > -- > Viking Software > Qt and C++ developers for hire > http://www.vikingsoft.eu > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From thiago.macieira at intel.com Thu Jan 21 17:33:05 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 21 Jan 2016 08:33:05 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <201601211002.42064.marc.mutz@kdab.com> References: <1858041.Py4cDg8Sz4@tjmaciei-mobl4> <201601211002.42064.marc.mutz@kdab.com> Message-ID: <10239462.aSIQx8Fpj0@tjmaciei-mobl4> On Thursday 21 January 2016 10:02:41 Marc Mutz wrote: > Having had to teach this stuff to customers when this came out in Qt 4, I > can tell you this distinction will not register with most Qt-newbies. > Allowing such ease of wrong API use is against my reading Qt's own design > principles ("make it hard to use an API incorrectly"). That QThread is a > QObject is a bug, not a featuee. It would be better as a non-QObject, > adding QThreadWatcher a la QFutureWatcher to enable singals. In that case, > QThread can be replaced with std::thread without much loss of generality. It wouldn't be QThread *Watcher* because it needs slots too, like quit() and terminate(). It would be more like QThreadManager. At that point, it's QThread again. I agree with you that we should make it harder for people to misuse. With the advent of lambdas, we can easily add a QThread::makeThread(lambda) and deprecate completely the overriding of virtual run(). That in turn discourages adding signals and slots. > How we'd represent a thread if QThread was dropped is a different question, > but easily resolved once we get there (QThreadHandle, or even re-using > QThread, but not as a QObject subclass). I don't see the point. We already have a threadId(). If we want to return a handle, I would call for it to be std::thread. That would imply replacing our backends with std::thread. Maybe in 2020. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mwoehlke.floss at gmail.com Thu Jan 21 17:54:33 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 21 Jan 2016 11:54:33 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601191152.06015.marc.mutz@kdab.com> <3042581.uBeHb1CvAO@tjmaciei-mobl4> Message-ID: On 2016-01-20 23:27, Kevin Kofler wrote: > Thiago Macieira wrote: >> The copy constructor is called once, then the move constructor. If >> value_type's move constructor is not noexcept, then it may throw after the >> container resized. > > Throwing an exception in a move constructor is really, really horrible. I > can see why a copy constructor would throw (out of memory, failure to > duplicate some other resource), but a move? Sure... and for the same reason you gave; out of memory. Some classes have an invariant that involves owning some allocated memory. Thus, even the move ctor must allocate memory (which is then exchanged with the instance being moved from) in order to maintain invariants. (This is, of course, why we need destructive move; we can eliminate the need to allocate when the moved-from object is also destroyed, because we can just *take* its memory in that case and not worry about the class invariants.) -- Matthew From mwoehlke.floss at gmail.com Thu Jan 21 18:01:06 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 21 Jan 2016 12:01:06 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <56A00D7B.6040701@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <39269570.93i4fJSI54@tjmaciei-mobl4> <04F92C44-73C5-4643-B2D4-1DE15C60D392@theqtcompany.com> <201601191152.06015.marc.mutz@kdab.com> <56A00D7B.6040701@kdab.com> Message-ID: On 2016-01-20 17:43, Giuseppe D'Angelo wrote: > This poses further questions down the line, such as whether it's "ok" > having an index API based on signed integers. (It is for convenience, it > is not for correctness, but I guess that's all the topic here, isn't it? > :)) As Thiago noted, C++ itself is moving *away* from size_t, even to using int in some cases. It's true, it would be nice if Qt (especially e.g. QByteArray) used ssize_t instead of int, but there are various strong reasons for using a signed integer rather than unsigned. (It makes 'did you find the index' checks much less obnoxious, it allows tail-based indexing, ...) > Qt containers are unsound for general-purpose storage. ...only if you use exceptions. Personally, I'm glad Qt *doesn't*. -- Matthew From mwoehlke.floss at gmail.com Thu Jan 21 18:10:21 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Thu, 21 Jan 2016 12:10:21 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601151220.27198.marc.mutz@kdab.com> Message-ID: On 2016-01-20 23:44, Kevin Kofler wrote: > Almost all my containers grow with allocations. How should I know in advance > how much memory to reserve? It'd just waste an arbitrary amount of memory > and then still end up reallocating because it'll inevitably be exceeded at > some point. Variable-size containers are variable-size for a reason. > > I consider reserve() to be a technical detail and a micro-optimization I > really should not have to bother with in 99+% of the cases. 99% is almost certainly an exaggeration. There are three categories of containers: - size is constant and known at compile time - size is constant and known at run time - size is variable (e.g. based on user actions) There are quite a few instances of the second category. For example, in reading a PLY file, the number of points and faces is (usually) known as soon as the header is read. Obviously, these depend on what file is being read, so the size is not a *compile* time constant, but it is known prior to filling the container, and is for the most part constant. Cases like these (or filling one container based on the contents of another) are where reserve() is extremely helpful, and most certainly more than "a technical detail and micro-optimization". That's not to say that there aren't *also* instances of the third. (And, yes, pedantically, in reality it is more like a continuum than three distinct categories.) -- Matthew From rjvbertin at gmail.com Thu Jan 21 18:29:46 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 21 Jan 2016 18:29:46 +0100 Subject: [Development] QFont::setFamily("monospace") on OS X Message-ID: <2659542.0KhKKKfcHv@portia.local> Hello, Not sure if this is the best place to ask: I think QFont::setFamily("monospace") should allow to obtain an appropriate monospace font on all platforms. It does with the XCB QPA , giving me the Consolas font (ideally it should return the fixed-width font that goes with the active (platform) style, though). On OS X with the cocoa QPA however, this gives Lucida Grande, i.e. the system fallback font. I suppose that's a bug, or is there a reason why this doesn't work as expected? Cf: https://bugreports.qt.io/browse/QTBUG-50564 R. From cavendish.qi at gmail.com Thu Jan 21 20:31:52 2016 From: cavendish.qi at gmail.com (Liang Qi) Date: Thu, 21 Jan 2016 20:31:52 +0100 Subject: [Development] QFont::setFamily("monospace") on OS X In-Reply-To: <2659542.0KhKKKfcHv@portia.local> References: <2659542.0KhKKKfcHv@portia.local> Message-ID: Perhaps QPlatformTheme::font() is related. https://github.com/qtproject/qtbase/blob/5.6/src/gui/kernel/qplatformtheme.h Regards, Liang On 21 January 2016 at 18:29, René J.V. wrote: > Hello, > > Not sure if this is the best place to ask: > I think QFont::setFamily("monospace") should allow to obtain an > appropriate monospace font on all platforms. It does with the XCB QPA , > giving me the Consolas font (ideally it should return the fixed-width font > that goes with the active (platform) style, though). > On OS X with the cocoa QPA however, this gives Lucida Grande, i.e. the > system fallback font. > > I suppose that's a bug, or is there a reason why this doesn't work as > expected? > > Cf: https://bugreports.qt.io/browse/QTBUG-50564 > > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- http://www.qiliang.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From milian.wolff at kdab.com Thu Jan 21 21:09:20 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 21 Jan 2016 21:09:20 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <56A079D1.9090501@familiesomers.nl> References: <201601051352.06816.marc.mutz@kdab.com> <3464653.Gn6Y02gMP5@tjmaciei-mobl4> <56A079D1.9090501@familiesomers.nl> Message-ID: <3484871.WaxoHX4OLg@agathebauer> On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote: > Op 21/01/2016 om 05:35 schreef Thiago Macieira: > > On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote: > >> Thiago Macieira wrote: > >>> The copy constructor is called once, then the move constructor. If > >>> value_type's move constructor is not noexcept, then it may throw after > >>> the > >>> container resized. > >> > >> Throwing an exception in a move constructor is really, really horrible. I > >> can see why a copy constructor would throw (out of memory, failure to > >> duplicate some other resource), but a move? > > > > Indeed. > > > > But the class in question may not have a move constructor. In the absence > > of one, the copy constructor gets called. > > I generally don't care. If I can't copy anymore due to running out of > memory, I'm pretty much done anyway. No reliable way to recover from > that. Might as well terminate the program. Right, _you_ don't care. But as a library one cannot usually make such claims. People may want to use it in conditions where they _do_ care, and for good reason. It would be a shame if C++ would not be applicable for such scenarios just because some people didn't care enough. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From rjvbertin at gmail.com Thu Jan 21 22:39:45 2016 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 21 Jan 2016 22:39:45 +0100 Subject: [Development] QFont::setFamily("monospace") on OS X In-Reply-To: References: <2659542.0KhKKKfcHv@portia.local> Message-ID: <1588213.cFyKctRODN@portia.local> On Thursday January 21 2016 20:31:52 Liang Qi wrote: Possibly, but that function takes a font type, not a family name. So it's probably the culprit only if it is called with the FixedFont type after someone did setFamily("monospace"). R. > Perhaps QPlatformTheme::font() is related. > > https://github.com/qtproject/qtbase/blob/5.6/src/gui/kernel/qplatformtheme.h > > Regards, > Liang > > On 21 January 2016 at 18:29, René J.V. wrote: > > > Hello, > > > > Not sure if this is the best place to ask: > > I think QFont::setFamily("monospace") should allow to obtain an > > appropriate monospace font on all platforms. It does with the XCB QPA , > > giving me the Consolas font (ideally it should return the fixed-width font > > that goes with the active (platform) style, though). > > On OS X with the cocoa QPA however, this gives Lucida Grande, i.e. the > > system fallback font. > > > > I suppose that's a bug, or is there a reason why this doesn't work as > > expected? > > > > Cf: https://bugreports.qt.io/browse/QTBUG-50564 > > > > R. > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > From andre at familiesomers.nl Thu Jan 21 22:44:02 2016 From: andre at familiesomers.nl (Andre Somers) Date: Thu, 21 Jan 2016 22:44:02 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <3484871.WaxoHX4OLg@agathebauer> References: <201601051352.06816.marc.mutz@kdab.com> <3464653.Gn6Y02gMP5@tjmaciei-mobl4> <56A079D1.9090501@familiesomers.nl> <3484871.WaxoHX4OLg@agathebauer> Message-ID: <56A15122.5020003@familiesomers.nl> On 21-1-2016 21:09, Milian Wolff wrote: > On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote: >> Op 21/01/2016 om 05:35 schreef Thiago Macieira: >>> On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote: >>>> Thiago Macieira wrote: >>>>> The copy constructor is called once, then the move constructor. If >>>>> value_type's move constructor is not noexcept, then it may throw after >>>>> the >>>>> container resized. >>>> Throwing an exception in a move constructor is really, really horrible. I >>>> can see why a copy constructor would throw (out of memory, failure to >>>> duplicate some other resource), but a move? >>> Indeed. >>> >>> But the class in question may not have a move constructor. In the absence >>> of one, the copy constructor gets called. >> I generally don't care. If I can't copy anymore due to running out of >> memory, I'm pretty much done anyway. No reliable way to recover from >> that. Might as well terminate the program. > Right, _you_ don't care. But as a library one cannot usually make such claims. > People may want to use it in conditions where they _do_ care, and for good > reason. It would be a shame if C++ would not be applicable for such scenarios > just because some people didn't care enough. > So, please, enlighten me. What would be a realistic way to recover from such an exception? André From milian.wolff at kdab.com Thu Jan 21 23:35:29 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 21 Jan 2016 23:35:29 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <56A15122.5020003@familiesomers.nl> References: <201601051352.06816.marc.mutz@kdab.com> <3484871.WaxoHX4OLg@agathebauer> <56A15122.5020003@familiesomers.nl> Message-ID: <1669457.Ltfc5S0LEZ@agathebauer> On Donnerstag, 21. Januar 2016 22:44:02 CET Andre Somers wrote: > On 21-1-2016 21:09, Milian Wolff wrote: > > On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote: > >> Op 21/01/2016 om 05:35 schreef Thiago Macieira: > >>> On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote: > >>>> Thiago Macieira wrote: > >>>>> The copy constructor is called once, then the move constructor. If > >>>>> value_type's move constructor is not noexcept, then it may throw after > >>>>> the > >>>>> container resized. > >>>> > >>>> Throwing an exception in a move constructor is really, really horrible. > >>>> I > >>>> can see why a copy constructor would throw (out of memory, failure to > >>>> duplicate some other resource), but a move? > >>> > >>> Indeed. > >>> > >>> But the class in question may not have a move constructor. In the > >>> absence > >>> of one, the copy constructor gets called. > >> > >> I generally don't care. If I can't copy anymore due to running out of > >> memory, I'm pretty much done anyway. No reliable way to recover from > >> that. Might as well terminate the program. > > > > Right, _you_ don't care. But as a library one cannot usually make such > > claims. People may want to use it in conditions where they _do_ care, and > > for good reason. It would be a shame if C++ would not be applicable for > > such scenarios just because some people didn't care enough. > > So, please, enlighten me. What would be a realistic way to recover from > such an exception? This of course heavily depends on the actual application and code path. Possible scenarios I can imagine: - drop caches to free up memory - abort current operation, assuming it will clean up after itself and went into an abnormal state, i.e. repeating it may not necessarily result in the same error - abort current operation without taking down other more important operations - abort whole application in orderly fashion (i.e. not terminate but do a real shutdown) - ... Be creative, I bet you can come up with realistic recovery situations yourself! -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From marc.mutz at kdab.com Fri Jan 22 00:59:12 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 22 Jan 2016 00:59:12 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <56A15122.5020003@familiesomers.nl> References: <201601051352.06816.marc.mutz@kdab.com> <3484871.WaxoHX4OLg@agathebauer> <56A15122.5020003@familiesomers.nl> Message-ID: <201601220059.13380.marc.mutz@kdab.com> On Thursday 21 January 2016 22:44:02 Andre Somers wrote: > On 21-1-2016 21:09, Milian Wolff wrote: > > On Donnerstag, 21. Januar 2016 07:25:21 CET André Somers wrote: > >> Op 21/01/2016 om 05:35 schreef Thiago Macieira: > >>> On Thursday 21 January 2016 05:27:50 Kevin Kofler wrote: > >>>> Thiago Macieira wrote: > >>>>> The copy constructor is called once, then the move constructor. If > >>>>> value_type's move constructor is not noexcept, then it may throw > >>>>> after the > >>>>> container resized. > >>>> > >>>> Throwing an exception in a move constructor is really, really > >>>> horrible. I can see why a copy constructor would throw (out of > >>>> memory, failure to duplicate some other resource), but a move? > >>> > >>> Indeed. > >>> > >>> But the class in question may not have a move constructor. In the > >>> absence of one, the copy constructor gets called. > >> > >> I generally don't care. If I can't copy anymore due to running out of > >> memory, I'm pretty much done anyway. No reliable way to recover from > >> that. Might as well terminate the program. > > > > Right, _you_ don't care. But as a library one cannot usually make such > > claims. People may want to use it in conditions where they _do_ care, > > and for good reason. It would be a shame if C++ would not be applicable > > for such scenarios just because some people didn't care enough. > > So, please, enlighten me. What would be a realistic way to recover from > such an exception? Take a server as an example. All it needs to do is return an error code to the client. It can prepare such an error before attempting the operation, so it will be able to produce the error message even in the case of bad_alloc. But the discussions about move ctors that throw aren't even about bad_alloc. They are about assertion exceptions. Kleopatra (KDEPIM), e.g., uses exception for assertions, precisely to be able to communicate a proper error code back to the client (Kleopatra is also a UI server). It doesn't even matter whether the program then continues to run or simply restarts itself. The important bit is to return that error code (and cancel any begun transactions) and not just drop out of the connection. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From simoneverts at gmail.com Thu Jan 21 23:55:58 2016 From: simoneverts at gmail.com (Simon Everts) Date: Thu, 21 Jan 2016 23:55:58 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <10239462.aSIQx8Fpj0@tjmaciei-mobl4> References: <1858041.Py4cDg8Sz4@tjmaciei-mobl4> <201601211002.42064.marc.mutz@kdab.com> <10239462.aSIQx8Fpj0@tjmaciei-mobl4> Message-ID: 2016-01-20 15:48 GMT+01:00 Ziller Eike : > > > But Qt is available in D and Python, too, so ... > > why do they use C++ if they so hate it? > > Maybe they don’t hate it, but still wished it had a less verbose API if you don’t need the verbosity. Understanding why people choose c++ and Qt is important when you want to look at the broader picture. I work in Industrial Automation business and program mainly in c++/Qt, c#/.NET/WPF and Js/HTML5/Polymer, targeting windows (WES) as that seems to be the standard in the PLC / Automation industry. At least on our branch... I split them in language / framework / user-interface. As that's is how I would compare them and choose the stack that's best for the job that needs to be done. If I would need to choose 1 stack to do it all it would be Qt, but that's my personal opinion. For our business C#/.NET is the standard go-to language on our department for desktop applications, simply because all our programmers know it (easy to learn?) and it's easy to hire programmers to jump-in if required. The same goes for Js/HTML5, but we use that more for the mobile / crossplatform apps. C++/Qt is used in our vision software doing image processing. We'd like to have more control over the compiler / optimizations, no garbage collector and no marshalling etc. When I try to use Qt for other apps I'm not making friends with our other programmers, but I actually find it easier to create small applications with Qt because of the simple to use and consistant API. I also find it harder to do things wrong as opposed to .NET. Also in QtCreator it's very easy and fast to call up the API reference for classes. With VisualStudio i always have to search, but maybe i'm doing something wrong here. The point is that in .NET is always need to look things up. In Qt the API more intuitive. It's important that I'm comparing Qt and .NET/WPF here, not c++ and c#. When comparing c++ and c# then I feel there is a large difference in productivity. When I've done work in C# using VisualStudio with Resharper or in Javascript/NodeJS, and then go back to c++ in QtCreater I feel not very productive. Refactoring plays a role here, but also language features. Downside of using VisualStudio with c++ is the lack of intellisense for QML (I do love the progress done in QtCreator though :) ) In C# it can be very productive to use lambda delegates as signal handlers. Or in NodeJS a lambda as a callback: const client = net.connect({port: 8124}, () => { //'connect' listener } Yesterday I tried to do something like this in a quick way for a unit-test with with the connected event of the QWebSocket, Tried connecting the signal to a lambda expression and it worked, but I wonder if it saved me time making it :) The point here is that if the API supports using those new language features, than that already could make the language feel a lot more productive. Another example would be the chaining of promises in javascript (with .then and.catch, is that possible with QFuture?) and or the async/awaitable functions in c#. When writing the user interface I definitely would prefer QML above fighting browsers with HTML/CSS or chewing XML with XAML. Although I sometimes would wish to have an easy way of styling standard components like in CSS using classes and mixins. Using qmake for small projects is also ok, it's easier to handle than a visual studio project for version control. But if the project is larger and needs to use subdirs, than i would have a hard time explaining it to other programmers. But showing them a CMakeLists.txt would scare them away i think ;) These are just some observations from my point of view, maybe some points are obvious, but I hope it can contribute to this discussion :) Best regards, Simon Everts From thiago.macieira at intel.com Fri Jan 22 00:50:58 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 21 Jan 2016 15:50:58 -0800 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: Message-ID: <1738685.gaf05j7nXm@tjmaciei-mobl4> On Thursday 21 January 2016 10:27:06 Jokiniva Jukka wrote: > Maintenance break is over and systems are back online. Use your unified Qt > Account credentials to login from now on. > > If you find bugs, please report them here: > https://bugreports.qt.io/browse/QTJIRA Looks like I will soon[*] have a problem: I use two different accounts for my Qt services. I need to use the account associated with my Intel mail address for Code Review, as that's the one associated with the Corporate CLA. But Intel's mail servers are bad (read: Exchange), so I use my personal account on JIRA. All the bug reports I'm associated with and the components I'm the default assignee for are with this account. I don't want to change it. So how do I keep receiving bug report email to my personal inbox while logged in to Gerrit with the Intel account? [*] soon because Gerrit hasn't logged me out yet. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Fri Jan 22 01:13:06 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 Jan 2016 01:13:06 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601210800.40363.marc.mutz@kdab.com> <56A081C6.40104@taschenorakel.de> <201601211103.08815.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > I was replying to Kevin. QModelIndex exactly fits his complaints about > const-&: > > It's a reference used in interfaces. As soon as you store it, though, it > may become stale at the next opportunity (like when calling a virtual > function). You're supposed to store them in QPersistentModelIndex in that > case. But QPMI is extremely expensive. > > Compare that to: > > const std::vector & foos(); > > You can either assign the result to a const-& (=QModelIndex case), get max > performance, but suffer from possible invalidation if you call out to > unknown code. Or you store it in a copy, incurring the copy, but > insulating yourself from changes to the original object > (=QPersistentModelIndex case). > > They really are two instances of the same class of problem: dangling > references. And you cannot escape that problem. Not in C++, and not in > other imperative languages, either. If you replaced QMI with an int, as > you could, for QAbstractListModels, then you'd have exactly the same > problems of invalidation (who updates your int if the row it points to > gets removed?). And my point is that in most cases, CoW avoids exactly that problem, allowing you to safely (and even thread-safely!) return newly-created data (i.e. NOT return a dangling reference), without having to deep-copy it. Model indexes are a different matter. > I don't like QList because only experts can tell which guarantees it > provides for any given type (can I keep references into the container > across appends?). Simply assume that you can't. > It's also the only container in the C++ world where iterator and reference > validity are not synonyms: An append where capacity() == size() > invalidates iterators in both QList modes, but only invalidates references > in vector-with- padding mode. Again: Consider references always invalidated. The fact that they sometimes happen to keep working is an implementation detail that must not be relied on. Would you want QList to go out of its way to invalidate references somehow (if, due to a performance optimization, the data did not actually move)? That would go against the very performance principles you are fighting for. Part of the concept of undefined behavior is that it may also appear to just work (and then it may also start breaking at any time). There is no guarantee that invoking undefined behavior will crash and burn, that would defeat the purpose of undefined behavior. So just consider working with dangling references to QList members after modifying the list to be undefined behavior. If you are keeping a reference to an element of QList or QVector across an insert / append / prepend / remove, you are doing something wrong! Those references are really only intended to be used in lines such as: myList[i] = foo; or at most in the equivalent of a "with" block in some higher-level languages, i.e., e.g.: { Foo &element = myList[i]; element.foo = foo; element.bar = bar; } (You can leave off the scope braces if you want, but my point is that at that point you should be done using element, so you may as well let it go out of scope.) Everything else is a blatant API abuse. > I don't like CoW because it creates long-range effects that are also the > underlying reason we don't like global variables. It also makes any > complexity specifications moot, because you never know whether you will > incur that extra O(N) detach. In many practical cases, the alternative is to ALWAYS deep-copy (plain assignment in STL, explicit clone() in Java or Python), so CoW will actually SAVE you many of those O(n) deep-copy operations. > I don't like QSharedPointer because it does nothing better, and lot of > things worse, than shared_ptr and was only added (long after > boost::shared_ptr and tr1::shared_ptr came into existence) because of an > overly strict sense of BC that extends beyond the Qt libraries (aka "we > can't use boost/std in our APIs"). I consider QSharedPointer good enough, and I really think a complete Qt class library should remain a goal. In particular, I also think QtAlgorithms should be undeprecated and extended with new algorithms. The goal should be that the average Qt-using developer should never have to use any STL class, and the Qt ones should have a friendlier API. This was already the case in QtAlgorithms compared to the STL algorithms, e.g., qSort had a convenient qSort(container) overload whereas std::sort requires you to write the ugly and redundant std::sort(container.begin(), container.end(), qLess());. So switching to STL algorithms was a huge step backwards in API quality. The std::sort API is also symptomatic of the main design issue of the STL: The STL API is always optimized for the complex corner case (such as wanting to sort only an arbitrary subset of a container), neglecting the convenience overloads for the common case that will matter in >99% of the cases (sorting the whole container). (Having to pass qLess explicitly is another issue, but that one is mostly a backwards compatibility issue. The bigger issue is that std::sort(container) just does not exist, even if you want the operator< comparison function the STL defaults to.) So you end up with boilerplate .begin() and .end() calls all over the place. > As for why I am receiving such heat: I don't. It's the same couple of > persons every time that troll around. I should get better at not feeding > them, sure. I see only one person trolling and that's you. Everyone on this list knows that you love the STL and the new C++ language features in C++11 and newer and would like everyone to pick them up immediately, throw away everything else and do everything the C++11 way, which you consider the one right way. But things are simply not that black and white. We also all know that you want to do very complex things with containers that many people (even on this list!) did not even know existed, let alone would have expected someone to actually try to use. Please keep in mind that you are not the average Qt-using developer. > The wider C++ community ignores Qt, and I feel that's to the detriment of > both. I think Qt should ignore the "wider C++ community", too. The STL is really a completely different beast, we only share the language-level parts. > Some try to fork the project. Somebody forking the project is exactly what is going to happen if you throw away the very things that made people use Qt. Kevin Kofler From kevin.kofler at chello.at Fri Jan 22 01:18:52 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 Jan 2016 01:18:52 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <3484871.WaxoHX4OLg@agathebauer> <56A15122.5020003@familiesomers.nl> <201601220059.13380.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > But the discussions about move ctors that throw aren't even about > bad_alloc. They are about assertion exceptions. How is a move constructor an appropriate place for a sanity check? The only way the moved object can be invalid is if the original object was already invalid. So the sanity check should have been in an appropriate place to prevent the original object from becoming invalid in the first place. Any properly implemented move satisfies the invariant that the moved object satisfies resp. violates exactly the same invariants than the original one. Kevin Kofler From kevin.kofler at chello.at Fri Jan 22 01:31:20 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 Jan 2016 01:31:20 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601161940.36706.marc.mutz@kdab.com> <201601211106.14451.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > Ivan was talking about thread-safe classes. You need to lock a mutex to > take the copy. Returning a QMap instead of a std::shared_ptr would be perfectly thread-safe there. The atomic reference counting would ensure that any thread that wants to write to the data that another thread still holds would detach first. The only way to be thread-unsafe with a QMap would be to explicitly bypass the implicit sharing by using something like std::shared_ptr, which of course doesn't make sense. Kevin Kofler From thiago.macieira at intel.com Fri Jan 22 03:14:31 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 21 Jan 2016 18:14:31 -0800 Subject: [Development] Qt 5.6.0 header diff In-Reply-To: <10618104.JO1si2AGgf@frederik-thinkcentre-m93p> References: <3323145.M7YjbZse3O@frederik-thinkcentre-m93p> <10618104.JO1si2AGgf@frederik-thinkcentre-m93p> Message-ID: <1562095.iQpZ7HGllv@tjmaciei-mobl4> On Thursday 21 January 2016 16:56:56 Frederik Gladhorn wrote: > Hello, > > this is an update, the final header diff. > Since we all agree that email is not the perfect medium for the header > review (I see some open questions in the old thread), I'd thought I'll go > for an attempt at pushing the diffs to gerrit. I'm not quite satisfied with > the outcome, ideas for improvement are welcome (as long as they don't mean > lots of work for me ;)) > > Here is a change containing all the different diffs: > https://codereview.qt-project.org/#/c/146876/ Thanks, Frederik. I'm reviewing now. You know, since we're using Gerrit, we could actually *use* Gerrit. If you check out v5.5.0, then checkout 5.6's files, commit and push, we'll get an actual diff to review, one per file. With some script magic, we can also remove noisy changes like copyright header changes and Q_NULLPTR changes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From perezmeyer at gmail.com Fri Jan 22 04:15:02 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 22 Jan 2016 00:15:02 -0300 Subject: [Development] A simple analysis of apps using qtbase's private headers Message-ID: <1642473.UpOgiBYOUB@luna> I did a **very** simple analysis of apps packaged in Debian using qtbase's private headers. My main concern was to see if we (Debian) can avoid having to rebuild them every time we push a new version of Qt to our archive. What I've found seemed interesting so I decided to share it here. The following three have something in common: they are all apps coded for Chinese people. I've been told that they need QPA's private stuff in order to have proper input systems, but I haven't checked. * fcitx-qt5 1.0.5 * gcin 2.8.4 * hime 0.9.10 If people go to the extent of using private headers for this maybe it's a very good reason to (somehow) make that part of the API public. It might make a difference for chinese coders. --8<-- The following three seems to be using at least qpa/qplatformtheme.h * KDE's frameworkintegration 5.16.0 * libqtxdg 1.3.0 * lxqt-qtplugin 0.10.0 Maybe for being able to create it's own theme? --8<-- And the rest for various reasons: * KDE's kdeclarative 5.16.0: code says to use QQuickImageProvider * KDE's kwin 5.4.3: qpa/qwindowsysteminterface.h * gammaray 2.4.0 I guess it needs to get into internal stuff. * musescore 2.0.2 An interesting false positive. It embeds Qt's code without a namespace so the resulting symbols files get catched by our tools and confuse them. * qtcurve 1.8.18: private/qwidget_p.h (no further digging) * calibre 2.48.0: quite a lot of stuff, just saw it and left it there. That's all. I really hope someone finds it interesting. -- Never attribute to malice that which is adequately explained by stupidity. http://en.wikipedia.org/wiki/Hanlon's_razor Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From Jukka.Jokiniva at theqtcompany.com Fri Jan 22 08:12:19 2016 From: Jukka.Jokiniva at theqtcompany.com (Jokiniva Jukka) Date: Fri, 22 Jan 2016 07:12:19 +0000 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: <1738685.gaf05j7nXm@tjmaciei-mobl4> References: <1738685.gaf05j7nXm@tjmaciei-mobl4> Message-ID: Unfortunately I can¹t think any optimal solution for this. Having two emails means that you need to have two Qt Accounts. I would resolve it by running Jira with my personal account on different browser. Not optimal, but works. ‹Jukka On 22/01/16 01:50, "Development on behalf of Thiago Macieira" wrote: >On Thursday 21 January 2016 10:27:06 Jokiniva Jukka wrote: >> Maintenance break is over and systems are back online. Use your unified >>Qt >> Account credentials to login from now on. >> >> If you find bugs, please report them here: >> https://bugreports.qt.io/browse/QTJIRA > >Looks like I will soon[*] have a problem: I use two different accounts >for my >Qt services. I need to use the account associated with my Intel mail >address >for Code Review, as that's the one associated with the Corporate CLA. > >But Intel's mail servers are bad (read: Exchange), so I use my personal >account on JIRA. All the bug reports I'm associated with and the >components >I'm the default assignee for are with this account. I don't want to >change it. > >So how do I keep receiving bug report email to my personal inbox while >logged >in to Gerrit with the Intel account? > >[*] soon because Gerrit hasn't logged me out yet. >-- >Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Jan 22 08:48:43 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 21 Jan 2016 23:48:43 -0800 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: <1738685.gaf05j7nXm@tjmaciei-mobl4> Message-ID: <12016268.n3Hi7QMIxB@tjmaciei-mobl4> On Friday 22 January 2016 07:12:19 Jokiniva Jukka wrote: > Unfortunately I can¹t think any optimal solution for this. > Having two emails means that you need to have two Qt Accounts. > > I would resolve it by running Jira with my personal account on different > browser. > Not optimal, but works. Not acceptable since I can't click URLs easily from the mail client. Is there any way to merge the two accounts, but still keep email delivery the way it is? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Jan 22 10:46:24 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 22 Jan 2016 10:46:24 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601211103.08815.marc.mutz@kdab.com> Message-ID: <201601221046.25376.marc.mutz@kdab.com> On Friday 22 January 2016 01:13:06 Kevin Kofler wrote: > > I don't like QList because only experts can tell which guarantees it > > provides for any given type (can I keep references into the container > > across appends?). > > Simply assume that you can't. > [...] Judging from the comments on my blog post from 2010(!), when they hear QList people first think std::list (ie. linked list). Then they see that there's also a QLinkedList and start thinking that QList is something like std::deque. And then, if they are lucky, they realise it isn't that, either. Because both of those std containers guarantee stability of references under appends, as does QList _by default_. > Everything else is a blatant API abuse. Tell that to the authors of QToolBox and QDataWidgetMapper (off the top of my head). Better yet: put code where your mouth is and fix that blatant API abuse. I'll be more than happy to give you a +2 on that one. > undeprecate QtAlgorithms And this is where I stop taking you seriously, sorry. You can demand such nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+ algorithms from the STL for Qt. Or play god deciding which are the ones "no- one will ever need" or "should never use" - IYHO. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Fri Jan 22 10:48:48 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 22 Jan 2016 10:48:48 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601211106.14451.marc.mutz@kdab.com> Message-ID: <201601221048.49038.marc.mutz@kdab.com> On Friday 22 January 2016 01:31:20 Kevin Kofler wrote: > Marc Mutz wrote: > > Ivan was talking about thread-safe classes. You need to lock a mutex to > > take the copy. > > Returning a QMap instead of a std::shared_ptr would be perfectly > thread-safe there. Wrong. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From abbapoh at gmail.com Fri Jan 22 09:43:17 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Fri, 22 Jan 2016 11:43:17 +0300 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601221048.49038.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601211106.14451.marc.mutz@kdab.com> <201601221048.49038.marc.mutz@kdab.com> Message-ID: Why? In case of QMap, we have no need to use operator= to change the map. We simply detach and insert new data in it. Of course, in case of multiple changes, the map can reach some "invalid state" before changes are finished (i.e. in case we need transacted changes, we have to use mutex anyway). But it is not neccessary in some cases. 2016-01-22 12:48 GMT+03:00 Marc Mutz : > On Friday 22 January 2016 01:31:20 Kevin Kofler wrote: > > Marc Mutz wrote: > > > Ivan was talking about thread-safe classes. You need to lock a mutex to > > > take the copy. > > > > Returning a QMap instead of a std::shared_ptr would be > perfectly > > thread-safe there. > > Wrong. > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri Jan 22 11:00:28 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 22 Jan 2016 11:00:28 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601221048.49038.marc.mutz@kdab.com> Message-ID: <201601221100.28663.marc.mutz@kdab.com> On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote: > Why? In case of QMap, we have no need to use operator= to change the map. > We simply detach and insert new data in it. > Of course, in case of multiple changes, the map can reach some "invalid > state" before changes are finished (i.e. in case we need transacted > changes, we have to use mutex anyway). But it is not neccessary in some > cases. class IWantToBeThreadSafe { int m_i; public: void setI(int i) { m_i = i; } int i() const { m_i; } }; Make this class thead-safe (without QAtomicInt :). Then replace 'int' with QMap. Then you have your answer. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Simon.Hausmann at theqtcompany.com Fri Jan 22 09:52:29 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Fri, 22 Jan 2016 08:52:29 +0000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: Message-ID: Hi, I think answering the question about the kind of airplane to build is closely tied to another question that may be worthwhile asking. I think it's worthwhile because I'm convinced that answers diverge greatly depending on who you ask. Why are we trying to build an airplane? Or differently put: What is our mission? Is our mission to transport people from A to B? Is the mission to transport goods from A to B? Is our mission to get people from A to B in the quickest way? Or is it about safety? The answer greatly influences the type of airplane to build (in the event that the airplane is the right method of transportation). I'm of the opinion that our mission should be to make life easier for programmers. That includes also novice programmers and especially people who's first language is not English. Who else agrees with me? Ways to achieve that include tooling to increase work flow productivity, intuitive and consistent APIs that are easy to remember and easy to use, especially for non-native english speakers. These are considerations that greatly affect the naming of functions (which may or may not justify diverging from the STL for example). Simon ________________________________________ From: Development on behalf of Bubke Marco Sent: Wednesday, January 20, 2016 11:48 To: Development at qt-project.org Subject: [Development] What kind of airplane we want to build? Hello After the exciting discussions in the last time with all the energy spend on them I want to try to make a short summary. Maybe we can transform the heat on some steam to progress further. ;-) I think many feel that C++ is rapidly changing. With C++ 17 on the horizon there is some excitement but also fear that Qt will not stay relevant if we not adapt. But there are arguments too about existing users who would be left in the cold we we change to much. So let use an airplane as metaphor. We built a fine piston engine airplane on that little bit cumbersome piston engine called C++. But now we see Jet engines coming up but all our technology is built the old piston engine technology so the adaption of jet engines is not that cheap. The jet engines are different but we are not sure about their advantages but we are sure it would be a big investment to change to them. So people propose different designs. Some say we should minimize investments and only apapt slowly other proposed to build a hyper mach airplane. The metaphor is not perfect but I hope it is productive enough. I think the big elephant is the massive move of the processing technology to multi cores, massive multi cores formerly known as GPUs and the new parallel mechanism which are proposed to utilize them. Resumable functions, ranges, parallel stl and how they all are called. This will change how C++ looks but how can we change Qt in that picture to utilize this new technologies. I think it would be productive for the discussion to build story of what we want to do. A story of the big picture. Maybe as a first step we can show how we tackle problems with Qt 5 and what are the proposed technologies in the future C++ standard. Maybewe see that we don't have to change so much. Maybe we find out the change would be so massive that we cannot call it Qt 6 anymore. There are many maybes because the future is uncertain but we handled uncertainty in the past so why we should not do it in the future? I really believe that before we make little changes like the containers etc. we have to find a story. A story how the future Qt should look, a story for the long run. In my opinion we have to build the story TOGETHER and this story should be build on actual experience and measured facts. We should be careful about emotions like doubt, fear or excitement. I think we should be stay calm. So we can try now this new C++ prototypes, find out how they fit with our technology like signal/slots, CoW etc.. And later if they are getting momentum we can provide our magic sauce on top to make our users more productive. And if we want change Qt much we have to provide a technology to make the adaptation of our users easy and reliable. So the gain should be bigger than the cost. I think Clang based technologies provide us some possible tools but we have to find out. It is not only about providing the tool kit for new shine projects but for existing ones too. Some maybe they don't want to change and that is a respectable decision but for the user who want and need to adapt we should make it easy. I know this sounds like common sense but after all the discussions in last time I think we should step back and get a bigger picture before starting detailed discussions again. So lets go out, start prototypes, gain experience and come back to fruitful discussions. ;-) -- Sent from cellphone, sorry for the typos _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From abbapoh at gmail.com Fri Jan 22 09:57:00 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Fri, 22 Jan 2016 11:57:00 +0300 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601221100.28663.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601221048.49038.marc.mutz@kdab.com> <201601221100.28663.marc.mutz@kdab.com> Message-ID: But i don't have multiple writers (1 thread can change map, multiple can read) and QMap actually uses atomics (so no memory ordering problems). What i'm missing? 2016-01-22 13:00 GMT+03:00 Marc Mutz : > On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote: > > Why? In case of QMap, we have no need to use operator= to change the map. > > We simply detach and insert new data in it. > > Of course, in case of multiple changes, the map can reach some "invalid > > state" before changes are finished (i.e. in case we need transacted > > changes, we have to use mutex anyway). But it is not neccessary in some > > cases. > > class IWantToBeThreadSafe { > int m_i; > public: > void setI(int i) { m_i = i; } > int i() const { m_i; } > }; > > Make this class thead-safe (without QAtomicInt :). > > Then replace 'int' with QMap. > > Then you have your answer. > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri Jan 22 11:14:47 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 22 Jan 2016 11:14:47 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601221100.28663.marc.mutz@kdab.com> Message-ID: <201601221114.47923.marc.mutz@kdab.com> On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > What > i'm missing? You haven't done the exercise with the int first. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From abbapoh at gmail.com Fri Jan 22 10:09:28 2016 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Fri, 22 Jan 2016 12:09:28 +0300 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601221114.47923.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601221100.28663.marc.mutz@kdab.com> <201601221114.47923.marc.mutz@kdab.com> Message-ID: Of course, i should add mutex to the getter and setter. 2016-01-22 13:14 GMT+03:00 Marc Mutz : > On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > > What > > i'm missing? > > You haven't done the exercise with the int first. > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.vatra at kdab.com Fri Jan 22 10:26:55 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Fri, 22 Jan 2016 11:26:55 +0200 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: Message-ID: <12864175.VQLJhK2Jco@zmeu> Hi, Personally I'd like to add to the nice to have list: the exceptions. Yeah, I know that there are some people that don't like them, but for me the exceptions are like the life vest under you seat, it is very good to have them, of course it's not that good to be in the situation to need them :), so, every plane should have them. AFAIK C++11/14 compilers have zero-cost exception, so, is there any reason why not start using them in Qt 6.0 ? Cheers, BogDan. On Wednesday 20 January 2016 10:48:20 Bubke Marco wrote: > Hello > > After the exciting discussions in the last time with all the energy spend on > them I want to try to make a short summary. Maybe we can transform the > heat on some steam to progress further. ;-) > > I think many feel that C++ is rapidly changing. With C++ 17 on the horizon > there is some excitement but also fear that Qt will not stay relevant if we > not adapt. But there are arguments too about existing users who would be > left in the cold we we change to much. > > So let use an airplane as metaphor. We built a fine piston engine airplane > on that little bit cumbersome piston engine called C++. But now we see Jet > engines coming up but all our technology is built the old piston engine > technology so the adaption of jet engines is not that cheap. The jet > engines are different but we are not sure about their advantages but we are > sure it would be a big investment to change to them. So people propose > different designs. Some say we should minimize investments and only apapt > slowly other proposed to build a hyper mach airplane. > > The metaphor is not perfect but I hope it is productive enough. > > I think the big elephant is the massive move of the processing technology to > multi cores, massive multi cores formerly known as GPUs and the new > parallel mechanism which are proposed to utilize them. Resumable functions, > ranges, parallel stl and how they all are called. This will change how C++ > looks but how can we change Qt in that picture to utilize this new > technologies. > > I think it would be productive for the discussion to build story of what we > want to do. A story of the big picture. Maybe as a first step we can show > how we tackle problems with Qt 5 and what are the proposed technologies in > the future C++ standard. > > Maybewe see that we don't have to change so much. Maybe we find out the > change would be so massive that we cannot call it Qt 6 anymore. There are > many maybes because the future is uncertain but we handled uncertainty in > the past so why we should not do it in the future? > > I really believe that before we make little changes like the containers etc. > we have to find a story. A story how the future Qt should look, a story for > the long run. In my opinion we have to build the story TOGETHER and this > story should be build on actual experience and measured facts. We should be > careful about emotions like doubt, fear or excitement. I think we should > be stay calm. > > So we can try now this new C++ prototypes, find out how they fit with our > technology like signal/slots, CoW etc.. And later if they are getting > momentum we can provide our magic sauce on top to make our users more > productive. > > And if we want change Qt much we have to provide a technology to make the > adaptation of our users easy and reliable. So the gain should be bigger > than the cost. I think Clang based technologies provide us some possible > tools but we have to find out. It is not only about providing the tool kit > for new shine projects but for existing ones too. Some maybe they don't > want to change and that is a respectable decision but for the user who want > and need to adapt we should make it easy. > > I know this sounds like common sense but after all the discussions in last > time I think we should step back and get a bigger picture before starting > detailed discussions again. > > So lets go out, start prototypes, gain experience and come back to > fruitful discussions. ;-) > > -- > Sent from cellphone, sorry for the typos > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Marco.Bubke at theqtcompany.com Fri Jan 22 10:27:56 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Fri, 22 Jan 2016 09:27:56 +0000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: Message-ID: On January 22, 2016 09:52:31 Hausmann Simon wrote: > Hi, > > I think answering the question about the kind of airplane to build is closely tied to another question that may be worthwhile > asking. I think it's worthwhile because I'm convinced that answers diverge greatly depending on who you ask. > > Why are we trying to build an airplane? > > Or differently put: What is our mission? > > Is our mission to transport people from A to B? Is the mission to transport goods from A to B? Is our mission to get people from > A to B in the quickest way? Or is it about safety? The answer greatly influences the type of airplane to build (in the event that > the airplane is the right method of transportation). > > > I'm of the opinion that our mission should be to make life easier for programmers. I strongly agree with you. One of my fears is that we add too much implicit magic to make it easier for the novice but providing headache for the average programmer. The very experienced programmer will find a way around our magic so I don't care so much about him. One example is CoW and false sharing. CoW is good for novices but an average programmer who gets a performance problem which is popping up here and there because of false sharing is lost. And don't forget performance is a feature too. If your program is slow from time to time you have to fix it. Like I was running in performance problems with the clang code model. So I think we should try to provide a two layer approach. One layer without magic where you have to be very explicit and one with magic on top. In the sense of CoW for most cases it is not important. If we return a vector member of 100 small items from time to time the difference is nelectable in the big picture. Only on some hot spots it is getting important and here we have in my opinion to measure what is better. I don't know the answer but I mistrust every deductive anwser which is based on what you think. Modern computers are fat too complex to make a guess. It is far better to measure and to measure under a simular workload.. > That includes also novice programmers and especially people who's first language is not English. > > Who else agrees with me? > > Ways to achieve that include tooling to increase work flow productivity, intuitive and consistent APIs that are easy to remember > and easy to use, especially for non-native english speakers. These are considerations that greatly affect the naming of functions > (which may or may not justify diverging from the STL for example). > > > Simon > > ________________________________________ > From: Development on behalf of Bubke Marco > Sent: Wednesday, January 20, 2016 11:48 > To: Development at qt-project.org > Subject: [Development] What kind of airplane we want to build? > > Hello > > After the exciting discussions in the last time with all the energy spend on them I want to try to make a short summary. Maybe we can transform the heat on some steam to progress further. ;-) > > I think many feel that C++ is rapidly changing. With C++ 17 on the horizon there is some excitement but also fear that Qt will not stay relevant if we not adapt. But there are arguments too about existing users who would be left in the cold we we change to much. > > So let use an airplane as metaphor. We built a fine piston engine airplane on that little bit cumbersome piston engine called C++. But now we see Jet engines coming up but all our technology is built the old piston engine technology so the adaption of jet engines is not that cheap. The jet engines are different but we are not sure about their advantages but we are sure it would be a big investment to change to them. So people propose different designs. Some say we should minimize investments and only apapt slowly other proposed to build a hyper mach airplane. > > The metaphor is not perfect but I hope it is productive enough. > > I think the big elephant is the massive move of the processing technology to multi cores, massive multi cores formerly known as GPUs and the new parallel mechanism which are proposed to utilize them. Resumable functions, ranges, parallel stl and how they all are called. This will change how C++ looks but how can we change Qt in that picture to utilize this new technologies. > > I think it would be productive for the discussion to build story of what we want to do. A story of the big picture. Maybe as a first step we can show how we tackle problems with Qt 5 and what are the proposed technologies in the future C++ standard. > > Maybewe see that we don't have to change so much. Maybe we find out the change would be so massive that we cannot call it Qt 6 anymore. There are many maybes because the future is uncertain but we handled uncertainty in the past so why we should not do it in the future? > > I really believe that before we make little changes like the containers etc. we have to find a story. A story how the future Qt should look, a story for the long run. In my opinion we have to build the story TOGETHER and this story should be build on actual experience and measured facts. We should be careful about emotions like doubt, fear or excitement. I think we should be stay calm. > > So we can try now this new C++ prototypes, find out how they fit with our technology like signal/slots, CoW etc.. And later if they are getting momentum we can provide our magic sauce on top to make our users more productive. > > And if we want change Qt much we have to provide a technology to make the adaptation of our users easy and reliable. So the gain should be bigger than the cost. I think Clang based technologies provide us some possible tools but we have to find out. It is not only about providing the tool kit for new shine projects but for existing ones too. Some maybe they don't want to change and that is a respectable decision but for the user who want and need to adapt we should make it easy. > > I know this sounds like common sense but after all the discussions in last time I think we should step back and get a bigger picture before starting detailed discussions again. > > So lets go out, start prototypes, gain experience and come back to fruitful discussions. ;-) > > -- > Sent from cellphone, sorry for the typos > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From edward.welbourne at theqtcompany.com Fri Jan 22 10:38:28 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Fri, 22 Jan 2016 09:38:28 +0000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <12864175.VQLJhK2Jco@zmeu> References: , <12864175.VQLJhK2Jco@zmeu> Message-ID: > AFAIK C++11/14 compilers have zero-cost exception, so, is there any > reason why not start using them in Qt 6.0 ? Any "zero cost" claim is with respect to some assumed base-point. ISTR exceptions require RTTI (run-time type info, as used by dynamic_cast<>), so I guess this "zero cost" claim takes for granted the cost of RTTI - which is surely non-trivial. Qt has its own meta-info so (IIUC) can be built without RTTI, so building with would be a non-trivial cost as a pre-requisite of exceptions. Eddy. From cristian.adam at gmail.com Fri Jan 22 10:48:12 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Fri, 22 Jan 2016 10:48:12 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <12864175.VQLJhK2Jco@zmeu> References: <12864175.VQLJhK2Jco@zmeu> Message-ID: On Fri, Jan 22, 2016 at 10:26 AM, Bogdan Vatra wrote: > > AFAIK C++11/14 compilers have zero-cost exception, so, is there any reason > why > not start using them in Qt 6.0 ? > > +1 Exceptions in normal path lead to faster execution than using return codes. For more information about this see this talk from MeetingC++ 2014: Writing robust code Code for this benchmarks can be found here: https://bitbucket.org/davidstone/error-handling Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri Jan 22 11:59:40 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 22 Jan 2016 11:59:40 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <12864175.VQLJhK2Jco@zmeu> Message-ID: <201601221159.41071.marc.mutz@kdab.com> On Friday 22 January 2016 10:38:28 Welbourne Edward wrote: > > AFAIK C++11/14 compilers have zero-cost exception, so, is there any > > reason why not start using them in Qt 6.0 ? > > Any "zero cost" claim is with respect to some assumed base-point. ISTR > exceptions require RTTI (run-time type info, as used by dynamic_cast<>), > so I guess this "zero cost" claim takes for granted the cost of RTTI - > which is surely non-trivial. Qt has its own meta-info so (IIUC) can be > built without RTTI, so building with would be a non-trivial cost as a > pre-requisite of exceptions. It's not just RTTI. It's also exception tables and cleanup code. So no, exceptions don't have zero cost. But they may have zero _runtime_ cost when not thrown, as MS claims for the Windows ABI on AMD64. A fair comparision would, however, not compare -fexceptions vs -fno- exceptions, but take a subsystem, and replace all manual error handling with exceptions, then compare performance and code size between the subsystem using exceptions and the version with manual error handling (as complete as possible, of course) and -fno-exceptions. I'm not sure about what outcome to expect, and I don't remember any numbers posted by anyone else, either. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From cristian.adam at gmail.com Fri Jan 22 10:55:34 2016 From: cristian.adam at gmail.com (Cristian Adam) Date: Fri, 22 Jan 2016 10:55:34 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <201601221159.41071.marc.mutz@kdab.com> References: <12864175.VQLJhK2Jco@zmeu> <201601221159.41071.marc.mutz@kdab.com> Message-ID: On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: > > I'm not sure about what outcome to expect, and I don't remember any numbers > posted by anyone else, either. > > > >From the David Stone's Writing Robust Code page 34: Performance of exceptions when not thrown ● Tested on gcc 4.9.2 ● Numbers relative to ignoring errors ● With no destructors – 12.8% overhead for exceptions – 32.8% overhead for return codes ● With destructors – 6.3% overhead for exceptions – 18.7% overhead for return codes And page 35: Performance of exceptions when thrown ● Tested on gcc 4.9.2 ● Numbers relative to ignoring errors ● With no destructors – 900% overhead for exceptions ● With destructors – 750% overhead Cheers, Cristian. -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Jan 22 11:08:14 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 22 Jan 2016 13:08:14 +0300 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <201601221159.41071.marc.mutz@kdab.com> References: <12864175.VQLJhK2Jco@zmeu> <201601221159.41071.marc.mutz@kdab.com> Message-ID: <8126091453457294@web12m.yandex.ru> 22.01.2016, 12:50, "Marc Mutz" : > On Friday 22 January 2016 10:38:28 Welbourne Edward wrote: >>  > AFAIK C++11/14 compilers have zero-cost exception, so, is there any >>  > reason why not start using them in Qt 6.0 ? >> >>  Any "zero cost" claim is with respect to some assumed base-point. ISTR >>  exceptions require RTTI (run-time type info, as used by dynamic_cast<>), >>  so I guess this "zero cost" claim takes for granted the cost of RTTI - >>  which is surely non-trivial. Qt has its own meta-info so (IIUC) can be >>  built without RTTI, so building with would be a non-trivial cost as a >>  pre-requisite of exceptions. > > It's not just RTTI. It's also exception tables and cleanup code. And this cleanup code more often than not interferes with compiler optimizations, so -fno-exceptions tends to work faster. > > So no, exceptions don't have zero cost. But they may have zero _runtime_ cost > when not thrown, as MS claims for the Windows ABI on AMD64. > > A fair comparision would, however, not compare -fexceptions vs -fno- > exceptions, but take a subsystem, and replace all manual error handling with > exceptions, then compare performance and code size between the subsystem using > exceptions and the version with manual error handling (as complete as > possible, of course) and -fno-exceptions. > > I'm not sure about what outcome to expect, and I don't remember any numbers > posted by anyone else, either. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From edward.welbourne at theqtcompany.com Fri Jan 22 11:09:57 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Fri, 22 Jan 2016 10:09:57 +0000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <12864175.VQLJhK2Jco@zmeu> <201601221159.41071.marc.mutz@kdab.com>, Message-ID: > On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: >> I'm not sure about what outcome to expect, and I don't remember any >> numbers posted by anyone else, either. Cristial replied: > From the David Stone's Writing Robust Code page 34: However, see what Marc said about how to do a proper comparison: you need to actually rewrite the code and compile with different options (including --fno-rtti, or similar, for the no-exception case); I'd also like to see comparison of the size of binaries produced. Paging bigger binaries in and out also slows programs down ... It is not clear how far Stone went in making a proper comparison, at least not from the slides I saw, Eddy. From annulen at yandex.ru Fri Jan 22 11:18:30 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 22 Jan 2016 13:18:30 +0300 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <12864175.VQLJhK2Jco@zmeu> <201601221159.41071.marc.mutz@kdab.com>, Message-ID: <8196211453457910@web12m.yandex.ru> Also, exceptions tend to hinder refactoring. -- Regards, Konstantin From bogdan.vatra at kdab.com Fri Jan 22 11:32:25 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Fri, 22 Jan 2016 12:32:25 +0200 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <201601221159.41071.marc.mutz@kdab.com> Message-ID: <1841565.rGxZQGxFVD@zmeu> On Friday 22 January 2016 10:55:34 Cristian Adam wrote: > On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: > > I'm not sure about what outcome to expect, and I don't remember any > > numbers > > posted by anyone else, either. > > From the David Stone's Writing Robust Code > page 34: > > Performance of exceptions when not thrown > ● Tested on gcc 4.9.2 > ● Numbers relative to ignoring errors > ● With no destructors > – 12.8% overhead for exceptions > – 32.8% overhead for return codes > ● With destructors > – 6.3% overhead for exceptions > – 18.7% overhead for return codes > Hmm, so, using exceptions makes your code 12-20% faster. This is a good thing, right?. Most probably the binary size will be slightly bigger, let's see if it's 12-20% bigger (my hunch is that it will not be more than 5% bigger). I'll do some tests this weekend and I'll share with you the results. > And page 35: > > Performance of exceptions when thrown > ● Tested on gcc 4.9.2 > ● Numbers relative to ignoring errors > ● With no destructors > – 900% overhead for exceptions > ● With destructors > – 750% overhead > As I said, exceptions are like *a life vest*, they should be used *only in critical situations* not everywhere. Cheers, BogDan. P.S. Android Alexandrescu has a nice video on this matter: https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C From julien.blanc at nmc-company.com Fri Jan 22 11:35:10 2016 From: julien.blanc at nmc-company.com (Julien Blanc) Date: Fri, 22 Jan 2016 11:35:10 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601210800.40363.marc.mutz@kdab.com> <56A081C6.40104@taschenorakel.de> <201601211103.08815.marc.mutz@kdab.com> Message-ID: <1453458910.12041.27.camel@nmc-company.com> Le vendredi 22 janvier 2016 à 01:13 +0100, Kevin Kofler a écrit : > > I think Qt should ignore the "wider C++ community", too. The STL is really a > completely different beast, we only share the language-level parts. That statement sounds very harsh. Please remember that your users are part of this « wider C++ community », in the sense that they rarely use Qt only. Any effort (and lots have already been done, thanks) to make Qt integrate well with other C++ code, including one that relies on modern techniques*) is greatly appreciated. I completely agree with Mark here in his statement that the lack of communication between Qt community and C++ wider community deserve both. Regards, Julien * since this thread has been talking about dangling references, please have a look at https://github.com/isocpp/CppCoreGuidelines/blob/master/docs/Lifetimes% 20I%20and%20II%20-%20v0.9.1.pdf and what will (hopefully) land in our compilers in the upcoming years -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Fri Jan 22 11:56:32 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 22 Jan 2016 13:56:32 +0300 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <1841565.rGxZQGxFVD@zmeu> References: <201601221159.41071.marc.mutz@kdab.com> <1841565.rGxZQGxFVD@zmeu> Message-ID: <8460061453460192@web12m.yandex.ru> 22.01.2016, 13:32, "Bogdan Vatra" : > On Friday 22 January 2016 10:55:34 Cristian Adam wrote: >>  On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: >>  > I'm not sure about what outcome to expect, and I don't remember any >>  > numbers >>  > posted by anyone else, either. >> >>  From the David Stone's Writing Robust Code >>   page 34: >> >>  Performance of exceptions when not thrown >>  ● Tested on gcc 4.9.2 >>  ● Numbers relative to ignoring errors >>  ● With no destructors >>      – 12.8% overhead for exceptions >>      – 32.8% overhead for return codes >>  ● With destructors >>      – 6.3% overhead for exceptions >>      – 18.7% overhead for return codes > > Hmm, so, using exceptions makes your code 12-20% faster. This is a good thing, > right?. Most probably the binary size will be slightly bigger, let's see if > it's 12-20% bigger (my hunch is that it will not be more than 5% bigger). I'll > do some tests this weekend and I'll share with you the results. > >>  And page 35: >> >>  Performance of exceptions when thrown >>  ● Tested on gcc 4.9.2 >>  ● Numbers relative to ignoring errors >>  ● With no destructors >>      – 900% overhead for exceptions >>  ● With destructors >>      – 750% overhead > > As I said, exceptions are like *a life vest*, they should be used *only in > critical situations* not everywhere. Yeah, but compiler cannot perform some optimizations even when your code does not throw anything, just because exceptions are enabled, if it does not know for sure that called code may not throw. > > Cheers, > BogDan. > > P.S. Android Alexandrescu has a nice video on this matter: > https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandrescu-Systematic-Error-Handling-in-C > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From milian.wolff at kdab.com Fri Jan 22 13:01:35 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Fri, 22 Jan 2016 13:01:35 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <1798369.RVjZQOMb0G@milian-kdab2> On Thursday, January 21, 2016 12:10:21 PM CET Matthew Woehlke wrote: > On 2016-01-20 23:44, Kevin Kofler wrote: > > Almost all my containers grow with allocations. How should I know in > > advance how much memory to reserve? It'd just waste an arbitrary amount > > of memory and then still end up reallocating because it'll inevitably be > > exceeded at some point. Variable-size containers are variable-size for a > > reason. > > > > I consider reserve() to be a technical detail and a micro-optimization I > > really should not have to bother with in 99+% of the cases. > > 99% is almost certainly an exaggeration. > > There are three categories of containers: > - size is constant and known at compile time > - size is constant and known at run time > - size is variable (e.g. based on user actions) > > There are quite a few instances of the second category. For example, in > reading a PLY file, the number of points and faces is (usually) known as > soon as the header is read. Obviously, these depend on what file is > being read, so the size is not a *compile* time constant, but it is > known prior to filling the container, and is for the most part constant. > Cases like these (or filling one container based on the contents of > another) are where reserve() is extremely helpful, and most certainly > more than "a technical detail and micro-optimization". > > That's not to say that there aren't *also* instances of the third. > > (And, yes, pedantically, in reality it is more like a continuum than > three distinct categories.) And even in the third case one can usually do an educated guess as to the expected size and use that for reserve optimizations. Inside Qt itself, I've done so most recently for moc and saw significant speedups. How you do that? Dump the final size of the container and do statistics to calculate the mean or average and use that. Then compare the performance (including memory consumption) before/after and see if it's worth it. As always, you need to actually measure instead of going by rule of thumb or hand wavy arguments. -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From oswald.buddenhagen at theqtcompany.com Fri Jan 22 15:16:54 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Fri, 22 Jan 2016 15:16:54 +0100 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: <1738685.gaf05j7nXm@tjmaciei-mobl4> References: <1738685.gaf05j7nXm@tjmaciei-mobl4> Message-ID: <20160122141654.GJ13371@troll08.it.local> On Thu, Jan 21, 2016 at 03:50:58PM -0800, Thiago Macieira wrote: > Looks like I will soon[*] have a problem: I use two different accounts for my > Qt services. I need to use the account associated with my Intel mail address > for Code Review, as that's the one associated with the Corporate CLA. > > But Intel's mail servers are bad (read: Exchange), so I use my personal > account on JIRA. All the bug reports I'm associated with and the components > I'm the default assignee for are with this account. I don't want to change it. > > So how do I keep receiving bug report email to my personal inbox while logged > in to Gerrit with the Intel account? > you're only one person, so having just one account is fine. just associate both addresses and both CLAs with it - ultimately, it's your responsibility to submit code as the right "persona" (with the right address) anyway. email delivery in gerrit is unfortunately determined by the publicly displayed primary address, so people would see your non-intel address in the reviewer list. this doesn't seem like a big deal. however, there is actually a catch ... this address is also used for the reviewed-by footers, and that might indeed be considered a big deal. :/ here's an idea: we can make an email alias on the qt-project mta (which gerrit uses for notifications), so your account (and list activity) would look all intel-y, but all mail would actually go elsewhere. this would affect all and only your qt-project activity, so this should be ok from a legal perspective. From mwoehlke.floss at gmail.com Fri Jan 22 15:16:51 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 22 Jan 2016 09:16:51 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <1669457.Ltfc5S0LEZ@agathebauer> References: <201601051352.06816.marc.mutz@kdab.com> <3484871.WaxoHX4OLg@agathebauer> <56A15122.5020003@familiesomers.nl> <1669457.Ltfc5S0LEZ@agathebauer> Message-ID: On 2016-01-21 17:35, Milian Wolff wrote: > On Donnerstag, 21. Januar 2016 22:44:02 CET Andre Somers wrote: >> So, please, enlighten me. What would be a realistic way to recover from >> such an exception? > > [...] > - abort whole application in orderly fashion (i.e. not terminate but do a real > shutdown) The above skirts is, but doesn't quite directly hit an important one: use previously allocated buffers to perform an emergency save of the current document before the application crashes and burns (e.g. inkscape), so that the error (hopefully) at least doesn't cause lost work. -- Matthew From oswald.buddenhagen at theqtcompany.com Fri Jan 22 15:23:57 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Fri, 22 Jan 2016 15:23:57 +0100 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: References: Message-ID: <20160122142357.GK13371@troll08.it.local> On Thu, Jan 21, 2016 at 10:27:06AM +0000, Jokiniva Jukka wrote: > Use your unified Qt Account credentials to login from now on. > fwiw, i'm anticipating that everyone who still used two different accounts for jira (proper) and gerrit will have problems now (though maybe not quite as tough as thiago's ;). so i'm accepting requests to remap all gerrit activity to the primary jira account and purge the duplicate. From mwoehlke.floss at gmail.com Fri Jan 22 15:30:17 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 22 Jan 2016 09:30:17 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601221100.28663.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601221048.49038.marc.mutz@kdab.com> <201601221100.28663.marc.mutz@kdab.com> Message-ID: On 2016-01-22 05:00, Marc Mutz wrote: > On Friday 22 January 2016 09:43:17 Иван Комиссаров wrote: >> Why? In case of QMap, we have no need to use operator= to change the map. >> We simply detach and insert new data in it. >> Of course, in case of multiple changes, the map can reach some "invalid >> state" before changes are finished (i.e. in case we need transacted >> changes, we have to use mutex anyway). But it is not neccessary in some >> cases. > > class IWantToBeThreadSafe { > int m_i; > public: > void setI(int i) { m_i = i; } > int i() const { m_i; } > }; > > Make this class thead-safe (without QAtomicInt :). > > Then replace 'int' with QMap. > > Then you have your answer. No, you don't. This is a blatant straw man. The original example returned a pointer-to-map that later¹ found its way into another thread. If the pointer-to-map was instead a QMap (by-value, not by-reference), there would be no problem; when someone tries to modify the map (which is now shared, under the hood, in multiple threads), a detach happens. The shared map is effectively read only and the reference is not (atomically) released until the copy completes, so there is no way for the shared map to be modified while it is shared. Thus, it is thread safe. (¹ Or at the same time. We're not talking about whether *calling that method itself* is thread safe; we would, indeed, need a mutex or other cleverness for that.) -- Matthew From pcman.tw at gmail.com Fri Jan 22 15:57:06 2016 From: pcman.tw at gmail.com (PCMan) Date: Fri, 22 Jan 2016 22:57:06 +0800 Subject: [Development] Fwd: A simple analysis of apps using qtbase's private headers In-Reply-To: References: <1642473.UpOgiBYOUB@luna> Message-ID: ---------- Forwarded message ---------- From: PCMan Date: Fri, Jan 22, 2016 at 10:56 PM Subject: Re: [Development] A simple analysis of apps using qtbase's private headers To: Lisandro Damián Nicanor Pérez Hello, I'm one of the LXQt developers so I can answer part of your questions. On Fri, Jan 22, 2016 at 11:15 AM, Lisandro Damián Nicanor Pérez < perezmeyer at gmail.com> wrote: > I did a **very** simple analysis of apps packaged in Debian using qtbase's > private headers. My main concern was to see if we (Debian) can avoid > having to > rebuild them every time we push a new version of Qt to our archive. > > What I've found seemed interesting so I decided to share it here. > > The following three have something in common: they are all apps coded for > Chinese people. I've been told that they need QPA's private stuff in order > to > have proper input systems, but I haven't checked. > > * fcitx-qt5 1.0.5 > * gcin 2.8.4 > * hime 0.9.10 > > If people go to the extent of using private headers for this maybe it's a > very > good reason to (somehow) make that part of the API public. It might make a > difference for chinese coders. > > --8<-- > > The following three seems to be using at least qpa/qplatformtheme.h > > * KDE's frameworkintegration 5.16.0 > * libqtxdg 1.3.0 > * lxqt-qtplugin 0.10.0 > > Maybe for being able to create it's own theme? > Yes, but it's not only for themes. Libqtxdg uses Qt private headers to woakround bugs in QIconTheme and QIcon. Lxqt-plugin uses Qt private qpa headers to support customized themes and make some desktop settings work correctly. Our LXQt file manager pcmanfm-qt will be using Qt private headers qdnd_p.h for workaround a regression bug of Qt 5.5 which breaks DND. Thanks! > > --8<-- > > And the rest for various reasons: > > * KDE's kdeclarative 5.16.0: code says to use QQuickImageProvider > > * KDE's kwin 5.4.3: qpa/qwindowsysteminterface.h > > * gammaray 2.4.0 I guess it needs to get into internal stuff. > > * musescore 2.0.2 An interesting false positive. It embeds Qt's code > without a > namespace so the resulting symbols files get catched by our tools and > confuse > them. > > * qtcurve 1.8.18: private/qwidget_p.h (no further digging) > > * calibre 2.48.0: quite a lot of stuff, just saw it and left it there. > > > That's all. I really hope someone finds it interesting. > > > > > > > > > > > > > > > -- > Never attribute to malice that which is adequately explained by stupidity. > http://en.wikipedia.org/wiki/Hanlon's_razor > > Lisandro Damián Nicanor Pérez Meyer > http://perezmeyer.com.ar/ > http://perezmeyer.blogspot.com/ > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robin+qt at viroteck.net Fri Jan 22 15:59:10 2016 From: robin+qt at viroteck.net (Robin Burchell) Date: Fri, 22 Jan 2016 15:59:10 +0100 Subject: [Development] Fwd: A simple analysis of apps using qtbase's private headers In-Reply-To: References: <1642473.UpOgiBYOUB@luna> Message-ID: <1453474750.3408571.499665186.24D7931E@webmail.messagingengine.com> On Fri, Jan 22, 2016, at 03:57 PM, PCMan wrote: > > The following three seems to be using at least qpa/qplatformtheme.h > > > > * KDE's frameworkintegration 5.16.0 > > * libqtxdg 1.3.0 > > * lxqt-qtplugin 0.10.0 > > > > Maybe for being able to create it's own theme? > > > > > Yes, but it's not only for themes. > Libqtxdg uses Qt private headers to woakround bugs in QIconTheme and > QIcon. > Lxqt-plugin uses Qt private qpa headers to support customized themes and > make some desktop settings work correctly. > Our LXQt file manager pcmanfm-qt will be using Qt private headers > qdnd_p.h > for workaround a regression bug of Qt 5.5 which breaks DND. > > Thanks! Do you happen to have bug IDs for the problems you're working around? From enmarantispam at gmail.com Fri Jan 22 16:09:55 2016 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Fri, 22 Jan 2016 18:09:55 +0300 Subject: [Development] Fwd: A simple analysis of apps using qtbase's private headers In-Reply-To: <1453474750.3408571.499665186.24D7931E@webmail.messagingengine.com> References: <1642473.UpOgiBYOUB@luna> <1453474750.3408571.499665186.24D7931E@webmail.messagingengine.com> Message-ID: Speaking of workarounds : I have to use this ugly hack that depends on otherwise inaccessible code to update QPrintPreviewDialog //dia is a QPrintPreviewDialog QPrintPreviewWidget* w = dia->findChild(); QMetaObject::invokeMethod(w, "updatePreview", Qt::QueuedConnection); can you please add "updatePreview" to the dialog's interface? On Fri, Jan 22, 2016 at 5:59 PM, Robin Burchell wrote: > On Fri, Jan 22, 2016, at 03:57 PM, PCMan wrote: > > > The following three seems to be using at least qpa/qplatformtheme.h > > > > > > * KDE's frameworkintegration 5.16.0 > > > * libqtxdg 1.3.0 > > > * lxqt-qtplugin 0.10.0 > > > > > > Maybe for being able to create it's own theme? > > > > > > > > > Yes, but it's not only for themes. > > Libqtxdg uses Qt private headers to woakround bugs in QIconTheme and > > QIcon. > > Lxqt-plugin uses Qt private qpa headers to support customized themes and > > make some desktop settings work correctly. > > Our LXQt file manager pcmanfm-qt will be using Qt private headers > > qdnd_p.h > > for workaround a regression bug of Qt 5.5 which breaks DND. > > > > Thanks! > > Do you happen to have bug IDs for the problems you're working around? > _______________________________________________ > 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 alexis.jeandet at member.fsf.org Fri Jan 22 16:16:26 2016 From: alexis.jeandet at member.fsf.org (Alexis Jeandet) Date: Fri, 22 Jan 2016 16:16:26 +0100 Subject: [Development] Charts and DataVis Questions Message-ID: <1453475786.3146.57.camel@member.fsf.org> Hi, I have few naive questions about Charts and DataVis modules. 1) As I understand DataVis module is mainly a 3d data visualization module while Charts is mainly a 1d data visualization module. Why not merging them to a unique data visualization module? In my lab scientists are interested in plotting 1d data in 3d or 2d plots. For example in space Physics people might be interested in plotting spacecraft electric potential vs time while looking particles spectrograms vs time. 2) The OpenGL acceleration in Charts module is really impressive, but I wonder why trying to draw big amount of points when the screen resolution is limited and why not integrating a king of downsampling algorithm as explained here: http://skemman.is/stream/get/1946/15343/37285/3/SS_MSthesis.pdf Or as implemented here: https://gitlab.com/DerManu/QCustomPlot/blob/master/src/plottables/plott able-graph.cpp#L1353 This would also reduce the memory usage of the graph. In this question I assume that OpenGL acceleration is used to plot bigger datasets I might be wrong. Best regards, Alexis. From perezmeyer at gmail.com Fri Jan 22 16:50:11 2016 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Fri, 22 Jan 2016 12:50:11 -0300 Subject: [Development] Fwd: A simple analysis of apps using qtbase's private headers In-Reply-To: References: <1642473.UpOgiBYOUB@luna> <1453474750.3408571.499665186.24D7931E@webmail.messagingengine.com> Message-ID: <3048883.7gTvH9zrlK@luna> On Friday 22 January 2016 18:09:55 NIkolai Marchenko wrote: > Speaking of workarounds : > I have to use this ugly hack that depends on otherwise inaccessible code to > update QPrintPreviewDialog > > //dia is a QPrintPreviewDialog > QPrintPreviewWidget* w = dia->findChild(); > QMetaObject::invokeMethod(w, "updatePreview", Qt::QueuedConnection); > > can you please add "updatePreview" to the dialog's interface? Is there a bug for that? -- firmaware: soft cuya licencia pagas enviando un autografo StucKman en #grulic, irc.freenode.net Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rjvbertin at gmail.com Fri Jan 22 17:08:17 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Fri, 22 Jan 2016 17:08:17 +0100 Subject: [Development] extending QtMacExtras? References: <28505033.zKFNZO87e7@patux> <5569B468-B537-47F3-9E0A-801418E1A738@digia.com> Message-ID: <1453527445.8Lrxd2GGWn@portia.local> Sorvig Morten wrote: >> One thing that's really missing from Qt at the moment is a way for an >> application that is not the foreground application to post a window in the >> foreground (cf. also my thread on extending QProcess). To my knowledge this >> can only be done by forcing the application to the foreground using the same >> technique also used by the QCocoaIntegration ctor. Crude, but sometimes >> required. > > I still don’t understand what the general-purpose API in Qt would do. Perhaps The basic GP API would provide functions like "come to the foreground"; becomeForegroundApplication(bool force) { [NSApp activateIgnoringOtherApps:force]; } No need for daemons in that case, as each application would only emit instructions about itself. >> A variant could take a WId and activate the application owning the >> corresponding window or widget. I'm not sure to what extent that would be >> trivial or even possible to implement (Jake? Morten?). It would allow to >> simulate things that can currently be done (only?) on Unix/X11: > >> 1) hand off a request from a foreground application ("A") to a background >> process or daemon ("D"), providing it a target WId > > But if WIds can’t be used in cross-application contexts (which is true for Qt > on OS X, they are NSView pointers), then you can’t send them to a background > process either. (?) Probably, but not necessarily so. It is possible to obtain a list of all open windows. It's not the most common thing to do and I forget exactly what information one obtains to identify the windows, but it did seem possible to do a simple comparison. In other words, even if you only have data that are pointers to memory you don't own, you can still compare those pointers among each other, which could then lead to finding an identifier of the target application. The interesting bit with the NSApplication class is that you can not only send requests to your own running application, but to any running application; see for instance http://stackoverflow.com/questions/13367703/cocoa-switch-focus-to-application-and-then-switch-it-back . It would of course be a lot easier if the WId were a thin wrapper that contained not only the window reference but also a reference to the owning application. Just thinking out loud, sorry :) R. From thiago.macieira at intel.com Fri Jan 22 17:40:50 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jan 2016 08:40:50 -0800 Subject: [Development] Heads up for Qt Bug Report & Code Review users In-Reply-To: <20160122141654.GJ13371@troll08.it.local> References: <1738685.gaf05j7nXm@tjmaciei-mobl4> <20160122141654.GJ13371@troll08.it.local> Message-ID: <290700464.xju5cly2Z3@tjmaciei-mobl4> On Friday 22 January 2016 15:16:54 Oswald Buddenhagen wrote: > here's an idea: we can make an email alias on the qt-project mta (which > gerrit uses for notifications), so your account (and list activity) > would look all intel-y, but all mail would actually go elsewhere. this > would affect all and only your qt-project activity, so this should be ok > from a legal perspective. That would be perfect! I don't like receiving Gerrit email in Exchange. If it ended up in my regular mailbox, all the better. Ditto for mailing lists, but this is already taken care of by disabling delivery to @intel.com and subscribing a different address. Can it be done? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jan 22 17:44:40 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jan 2016 08:44:40 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601221114.47923.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601221114.47923.marc.mutz@kdab.com> Message-ID: <2219966.eMWrpDoIDW@tjmaciei-mobl4> On Friday 22 January 2016 11:14:47 Marc Mutz wrote: > On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > > What > > i'm missing? > > You haven't done the exercise with the int first. Here's the exercise with int. This is thread-safe: int f() { return 1; } auto x = f(); ++x; No matter how many threads call f(), all of them will get a value from f, can assign it to a variable and modify without caring what other threads do. Replace int with QMap or QString and you have the same behaviour. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jan 22 17:50:52 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jan 2016 08:50:52 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <12864175.VQLJhK2Jco@zmeu> References: <12864175.VQLJhK2Jco@zmeu> Message-ID: <3384483.q7Q4vzIsBQ@tjmaciei-mobl4> On Friday 22 January 2016 11:26:55 Bogdan Vatra wrote: > AFAIK C++11/14 compilers have zero-cost exception, so, is there any reason > why not start using them in Qt 6.0 ? Yes. There's a couple of man-decades worth of work to make entire Qt thread- safe. Then there's the whole discussion about what to do in OOM situations and whether we can even reliably detect them, which I won't rehash here. If you meant it restricted to a few classes, like containers, that's achievable within one year. If we decide to do that, to make it truly useful we probably should extend to all value-type classes, like QString and QNetworkProxy. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jan 22 17:53:27 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jan 2016 08:53:27 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <8460061453460192@web12m.yandex.ru> References: <1841565.rGxZQGxFVD@zmeu> <8460061453460192@web12m.yandex.ru> Message-ID: <1652232.ipe8RTCxj3@tjmaciei-mobl4> On Friday 22 January 2016 13:56:32 Konstantin Tokarev wrote: > Yeah, but compiler cannot perform some optimizations even when your code > does not throw anything, just because exceptions are enabled, if it does > not know for sure that called code may not throw. We've been plastering our API with Q_DECL_NOTHROW. Special thanks to Marc on this. We also asked the C++ std discussion about noexcept(auto) but it's gone nowhere so far. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Jan 22 19:13:32 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 22 Jan 2016 19:13:32 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <2219966.eMWrpDoIDW@tjmaciei-mobl4> References: <201601051352.06816.marc.mutz@kdab.com> <201601221114.47923.marc.mutz@kdab.com> <2219966.eMWrpDoIDW@tjmaciei-mobl4> Message-ID: <201601221913.32414.marc.mutz@kdab.com> On Friday 22 January 2016 17:44:40 Thiago Macieira wrote: > On Friday 22 January 2016 11:14:47 Marc Mutz wrote: > > On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > > > What > > > i'm missing? > > > > You haven't done the exercise with the int first. > > Here's the exercise with int. This is thread-safe: > > int f() > { > return 1; > } > > auto x = f(); > ++x; > > No matter how many threads call f(), all of them will get a value from f, > can assign it to a variable and modify without caring what other threads > do. > > Replace int with QMap or QString and you have the same behaviour. This part of the discussion was about copying a container. You return a new instance instead. Returning a new instance does not copy, nor move, due to NRVO. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From mwoehlke.floss at gmail.com Fri Jan 22 18:34:26 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 22 Jan 2016 12:34:26 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601221913.32414.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601221114.47923.marc.mutz@kdab.com> <2219966.eMWrpDoIDW@tjmaciei-mobl4> <201601221913.32414.marc.mutz@kdab.com> Message-ID: On 2016-01-22 13:13, Marc Mutz wrote: > On Friday 22 January 2016 17:44:40 Thiago Macieira wrote: >> On Friday 22 January 2016 11:14:47 Marc Mutz wrote: >>> On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: >>>> What >>>> i'm missing? >>> >>> You haven't done the exercise with the int first. >> >> Here's the exercise with int. This is thread-safe: >> >> int f() >> { >> return 1; >> } >> >> auto x = f(); >> ++x; >> >> No matter how many threads call f(), all of them will get a value from f, >> can assign it to a variable and modify without caring what other threads >> do. >> >> Replace int with QMap or QString and you have the same behaviour. > > This part of the discussion was about copying a container. You return a new > instance instead. Returning a new instance does not copy, nor move, due to > NRVO. The same assertions would hold if Thiago had written: int f() { static int result = 1; return result; } ...or anything else for the body of f(). And in fact, you're again attacking a straw man. The implementation of getMap() was not shown; for all you know, it too might have returned a new instance every time. (Probably not, but doesn't matter.) What matters is that the result is returned *by value*. It is thread safe because it is not a reference, it is a copy. Qt containers are likewise thread safe because they behave (in a thread-safe manner) *as if* an actual copy was made (even though the actual copy might not happen until some time later, if ever). -- Matthew From Marco.Bubke at theqtcompany.com Fri Jan 22 19:02:53 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Fri, 22 Jan 2016 18:02:53 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601221114.47923.marc.mutz@kdab.com> <2219966.eMWrpDoIDW@tjmaciei-mobl4> <201601221913.32414.marc.mutz@kdab.com> Message-ID: Actually what is happen if I am in the middle of changing a qvector, and then copying the vector in an other thread? -- Sent from cellphone, sorry for the typos On January 22, 2016 18:34:46 Matthew Woehlke wrote: > On 2016-01-22 13:13, Marc Mutz wrote: >> On Friday 22 January 2016 17:44:40 Thiago Macieira wrote: >>> On Friday 22 January 2016 11:14:47 Marc Mutz wrote: >>>> On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: >>>>> What >>>>> i'm missing? >>>> >>>> You haven't done the exercise with the int first. >>> >>> Here's the exercise with int. This is thread-safe: >>> >>> int f() >>> { >>> return 1; >>> } >>> >>> auto x = f(); >>> ++x; >>> >>> No matter how many threads call f(), all of them will get a value from f, >>> can assign it to a variable and modify without caring what other threads >>> do. >>> >>> Replace int with QMap or QString and you have the same behaviour. >> >> This part of the discussion was about copying a container. You return a new >> instance instead. Returning a new instance does not copy, nor move, due to >> NRVO. > > The same assertions would hold if Thiago had written: > > int f() > { > static int result = 1; > return result; > } > > ...or anything else for the body of f(). > > And in fact, you're again attacking a straw man. The implementation of > getMap() was not shown; for all you know, it too might have returned a > new instance every time. (Probably not, but doesn't matter.) > > What matters is that the result is returned *by value*. It is thread > safe because it is not a reference, it is a copy. Qt containers are > likewise thread safe because they behave (in a thread-safe manner) *as > if* an actual copy was made (even though the actual copy might not > happen until some time later, if ever). > > -- > Matthew > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From dangelog at gmail.com Fri Jan 22 19:37:02 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Fri, 22 Jan 2016 19:37:02 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601221114.47923.marc.mutz@kdab.com> <2219966.eMWrpDoIDW@tjmaciei-mobl4> <201601221913.32414.marc.mutz@kdab.com> Message-ID: Il 22 gen 2016 6:03 PM, "Bubke Marco" ha scritto: > > Actually what is happen if I am in the middle of changing a qvector, and then copying the vector in an other thread? > If you have QVector v; , and thread 1 does v[5] = ...; thread 2 does QVector copy = v; without synchronizations, then you have a data race since QVector is only reentrant. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Fri Jan 22 19:37:33 2016 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 22 Jan 2016 19:37:33 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <1841565.rGxZQGxFVD@zmeu> References: <1841565.rGxZQGxFVD@zmeu> Message-ID: <201601221937.33298.kde@carewolf.com> On Friday 22 January 2016, Bogdan Vatra wrote: > On Friday 22 January 2016 10:55:34 Cristian Adam wrote: > > On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: > > > I'm not sure about what outcome to expect, and I don't remember any > > > numbers > > > posted by anyone else, either. > > > > From the David Stone's Writing Robust Code > > page 34: > > > > Performance of exceptions when not thrown > > ● Tested on gcc 4.9.2 > > ● Numbers relative to ignoring errors > > ● With no destructors > > > > – 12.8% overhead for exceptions > > – 32.8% overhead for return codes > > > > ● With destructors > > > > – 6.3% overhead for exceptions > > – 18.7% overhead for return codes > > Hmm, so, using exceptions makes your code 12-20% faster. This is a good > thing, right?. Most probably the binary size will be slightly bigger, > let's see if it's 12-20% bigger (my hunch is that it will not be more than > 5% bigger). I'll do some tests this weekend and I'll share with you the > results. > > > And page 35: > > > > Performance of exceptions when thrown > > ● Tested on gcc 4.9.2 > > ● Numbers relative to ignoring errors > > ● With no destructors > > > > – 900% overhead for exceptions > > > > ● With destructors > > > > – 750% overhead > > As I said, exceptions are like *a life vest*, they should be used *only in > critical situations* not everywhere. > Using them anywhere, can break code everywhere as the number of return points and code paths immediately becomes near infinite. They shouldn't be used PERIOD. 'Allan From mwoehlke.floss at gmail.com Fri Jan 22 19:37:22 2016 From: mwoehlke.floss at gmail.com (Matthew Woehlke) Date: Fri, 22 Jan 2016 13:37:22 -0500 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601221114.47923.marc.mutz@kdab.com> <2219966.eMWrpDoIDW@tjmaciei-mobl4> <201601221913.32414.marc.mutz@kdab.com> Message-ID: On 2016-01-22 13:02, Bubke Marco wrote: > Actually what is happen if I am in the middle of changing a qvector, and then copying the vector in an other thread? Are you concurrently modifying and copying *the same* vector, or a shallow copy that, under the hood, happens to be shared? The latter is no problem; as soon as you try to modify the vector, it will detach, and they'll cease being shared. The one that's just being copied is not modified. If you really have *the same* vector... Don't do that :-). Note that this implies that you are either operating on the same variable, or one thread is operating on a reference. That's not very common, and it's just not thread safe, ever¹, regardless of the data type. (¹ Well, besides atomic types, but we're talking about containers...) -- Matthew From marc.mutz at kdab.com Fri Jan 22 20:46:54 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 22 Jan 2016 20:46:54 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601221913.32414.marc.mutz@kdab.com> Message-ID: <201601222046.54850.marc.mutz@kdab.com> On Friday 22 January 2016 18:34:26 Matthew Woehlke wrote: > On 2016-01-22 13:13, Marc Mutz wrote: > > On Friday 22 January 2016 17:44:40 Thiago Macieira wrote: > >> On Friday 22 January 2016 11:14:47 Marc Mutz wrote: > >>> On Friday 22 January 2016 09:57:00 Иван Комиссаров wrote: > >>>> What > >>>> i'm missing? > >>> > >>> You haven't done the exercise with the int first. > >> > >> Here's the exercise with int. This is thread-safe: > >> > >> int f() > >> { > >> > >> return 1; > >> > >> } > >> > >> auto x = f(); > >> ++x; > >> > >> No matter how many threads call f(), all of them will get a value from > >> f, can assign it to a variable and modify without caring what other > >> threads do. > >> > >> Replace int with QMap or QString and you have the same behaviour. > > > > This part of the discussion was about copying a container. You return a > > new instance instead. Returning a new instance does not copy, nor move, > > due to NRVO. > > The same assertions would hold if Thiago had written: > > int f() > { > static int result = 1; > return result; > } > > ...or anything else for the body of f(). > > And in fact, you're again attacking a straw man. The implementation of > getMap() was not shown; for all you know, it too might have returned a > new instance every time. (Probably not, but doesn't matter.) > > What matters is that the result is returned *by value*. It is thread > safe because it is not a reference, it is a copy. Qt containers are > likewise thread safe because they behave (in a thread-safe manner) *as > if* an actual copy was made (even though the actual copy might not > happen until some time later, if ever). QVector and std::vector have exactly the same threading guarantees: concurrent reads are ok, but if you have writers, all access (incl. reads) need to be synchronized. So what you are so upset about can only be that in the case of std::vector, the copy is made immediately, and with QVector later, or never. Whether one or the other is faster depends on so many factors that one cannot give a single correct answer. It depends. On how frequently the copy is modified. On the payload type. On the size of the vector. How often the function is accessed. Just one example: If you hammer the function returning the QVector, you will see massive contention on the atomic int. Since the atomic int is embedded into the same memory chunk as the data, so is the beginning of the data (this could be fixed by padding the header to a cache line width). That means each iteration in every thread geta a hw mutex lock on reading the first few items. If the same function returned a std::vector, given a scalable allocator, the readers are completely insulated from each other, each core's cache can contain the whole data without cache-line pingpong. Which one is faster? On a dual-core, probably QVector. On a 64-core processor, probably std::vector. And all of this moot, since thread-safe object are pretty rare. Qt itself contains maybe 10. The std library maybe a handful. And if you care about performance there, you probably need some lockfree container, anyway. And once you have to externally synchronise access to the object, a const-& becomes a very valid option again. But, yes, as I wrote in "Understand the Qt containers" one area where CoW may actually be useful is in MT code. I posted a hacky code snippet there that updated a container without mutex locking, except for two very brief moments at the beginning and end, retrying if another thread was faster. But again, CoW can be retrofitted onto any value type (e.g. shared_ptr), while CoW types will never be truly value types. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Fri Jan 22 21:16:01 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 22 Jan 2016 21:16:01 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <201601222116.02039.marc.mutz@kdab.com> On Friday 22 January 2016 19:37:22 Matthew Woehlke wrote: > On 2016-01-22 13:02, Bubke Marco wrote: > > Actually what is happen if I am in the middle of changing a qvector, and > > then copying the vector in an other thread? > > Are you concurrently modifying and copying *the same* vector, or a > shallow copy that, under the hood, happens to be shared? The latter is > no problem; as soon as you try to modify the vector, it will detach, and > they'll cease being shared. The one that's just being copied is not > modified. > > If you really have *the same* vector... Don't do that :-). Note that > this implies that you are either operating on the same variable, or one > thread is operating on a reference. That's not very common, and it's > just not thread safe, ever¹, regardless of the data type. > > (¹ Well, besides atomic types, but we're talking about containers...) Actually, now that you mention this, std::vector guarantees that concurrent write access to non-overlapping regions of a single vector is ok: std::vector strings = ...; auto process = [&strings](int from, int to) { for (int i = from; i < to; ++i) strings[i] = strings[i].toLower(); } auto t = std::thread(process, 0, strings.size() / 2); process(string.size() / 2, string.size()); t1.join(); For QVector, you need to ensure the container is detached to start with. If it is shared, two threads may try to detach at the same time, racing over who gets to update the d pointer. Granted, this is easily fixed by handing iterators to the lambda, but only because that causes the QVector to detach before any thread is started. I expect this to bite when people try to use #pragma omp parallel or similar. I don't think omp parallel loops can use iterators as control variables. They need indexes. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Fri Jan 22 22:23:56 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jan 2016 13:23:56 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <3150393.RoL1FZP32S@tjmaciei-mobl4> On Friday 22 January 2016 18:02:53 Bubke Marco wrote: > Actually what is happen if I am in the middle of changing a qvector, and > then copying the vector in an other thread? s/qvector/int/ and that answers your question. If you're mutating the same variable, then either use a mutex or use atomic operations (for which there aren't any for QVector). If you're operating on different variables, then you're safe, regardless of where the actual data came from. If you're only reading the same variable and the proper memory barriers were in place for obtaining it, then you can do that without a mutex or atomic operations. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jan 22 22:26:13 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jan 2016 13:26:13 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> Message-ID: <7694759.xjciv3vTvn@tjmaciei-mobl4> On Friday 22 January 2016 13:37:22 Matthew Woehlke wrote: > If you really have *the same* vector... Don't do that :-). Note that > this implies that you are either operating on the same variable, or one > thread is operating on a reference. That's not very common, and it's > just not thread safe, ever¹, regardless of the data type. > > (¹ Well, besides atomic types, but we're talking about containers...) You may still have data races of more benign kind, like read-after-write and write-after-write. If two threads race to write a value, it's undetermined which one wins. "Atomic" does not imply "magic" :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From lorn.potter at gmail.com Fri Jan 22 22:36:06 2016 From: lorn.potter at gmail.com (Lorn Potter) Date: Sat, 23 Jan 2016 07:36:06 +1000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: Message-ID: <56A2A0C6.7090104@gmail.com> On 22/01/16 18:52, Hausmann Simon wrote: > I'm of the opinion that our mission should be to make life easier for programmers. I think this has always been the main mission for Qt. From lorn.potter at gmail.com Fri Jan 22 22:42:21 2016 From: lorn.potter at gmail.com (Lorn Potter) Date: Sat, 23 Jan 2016 07:42:21 +1000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <201601221937.33298.kde@carewolf.com> References: <1841565.rGxZQGxFVD@zmeu> <201601221937.33298.kde@carewolf.com> Message-ID: <56A2A23D.4040005@gmail.com> On 23/01/16 04:37, Allan Sandfeld Jensen wrote: >> As I said, exceptions are like*a life vest*, they should be used *only in >> >critical situations* not everywhere. >> > > Using them anywhere, can break code everywhere as the number of return points > and code paths immediately becomes near infinite. They shouldn't be used > PERIOD. +1 I've been thankful I have not had to deal with exception handling when working with Qt. From kevin.kofler at chello.at Fri Jan 22 22:51:30 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 Jan 2016 22:51:30 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601211103.08815.marc.mutz@kdab.com> <201601221046.25376.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > Judging from the comments on my blog post from 2010(!), when they hear > QList people first think std::list (ie. linked list). Then they see that > there's also a QLinkedList and start thinking that QList is something like > std::deque. And then, if they are lucky, they realise it isn't that, > either. Because both of those std containers guarantee stability of > references under appends, as does QList _by default_. It's funny, because having learned C++ mostly together with Qt, I just see std::list and std::deque as terse and incomplete names, and so std::list is what I think is incorrectly named, not QList. :-) Qt would never approve a name like "deque" in an API review! Sure, Qt 3's QList was also a linked list, but I have internalized the Qt 4 changes by now. >> Everything else is a blatant API abuse. > > Tell that to the authors of QToolBox and QDataWidgetMapper (off the top of > my head). Better yet: put code where your mouth is and fix that blatant > API abuse. I'll be more than happy to give you a +2 on that one. Oh, there's code inside Qt that sits on references into containers? Ewww! >> undeprecate QtAlgorithms > > And this is where I stop taking you seriously, sorry. You can demand such > nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+ > algorithms from the STL for Qt. Or play god deciding which are the ones > "no- one will ever need" or "should never use" - IYHO. I'd already be happy with those that were (are, actually) already there. I'd rather have 10-20 common algorithms with a convenient API than 80+ obscure ones that force me to use iterators (especially the boilerplate .begin() and .end() iterators that will be used in 99+% of the cases – copy&paste programming sucks). Kevin Kofler From marc.mutz at kdab.com Sat Jan 23 00:11:27 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 23 Jan 2016 00:11:27 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601222046.54850.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601222046.54850.marc.mutz@kdab.com> Message-ID: <201601230011.27639.marc.mutz@kdab.com> On Friday 22 January 2016 20:46:54 Marc Mutz wrote: > Which one is faster? On a dual-core, probably QVector. On a 64-core > processor, probably std::vector. Running attached test program (4 cores + 2-fold HT), I get these numbers: QVector; 1: 483 2: 492 4: 498 8: 503 16: 502 32: 513 64: 631 128: 615 256: 1070 512: 2202 1024: 3987 2048: 8531 4096: 16385 std::vector: 1: 132 2: 130 4: 125 8: 123 16: 140 32: 233 64: 370 128: 546 256: 994 512: 1931 1024: 3759 2048: 7383 4096: 14841 'Nuff said. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cpp Type: text/x-c++src Size: 1292 bytes Desc: not available URL: From marc.mutz at kdab.com Sat Jan 23 00:13:30 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 23 Jan 2016 00:13:30 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601230011.27639.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601222046.54850.marc.mutz@kdab.com> <201601230011.27639.marc.mutz@kdab.com> Message-ID: <201601230013.30690.marc.mutz@kdab.com> On Saturday 23 January 2016 00:11:27 Marc Mutz wrote: > Running attached test program (4 cores + 2-fold HT), I get these numbers: Same machine as described earlier. Linux 3.2, GCC 5.3, libc 2.13, 8GiB RAM. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From kevin.kofler at chello.at Fri Jan 22 23:51:41 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 Jan 2016 23:51:41 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601211106.14451.marc.mutz@kdab.com> <201601221048.49038.marc.mutz@kdab.com> Message-ID: Иван Комиссаров wrote: > Why? In case of QMap, we have no need to use operator= to change the map. > We simply detach and insert new data in it. Even operator= would actually be safe here. Kevin Kofler From kevin.kofler at chello.at Fri Jan 22 23:56:16 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 22 Jan 2016 23:56:16 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601221114.47923.marc.mutz@kdab.com> <2219966.eMWrpDoIDW@tjmaciei-mobl4> <201601221913.32414.marc.mutz@kdab.com> Message-ID: Giuseppe D'Angelo wrote: > If you have QVector v; , and > > thread 1 does v[5] = ...; > thread 2 does QVector copy = v; > > without synchronizations, then you have a data race since QVector is only > reentrant. Of course you would. You would have a data race there even without CoW. Kevin Kofler From kevin.kofler at chello.at Sat Jan 23 00:12:30 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 Jan 2016 00:12:30 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601221913.32414.marc.mutz@kdab.com> <201601222046.54850.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > But again, CoW can be retrofitted onto any value type (e.g. > shared_ptr), while CoW types will never be truly value types. Again this nonsensical claim that shared_ptr is CoW. I already replied once explaining that it is not. Or where do you see a copy on write being done? shared_ptr does NOT detach. It is explicitly shared, you have to manually deep-copy the contained T object if you need a deep copy. It does track an atomic reference count, so it should be possible to implement CoW on top of shared_ptr, but shared_ptr by itself is not CoW. There is no CoW smart pointer in the STL. Kevin Kofler From thiago.macieira at intel.com Sat Jan 23 00:35:33 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jan 2016 15:35:33 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601221046.25376.marc.mutz@kdab.com> Message-ID: <1532691.AmSeZvPznq@tjmaciei-mobl4> On Friday 22 January 2016 22:51:30 Kevin Kofler wrote: > Sure, Qt 3's QList was also a linked list, but I have internalized the Qt 4 > changes by now. Nitpick: that's Qt 2's QList. In Qt 3, we had QValueList and QPtrList. Qt 3's QValueList (which was a linked list) became Qt 4's QList whereas QPtrList became Q3PtrList. http://doc.qt.io/archives/2.3/qlist.html http://doc.qt.io/archives/3.3/qvaluelist.html http://doc.qt.io/archives/3.3/qptrlist.html Qt2's QList inherited from QGList, which inherited from QCollection, which has virtuals. That's early 90's OOP for you! -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Sat Jan 23 01:12:51 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 Jan 2016 01:12:51 +0100 Subject: [Development] What kind of airplane we want to build? References: <201601201512.48597.marc.mutz@kdab.com> <5DE56EBC-DBE4-44C6-988A-235267FF7749@theqtcompany.com> Message-ID: Ziller Eike wrote: >> I would like that trend to continue. The likely next candidates are >> threads, futures and locks. > > +1 I wonder why everyone so far agreed on that. So let me dissent: I think having these things in Qt with Qt-style APIs is a good thing and I don't see why we should discard our solution for the STL one. At most, where it makes sense, we could wrap the STL stuff as we're doing with std::atomic. > I find it much nicer and more readable if I can just write sort(v). +1! And I don't think ranges are the answer here. It's just another layer of overengineered abstraction (as they will surely be implemented as a pair of iterators in practice) when in 99+% of the cases you just want to operate on the whole container anyway. > Or "const List foos = transformed(myThings, &Thing::foo);" > instead of "List foos; std::transform(myThings.begin(), myThings.end(), > std::back_inserter(foos), std::mem_fn(&Thing::foo));” (notice that “foos” > is also not const in the “pure" std version) Wow, the STL version is horrible! std::back_inserter is particularly ugly, and the usual misleading STL name (which suggests "backwards", when actually it means "to the back", so when inserting multiple elements, forward) does not help either. > We started some experiments with convenience wrappers for std algorithms > for use in Qt Creator when we started requiring C++11: > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h Interesting. That could be a starting point for a QtAlgorithms successor. >> why do they use C++ if they so hate it? > > Maybe they don’t hate it, but still wished it had a less verbose API if > you don’t need the verbosity. The funny thing is that only redundant boilerplate is verbose in the STL. The stuff that matters, the API names, are horribly terse (e.g. "deque"). And I don't hate the C++ language, only its standard library. The language is actually great, much better than Java or Python. So, since Qt lets me not touch the STL with a 10-foot pole, I see no problem with using C++. (Qt is also by far the best class library out there.) Kevin Kofler From kevin.kofler at chello.at Sat Jan 23 01:23:30 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 Jan 2016 01:23:30 +0100 Subject: [Development] What kind of airplane we want to build? References: Message-ID: Bubke Marco wrote: > I think many feel that C++ is rapidly changing. I feel it's actually TOO rapidly changing. C++11 even threw out C compatibility, not only by not adopting all C99 improvements (e.g. VLAs), but also by subtly interpreting even as simple valid C90 code as "auto x = 1.5;" in an incompatible way. (OK, that code is not valid C++98, but at least a C++98 compiler would tell you what is wrong with it, C++11 just silently gives it a different meaning.) I consider the fix of the "have to write '> >' to close double templates" issue as the most useful improvement in the entire C++11 standard. > Maybewe see that we don't have to change so much. Maybe we find out the > change would be so massive that we cannot call it Qt 6 anymore. There are > many maybes because the future is uncertain but we handled uncertainty in > the past so why we should not do it in the future? Please do not make major changes to Qt that break all existing code, or even replace it with something entirely different. It causes major pain. There is useful software out there still stuck on Qt 3 years after Qt 4.0.0, and the changes you suggest would be even much worse than the Qt 3 to 4 transition. Kevin Kofler From thiago.macieira at intel.com Sat Jan 23 01:39:47 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jan 2016 16:39:47 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <5DE56EBC-DBE4-44C6-988A-235267FF7749@theqtcompany.com> Message-ID: <1563853.VKhDmtlTSd@tjmaciei-mobl4> On Saturday 23 January 2016 01:12:51 Kevin Kofler wrote: > I wonder why everyone so far agreed on that. So let me dissent: I think > having these things in Qt with Qt-style APIs is a good thing and I don't see > why we should discard our solution for the STL one. At most, where it makes > sense, we could wrap the STL stuff as we're doing with std::atomic. But I have no plans on extending QAtomicInteger and QAtomicPointer further. There are a couple of missing features that will probably never be implemented: * std::memory_order_consume and std::memory_order_cst * GCC's extension for hidden lock elision * compare_exchange_weak (doesn't affect Intel, so I don't care) * weaker memory model for the failing compare_exchange's reload * atomics on non-integral and non-pointer types, including larger types * volatile support >From my point of view, if you need to go further on atomics, you should just use std::atomic. We could introduce QAtomic which wraps the std::atomic API and adds the Qt- style names. Is it worth it? > > We started some experiments with convenience wrappers for std algorithms > > for use in Qt Creator when we started requiring C++11: > > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algor > > ithm.h > Interesting. That could be a starting point for a QtAlgorithms successor. Agreed. Instead of reimplementing , expanding them for convenience API. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Sat Jan 23 01:44:32 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sat, 23 Jan 2016 01:44:32 +0100 Subject: [Development] What kind of airplane we want to build? References: <201601210237.43792.marc.mutz@kdab.com> <1858041.Py4cDg8Sz4@tjmaciei-mobl4> <201601211002.42064.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > I'm not saying we don't need new API should we replace QThread with > std::thead. I'm saying that all the hard, impressive, work is already > done. It seems to be mostly a question of API now. It shall be noted that QThread has backends for both POSIX threads (pthreads) and Win32 threads, whereas (last I checked) at least GCC's libstdc++ supports only POSIX threads for std::thread, so you have to use a pthreads compatibility layer to use std::thread with MinGW. Kevin Kofler From thiago.macieira at intel.com Sat Jan 23 01:47:38 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jan 2016 16:47:38 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: Message-ID: <484507646.2gnxYCXCBF@tjmaciei-mobl4> On Saturday 23 January 2016 01:23:30 Kevin Kofler wrote: > I feel it's actually TOO rapidly changing. C++11 even threw out C > compatibility, not only by not adopting all C99 improvements (e.g. VLAs), > but also by subtly interpreting even as simple valid C90 code as "auto x = > 1.5;" in an incompatible way. (OK, that code is not valid C++98, but at > least a C++98 compiler would tell you what is wrong with it, C++11 just > silently gives it a different meaning.) I disagree with you on all points here. C++ is *not* moving too fast. In some areas, it's not moving even fast enough: where's the reflection support? Meanwhile, discussions linger in the standards proposal mailing list about how many templates we need for parsing a string to integer. Specifically on VLAs, the proposal was added to C++14, but dropped due to disagreement. C++ would have implemented a subset of C99's requirement, but not the controversial parts like taking a sizeof and getting the runtime size and passing them as parameters. The less we talk about void f(int n, char array[static n]); the better. On auto, it's not a big loss. So what if it's incompatible between C and C++? NO ONE writes "auto" anymore in C, since the only place where you can use it are places where it's redundant. As for the case you showed, even C99 deprecated it. I miss designated initialisers and that is a shame. When that comes around, the discussion always goes on to talk about named parameters, which meets stiff resistance in the committee. > I consider the fix of the "have to write '> >' to close double templates" > issue as the most useful improvement in the entire C++11 standard. Not variadic templates? Not constexpr? Not decltype? Not rvalue references? By the way, if you Google for "C++ most vexing", you'll see a problem that is still not solved and probably won't be. > Please do not make major changes to Qt that break all existing code, or even > replace it with something entirely different. It causes major pain. There > is useful software out there still stuck on Qt 3 years after Qt 4.0.0, and > the changes you suggest would be even much worse than the Qt 3 to 4 > transition. We will have to eventually break some things. Compatibility with old code has kept QIODevice stuck in time, unable to move forward and implement important things like zero-copy buffering. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Jan 23 01:59:03 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 22 Jan 2016 16:59:03 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <201601211002.42064.marc.mutz@kdab.com> Message-ID: <4356122.UEOl9Hzj8u@tjmaciei-mobl4> On Saturday 23 January 2016 01:44:32 Kevin Kofler wrote: > Marc Mutz wrote: > > I'm not saying we don't need new API should we replace QThread with > > std::thead. I'm saying that all the hard, impressive, work is already > > done. It seems to be mostly a question of API now. > > It shall be noted that QThread has backends for both POSIX threads > (pthreads) and Win32 threads, whereas (last I checked) at least GCC's > libstdc++ supports only POSIX threads for std::thread, so you have to use a > pthreads compatibility layer to use std::thread with MinGW. That's libwinpthread, which exists and is deployed with MinGW. We just happen not to use it in Qt because we shouldn't use a wrapper if we already have the code that goes deeper. There's also nothing stopping MinGW developers from writing the backend for regular Windows thread support. But until they do, using std::thread means using a wrapper that abstracts the abstraction layer around that which we have code for... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From szehowe.koh at gmail.com Sat Jan 23 04:30:05 2016 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Sat, 23 Jan 2016 11:30:05 +0800 Subject: [Development] Doc: Making it easier for devs to know if a class is supported on a given platform Message-ID: Hi all, With the proliferation of supported platforms and add-on modules, we now have a situation where some classes are only useable on particular platforms. There've been cases where a developer sees a class in the Qt docs and thinks "Ooh, this is just what I need!", only to find out (after spending time studying examples and writing code) that the class can't be used on their platform of interest. [1] It would be nice to help them find out earlier whether a class is available or not. We currently have some documentation, e.g. http://doc.qt.io/qt-5/qtmodules.html lists "Target Platforms" for add-on modules. However, a user who finds the class ref via a search engine might miss this. One idea is to add a "Target Platforms" row in the class reference, below the "Header", "qmake", and "Inherits" rows. qdoc could populate this for each class based on info provided about the module. However, we have a situation in Qt Multimedia where the module is broadly available, but particular features are not: https://wiki.qt.io/Qt_5.5.0_Multimedia_Backends so Qt Multimedia is available on iOS but QAudioProbe is not. The previous idea for an auto-populated "Target Platforms" row would be erroneous in this case. Perhaps we could have a per-class "\supports" qdoc command, or even manually type in a line saying "This class is (not) supported on _____"? (I'm happy to spend time doing this, but it's not a very maintainable solution) Any other thoughts/ideas? (I haven't thought through QML types yet) Regards, Sze-Howe [1] http://forum.qt.io/topic/63110/list-of-video-formats-qt-supports/14?page=2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominik.holland at pelagicore.com Sat Jan 23 11:27:49 2016 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Sat, 23 Jan 2016 11:27:49 +0100 Subject: [Development] Doc: Making it easier for devs to know if a class is supported on a given platform In-Reply-To: References: Message-ID: <56A355A5.3090505@pelagicore.com> Hi, how about doing the automatic population, but every class is able to override this by using the "\supports" command. Maybe it would be also possible to add an link in the Target Platforms row to the platform overview page of that modules (here qtmultimedia could document what's available on which platform) Dominik Am 23.01.16 um 04:30 schrieb Sze Howe Koh: > Hi all, > > With the proliferation of supported platforms and add-on modules, we now > have a situation where some classes are only useable on particular > platforms. There've been cases where a developer sees a class in the Qt > docs and thinks "Ooh, this is just what I need!", only to find out > (after spending time studying examples and writing code) that the class > can't be used on their platform of interest. [1] > > It would be nice to help them find out earlier whether a class is > available or not. > > We currently have some documentation, e.g. > http://doc.qt.io/qt-5/qtmodules.html lists "Target Platforms" for add-on > modules. However, a user who finds the class ref via a search engine > might miss this. > > One idea is to add a "Target Platforms" row in the class reference, > below the "Header", "qmake", and "Inherits" rows. qdoc could populate > this for each class based on info provided about the module. > > However, we have a situation in Qt Multimedia where the module is > broadly available, but particular features are > not: https://wiki.qt.io/Qt_5.5.0_Multimedia_Backends so Qt Multimedia is > available on iOS but QAudioProbe is not. > > The previous idea for an auto-populated "Target Platforms" row would be > erroneous in this case. Perhaps we could have a per-class "\supports" > qdoc command, or even manually type in a line saying "This class is > (not) supported on _____"? (I'm happy to spend time doing this, but it's > not a very maintainable solution) > > Any other thoughts/ideas? (I haven't thought through QML types yet) > > > Regards, > Sze-Howe > > [1] http://forum.qt.io/topic/63110/list-of-video-formats-qt-supports/14?page=2 > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From nospam at vuorela.dk Sat Jan 23 12:15:09 2016 From: nospam at vuorela.dk (Sune Vuorela) Date: Sat, 23 Jan 2016 11:15:09 +0000 (UTC) Subject: [Development] Fwd: A simple analysis of apps using qtbase's private headers References: <1642473.UpOgiBYOUB@luna> <1453474750.3408571.499665186.24D7931E@webmail.messagingengine.com> <3048883.7gTvH9zrlK@luna> Message-ID: On 2016-01-22, Lisandro Damián Nicanor Pérez Meyer wrote: > On Friday 22 January 2016 18:09:55 NIkolai Marchenko wrote: >> Speaking of workarounds : >> I have to use this ugly hack that depends on otherwise inaccessible c= > ode to >> update QPrintPreviewDialog >>=20 >> //dia is a QPrintPreviewDialog >> QPrintPreviewWidget* w =3D dia->findChild(); >> QMetaObject::invokeMethod(w, "updatePreview", Qt::QueuedConnection); >>=20 >> can you please add "updatePreview" to the dialog's interface? > > Is there a bug for that? Or even better. A gerrit submission. /Sune From Uwe.Rathmann at tigertal.de Sat Jan 23 13:45:04 2016 From: Uwe.Rathmann at tigertal.de (Uwe Rathmann) Date: Sat, 23 Jan 2016 12:45:04 +0000 (UTC) Subject: [Development] Charts and DataVis Questions References: <1453475786.3146.57.camel@member.fsf.org> Message-ID: Hi, > The OpenGL acceleration in Charts module is really impressive ... Unfortunately part of the truth is, that the performance of the software renderer does not necessarily be that far behind. An example: in a test program I'm creating a polygon of 10000 points in an area of 1000x1000 using (qAbs(random) % 1000) and then I'm drawing it this way: void draw( const QPolygonF &points, QPaintDevice &paintDevice ) { QPainter painter( &paintDevice ); painter.setPen( QPen( Qt::black, 2 ) ); painter.drawPolyline( points ); painter.end(); } As I want to compare hardware vs. software renderer I'm using Qt 4.8 with X11 ( "native" ) as backend. Here drawing to a QImage uses the software renderer, while drawing to a pixmap is usually hardware accelerated. To make it comparable I'm converting the pixmap to an image, so that I have the same input and the same output. ( in case you are interested I added the code at the end of this posting. ) O.k. this is what I see with Qt 4.8: - Raster 735ms - X11 120ms When doing the same with a Qt-5.6 beta: - Raster 775ms - X11 775ms ( no surprise ) Next I modified the draw method a bit: void draw( const QPolygonF &points, QPaintDevice &paintDevice ) { QPainter painter( &paintDevice ); painter.setPen( QPen( Qt::black, 2 ) ); const int numPoints = 100; const int numChunks = points.size() / numPoints; for ( int i = 0; i < numChunks; i++ ) { painter.drawPolyline( points.constData() + i * numPoints, numPoints ); } painter.end(); } ( of course this is not exactly the same as the pixels to join the chunks at there ends are missing ). Now the result is: Raster ( Qt 4.8 ): 382ms Raster ( Qt 5.6 ): 403ms When using a chunk size ( = numPoints ) of 10 I have: Raster ( Qt 4.8 ): 192 Raster ( Qt 5.6 ): 181 X11 ( Qt 4.8 ): 93 In the end the implementation of a chart package is full of finding and implementing workarounds and optimizations like this one - at least this is my experience with being the maintainer of a chart package ( Qwt ) over the years. Uwe -- QImage renderRaster( const QPolygonF &points ) { QImage img( 1000, 1000, QImage::Format_RGB32 ); img.fill( Qt::white ); QElapsedTimer timer; timer.start(); draw( points, img ); qDebug() << "Raster" << timer.elapsed(); return img; } QImage renderX11( const QPolygonF &points ) { QPixmap pm( 1000, 1000 ); pm.fill( Qt::white ); QElapsedTimer timer; timer.start(); draw( points, pm ); const QImage img = pm.toImage(); qDebug() << "X11" << timer.elapsed(); return img; } From charleyb123 at gmail.com Sat Jan 23 15:20:20 2016 From: charleyb123 at gmail.com (charleyb123 .) Date: Sat, 23 Jan 2016 06:20:20 -0800 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <1563853.VKhDmtlTSd@tjmaciei-mobl4> References: <5DE56EBC-DBE4-44C6-988A-235267FF7749@theqtcompany.com> <1563853.VKhDmtlTSd@tjmaciei-mobl4> Message-ID: Thiago sayeth: > , > But I have no plans on extending QAtomicInteger and QAtomicPointer further. > There are a couple of missing features that will probably never be > implemented: > > * std::memory_order_consume and std::memory_order_cst > * GCC's extension for hidden lock elision > * compare_exchange_weak (doesn't affect Intel, so I don't care) > * weaker memory model for the failing compare_exchange's reload > * atomics on non-integral and non-pointer types, including larger types > * volatile support > > From my point of view, if you need to go further on atomics, you should > just > use std::atomic. > > We could introduce QAtomic which wraps the std::atomic API and adds the Qt- > style names. Is it worth it? > That would have been handy for a previous project, as we had the same codebase deploying to multiple architectures and we effectively had to do that ourselves -- we preferred QAtomics (because of the better API), but needed to wrap std::atomic for our deployment to one ARM platform. So, we made our own wrapper atomic class with the Qt interface, but had an #ifdef...#endif to wrap std::atomic for one platform. Worked fine (it's now a preferred pattern). > > > We started some experiments with convenience wrappers for std > algorithms > > > for use in Qt Creator when we started requiring C++11: > > > > http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algor > > > ithm.h > > Interesting. That could be a starting point for a QtAlgorithms successor. > > Agreed. Instead of reimplementing , expanding them for > convenience > API. > Agree here also, and with other comments in the thread regarding "not-much-love" for STL API choices/semantics. IMHO: (1) Most programmers don't even know about the STL algorithms. (2) Most programmers have a hard time conceptualizing what the STL algorithms are "supposed to do", even when looking right at them, after they are correctly employed in working code. (3) STL API conventions and volatility across versions are ... unfortunate. (4) Due to 1-3, many informed programmers remain unconvinced of the value of even bothering to increase STL algorithm adoption. (I think this is disappointing, but concede it to be a rational response by many teams.) I really think the, "convenience API" is worth a *lot*. Even just wrapping with Qt semantics is worth a ton. Programmers would actually *use* those, and *understand* those in code. Recall that even in on the C++ committee, there is not universal support for the ".begin(), .end()" where two parameters are required to iterate a single container (e.g., web search for, "Iterators Must Go", Niebler's new iterators work, proposals for future modified APIs for parallel-iteration of container elements). So, this would add another interesting motivation (and I'm seriously going to, "get out the popcorn" to watch the events unfold as I listen to the wailing and lamenting and gnashing-of-teeth as...) (5) In the not-too-distant future, the existing STL iterators API may be deprecated in favor of new iterator conventions. That sure is a lot of code to migrate, and it would be nice to have a convenience API to adopt. --charley -------------- next part -------------- An HTML attachment was scrubbed... URL: From milian.wolff at kdab.com Sat Jan 23 16:18:00 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Sat, 23 Jan 2016 16:18:00 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <484507646.2gnxYCXCBF@tjmaciei-mobl4> References: <484507646.2gnxYCXCBF@tjmaciei-mobl4> Message-ID: <7022823.EZhvZ3aZPl@agathebauer> On Freitag, 22. Januar 2016 16:47:38 CET Thiago Macieira wrote: > On Saturday 23 January 2016 01:23:30 Kevin Kofler wrote: > > I consider the fix of the "have to write '> >' to close double templates" > > issue as the most useful improvement in the entire C++11 standard. > > Not variadic templates? Not constexpr? Not decltype? Not rvalue references? > > By the way, if you Google for "C++ most vexing", you'll see a problem that > is still not solved and probably won't be. At least it is now work-arounded via the uniform initialization syntax. Cheers -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From milian.wolff at kdab.com Sat Jan 23 17:39:51 2016 From: milian.wolff at kdab.com (Milian Wolff) Date: Sat, 23 Jan 2016 17:39:51 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601221046.25376.marc.mutz@kdab.com> Message-ID: <8665474.JrK60kyO0h@agathebauer> On Freitag, 22. Januar 2016 22:51:30 CET Kevin Kofler wrote: > Marc Mutz wrote: > > And this is where I stop taking you seriously, sorry. You can demand such > > nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+ > > algorithms from the STL for Qt. Or play god deciding which are the ones > > "no- one will ever need" or "should never use" - IYHO. > > I'd already be happy with those that were (are, actually) already there. I'd > rather have 10-20 common algorithms with a convenient API than 80+ obscure > ones that force me to use iterators (especially the boilerplate .begin() > and .end() iterators that will be used in 99+% of the cases – copy&paste > programming sucks). You should educate yourself by watching a few of Sean Parent's talks and it will become clear that most of these "obscure ones" are actually very applicable in many scenarios where you currently write handwritten loops which are probably not as efficient and well-tested as the STL implementations. The code also becomes more self-explaining by using algorithms. And you do know that people are working on a STL v2 for ranges which invalidates all your "I hate iterators" complaints? -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From andre at familiesomers.nl Sat Jan 23 17:46:39 2016 From: andre at familiesomers.nl (Andre Somers) Date: Sat, 23 Jan 2016 17:46:39 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601211103.08815.marc.mutz@kdab.com> <201601221046.25376.marc.mutz@kdab.com> Message-ID: <56A3AE6F.8060902@familiesomers.nl> On 22-1-2016 22:51, Kevin Kofler wrote: > I'd already be happy with those that were (are, actually) already > there. I'd rather have 10-20 common algorithms with a convenient API > than 80+ obscure ones that force me to use iterators (especially the > boilerplate .begin() and .end() iterators that will be used in 99+% of > the cases – copy&paste programming sucks). Please note that the algorithms in STD are by no means complete. You are stimulated to add your own that you find useful, either as specializations or combinations of what is already there, as implementations of known algorithms in literature or even completely new ones ("Publish! Become Famous! (Don't patent please.)" - Sean Parent). Stephanov has seen his original design of STL been significantly shortened to get it through the commission; the proposal included much more than what is in STD even now after the more recent additions. So, by all means, add what you deem useful. I certainly agree that having to write begin/end pairs for all algorithms is not nice. It is the most general way to specify them however, so I understand why they are like this. And it even makes sense for some of them (like find, where you can then call find again using the return value of the last call to get the next match). Even for sort there certainly are use cases for a pair of iterators instead of passing the whole container. Still, it would make perfect sense to create versions that take a whole container. I don't even think that that is hard to do... template < class Container, class Compare > void sort ( Container container, Compare compare) { sort(begin(container), end(container), compare); }; Something like that perhaps? Feel free to add as many as you think are useful. André From andre at familiesomers.nl Sat Jan 23 17:52:11 2016 From: andre at familiesomers.nl (Andre Somers) Date: Sat, 23 Jan 2016 17:52:11 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <8665474.JrK60kyO0h@agathebauer> References: <201601051352.06816.marc.mutz@kdab.com> <201601221046.25376.marc.mutz@kdab.com> <8665474.JrK60kyO0h@agathebauer> Message-ID: <56A3AFBB.8070906@familiesomers.nl> On 23-1-2016 17:39, Milian Wolff wrote: > On Freitag, 22. Januar 2016 22:51:30 CET Kevin Kofler wrote: >> Marc Mutz wrote: >>> And this is where I stop taking you seriously, sorry. You can demand such >>> nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+ >>> algorithms from the STL for Qt. Or play god deciding which are the ones >>> "no- one will ever need" or "should never use" - IYHO. >> I'd already be happy with those that were (are, actually) already there. I'd >> rather have 10-20 common algorithms with a convenient API than 80+ obscure >> ones that force me to use iterators (especially the boilerplate .begin() >> and .end() iterators that will be used in 99+% of the cases – copy&paste >> programming sucks). > You should educate yourself by watching a few of Sean Parent's talks and it > will become clear that most of these "obscure ones" are actually very > applicable in many scenarios where you currently write handwritten loops which > are probably not as efficient and well-tested as the STL implementations. The > code also becomes more self-explaining by using algorithms. I can certainly agree with that one! Google for No Raw Loops for instance. Also, there are a lot of classes by Stephanov online that are quite educational (A9 published a couple of series on YouTube). There is even one where Sean Parent comes to talk to Stephanovs class there. It is an extended version of the No Raw Loops talk you'll find elsewhere. It pays off to familiarize yourself with these algorithms. You can use them more often than you think. André From marc.mutz at kdab.com Sat Jan 23 19:22:34 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 23 Jan 2016 19:22:34 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <56A3AE6F.8060902@familiesomers.nl> References: <201601051352.06816.marc.mutz@kdab.com> <56A3AE6F.8060902@familiesomers.nl> Message-ID: <201601231922.34851.marc.mutz@kdab.com> On Saturday 23 January 2016 17:46:39 Andre Somers wrote: > On 22-1-2016 22:51, Kevin Kofler wrote: > > I'd already be happy with those that were (are, actually) already > > there. I'd rather have 10-20 common algorithms with a convenient API > > than 80+ obscure ones that force me to use iterators (especially the > > boilerplate .begin() and .end() iterators that will be used in 99+% of > > the cases – copy&paste programming sucks). > > Please note that the algorithms in STD are by no means complete. You are > stimulated to add your own that you find useful, either as > specializations or combinations of what is already there, as > implementations of known algorithms in literature or even completely new > ones ("Publish! Become Famous! (Don't patent please.)" - Sean Parent). > Stephanov has seen his original design of STL been significantly > shortened to get it through the commission; the proposal included much > more than what is in STD even now after the more recent additions. > > So, by all means, add what you deem useful. > > I certainly agree that having to write begin/end pairs for all > algorithms is not nice. It is the most general way to specify them > however, so I understand why they are like this. And it even makes sense > for some of them (like find, where you can then call find again using > the return value of the last call to get the next match). Even for sort > there certainly are use cases for a pair of iterators instead of passing > the whole container. Still, it would make perfect sense to create > versions that take a whole container. I don't even think that that is > hard to do... > > template < class Container, class Compare > > void sort ( Container container, Compare compare) > { > sort(begin(container), end(container), compare); > }; > > Something like that perhaps? Feel free to add as many as you think are > useful. The problem is that these overloads quickly become ambiguous with existing ones. So at a minimum, you need to have a special suffix (_all).Overloading on concepts is needed to solve this properly. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From bogdan.vatra at kdab.com Sat Jan 23 18:31:22 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Sat, 23 Jan 2016 19:31:22 +0200 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <1841565.rGxZQGxFVD@zmeu> References: <1841565.rGxZQGxFVD@zmeu> Message-ID: <2365294.1PGHJMIRuV@zmeu> Hi, As I promised, I did some benchmarks myself and I got some very surprising results. The benchmark code is here: https://github.com/bog-dan-ro/exceptions_benchmark The benchmark calls a function 1000000000 times and this function trows an exception/return an error every x calls (x = 100; x*=10). The noexcept function tries to mimic Qt's way to handle errors. The results on desktop (intel i7) are here: https://paste.kde.org/pbdedo4mw gcc -O2 and -O3 gives the worst/random/surprising results. On the other hand, clang (to my HUGE surprise) gives the most consistent results. Even more surprising is the fact that in most/some cases the exception code produced by clang is faster :O ! The results on nvidia shield X1 are here: https://paste.kde.org/pz1leberi The results even more surprising (the percentages are bigger). Regarding the size overhead, I tested Qt(base) with&without exceptions (rtti seems enabled already) and the difference is only ~1Mb (23673504 with exceptions and 22584408 without), but because it doesn't use try/catch (almost?) anywhere, the size difference is pretty small (~5%). Then I found the following paragraph on https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_exceptions.html : "Exception handling overhead can be measured in the size of the executable binary, and varies with the capabilities of the underlying operating system and specific configuration of the C++ compiler. On recent hardware with GNU system software of the same age, the combined code and data size overhead for enabling exception handling is around 7%. Of course, if code size is of singular concern than using the appropriate optimizer setting with exception handling enabled (ie, -Os -fexceptions) may save up to twice that, and preserve error checking." So, if the size overhead of libstdc++ (which uses exceptions a LOT) is just 7% (+3.5% if we're using -Os), I'm pretty sure that Qt's overhead will be the same or even smaller. Therefore, I see no reason not starting using exceptions in 6.0, or at least to think&discuss on this matter. Cheers, BogDan. On Friday 22 January 2016 12:32:25 Bogdan Vatra wrote: > On Friday 22 January 2016 10:55:34 Cristian Adam wrote: > > On Fri, Jan 22, 2016 at 11:59 AM, Marc Mutz wrote: > > > I'm not sure about what outcome to expect, and I don't remember any > > > numbers > > > posted by anyone else, either. > > > > From the David Stone's Writing Robust Code > > page 34: > > > > Performance of exceptions when not thrown > > ● Tested on gcc 4.9.2 > > ● Numbers relative to ignoring errors > > ● With no destructors > > > > – 12.8% overhead for exceptions > > – 32.8% overhead for return codes > > > > ● With destructors > > > > – 6.3% overhead for exceptions > > – 18.7% overhead for return codes > > Hmm, so, using exceptions makes your code 12-20% faster. This is a good > thing, right?. Most probably the binary size will be slightly bigger, let's > see if it's 12-20% bigger (my hunch is that it will not be more than 5% > bigger). I'll do some tests this weekend and I'll share with you the > results. > > > And page 35: > > > > Performance of exceptions when thrown > > ● Tested on gcc 4.9.2 > > ● Numbers relative to ignoring errors > > ● With no destructors > > > > – 900% overhead for exceptions > > > > ● With destructors > > > > – 750% overhead > > As I said, exceptions are like *a life vest*, they should be used *only in > critical situations* not everywhere. > > Cheers, > BogDan. > > P.S. Android Alexandrescu has a nice video on this matter: > https://channel9.msdn.com/Shows/Going+Deep/C-and-Beyond-2012-Andrei-Alexandr > escu-Systematic-Error-Handling-in-C > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Sat Jan 23 19:36:54 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 23 Jan 2016 10:36:54 -0800 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601231922.34851.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <56A3AE6F.8060902@familiesomers.nl> <201601231922.34851.marc.mutz@kdab.com> Message-ID: <1607607.jM704FgJld@tjmaciei-mobl4> On Saturday 23 January 2016 19:22:34 Marc Mutz wrote: > > template < class Container, class Compare > > > void sort ( Container container, Compare compare) > > { > > > > sort(begin(container), end(container), compare); > > > > }; > > > > > > > > Something like that perhaps? Feel free to add as many as you think are > > useful. > > The problem is that these overloads quickly become ambiguous with existing > ones. So at a minimum, you need to have a special suffix (_all).Overloading > on concepts is needed to solve this properly. Another way to do that is to have a special prefix of "q". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sh at theharmers.co.uk Sat Jan 23 19:52:24 2016 From: sh at theharmers.co.uk (Sean Harmer) Date: Sat, 23 Jan 2016 18:52:24 +0000 Subject: [Development] Charts and DataVis Questions In-Reply-To: References: <1453475786.3146.57.camel@member.fsf.org> Message-ID: <56A3CBE8.10809@theharmers.co.uk> On 23/01/2016 12:45, Uwe Rathmann wrote: > Hi, > >> The OpenGL acceleration in Charts module is really impressive ... > Unfortunately part of the truth is, that the performance of the software > renderer does not necessarily be that far behind. Now try it against OpenGL with 100k points rendering to a 4k screen. The difference between software and hardware will increase with those parameters (up to some fill rate or vertex rate that the hardware can handle). Cheers, Sean > > An example: in a test program I'm creating a polygon of 10000 points in > an area of 1000x1000 using (qAbs(random) % 1000) and then I'm drawing it > this way: > > void draw( const QPolygonF &points, QPaintDevice &paintDevice ) > { > QPainter painter( &paintDevice ); > painter.setPen( QPen( Qt::black, 2 ) ); > painter.drawPolyline( points ); > painter.end(); > } > > > As I want to compare hardware vs. software renderer I'm using Qt 4.8 with > X11 ( "native" ) as backend. Here drawing to a QImage uses the software > renderer, while drawing to a pixmap is usually hardware accelerated. > > To make it comparable I'm converting the pixmap to an image, so that I > have the same input and the same output. ( in case you are interested I > added the code at the end of this posting. ) > > O.k. this is what I see with Qt 4.8: > > - Raster 735ms > - X11 120ms > > When doing the same with a Qt-5.6 beta: > > - Raster 775ms > - X11 775ms ( no surprise ) > > > Next I modified the draw method a bit: > > void draw( const QPolygonF &points, QPaintDevice &paintDevice ) > { > QPainter painter( &paintDevice ); > painter.setPen( QPen( Qt::black, 2 ) ); > > const int numPoints = 100; > const int numChunks = points.size() / numPoints; > for ( int i = 0; i < numChunks; i++ ) > { > painter.drawPolyline( points.constData() + i * numPoints, > numPoints ); > } > painter.end(); > } > > ( of course this is not exactly the same as the pixels to join the chunks > at there ends are missing ). > > Now the result is: > > Raster ( Qt 4.8 ): 382ms > Raster ( Qt 5.6 ): 403ms > > When using a chunk size ( = numPoints ) of 10 I have: > > Raster ( Qt 4.8 ): 192 > Raster ( Qt 5.6 ): 181 > X11 ( Qt 4.8 ): 93 > > In the end the implementation of a chart package is full of finding and > implementing workarounds and optimizations like this one - at least this > is my experience with being the maintainer of a chart package ( Qwt ) > over the years. > > Uwe > > -- > > > QImage renderRaster( const QPolygonF &points ) > { > QImage img( 1000, 1000, QImage::Format_RGB32 ); > img.fill( Qt::white ); > > QElapsedTimer timer; > timer.start(); > > draw( points, img ); > > qDebug() << "Raster" << timer.elapsed(); > > return img; > } > > QImage renderX11( const QPolygonF &points ) > { > QPixmap pm( 1000, 1000 ); > pm.fill( Qt::white ); > > QElapsedTimer timer; > timer.start(); > > draw( points, pm ); > > const QImage img = pm.toImage(); > qDebug() << "X11" << timer.elapsed(); > > return img; > } > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kevin.kofler at chello.at Sun Jan 24 03:01:57 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 24 Jan 2016 03:01:57 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601222046.54850.marc.mutz@kdab.com> <201601230011.27639.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > On Friday 22 January 2016 20:46:54 Marc Mutz wrote: >> Which one is faster? On a dual-core, probably QVector. On a 64-core >> processor, probably std::vector. > > Running attached test program (4 cores + 2-fold HT), I get these numbers: That's already 8 virtual cores. He wrote "on a dual-core". :-) Kevin Kofler From kevin.kofler at chello.at Sun Jan 24 03:11:26 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 24 Jan 2016 03:11:26 +0100 Subject: [Development] What kind of airplane we want to build? References: <1841565.rGxZQGxFVD@zmeu> <2365294.1PGHJMIRuV@zmeu> Message-ID: Bogdan Vatra wrote: > gcc -O2 and -O3 gives the worst/random/surprising results. On the other > hand, clang (to my HUGE surprise) gives the most consistent results. That doesn't surprise me all that much. I've seen REALLY strange benchmarking results from GCC-generated code. In particular, I had a program where I was trying to benchmark the win from parallelizing the code, and I found that the mere fact of adding -pthreads to the compiler flags, without actually doing ANY parallelization, was making the code FASTER. (If anything, it is expected to run slower, because of additional locks.) Kevin Kofler From marc.mutz at kdab.com Sun Jan 24 04:30:14 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 24 Jan 2016 04:30:14 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601230011.27639.marc.mutz@kdab.com> Message-ID: <201601240430.14883.marc.mutz@kdab.com> On Sunday 24 January 2016 03:01:57 Kevin Kofler wrote: > Marc Mutz wrote: > > On Friday 22 January 2016 20:46:54 Marc Mutz wrote: > >> Which one is faster? On a dual-core, probably QVector. On a 64-core > >> processor, probably std::vector. > > > > Running attached test program (4 cores + 2-fold HT), I get these numbers: > > That's already 8 virtual cores. He wrote "on a dual-core". :-) Not that I didn't post the code, so you could run the benchmark on your machine, or with numThreads hard-coded to 2... QVector: 1: 111 2: 100 4: 111 8: 115 16: 139 32: 179 64: 204 128: 337 256: 644 512: 1287 1024: 2611 2048: 5020 4096: 10113 std::vector: 1: 63 2: 63 4: 65 8: 69 16: 119 32: 198 64: 264 128: 375 256: 735 512: 1385 1024: 2719 2048: 5545 4096: 10444 (numThread == 2, same box) Copying is still not significantly slower than ref-counting, even for 4K elements. And yes, this suprises even me, but since it perfectly matches my expecations, at least qualitatively, I won't spend more time trying to understand this. The code is there, I took great care to make it fair, now the CoW fanboys can explain this (or find a bug in the benchmark). At least it seems as if the allocator has a very fast path for alloc/dealloc/alloc/dealloc/etc chains of a same-sized memory block. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From Marco.Bubke at theqtcompany.com Sun Jan 24 11:41:25 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Sun, 24 Jan 2016 10:41:25 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <201601240430.14883.marc.mutz@kdab.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601230011.27639.marc.mutz@kdab.com> <201601240430.14883.marc.mutz@kdab.com> Message-ID: Folly string is doing CoW only for sizes bigger than 255 and I believe Facebook has measured it because for them it is money. ;-) I am not sure if they use atomics. Maybe you could benchmark them too. On January 24, 2016 03:21:31 Marc Mutz wrote: > On Sunday 24 January 2016 03:01:57 Kevin Kofler wrote: >> Marc Mutz wrote: >> > On Friday 22 January 2016 20:46:54 Marc Mutz wrote: >> >> Which one is faster? On a dual-core, probably QVector. On a 64-core >> >> processor, probably std::vector. >> > >> > Running attached test program (4 cores + 2-fold HT), I get these numbers: >> >> That's already 8 virtual cores. He wrote "on a dual-core". :-) > > Not that I didn't post the code, so you could run the benchmark on your > machine, or with numThreads hard-coded to 2... > > QVector: > > 1: 111 > 2: 100 > 4: 111 > 8: 115 > 16: 139 > 32: 179 > 64: 204 > 128: 337 > 256: 644 > 512: 1287 > 1024: 2611 > 2048: 5020 > 4096: 10113 > > std::vector: > > 1: 63 > 2: 63 > 4: 65 > 8: 69 > 16: 119 > 32: 198 > 64: 264 > 128: 375 > 256: 735 > 512: 1385 > 1024: 2719 > 2048: 5545 > 4096: 10444 > > (numThread == 2, same box) > > Copying is still not significantly slower than ref-counting, even for 4K > elements. > > And yes, this suprises even me, but since it perfectly matches my expecations, > at least qualitatively, I won't spend more time trying to understand this. The > code is there, I took great care to make it fair, now the CoW fanboys can > explain this (or find a bug in the benchmark). > > At least it seems as if the allocator has a very fast path for > alloc/dealloc/alloc/dealloc/etc chains of a same-sized memory block. > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From kevin.kofler at chello.at Sun Jan 24 17:44:59 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 24 Jan 2016 17:44:59 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601230011.27639.marc.mutz@kdab.com> <201601240430.14883.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > (numThread == 2, same box) > > Copying is still not significantly slower than ref-counting, even for 4K > elements. But it is already slower with as little as 32 elements, and stops being significantly faster already at 16 elements. And now try with numThread == 1 for some extra fun. :-) A lot of code out there is still single-threaded. Kevin Kofler From Marco.Bubke at theqtcompany.com Sun Jan 24 19:09:55 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Sun, 24 Jan 2016 18:09:55 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601230011.27639.marc.mutz@kdab.com> <201601240430.14883.marc.mutz@kdab.com> Message-ID: On January 24, 2016 17:45:36 Kevin Kofler wrote: > Marc Mutz wrote: >> (numThread == 2, same box) >> >> Copying is still not significantly slower than ref-counting, even for 4K >> elements. > > But it is already slower with as little as 32 elements, and stops being > significantly faster already at 16 elements. > > And now try with numThread == 1 for some extra fun. :-) A lot of code out > there is still single-threaded. > Yes but in the future the processors getting more and more parallel. If I am working on the bigger dataset with parallel algorithms I don't want to share writes to the same cache like. Something which CoW is providing. > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From Simon.Hausmann at theqtcompany.com Sun Jan 24 21:11:15 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Sun, 24 Jan 2016 20:11:15 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601230011.27639.marc.mutz@kdab.com> <201601240430.14883.marc.mutz@kdab.com> , Message-ID: <20160124201114.5922898.95112.57009@theqtcompany.com> Hi, Could you elaborate where you see copy on write causing writes to shared cache lines? Are you concerned about the shared cache line for the reference count? For reading MESI allows for shared cache lines and for hyper threads the shared l1 data cache mode favors sharing and thus CoW. What am I missing to understand your statement? Simon Original Message From: Bubke Marco Sent: Sunday, January 24, 2016 19:10 To: Kevin Kofler; development at qt-project.org Subject: Re: [Development] Question about QCoreApplicationData::*_libpaths On January 24, 2016 17:45:36 Kevin Kofler wrote: > Marc Mutz wrote: >> (numThread == 2, same box) >> >> Copying is still not significantly slower than ref-counting, even for 4K >> elements. > > But it is already slower with as little as 32 elements, and stops being > significantly faster already at 16 elements. > > And now try with numThread == 1 for some extra fun. :-) A lot of code out > there is still single-threaded. > Yes but in the future the processors getting more and more parallel. If I am working on the bigger dataset with parallel algorithms I don't want to share writes to the same cache like. Something which CoW is providing. > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Marco.Bubke at theqtcompany.com Sun Jan 24 21:41:08 2016 From: Marco.Bubke at theqtcompany.com (Bubke Marco) Date: Sun, 24 Jan 2016 20:41:08 +0000 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: <20160124201114.5922898.95112.57009@theqtcompany.com> References: <201601051352.06816.marc.mutz@kdab.com> <201601230011.27639.marc.mutz@kdab.com> <201601240430.14883.marc.mutz@kdab.com> , <20160124201114.5922898.95112.57009@theqtcompany.com> Message-ID: On January 24, 2016 21:11:18 Hausmann Simon wrote: > Hi, > > Could you elaborate where you see copy on write causing writes to shared cache lines? Are you concerned about the shared cache line for the reference count? > > For reading MESI allows for shared cache lines and for hyper threads the shared l1 data cache mode favors sharing and thus CoW. I was speaking about distinct caches and the latency you introduce if you are invalidate a cache line. It really depends on your out of order implementation but so far I understand atomics are still much slower as if you simply not share at all. But like I said it is better to measure it. But my general question is why do we use CoW, how often it helps, how often it hurts. What are other techniques? How can we help with tools, so the we fix it much earlier and not at run time. Could we find out with some kind of profiling the cases where sharing would be good and add fixits for it? E.g. You returned this really big member in the test run. We can change it to a shared pointer or a CoW container. Do you want it? Yes or no? Actually I think many mistakes like unneeded copies could be hinted by the code model too. > What am I missing to understand your statement? > > > Simon > > Original Message > From: Bubke Marco > Sent: Sunday, January 24, 2016 19:10 > To: Kevin Kofler; development at qt-project.org > Subject: Re: [Development] Question about QCoreApplicationData::*_libpaths > > > On January 24, 2016 17:45:36 Kevin Kofler wrote: > >> Marc Mutz wrote: >>> (numThread == 2, same box) >>> >>> Copying is still not significantly slower than ref-counting, even for 4K >>> elements. >> >> But it is already slower with as little as 32 elements, and stops being >> significantly faster already at 16 elements. >> >> And now try with numThread == 1 for some extra fun. :-) A lot of code out >> there is still single-threaded. >> > > Yes but in the future the processors getting more and more parallel. If I am working on the bigger dataset with parallel algorithms I don't want to share writes to the same cache like. Something which CoW is providing. > >> Kevin Kofler >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Sent from cellphone, sorry for the typos > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Sent from cellphone, sorry for the typos From kevin.kofler at chello.at Mon Jan 25 05:43:03 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Mon, 25 Jan 2016 05:43:03 +0100 Subject: [Development] QtWebEngine on x86 without SSE2 References: Message-ID: PS: > I verified that this builds on GNU/Linux on i686, on x86_64 (where SSE2 is > part of the baseline and can thus be assumed safely) and on ARM (where > SSE2 does not exist at all and so the patch should have no effect). I have > not done runtime testing yet. I have now done a basic functionality test in QEMU-KVM, both with the default SSE2-enabled qemu64 CPU and with "-cpu pentium3" (which claims to not support SSE2 in cpuid), and in both cases things appear to work. I am not aware of any testing done on a real non-SSE2 machine though. (The KVM test with the fake cpuid tests that the non-SSE2 code paths don't crash, but it does not guarantee that there are really no SSE2 instructions encountered. That can only be reliably verified with full software CPU emulation or with a real non-SSE2 CPU.) Kevin Kofler From Martin.Smith at theqtcompany.com Mon Jan 25 09:31:01 2016 From: Martin.Smith at theqtcompany.com (Smith Martin) Date: Mon, 25 Jan 2016 08:31:01 +0000 Subject: [Development] Doc: Making it easier for devs to know if a class is supported on a given platform In-Reply-To: References: Message-ID: I suppose the default should be that a class is fully supported on all Qt platforms, so the qdoc command should be \notsupported with the list of not supported platforms. \notsupported ...could appear in a \class or a \fn or in a \qmltype or \qmlmethod. martin ________________________________ From: Development on behalf of Sze Howe Koh Sent: Saturday, January 23, 2016 4:30 AM To: development at qt-project.org Subject: [Development] Doc: Making it easier for devs to know if a class is supported on a given platform Hi all, With the proliferation of supported platforms and add-on modules, we now have a situation where some classes are only useable on particular platforms. There've been cases where a developer sees a class in the Qt docs and thinks "Ooh, this is just what I need!", only to find out (after spending time studying examples and writing code) that the class can't be used on their platform of interest. [1] It would be nice to help them find out earlier whether a class is available or not. We currently have some documentation, e.g. http://doc.qt.io/qt-5/qtmodules.html lists "Target Platforms" for add-on modules. However, a user who finds the class ref via a search engine might miss this. All Modules | Qt 5.5 doc.qt.io If you use qmake to build your projects, the Qt Core and Qt GUI modules are included by default. To link only against Qt Core, add the following line to your .pro file: One idea is to add a "Target Platforms" row in the class reference, below the "Header", "qmake", and "Inherits" rows. qdoc could populate this for each class based on info provided about the module. However, we have a situation in Qt Multimedia where the module is broadly available, but particular features are not: https://wiki.qt.io/Qt_5.5.0_Multimedia_Backends so Qt Multimedia is available on iOS but QAudioProbe is not. The previous idea for an auto-populated "Target Platforms" row would be erroneous in this case. Perhaps we could have a per-class "\supports" qdoc command, or even manually type in a line saying "This class is (not) supported on _____"? (I'm happy to spend time doing this, but it's not a very maintainable solution) Any other thoughts/ideas? (I haven't thought through QML types yet) Regards, Sze-Howe [1] http://forum.qt.io/topic/63110/list-of-video-formats-qt-supports/14?page=2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eike.Ziller at theqtcompany.com Mon Jan 25 10:52:30 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Mon, 25 Jan 2016 09:52:30 +0000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <484507646.2gnxYCXCBF@tjmaciei-mobl4> References: <484507646.2gnxYCXCBF@tjmaciei-mobl4> Message-ID: > On Jan 23, 2016, at 1:47 AM, Thiago Macieira wrote: > > On Saturday 23 January 2016 01:23:30 Kevin Kofler wrote: >> I feel it's actually TOO rapidly changing. C++11 even threw out C >> compatibility, not only by not adopting all C99 improvements (e.g. VLAs), >> but also by subtly interpreting even as simple valid C90 code as "auto x = >> 1.5;" in an incompatible way. (OK, that code is not valid C++98, but at >> least a C++98 compiler would tell you what is wrong with it, C++11 just >> silently gives it a different meaning.) > > I disagree with you on all points here. C++ is *not* moving too fast. In some > areas, it's not moving even fast enough: where's the reflection support? > Meanwhile, discussions linger in the standards proposal mailing list about how > many templates we need for parsing a string to integer. > > Specifically on VLAs, the proposal was added to C++14, but dropped due to > disagreement. C++ would have implemented a subset of C99's requirement, but > not the controversial parts like taking a sizeof and getting the runtime size > and passing them as parameters. The less we talk about > void f(int n, char array[static n]); > the better. > > On auto, it's not a big loss. So what if it's incompatible between C and C++? > NO ONE writes "auto" anymore in C, since the only place where you can use it > are places where it's redundant. As for the case you showed, even C99 > deprecated it. > > I miss designated initialisers and that is a shame. When that comes around, > the discussion always goes on to talk about named parameters, which meets > stiff resistance in the committee. > >> I consider the fix of the "have to write '> >' to close double templates" >> issue as the most useful improvement in the entire C++11 standard. > > Not variadic templates? Not constexpr? Not decltype? Not rvalue references? Variadic templates + decltype + SFINAE/type_traits + universal references are able to reduce several thousand lines of very limited functionality, repetitive, unreadable QtConcurrent code, to probably something like a few hundred lines with more features and better behavior (e.g. unlimited arguments and argument types, movable types). I'd see most of http://code.qt.io/cgit/qt/qtbase.git/tree/src/concurrent/qtconcurrentstoredfunctioncall.h and http://code.qt.io/cgit/qt/qtbase.git/tree/src/concurrent/qtconcurrentrun.h would just be gone. > By the way, if you Google for "C++ most vexing", you'll see a problem that is > still not solved and probably won't be. > >> Please do not make major changes to Qt that break all existing code, or even >> replace it with something entirely different. It causes major pain. There >> is useful software out there still stuck on Qt 3 years after Qt 4.0.0, and >> the changes you suggest would be even much worse than the Qt 3 to 4 >> transition. > > We will have to eventually break some things. Compatibility with old code has > kept QIODevice stuck in time, unable to move forward and implement important > things like zero-copy buffering. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From Eike.Ziller at theqtcompany.com Mon Jan 25 10:53:16 2016 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Mon, 25 Jan 2016 09:53:16 +0000 Subject: [Development] What kind of airplane we want to build? In-Reply-To: References: <201601201512.48597.marc.mutz@kdab.com> <5DE56EBC-DBE4-44C6-988A-235267FF7749@theqtcompany.com> Message-ID: > On Jan 23, 2016, at 1:12 AM, Kevin Kofler wrote: > > Ziller Eike wrote: >>> I would like that trend to continue. The likely next candidates are >>> threads, futures and locks. >> >> +1 > > I wonder why everyone so far agreed on that. So let me dissent: I think > having these things in Qt with Qt-style APIs is a good thing and I don't see > why we should discard our solution for the STL one. At most, where it makes > sense, we could wrap the STL stuff as we're doing with std::atomic. The +1 statement above doesn’t mean that there is no room for convenience on top of the std features, and integrating them with Qt features like signals/slots. E.g. std::future doesn’t support asynchronous result reporting (some thread has at some point to block for getting the result in the end), or progress reporting, something that the QFutureInterface, QFuture, QFutureWatcher triple provides. (Though, also only partially in Qt. We added more within Qt Creator, which was supposed to migrate to Qt but didn’t make it.) That still means that any Qt solution to that should best only be convenience around std::future and std::thread and the async algorithms that will probably come to C++ at some point. We will want to not block ourselves from coming C++ features like future.then(...) and so on. > I find it much nicer and more readable if I can just write sort(v). > > +1! > > And I don't think ranges are the answer here. It's just another layer of > overengineered abstraction (as they will surely be implemented as a pair of > iterators in practice) when in 99+% of the cases you just want to operate on > the whole container anyway. > >> Or "const List foos = transformed(myThings, &Thing::foo);" >> instead of "List foos; std::transform(myThings.begin(), myThings.end(), >> std::back_inserter(foos), std::mem_fn(&Thing::foo));” (notice that “foos” >> is also not const in the “pure" std version) > > Wow, the STL version is horrible! std::back_inserter is particularly ugly, > and the usual misleading STL name (which suggests "backwards", when actually > it means "to the back", so when inserting multiple elements, forward) does > not help either. > >> We started some experiments with convenience wrappers for std algorithms >> for use in Qt Creator when we started requiring C++11: >> http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/src/libs/utils/algorithm.h > > Interesting. That could be a starting point for a QtAlgorithms successor. > >>> why do they use C++ if they so hate it? >> >> Maybe they don’t hate it, but still wished it had a less verbose API if >> you don’t need the verbosity. > > The funny thing is that only redundant boilerplate is verbose in the STL. > The stuff that matters, the API names, are horribly terse (e.g. "deque"). > > And I don't hate the C++ language, only its standard library. The language > is actually great, much better than Java or Python. So, since Qt lets me not > touch the STL with a 10-foot pole, I see no problem with using C++. (Qt is > also by far the best class library out there.) > > Kevin Kofler > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Principle Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From alexis.jeandet at member.fsf.org Mon Jan 25 10:57:56 2016 From: alexis.jeandet at member.fsf.org (Alexis Jeandet) Date: Mon, 25 Jan 2016 10:57:56 +0100 Subject: [Development] Charts and DataVis Questions In-Reply-To: References: <1453475786.3146.57.camel@member.fsf.org> Message-ID: <1453715876.3146.80.camel@member.fsf.org> Le samedi 23 janvier 2016 à 12:45 +0000, Uwe Rathmann a écrit : > Hi, > > > The OpenGL acceleration in Charts module is really impressive ... > > Unfortunately part of the truth is, that the performance of the > software  > renderer does not necessarily be that far behind. The test I did with QCharts gave me something like 6x speedup. > > An example: in a test program I'm creating a polygon of 10000 points > in  > an area of 1000x1000 using (qAbs(random) % 1000) and then I'm drawing > it  My experience with polygons and Qt is that you will really increase drawing performances if you divide them in smaller ones. I found that the relation between the number of edges of a polygon and the drawing time wasn't linear. With this naive algorithm I got good rendering speedups: https://hephaistos.lpp.polytechnique.fr/rhodecode/HG_REPOSITORIES/LPP/I NSTRUMENTATION/kicadtools/files/b59e8f9f12322445df6df1e8fe1090ef7f6cafc 4/test/PCBView/pcbzone.cpp#L123 In your case I don't know since you draw it manually with drawPolyline. Anyway my point isn't to make faster a the rendering of big datasets but avoiding to draw them with some downsampling algorithms. Even if we succeed to render 1 million of points smoothly it won't scale at 10M it will suck a lot of memory for nothing. > this way: > > void draw( const QPolygonF &points, QPaintDevice &paintDevice ) > { >     QPainter painter( &paintDevice ); >     painter.setPen( QPen( Qt::black, 2 ) ); >     painter.drawPolyline( points ); >     painter.end(); > } > > > As I want to compare hardware vs. software renderer I'm using Qt 4.8 > with  > X11 ( "native" ) as backend. Here drawing to a QImage uses the > software  > renderer, while drawing to a pixmap is usually hardware accelerated. > > To make it comparable I'm converting the pixmap to an image, so that > I  > have the same input and the same output.  ( in case you are > interested I  > added the code at the end of this posting. ) > > O.k. this is what I see with Qt 4.8: > > - Raster 735ms > - X11 120ms > > When doing the same with a Qt-5.6 beta: > > - Raster 775ms > - X11 775ms ( no surprise ) > > > Next I modified the draw method a bit: > > void draw( const QPolygonF &points, QPaintDevice &paintDevice ) > { >     QPainter painter( &paintDevice ); >     painter.setPen( QPen( Qt::black, 2 ) ); > >     const int numPoints = 100; >     const int numChunks = points.size() / numPoints; >     for ( int i = 0; i < numChunks; i++ ) >     { >         painter.drawPolyline( points.constData() + i * numPoints,  > numPoints ); >     } >     painter.end(); > } > > ( of course this is not exactly the same as the pixels to join the > chunks  > at there ends are missing ). > > Now the result is: > > Raster ( Qt 4.8 ): 382ms > Raster ( Qt 5.6 ): 403ms > > When using a chunk size ( = numPoints ) of 10 I have: > > Raster ( Qt 4.8 ): 192 > Raster ( Qt 5.6 ): 181 > X11    ( Qt 4.8 ):  93 > > In the end the implementation of a chart package is full of finding > and  > implementing workarounds and optimizations like this one - at least > this  > is my experience with being the maintainer of a chart package ( Qwt > )  > over the years. > > Uwe > > -- > > > QImage renderRaster( const QPolygonF &points ) > { >     QImage img( 1000, 1000, QImage::Format_RGB32 ); >     img.fill( Qt::white ); > >     QElapsedTimer timer; >     timer.start(); > >     draw( points, img ); > >     qDebug() << "Raster" << timer.elapsed(); > >     return img; > } > > QImage renderX11( const QPolygonF &points ) > { >     QPixmap pm( 1000, 1000 ); >     pm.fill( Qt::white ); > >     QElapsedTimer timer; >     timer.start(); > >     draw( points, pm ); > >     const QImage img = pm.toImage(); >     qDebug() << "X11" << timer.elapsed(); > >     return img; > } > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Shawn.Rutledge at theqtcompany.com Mon Jan 25 11:20:43 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Mon, 25 Jan 2016 10:20:43 +0000 Subject: [Development] Charts and DataVis Questions In-Reply-To: <56A3CBE8.10809@theharmers.co.uk> References: <1453475786.3146.57.camel@member.fsf.org> <56A3CBE8.10809@theharmers.co.uk> Message-ID: <0C63835B-BA8D-4301-80E5-F6F4E8B97275@digia.com> On 23 Jan 2016, at 19:52, Sean Harmer > wrote: On 23/01/2016 12:45, Uwe Rathmann wrote: Hi, The OpenGL acceleration in Charts module is really impressive ... Unfortunately part of the truth is, that the performance of the software renderer does not necessarily be that far behind. Now try it against OpenGL with 100k points rendering to a 4k screen. The difference between software and hardware will increase with those parameters (up to some fill rate or vertex rate that the hardware can handle). You especially don’t want to do antialiasing with the software renderer (been there done that: it was about 2008 and using AA when rendering a QPainterPath made it several times slower than without), whereas vertex antialiasing with OpenGL is doable. QtCharts so far uses GL_LINES for the line graph, but AFAIK the only way to get antialiasing with that approach is to turn on multi-sampling, which performs well only on certain desktop graphics cards (line graphs are simple enough, but it wouldn’t be so great to turn on MSAA in the whole QtQuick scene if your app is complex and you expect it to be portable). I’ve been working on an antialiasing line graph, outside of Qt Charts so far though. It’s similar to qtdeclarative/examples/quick/scenegraph/graph but does mitering right in the vertex shader, and antialiasing by setting the transparency proportional to distance away from the virtual line, in the fragment shader. And of course with GPU rendering you can have full-frame-rate dynamism, whether the data is actually changing that fast or you are interacting - zooming, panning, moving a time cursor to see the corresponding data point, etc. My laptop can render 60FPS while keeping the CPU at its lowest clock rate. Or maybe a raspberry pi would have sufficient power to run an oscilloscope display, with the trace so smooth that it looks like an analog scope; I haven’t tried that, but it would make a nice demo. Data modelling is another consideration. I think the holy grail would be if we could send the actual data to the GPU unmodified, and render it there. Vertex AA requires generating duplicate vertices though, to be able to expand them away from the line, to give it thickness. So, for speed (but not memory conservation) we want to keep that array of vertices around, add new datapoints to one end and remove old ones from the other - as opposed to generating vertices each time we render one frame. So it needs to have that kind of API, and you then should try to minimize any additional copying: store the data how you like but manage the vertices incrementally, or add each new sample to the vertex array and don’t bother keeping your own copy. So I tried writing a data model which works that way: it stores the vertices on behalf of the rendering code, without exposing them directly in the API. Whereas QLineSeries both stores data and renders it, as you can see in the example with the use of the append() function. So maybe it could be refactored so that you can instead implement a model by subclassing an abstract base class, similar to the way that QListWidget is a QListView with an internal model, whereas in non-trivial applications you write your own QAIM and use QListView and/or QML ListView. But a time series is just one kind of data, and only makes sense with certain types of visualization. So we could follow through and write abstract model classes for other kinds of data that can be visualized, but this kind of modelling amounts to making assumptions, which requires a lot of care to keep it as widely applicable as possible. Later I want to try using a geometry shader to expand the datapoints into vertices. That will be less portable though (won’t work on OpenGL ES). But maybe it would make zero-copy (on the CPU) visualization possible, as long as you are OK to model the data the way that the rendering code expects (a time-value struct, just two floats or doubles per data point; or maybe two arrays, one for times and one for values). My mitering shader has trouble with excessively high-frequency data, so resampling is useful, to get the sample rate down to one sample per horizontal pixel, or less. There is some recent research on how to do that while preserving the psychological impression of how the data looks, which I’ve been implementing (only on the CPU so far): http://skemman.is/stream/get/1946/15343/37285/3/SS_MSthesis.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at theqtcompany.com Mon Jan 25 12:39:22 2016 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 25 Jan 2016 11:39:22 +0000 Subject: [Development] HEADS UP: Qt 5.6.0 branching ongoing In-Reply-To: References: Message-ID: ‘5.6.0’ branch is now available, please start using it for the changes targeted to Qt5.6.0 release. We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on. Target is to release Qt5.6.0 RC quite soon so please make sure all blockers will be fixed as soon as possible. Blocker list here: https://bugreports.qt.io/issues/?filter=17225 Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize changes between RC and final. And please remember: Do not add any 'nice to have' -changes in anymore (P0 & P1 bug fixes mostly, in some special cases p2 fixes might be ok as well). Best regards, Jani Heikkinen Release Manager | The Qt Company The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland Email: jani.heikkinen at theqtcompany.com | Mobile: + 358 50 48 73 735 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt From rpzrpzrpz at gmail.com Mon Jan 25 13:15:03 2016 From: rpzrpzrpz at gmail.com (mark diener) Date: Mon, 25 Jan 2016 06:15:03 -0600 Subject: [Development] HEADS UP: Qt 5.6.0 branching ongoing In-Reply-To: References: Message-ID: Jani: I see the 5.6.0 RC blocker list. But what about bugs like? Using 5.6.0 Beta: https://bugreports.qt.io/browse/QTBUG-50374 What is the criterion for entry into the blocker list? Only core code, not tools? Thank you, md On Mon, Jan 25, 2016 at 5:39 AM, Heikkinen Jani wrote: > ‘5.6.0’ branch is now available, please start using it for the changes targeted to Qt5.6.0 release. > > We will merge ‘5.6’ branch to ‘5.6.0’ Monday 1st February so there should be enough time to finalize ongoing changes in ‘5.6’ and start using '5.6.0'. All new changes for Qt5.6.0 should be done in ‘5.6.0’ branch from now on. > > Target is to release Qt5.6.0 RC quite soon so please make sure all blockers will be fixed as soon as possible. Blocker list here: https://bugreports.qt.io/issues/?filter=17225 > Please make sure all Qt 5.6.0 blockers are found from blocker list (== set 5.6.0 RC as fix version(s)): We should fix all blockers before RC & minimize changes between RC and final. > > And please remember: Do not add any 'nice to have' -changes in anymore (P0 & P1 bug fixes mostly, in some special cases p2 fixes might be ok as well). > > Best regards, > Jani Heikkinen > Release Manager | The Qt Company > > The Qt Company / Digia Finland Ltd, Elektroniikkatie 13, 90590 Oulu, Finland > Email: jani.heikkinen at theqtcompany.com | Mobile: + 358 50 48 73 735 > www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject Facebook: www.facebook.com/qt > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jedrzej.nowacki at theqtcompany.com Mon Jan 25 14:25:52 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Mon, 25 Jan 2016 14:25:52 +0100 Subject: [Development] What kind of airplane we want to build? In-Reply-To: <3384483.q7Q4vzIsBQ@tjmaciei-mobl4> References: <12864175.VQLJhK2Jco@zmeu> <3384483.q7Q4vzIsBQ@tjmaciei-mobl4> Message-ID: <1938597.3eVWahOxay@42> On Friday 22 of January 2016 08:50:52 Thiago Macieira wrote: > On Friday 22 January 2016 11:26:55 Bogdan Vatra wrote: > > AFAIK C++11/14 compilers have zero-cost exception, so, is there any reason > > why not start using them in Qt 6.0 ? > > Yes. There's a couple of man-decades worth of work to make entire Qt thread- > safe. Then there's the whole discussion about what to do in OOM situations > and whether we can even reliably detect them, which I won't rehash here. > > If you meant it restricted to a few classes, like containers, that's > achievable within one year. If we decide to do that, to make it truly useful > we probably should extend to all value-type classes, like QString and > QNetworkProxy. I agree, making Qt exception safe is close to impossible in the current situation. We could maybe go to basic level of exception safety by adding GC. I'm not sure if it is worth it. I like exceptions but Qt is not designed to use them. Cheers, Jędrek From giuseppe.dangelo at kdab.com Mon Jan 25 14:54:13 2016 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 25 Jan 2016 14:54:13 +0100 Subject: [Development] Stepping down as Windows Embedded Compact port maintainer In-Reply-To: <20151023201923.5918801.19541.46611@theqtcompany.com> References: <1767079.2xVaFgdK3c@bjoern-upc.site> <11132448.BouJTBqgb6@milian-kdab2> <607A7B9A-1446-4B93-B6BA-21374CF6E506@theqtcompany.com> <1718706.38BQBtkiCB@tjmaciei-mobl4> <20151023201923.5918801.19541.46611@theqtcompany.com> Message-ID: <56A62905.9020702@kdab.com> Il 23/10/2015 22:19, Hausmann Simon ha scritto: > +1x2 Howdy, was this nomination somehow lost in the process? I guess enough time has passed to make Andreas both Approver and WinCE maintainer! Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4068 bytes Desc: Firma crittografica S/MIME URL: From Lars.Knoll at theqtcompany.com Mon Jan 25 15:21:04 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 25 Jan 2016 14:21:04 +0000 Subject: [Development] Stepping down as Windows Embedded Compact port maintainer In-Reply-To: <56A62905.9020702@kdab.com> References: <1767079.2xVaFgdK3c@bjoern-upc.site> <11132448.BouJTBqgb6@milian-kdab2> <607A7B9A-1446-4B93-B6BA-21374CF6E506@theqtcompany.com> <1718706.38BQBtkiCB@tjmaciei-mobl4> <20151023201923.5918801.19541.46611@theqtcompany.com> <56A62905.9020702@kdab.com> Message-ID: On 25/01/16 14:54, "Development on behalf of Giuseppe D'Angelo" wrote: >Il 23/10/2015 22:19, Hausmann Simon ha scritto: >> +1x2 > >Howdy, > >was this nomination somehow lost in the process? Looks like it. Sorry for that. >I guess enough time has >passed to make Andreas both Approver and WinCE maintainer! He was already listed as the maintainer, but was not in the approvers list in gerrit. Should be all fixed now. Congratulations Andreas! Cheers, Lars From alexander.blasche at theqtcompany.com Mon Jan 25 15:55:27 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Mon, 25 Jan 2016 14:55:27 +0000 Subject: [Development] Proposal to include qtscxml as Qt add-on module Message-ID: Hi, As part of the renewed publishing process following the new KDE Free Qt foundation agreement, we'd like to publish the source of the new Qt SCXML module. I'd like to propose the module to be accepted as part of the Qt add-on modules. The module itself is brand new as well (target is a 5.7 TP). Initially it would have been part of our Qt Automotive effort. It permits the definition of state machines using SCXML and generates relevant Qt C++ state machines at compile time or runtime. As maintainer I'd like to propose Erik Verbruggen. -- Alex From laszlo.agocs at theqtcompany.com Mon Jan 25 16:37:45 2016 From: laszlo.agocs at theqtcompany.com (Agocs Laszlo) Date: Mon, 25 Jan 2016 15:37:45 +0000 Subject: [Development] Proposal to include QtGamepad as an add-on module Message-ID: Hello, The Qt Gamepad module has been living in a qt-labs repo (*) for some time. I'd like to propose to upgrade it to an add-on module and include it as a Tech Preview in Qt 5.7. This would also benefit other modules, for instance Qt 3D has pending contributions for gamepad support via the Qt Gamepad module. As the maintainer I'm proposing Andy Nichols. Best regards, Laszlo (*) http://code.qt.io/cgit/qt-labs/qtgamepad.git/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bogdan.vatra at kdab.com Mon Jan 25 16:40:49 2016 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Mon, 25 Jan 2016 17:40:49 +0200 Subject: [Development] Proposal to include QtGamepad as an add-on module In-Reply-To: References: Message-ID: <21380221.fmjxlS0pLv@zmeu> +1 BogDan. On Monday 25 January 2016 15:37:45 Agocs Laszlo wrote: > Hello, > > The Qt Gamepad module has been living in a qt-labs repo (*) for some time. > I'd like to propose to upgrade it to an add-on module and include it as a > Tech Preview in Qt 5.7. This would also benefit other modules, for instance > Qt 3D has pending contributions for gamepad support via the Qt Gamepad > module. > > As the maintainer I'm proposing Andy Nichols. > > Best regards, > Laszlo > > (*) http://code.qt.io/cgit/qt-labs/qtgamepad.git/ From sean.harmer at kdab.com Mon Jan 25 19:38:12 2016 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 25 Jan 2016 18:38:12 +0000 Subject: [Development] Proposal to include QtGamepad as an add-on module In-Reply-To: References: Message-ID: <56A66B94.5040102@kdab.com> On 25/01/2016 15:37, Agocs Laszlo wrote: > > Hello, > > The Qt Gamepad module has been living in a qt-labs repo (*) for some > time. I’d like to propose to upgrade it to an add-on module and > include it as a Tech Preview in Qt 5.7. This would also benefit other > modules, for instance Qt 3D has pending contributions for gamepad > support via the Qt Gamepad module. > +1 > As the maintainer I’m proposing Andy Nichols. > And another +1 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Mon Jan 25 19:49:38 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Mon, 25 Jan 2016 18:49:38 +0000 Subject: [Development] Proposal to include qtscxml as Qt add-on module In-Reply-To: References: Message-ID: <0D08658E-B3E4-4BF2-846D-63297D1D9696@theqtcompany.com> +1 State machine framework has been part of Qt for many years and there was also some work earlier for scxml compatibility, which was never completed. SCXML is an industry standard format, which can be exported from multiple different tools. Yours, Tuukka > Blasche Alexander kirjoitti 25.1.2016 kello 16.55: > > Hi, > > As part of the renewed publishing process following the new KDE Free Qt foundation agreement, we'd like to publish the source of the new Qt SCXML module. > > I'd like to propose the module to be accepted as part of the Qt add-on modules. The module itself is brand new as well (target is a 5.7 TP). Initially it would have been part of our Qt Automotive effort. It permits the definition of state machines using SCXML and generates relevant Qt C++ state machines at compile time or runtime. > > As maintainer I'd like to propose Erik Verbruggen. > > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kfunk at kde.org Mon Jan 25 21:02:01 2016 From: kfunk at kde.org (Kevin Funk) Date: Mon, 25 Jan 2016 21:02:01 +0100 Subject: [Development] Proposal to include qtscxml as Qt add-on module In-Reply-To: References: Message-ID: <4304139.IGPr9u1qHP@kerberos> On Monday, January 25, 2016 02:55:27 PM Blasche Alexander wrote: > Hi, > > As part of the renewed publishing process following the new KDE Free Qt > foundation agreement, we'd like to publish the source of the new Qt SCXML > module. > > I'd like to propose the module to be accepted as part of the Qt add-on > modules. The module itself is brand new as well (target is a 5.7 TP). > Initially it would have been part of our Qt Automotive effort. It permits > the definition of state machines using SCXML and generates relevant Qt C++ > state machines at compile time or runtime. > > As maintainer I'd like to propose Erik Verbruggen. +1 Nice to see the state machine framework moving forward (and being enhanced with additional tooling) /me is interested in checking out the new Qt SCXML module! Thanks, Kevin > -- > Alex > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Kevin Funk | kfunk at kde.org | http://kfunk.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: This is a digitally signed message part. URL: From mike.krus at kdab.com Mon Jan 25 21:06:50 2016 From: mike.krus at kdab.com (Mike Krus) Date: Mon, 25 Jan 2016 20:06:50 +0000 Subject: [Development] tvOS port Message-ID: <28D7D8E7-F1F4-434A-A6D8-FB4107E304E4@kdab.com> Hi during the xmas break, I took "advantage" of the dreadful weather to investigate porting Qt5 (dev branch) to Apple's tvOS. Due to tvOS being mostly built upon iOS, the initial work was quite straight forward, adding a new mkspec, a new configure option, a CONFIG variable (tvos), enabling and disabling things where appropriate. [1] Past the initial prototyping, most of the work has been focused on reducing the duplication in the build configuration, following initial feedback on gerrit. Have learned more about prf files than I ever wanted to know :) Most relevant modules have been updated to build for tvOS, but with very limited testing. Beyond testing, key challenge remaining is the user interaction. Due to the lack of direct touch, or even a mouse cursor, handling focus, mouse areas, etc, will require more careful work. As always, feedback and suggestions will be greatly appreciated. Mike [1] pending changelists: https://codereview.qt-project.org/144800 https://codereview.qt-project.org/145174 https://codereview.qt-project.org/145519 -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44-1625-809908 Mobile +44 7833 491941 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3859 bytes Desc: not available URL: From mike.krus at kdab.com Tue Jan 26 08:42:03 2016 From: mike.krus at kdab.com (Mike Krus) Date: Tue, 26 Jan 2016 07:42:03 +0000 Subject: [Development] Proposal to include QtGamepad as an add-on module In-Reply-To: References: Message-ID: <56A7234B.9070803@kdab.com> +1, will be useful for the tvOS remote! Mike On 25/01/2016 15:37, Agocs Laszlo wrote: > Hello, > > The Qt Gamepad module has been living in a qt-labs repo (*) for some > time. I’d like to propose to upgrade it to an add-on module and include > it as a Tech Preview in Qt 5.7. This would also benefit other modules, > for instance Qt 3D has pending contributions for gamepad support via the > Qt Gamepad module. > > As the maintainer I’m proposing Andy Nichols. > > Best regards, > > Laszlo > > (*) http://code.qt.io/cgit/qt-labs/qtgamepad.git/ > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44-1625-809908 Mobile +44 7833 491941 KDAB - The Qt Experts From Lars.Knoll at theqtcompany.com Tue Jan 26 08:47:17 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 26 Jan 2016 07:47:17 +0000 Subject: [Development] Proposal to include qtscxml as Qt add-on module In-Reply-To: <0D08658E-B3E4-4BF2-846D-63297D1D9696@theqtcompany.com> References: <0D08658E-B3E4-4BF2-846D-63297D1D9696@theqtcompany.com> Message-ID: <9C45D449-99A0-49C7-94D6-386B2BC185AA@theqtcompany.com> +1 for making it a TP in 5.7 and another +1 for Erik becoming the maintainer. Cheers, Lars On 25/01/16 19:49, "Development on behalf of Turunen Tuukka" wrote: > >+1 > >State machine framework has been part of Qt for many years and there was also some work earlier for scxml compatibility, which was never completed. SCXML is an industry standard format, which can be exported from multiple different tools. > >Yours, > >Tuukka > >> Blasche Alexander kirjoitti 25.1.2016 kello 16.55: >> >> Hi, >> >> As part of the renewed publishing process following the new KDE Free Qt foundation agreement, we'd like to publish the source of the new Qt SCXML module. >> >> I'd like to propose the module to be accepted as part of the Qt add-on modules. The module itself is brand new as well (target is a 5.7 TP). Initially it would have been part of our Qt Automotive effort. It permits the definition of state machines using SCXML and generates relevant Qt C++ state machines at compile time or runtime. >> >> As maintainer I'd like to propose Erik Verbruggen. >> >> -- >> Alex >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at theqtcompany.com Tue Jan 26 08:47:42 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 26 Jan 2016 07:47:42 +0000 Subject: [Development] Proposal to include QtGamepad as an add-on module In-Reply-To: <56A7234B.9070803@kdab.com> References: <56A7234B.9070803@kdab.com> Message-ID: <95499C6D-38DF-4DB3-B2FF-904DE0A53E0E@theqtcompany.com> And another +1 from me. Cheers, Lars On 26/01/16 08:42, "Development on behalf of Mike Krus" wrote: >+1, will be useful for the tvOS remote! > > >Mike > >On 25/01/2016 15:37, Agocs Laszlo wrote: >> Hello, >> >> The Qt Gamepad module has been living in a qt-labs repo (*) for some >> time. I’d like to propose to upgrade it to an add-on module and include >> it as a Tech Preview in Qt 5.7. This would also benefit other modules, >> for instance Qt 3D has pending contributions for gamepad support via the >> Qt Gamepad module. >> >> As the maintainer I’m proposing Andy Nichols. >> >> Best regards, >> >> Laszlo >> >> (*) http://code.qt.io/cgit/qt-labs/qtgamepad.git/ >> >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > >-- >Mike Krus | mike.krus at kdab.com | Senior Software Engineer >KDAB (UK) Ltd., a KDAB Group company >Tel: UK Office +44-1625-809908 Mobile +44 7833 491941 >KDAB - The Qt Experts >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at theqtcompany.com Tue Jan 26 08:48:16 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Tue, 26 Jan 2016 07:48:16 +0000 Subject: [Development] tvOS port In-Reply-To: <28D7D8E7-F1F4-434A-A6D8-FB4107E304E4@kdab.com> References: <28D7D8E7-F1F4-434A-A6D8-FB4107E304E4@kdab.com> Message-ID: Awesome work :) Simon ________________________________________ From: Development on behalf of Mike Krus Sent: Monday, January 25, 2016 21:06 To: Qt Development Group Subject: [Development] tvOS port Hi during the xmas break, I took "advantage" of the dreadful weather to investigate porting Qt5 (dev branch) to Apple's tvOS. Due to tvOS being mostly built upon iOS, the initial work was quite straight forward, adding a new mkspec, a new configure option, a CONFIG variable (tvos), enabling and disabling things where appropriate. [1] Past the initial prototyping, most of the work has been focused on reducing the duplication in the build configuration, following initial feedback on gerrit. Have learned more about prf files than I ever wanted to know :) Most relevant modules have been updated to build for tvOS, but with very limited testing. Beyond testing, key challenge remaining is the user interaction. Due to the lack of direct touch, or even a mouse cursor, handling focus, mouse areas, etc, will require more careful work. As always, feedback and suggestions will be greatly appreciated. Mike [1] pending changelists: https://codereview.qt-project.org/144800 https://codereview.qt-project.org/145174 https://codereview.qt-project.org/145519 -- Mike Krus | mike.krus at kdab.com | Senior Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel: UK Office +44-1625-809908 Mobile +44 7833 491941 KDAB - The Qt Experts From helio at kde.org Tue Jan 26 08:52:57 2016 From: helio at kde.org (Helio Chissini de Castro) Date: Tue, 26 Jan 2016 08:52:57 +0100 Subject: [Development] Proposal to include qtscxml as Qt add-on module In-Reply-To: <9C45D449-99A0-49C7-94D6-386B2BC185AA@theqtcompany.com> References: <0D08658E-B3E4-4BF2-846D-63297D1D9696@theqtcompany.com> <9C45D449-99A0-49C7-94D6-386B2BC185AA@theqtcompany.com> Message-ID: Hello I'm just curious, is Qt project aiming for be a umbrella of libraries tied to Qt release or this libraries like QtGamePad on other thread should be more suitable to something like inqlude.org ( or similar ). Just to clarify, as a distro packager too. []'s On Tue, Jan 26, 2016 at 8:47 AM, Knoll Lars wrote: > +1 for making it a TP in 5.7 and another +1 for Erik becoming the > maintainer. > > Cheers, > Lars > > > > On 25/01/16 19:49, "Development on behalf of Turunen Tuukka" < > development-bounces at qt-project.org on behalf of > tuukka.turunen at theqtcompany.com> wrote: > > > > >+1 > > > >State machine framework has been part of Qt for many years and there was > also some work earlier for scxml compatibility, which was never completed. > SCXML is an industry standard format, which can be exported from multiple > different tools. > > > >Yours, > > > >Tuukka > > > >> Blasche Alexander kirjoitti > 25.1.2016 kello 16.55: > >> > >> Hi, > >> > >> As part of the renewed publishing process following the new KDE Free Qt > foundation agreement, we'd like to publish the source of the new Qt SCXML > module. > >> > >> I'd like to propose the module to be accepted as part of the Qt add-on > modules. The module itself is brand new as well (target is a 5.7 TP). > Initially it would have been part of our Qt Automotive effort. It permits > the definition of state machines using SCXML and generates relevant Qt C++ > state machines at compile time or runtime. > >> > >> As maintainer I'd like to propose Erik Verbruggen. > >> > >> -- > >> Alex > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > >_______________________________________________ > >Development mailing list > >Development at qt-project.org > >http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > 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 alexis.jeandet at member.fsf.org Tue Jan 26 10:20:10 2016 From: alexis.jeandet at member.fsf.org (Alexis Jeandet) Date: Tue, 26 Jan 2016 10:20:10 +0100 Subject: [Development] Charts and DataVis Questions In-Reply-To: <0C63835B-BA8D-4301-80E5-F6F4E8B97275@digia.com> References: <1453475786.3146.57.camel@member.fsf.org> <56A3CBE8.10809@theharmers.co.uk> <0C63835B-BA8D-4301-80E5-F6F4E8B97275@digia.com> Message-ID: <1453800010.3146.107.camel@member.fsf.org> Le lundi 25 janvier 2016 à 10:20 +0000, Rutledge Shawn a écrit : > > On 23 Jan 2016, at 19:52, Sean Harmer wrote: > > > > On 23/01/2016 12:45, Uwe Rathmann wrote: > > >  Hi, > > > > > > > The OpenGL acceleration in Charts module is really impressive > > > > ... > > > Unfortunately part of the truth is, that the performance of the > > > software > > > renderer does not necessarily be that far behind. > > Now try it against OpenGL with 100k points rendering to a 4k > > screen. The difference between software and hardware will increase > > with those parameters (up to some fill rate or vertex rate that the > > hardware can handle). > You especially don’t want to do antialiasing with the software > renderer (been there done that: it was about 2008 and using AA when > rendering a QPainterPath made it several times slower than without), > whereas vertex antialiasing with OpenGL is doable.  QtCharts so far > uses GL_LINES for the line graph, but AFAIK the only way to get > antialiasing with that approach is to turn on multi-sampling, which > performs well only on certain desktop graphics cards (line graphs are > simple enough, but it wouldn’t be so great to turn on MSAA in the > whole QtQuick scene if your app is complex and you expect it to be > portable).  I’ve been working on an antialiasing line graph, outside > of Qt Charts so far though.  It’s similar to > qtdeclarative/examples/quick/scenegraph/graph but does mitering right > in the vertex shader, and antialiasing by setting the transparency > proportional to distance away from the virtual line, in the fragment > shader. > > And of course with GPU rendering you can have full-frame-rate > dynamism, whether the data is actually changing that fast or you are > interacting - zooming, panning, moving a time cursor to see the > corresponding data point, etc.  My laptop can render 60FPS while > keeping the CPU at its lowest clock rate.  Or maybe a raspberry pi > would have sufficient power to run an oscilloscope display, with the > trace so smooth that it looks like an analog scope; I haven’t tried > that, but it would make a nice demo. Yes not only, for embedded measurement there would be a lot of users.... > > > > Data modelling is another consideration.  I think the holy grail would be if we could send the actual data to the GPU unmodified, and render it there.  Vertex AA requires generating duplicate vertices though, to be able to expand them away from > the line, to give it thickness.  So, for speed (but not memory conservation) we want to keep that array of vertices around, add new datapoints to one end and remove old ones from the other - as opposed to generating vertices each time we render one frame. >  So it needs to have that kind of API, and you then should try to minimize any additional copying: store the data how you like but manage the vertices incrementally, or add each new sample to the vertex array and don’t bother keeping your own copy.  So I tried > writing a data model which works that way: it stores the vertices on behalf of the rendering code, without exposing them directly in the API.  Whereas QLineSeries both stores data and renders it, as you can see in the example with the use of the append() function. >  So maybe it could be refactored so that you can instead implement a model by subclassing an abstract base class, similar to the way that QListWidget is a QListView with an internal model, whereas in non-trivial applications you write your own QAIM and use > QListView and/or QML ListView.  But a time series is just one kind of data, and only makes sense with certain types of visualization.  So we could follow through and write abstract model classes for other kinds of data that can be visualized, but this kind > of modelling amounts to making assumptions, which requires a lot of care to keep it as widely applicable as possible. Indeed, the openglseries example, sucks 1,6GB for  2x5000000 points that makes around 160B per data point. Also the perfs are really bad where QCustomPlot(modified to use QVectors) may be faster without OpenGL. > > > > Later I want to try using a geometry shader to expand the datapoints into vertices.  That will be less portable though (won’t work on OpenGL ES).  But maybe it would make zero-copy (on the CPU) visualization possible, as long as you are OK to > model the data the way that the rendering code expects (a time-value struct, just two floats or doubles per data point; or maybe two arrays, one for times and one for values). Doubles would be good when using epoch like times series with high sampling rate. > > > > My mitering shader has trouble with excessively high-frequency data, so resampling is useful, to get the sample rate down to one sample per horizontal pixel, or less.  There is some recent research on how to do that while preserving the psychological > impression of how the data looks, which I’ve been implementing (only on the CPU so far): > > > > http://skemman.is/stream/get/1946/15343/37285/3/SS_MSthesis.pdf I pointed this publication initially but I think that the Largest Triangle Three Buckets isn't as good(visual result) as the method implemented in QCustomPlot and needs more CPU. At least for line plot. > > > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org> http://lists.qt-project.org/mailman/listinfo/development> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at theqtcompany.com Tue Jan 26 15:13:12 2016 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Tue, 26 Jan 2016 14:13:12 +0000 Subject: [Development] Proposal to include qtscxml as Qt add-on module In-Reply-To: References: Message-ID: The module is now available under git clone https://codereview.qt-project.org/qt/qtscxml. There is still some refactoring ongoing as the very recent API review created good suggestions and revealed some issues. Therefore stay tuned. -- Alex ________________________________________ From: Development on behalf of Blasche Alexander Sent: Monday, January 25, 2016 15:55 To: development at qt-project.org Subject: [Development] Proposal to include qtscxml as Qt add-on module Hi, As part of the renewed publishing process following the new KDE Free Qt foundation agreement, we'd like to publish the source of the new Qt SCXML module. I'd like to propose the module to be accepted as part of the Qt add-on modules. The module itself is brand new as well (target is a 5.7 TP). Initially it would have been part of our Qt Automotive effort. It permits the definition of state machines using SCXML and generates relevant Qt C++ state machines at compile time or runtime. As maintainer I'd like to propose Erik Verbruggen. -- Alex _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From xbenlau at gmail.com Tue Jan 26 16:37:02 2016 From: xbenlau at gmail.com (Ben Lau) Date: Tue, 26 Jan 2016 23:37:02 +0800 Subject: [Development] Setup CI service Message-ID: Hi, Since Qt 5.5, the command line installer has been broken. Therefore, it can not use Qt 5.5 in CI service like travis / drone.io etc. Is there has any alternative solution developing and will available in Qt 5.6? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From charleyb123 at gmail.com Tue Jan 26 17:22:41 2016 From: charleyb123 at gmail.com (charleyb123 .) Date: Tue, 26 Jan 2016 08:22:41 -0800 Subject: [Development] CppNow Call For Submissions 2016 Message-ID: The Call For Submissions for the CppNow conference (May 9-14, 2016) in Aspen, CO will close this Friday (Fri-29-Jan). This is an intimate C++ conference with great minds, including many Qt users, and past speakers have come from the Qt community. Consider attending, and/or submitting a talk. http://cppnow.org/2016-conference/announcements/2015/11/17/call-for-submission.html --charley -------------- next part -------------- An HTML attachment was scrubbed... URL: From dchamberlain at ics.com Tue Jan 26 18:11:55 2016 From: dchamberlain at ics.com (David Chamberlain) Date: Tue, 26 Jan 2016 12:11:55 -0500 Subject: [Development] Proposal to include qtscxml as Qt add-on module In-Reply-To: References: Message-ID: Hello, Interested parties would like to know whether this [qtscxml] module will be remaining under the LGPL license for Qt 5.7 (and beyond) to the best of current knowledge. Thanks! -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at theqtcompany.com Tue Jan 26 21:13:05 2016 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Tue, 26 Jan 2016 20:13:05 +0000 Subject: [Development] Proposal to include qtscxml as Qt add-on module In-Reply-To: References: , Message-ID: Hi David, The new Qt SCXML is licensed under LGPLv3 (and GPL and Commercial), and there are no plans to remove the LGPLv3 option of it. There are a few tooling parts that are GPLv3 (with exceptions) just like the other tools and applications going forward. So it is possible to use Qt SCXML also in closed-source applications as long as the user complies with LGPLv3 license terms. Yours, Tuukka ________________________________ Lähettäjä: Development käyttäjän puolestaDavid Chamberlain Lähetetty: 26. tammikuuta 2016 19:11 Vastaanottaja: development at qt-project.org Aihe: Re: [Development] Proposal to include qtscxml as Qt add-on module Hello, Interested parties would like to know whether this [qtscxml] module will be remaining under the LGPL license for Qt 5.7 (and beyond) to the best of current knowledge. Thanks! -- David -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at theqtcompany.com Wed Jan 27 08:30:09 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Wed, 27 Jan 2016 07:30:09 +0000 Subject: [Development] Setup CI service In-Reply-To: References: Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On > Behalf Of Ben Lau > Sent: Tuesday, January 26, 2016 4:37 PM > To: development at qt-project.org > Subject: [Development] Setup CI service > > Hi, > > Since Qt 5.5, the command line installer has been broken. Therefore, it can > not use Qt 5.5 in CI service like travis / drone.io etc. Is > there has any alternative solution developing and will available in Qt 5.6? Could you elaborate which installer you mean, and what is exactly broke? Regards Kai From xbenlau at gmail.com Wed Jan 27 08:54:08 2016 From: xbenlau at gmail.com (Ben Lau) Date: Wed, 27 Jan 2016 15:54:08 +0800 Subject: [Development] Setup CI service In-Reply-To: References: Message-ID: On 27 January 2016 at 15:30, Koehne Kai wrote: > > > > -----Original Message----- > > From: Development [mailto:development-bounces at qt-project.org] On > > Behalf Of Ben Lau > > Sent: Tuesday, January 26, 2016 4:37 PM > > To: development at qt-project.org > > Subject: [Development] Setup CI service > > > > Hi, > > > > Since Qt 5.5, the command line installer has been broken. Therefore, it > can > > not use Qt 5.5 in CI service like travis / drone.io > etc. Is > > there has any alternative solution developing and will available in Qt > 5.6? > > Could you elaborate which installer you mean, and what is exactly broke? > > Regards > > Kai > > Hi Kai, I mean the official Qt offline installer (Linux) downloaded from https://download.qt.io/archive/qt/5.5/ Before Qt 5.5, it could be run in command line environment and extract its content by " --dump-binary-data". But this options has been dropped. I am using drone.io to build Qt Android application, but due to this problem, it is still using Qt 5.4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at theqtcompany.com Wed Jan 27 09:12:45 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Wed, 27 Jan 2016 08:12:45 +0000 Subject: [Development] Setup CI service In-Reply-To: References: Message-ID: > -----Original Message----- > From: Ben Lau [mailto:xbenlau at gmail.com] >[...] > Hi Kai, > > I mean the official Qt offline installer (Linux) downloaded from > https://download.qt.io/archive/qt/5.5/ > > Before Qt 5.5, it could be run in command line environment and extract its > content by " --dump-binary-data". But this options has been dropped. It got moved to an extra executable called 'devtool'. You can still use it by getting the IFW itself, e.g. from http://download.qt.io/official_releases/qt-installer-framework/2.0.1/ , and launching devtool with the installer as an argument. Anyhow, also the installer itself can be scripted & execute automatically. Regards Kai From Lars.Knoll at theqtcompany.com Wed Jan 27 09:30:10 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 27 Jan 2016 08:30:10 +0000 Subject: [Development] 5.7 feature freeze Message-ID: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> Hi everybody, we’re slightly past the originally planned date for the feature freeze, for various reasons (new stuff being open sourced, license change and being late with 5.6). But I believe most things should be in place now to do the feature freeze for 5.7 next Monday. There are currently three exceptions to the freeze: * ok to finish the printing support in web engine * ok for BTLE support for Linux in qtconnectivity (merge neard branch) * Modules that are flagged as TP can also have some more time If anybody else has a feature he believes absolutely has to make it to 5.7, get it done until Monday or talk to me :) Cheers, Lars From Simon.Hausmann at theqtcompany.com Wed Jan 27 09:45:03 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Wed, 27 Jan 2016 08:45:03 +0000 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 In-Reply-To: <2718327.vc9pWrFWa0@finn> References: ,<2718327.vc9pWrFWa0@finn> Message-ID: <20160127084501.5922898.15143.57533@theqtcompany.com> Ok, I had another look. I don't think find_if is new in C++11: ‎http://en.cppreference.com/w/cpp/algorithm/find It seems find_if_not is, but not find_if. So I think what we see here is‎ simply a compiler bug perhaps? Thanks to Marco it seems that we have a workaround: https://codereview.qt-project.org/#/c/147484/ ‎So I don't have the impression that C++11 code can slip through the CI for the 5.6 branches. However if you do discover an incidence please holler :) Simon Original Message From: Olivier Goffart Sent: Monday, January 18, 2016 16:26 To: development at qt-project.org Cc: Rex Dieter Subject: Re: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 On Montag, 18. Januar 2016 08:31:01 CET Rex Dieter wrote: > I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run > into a build failure in qtdeclarative, > beta/tools/qmlimportscanner/main.cpp:376: error: no matching function for > call to 'find_if(QList::const_iterator, std::find_if is new in C++11 And it was used in https://codereview.qt-project.org/125853/ in the 5.6 which still does not require C++11. Apparently the CI does not try to build this with non-c++11 enabled compilers? -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From xbenlau at gmail.com Wed Jan 27 10:57:03 2016 From: xbenlau at gmail.com (Ben Lau) Date: Wed, 27 Jan 2016 17:57:03 +0800 Subject: [Development] Setup CI service In-Reply-To: References: Message-ID: On 27 January 2016 at 16:12, Koehne Kai wrote: > > > > -----Original Message----- > > From: Ben Lau [mailto:xbenlau at gmail.com] > >[...] > > Hi Kai, > > > > I mean the official Qt offline installer (Linux) downloaded from > > https://download.qt.io/archive/qt/5.5/ > > > > Before Qt 5.5, it could be run in command line environment and extract > its > > content by " --dump-binary-data". But this options has been dropped. > > It got moved to an extra executable called 'devtool'. You can still use it > by getting the IFW itself, e.g. from > http://download.qt.io/official_releases/qt-installer-framework/2.0.1/ , > and launching devtool with the installer as an argument. > > But how can I install devtool in command line environment? > Anyhow, also the installer itself can be scripted & execute automatically. > > Any example? > Regards > > Kai > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at theqtcompany.com Wed Jan 27 11:09:21 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Wed, 27 Jan 2016 10:09:21 +0000 Subject: [Development] Setup CI service In-Reply-To: References: Message-ID: > -----Original Message----- > From: Ben Lau [mailto:xbenlau at gmail.com] > Sent: Wednesday, January 27, 2016 10:57 AM > To: Koehne Kai > Cc: development at qt-project.org > Subject: Re: [Development] Setup CI service > > > > On 27 January 2016 at 16:12, Koehne Kai > wrote: > > > > > > -----Original Message----- > > From: Ben Lau [mailto:xbenlau at gmail.com > ] > >[...] > > Hi Kai, > > > > I mean the official Qt offline installer (Linux) downloaded from > > https://download.qt.io/archive/qt/5.5/ > > > > Before Qt 5.5, it could be run in command line environment and > extract its > > content by " --dump-binary-data". But this options has been > dropped. > > It got moved to an extra executable called 'devtool'. You can still > use it > by getting the IFW itself, e.g. from > http://download.qt.io/official_releases/qt-installer- > framework/2.0.1/ , > and launching devtool with the installer as an argument. > > But how can I install devtool in command line environment? This is a bit of a chicken-and-egg problem indeed (that is, if you really want to start with a completely clean slate. The devtools version doesn't have to necessarily match exactly the installer version). > Anyhow, also the installer itself can be scripted & execute > automatically. > > Any example? http://doc.qt.io/qtinstallerframework/qt-installer-framework-quitinstaller-example.html (Note though that the Qt Account page isn't part of this example, since it's not part of the general IFW. But I guess you can just add another "Next" for this page ...) Regards Kai PS: Feel free to move the thread to interest@ From xbenlau at gmail.com Wed Jan 27 11:13:30 2016 From: xbenlau at gmail.com (Ben Lau) Date: Wed, 27 Jan 2016 18:13:30 +0800 Subject: [Development] Setup CI service In-Reply-To: References: Message-ID: On 27 January 2016 at 18:09, Koehne Kai wrote: > > > > -----Original Message----- > > From: Ben Lau [mailto:xbenlau at gmail.com] > > Sent: Wednesday, January 27, 2016 10:57 AM > > To: Koehne Kai > > Cc: development at qt-project.org > > Subject: Re: [Development] Setup CI service > > > > > > > > On 27 January 2016 at 16:12, Koehne Kai > > wrote: > > > > > > > > > > > -----Original Message----- > > > From: Ben Lau [mailto:xbenlau at gmail.com > > ] > > >[...] > > > Hi Kai, > > > > > > I mean the official Qt offline installer (Linux) downloaded from > > > https://download.qt.io/archive/qt/5.5/ > > > > > > Before Qt 5.5, it could be run in command line environment and > > extract its > > > content by " --dump-binary-data". But this options has been > > dropped. > > > > It got moved to an extra executable called 'devtool'. You can > still > > use it > > by getting the IFW itself, e.g. from > > http://download.qt.io/official_releases/qt-installer- > > framework/2.0.1/ , > > and launching devtool with the installer as an argument. > > > > But how can I install devtool in command line environment? > > This is a bit of a chicken-and-egg problem indeed (that is, if you really > want to start with a completely clean slate. The devtools version doesn't > have to necessarily match exactly the installer version). > > That is the exact problem. I think it need to have a command line installable ifw to get started . (e.g a PPA in Ubuntu) > > Anyhow, also the installer itself can be scripted & execute > > automatically. > > > > Any example? > > > http://doc.qt.io/qtinstallerframework/qt-installer-framework-quitinstaller-example.html > > (Note though that the Qt Account page isn't part of this example, since > it's not part of the general IFW. But I guess you can just add another > "Next" for this page ...) > A bit confused. That is the instruction to build a installer or manipulate an existing installer? > > Regards > > Kai > > PS: Feel free to move the thread to interest@ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Jan 27 14:37:31 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 27 Jan 2016 14:37:31 +0100 Subject: [Development] API review and API quality In-Reply-To: <14982660.RFZjYkf8mA@rechenplan> References: <14982660.RFZjYkf8mA@rechenplan> Message-ID: <201601271437.32048.marc.mutz@kdab.com> On Monday 18 January 2016 15:48:54 Andreas Hartmetz wrote: > Everything I have written about API applies to documentation as well. It > seems like whatever the implementor writes is accepted and that is that. > AFAIU that was not exactly how it used to be done at Trolltech when it > was still called Trolltech? +1 To wit: https://codereview.qt-project.org/146112 (staged while being -1'ed for the docs (and commit message)). /me shakes head -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From annulen at yandex.ru Wed Jan 27 13:34:23 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 27 Jan 2016 15:34:23 +0300 Subject: [Development] New KDE Free Qt Foundation agreement and changes to Qt In-Reply-To: <578CF287-C1BC-4F31-9DA6-78F75157DD72@theqtcompany.com> References: <578CF287-C1BC-4F31-9DA6-78F75157DD72@theqtcompany.com> Message-ID: <844431453898063@web12o.yandex.ru> 13.01.2016, 14:15, "Knoll Lars" : > Hi everybody, > > The Qt Company has over the last days signed a new and updated agreement with the KDE Free Foundation. With this new agreement come some adjustments to the open source licensing of Qt. Basically LGPLv3 will in the future be our main license for frameworks, GPLv3 for the tooling. > > At the same time, The Qt Company committed to open source the currently commercial only parts of Qt for Application Development under the GPLv3 and make those available to the open source community. > > I have discussed this change with many of our Maintainers over the last week, getting a lot of positive feedback to this change. > > Please have a read through the blog post at > http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation for all the details. > > We have already pushed the sources of Qt Charts, Qt Data Visualisation and the Qt virtual keyboard to codereview, and you can pull the code from there. I would personally like to see most of these things integrated into the Qt 5.7 open source packages already, and minimise the feature delta between the OSS and commercial versions of Qt for Application Development. Just to clarify things: does this change affect QtWebKit? -- Regards, Konstantin From rpzrpzrpz at gmail.com Wed Jan 27 13:34:24 2016 From: rpzrpzrpz at gmail.com (mark diener) Date: Wed, 27 Jan 2016 06:34:24 -0600 Subject: [Development] 5.7 feature freeze In-Reply-To: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> Message-ID: Lars: I am sure I am not the only newcomer to QT who would love to add code to the 5.7 feature list, but barely have time to contribute bugs to debug 5.6.0 beta let alone look ahead to 5.7 Now we are faced with waiting until 5.8 to even think about a set of key missing functions in Qt QML. I am still firmly planted on the interest list and not on the development list. One major problem lies with QQmlEngine design: It has the following functions defined: QQmlEngine->trimComponentCache() QQmlEngine->clearComponentCache() (https://bugreports.qt.io/browse/QTBUG-50500) But it is absolutely missing: QQmlEngine->addComponent("MyComponentLib",1,0,"MyComponentName",QQmlComponent& gcomp) -> error code QQmlEngine->removeComponent("MyComponentLib",1,0,"MyComponentName") -> error code QQmlEngine->isComponentLoaded("MyComponentLib",1,0,"MyComponentName") -> bool Devs are stuck using a QMLDIR file based import pattern that has the flexibility of an ice cube. We really need qml files to be able to execute: import MyComponentLib 1.0 without using QMLDIR files! The other major problem is that QQuickItem does not allow for QSGTextRect, so updatePaintNode CANNOT have text rendering in coordination with QSGGeometry. The current recommendation is to try to coordinate using signals between 2 different QQuickItems, 1 with text, the other with graphical geometry. This is a restriction that appears to have occurred by chance. This cripples custom controls capabilities and forces me to explain to customers about Qt limitations. So how can we get the header file for QQmlEngine changed for 5.7 feature freeze to add those 3 function declarations and un-sandbox QSGTextRect and still pass maintainer acceptance all by Monday? Cheers, md On Wed, Jan 27, 2016 at 2:30 AM, Knoll Lars wrote: > Hi everybody, > > we’re slightly past the originally planned date for the feature freeze, for various reasons (new stuff being open sourced, license change and being late with 5.6). But I believe most things should be in place now to do the feature freeze for 5.7 next Monday. > > There are currently three exceptions to the freeze: > > * ok to finish the printing support in web engine > * ok for BTLE support for Linux in qtconnectivity (merge neard branch) > * Modules that are flagged as TP can also have some more time > > If anybody else has a feature he believes absolutely has to make it to 5.7, get it done until Monday or talk to me :) > > Cheers, > Lars > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Lars.Knoll at theqtcompany.com Wed Jan 27 13:37:36 2016 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 27 Jan 2016 12:37:36 +0000 Subject: [Development] New KDE Free Qt Foundation agreement and changes to Qt In-Reply-To: <844431453898063@web12o.yandex.ru> References: <578CF287-C1BC-4F31-9DA6-78F75157DD72@theqtcompany.com> <844431453898063@web12o.yandex.ru> Message-ID: On 27/01/16 13:34, "Konstantin Tokarev" wrote: > > >13.01.2016, 14:15, "Knoll Lars" : >> Hi everybody, >> >> The Qt Company has over the last days signed a new and updated agreement with the KDE Free Foundation. With this new agreement come some adjustments to the open source licensing of Qt. Basically LGPLv3 will in the future be our main license for frameworks, GPLv3 for the tooling. >> >> At the same time, The Qt Company committed to open source the currently commercial only parts of Qt for Application Development under the GPLv3 and make those available to the open source community. >> >> I have discussed this change with many of our Maintainers over the last week, getting a lot of positive feedback to this change. >> >> Please have a read through the blog post at >> http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation for all the details. >> >> We have already pushed the sources of Qt Charts, Qt Data Visualisation and the Qt virtual keyboard to codereview, and you can pull the code from there. I would personally like to see most of these things integrated into the Qt 5.7 open source packages already, and minimise the feature delta between the OSS and commercial versions of Qt for Application Development. > >Just to clarify things: does this change affect QtWebKit? No, only modules that are going to be part of the official Qt 5.7. Cheers, Lars From f at rtfs.org Wed Jan 27 17:01:26 2016 From: f at rtfs.org (Fabian Sturm) Date: Wed, 27 Jan 2016 16:01:26 +0000 Subject: [Development] qt quick with dummydata/context in Ubuntu 15.10 Message-ID: <20160127160126.Horde.0QJA_WzJMkwL9Z_4FZYdVw1@www.rtfs.org> Hello, I try to edit a qml file in QtCreator and it obviously has problems since I refer to a non existent parent.width property. The solution as described here: http://blog.qt.io/blog/2011/07/28/mockup-data-for-the-qml-designer/ is to create a dummydata/context directory and in this create a file with the same name as the original qml file which provides the context. Unfortunately this seems to not work in Ubuntu 15.10. From the strace of the QtCreator (and childs) I see that it successfully loads the context document but then fails loading the QmlDesigner plugin. Maybe that is the reason for my problem? Here are the files: Test.qml import QtQuick 2.3 Text { width: parent.width height: parent.height text: clock.time } dummydata/clock.qml (that is loaded correct) QtObject { property int time: 54321 } dummydata/context/Test.qml import QtQuick 2.3 import QmlDesigner 1.0 DummyContextObject { parent: Item { width: 640 height: 300 } } What do I need to do to get ot working? Or is there another way to provide a default parent? Thanks a lot, Fabian From Shawn.Rutledge at theqtcompany.com Wed Jan 27 17:15:29 2016 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Wed, 27 Jan 2016 16:15:29 +0000 Subject: [Development] [Interest] 5.7 feature freeze In-Reply-To: References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> Message-ID: <1D403F5B-429F-4814-B3CF-883463017365@digia.com> > On 27 Jan 2016, at 13:34, mark diener wrote: > > The other major problem is that QQuickItem does not allow for > QSGTextRect, so updatePaintNode CANNOT have text rendering > in coordination with QSGGeometry. The current recommendation is to > try to coordinate using signals between 2 different QQuickItems, 1 > with text, the other > with graphical geometry. This is a restriction that appears to have > occurred by chance. That’s not the right class name AFAICT, but you mean you want public C++ API to populate text nodes into the scene graph, right? Following the pattern that QSGSimpleRectNode and QSGSimpleTextureNode are public. Yes this has been a sore thumb for quite some time. Meanwhile, you can use private API. If we make it public, then we are committed to keeping it compatible from now on, so I think that’s why the text-related nodes have not been made public so far: fear of losing flexibility to evolve. We know that text rendering in Qt Quick needs to be more efficient. What if that involves some refactoring? And text rendering is complex, more or less depending on how fancy layout you need. So I think in the long term we need some lower-level stuff, like a Glyph object in some QtQuick module (for putting FontAwesome icons [and future color-font icons!] on tool buttons, and selecting them by name rather than by unicode ID), and a PlainText item restricted to left-to-right rendering in a single font and color (no character spans, no markup, no harfbuzz, no RTL, but maybe with tab stops), as long as such an approach actually speeds up the common case. Maybe such simple classes will be easier to make public, too, because they will have thin API. (And then I would like to use the PlainText item to build a wicked-fast plain-text TableView.) But, I did this https://codereview.qt-project.org/#/c/125753/ because in addition to being private, QQuickTextNode wasn’t even exported from the module; that must have been an oversight. But that’s for 5.7. So at least you can work at the level of Items rather than scene-graph nodes, using private C++ API. And there is also private API for manipulating the scene graph nodes. This came up for me when I wanted to label the tick marks on the axes of a line graph. (I didn’t want to use bindings to position individual Text items.) I tried adding QT+=quick-private #include and managed to spit out a few glyphs, but realized that our layout API is a little cumbersome (and I found a bug while I was at it, which has since been fixed if memory serves), and figured I’d need more time than I thought to get it working well. So then I tried using QQuickTextNode instead, which works now (on 5.7 branch). But it’s not the fastest possible way to do simple left-to-right labelling, so I should probably go back to the first way at some point. And if you haven’t, you should try it too, and then be careful what kind of public API you wish for. ;-) > This cripples custom controls capabilities and forces me to explain to > customers about Qt limitations. > > So how can we get the header file for QQmlEngine changed for 5.7 What is that about? > feature freeze to add those 3 function declarations and un-sandbox > QSGTextRect > and still pass maintainer acceptance all by Monday? If nobody started that yet, that means it’s potentially 5.8 material, right? And as soon as dev is branched for 5.7, it implies that any further development on dev branch is actually for 5.8. So someone could potentially have a full half-year cycle to make the existing private APIs decent, and/or write the new stuff, debug it, document it, do API review, use it in some pet application(s), and catch all the gotcha’s. Assuming that everyone involved can be persuaded that it actually ought to be public at all, within that time frame, or assuming that somebody finds the time to implement APIs which are definitely good enough to make public and support over the long term. (I would like to actually, but my main goal for 5.8 is the set of new pointer handlers, which is notoriously time-consuming stuff: it’s hard to get reviewers to be interested and have sufficient attention span, autotests take a lot of work, etc.) > > Cheers, > > md > > > On Wed, Jan 27, 2016 at 2:30 AM, Knoll Lars wrote: >> Hi everybody, >> >> we’re slightly past the originally planned date for the feature freeze, for various reasons (new stuff being open sourced, license change and being late with 5.6). But I believe most things should be in place now to do the feature freeze for 5.7 next Monday. >> >> There are currently three exceptions to the freeze: >> >> * ok to finish the printing support in web engine >> * ok for BTLE support for Linux in qtconnectivity (merge neard branch) >> * Modules that are flagged as TP can also have some more time >> >> If anybody else has a feature he believes absolutely has to make it to 5.7, get it done until Monday or talk to me :) >> >> Cheers, >> Lars >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Interest mailing list > Interest at qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest From annulen at yandex.ru Wed Jan 27 17:16:58 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 27 Jan 2016 19:16:58 +0300 Subject: [Development] Setting up test server for QtNetwork tests Message-ID: <280901453911418@web22o.yandex.ru> Hello, What is the recommended (and possibly easiest) way to set up test server for QtNetwork? I've found manual [1]. Is it the preferred way? If so, is Ubuntu 10.04 required, or other versions (e.g., 12.04 or 14.04) may be used as well? Isn't there any ready-to-use VirtualBox or Docker image with test server? [1] http://code.qt.io/cgit/qtqa/sysadmin.git/tree/README.network_test_server.txt -- Regards, Konstantin From rjvbertin at gmail.com Wed Jan 27 19:03:46 2016 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 27 Jan 2016 19:03:46 +0100 Subject: [Development] [OS X]: native classes (widgets) used for QTabBar and QTabWidget? References: <2063068.e6xtoLpgx3@portia.local> <1514935.9Q06xFpApu@finn> Message-ID: <2582812.cY4kCuqWYN@portia.local> Olivier Goffart wrote: Hi, > On Friday 4. December 2015 12:10:10 René J.V. Bertin wrote: >> Hi, >> >> What are the native classes (widgets) used to implement QTabBar and >> QTabWidget widgets on OS X? I was expecting NSTabView and family, but can >> find no occurrence of anything related in the source. > > QWidgets (and QML) don't use native UI views. They draw everything themself. > The drawing is done in the style (qmacstyle_mac.mm in this case) > > So to repeat: > QTabBar::paintEvent asks the style to paint the tabs > QMacStyle::drawControl (see the case CE_TabBarTabShape) draws it. > Apparently it's using HIThemeTabDrawInfo and HIThemeDrawTab. I finally had some time and motivation to dig into this. The actual relevant case is CE_TabBarTabLabel in QMacStyle::drawControl() . To repeat, my issue is that 2 fonts are being used for drawing the tab widget labels when I enable the use of the KDE (KF5) platform theme and combine that with the macintosh style. This should result in widgets that look like Mac widgets as usual, but using the fonts and colour palettes specified in ~/.config/kdeglobals . Tab widgets are a notable exception: the active (selected) tab is drawn with the correct font, but the non-active tabs are drawn with the system font. That looks weird and leads to layout errors if the user- specified font is much narrower than the system font, as tab dimensions are determined from the selected font. The culprit here is the test bool nonDefaultFont = p->font() != qt_app_fonts_hash()->value("QComboMenuItem"); which is always false : the KDE platform theme returns the relevant desired font through the ComboMenuItem style hint. As a result, the tab label is drawn using HIThemeDrawTextBox(). Shunting nonDefaultFont to true gives the correct behaviour (but the borders between tabs in a QTabWidget always look "fuzzy" ... because of isSelectedAndNeedsShadow?). I haven't check but I presume that the active tab was always drawn with the correct font because of isSelectedAndNeedsShadow being true. Question: is there another way to do the nonDefaultFont check, possibly comparing fontIDs (i.e. fontID(p->font()) not in {kThemeSystemFont,kThemeSmallSystemFont,kThemeMiniSystemFont})? R From rpzrpzrpz at gmail.com Wed Jan 27 19:09:21 2016 From: rpzrpzrpz at gmail.com (rpzrpzrpz at gmail.com) Date: Wed, 27 Jan 2016 12:09:21 -0600 Subject: [Development] [Interest] 5.7 feature freeze In-Reply-To: <1D403F5B-429F-4814-B3CF-883463017365@digia.com> References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> <1D403F5B-429F-4814-B3CF-883463017365@digia.com> Message-ID: <56A907D1.8050608@gmail.com> Shawn: Well, that is news, private API. QT+=quick-private #include Honestly, I don't actually care whether private or public, as long as I can compile and run from Qt Creator, I send out the entire app on android and IOS anyways, so that means I re-ship the share libraries every time anyways. Based on your answer, it looks like if I want QmlEngine->loadComponent(....,QQmlComponent& gcomp), I need to add it in the next 3 days on Git hub regardless of whether it currently works or not. In any case, shawn, thank you for your response. Maybe the powers that be will ask: "Where the hell is the matching API for QmlEngine->trimComponentCache() and QmlEngine->clearComponentCache()?" "Why do we force our devs to use qmldir files in the first place?" Thanks, md On 1/27/2016 10:15 AM, Rutledge Shawn wrote: >> On 27 Jan 2016, at 13:34, mark diener wrote: >> >> The other major problem is that QQuickItem does not allow for >> QSGTextRect, so updatePaintNode CANNOT have text rendering >> in coordination with QSGGeometry. The current recommendation is to >> try to coordinate using signals between 2 different QQuickItems, 1 >> with text, the other >> with graphical geometry. This is a restriction that appears to have >> occurred by chance. > That’s not the right class name AFAICT, but you mean you want public C++ API to populate text nodes into the scene graph, right? Following the pattern that QSGSimpleRectNode and QSGSimpleTextureNode are public. Yes this has been a sore thumb for quite some time. > > Meanwhile, you can use private API. If we make it public, then we are committed to keeping it compatible from now on, so I think that’s why the text-related nodes have not been made public so far: fear of losing flexibility to evolve. > > We know that text rendering in Qt Quick needs to be more efficient. What if that involves some refactoring? > > And text rendering is complex, more or less depending on how fancy layout you need. So I think in the long term we need some lower-level stuff, like a Glyph object in some QtQuick module (for putting FontAwesome icons [and future color-font icons!] on tool buttons, and selecting them by name rather than by unicode ID), and a PlainText item restricted to left-to-right rendering in a single font and color (no character spans, no markup, no harfbuzz, no RTL, but maybe with tab stops), as long as such an approach actually speeds up the common case. Maybe such simple classes will be easier to make public, too, because they will have thin API. (And then I would like to use the PlainText item to build a wicked-fast plain-text TableView.) > > But, I did this https://codereview.qt-project.org/#/c/125753/ because in addition to being private, QQuickTextNode wasn’t even exported from the module; that must have been an oversight. But that’s for 5.7. So at least you can work at the level of Items rather than scene-graph nodes, using private C++ API. And there is also private API for manipulating the scene graph nodes. This came up for me when I wanted to label the tick marks on the axes of a line graph. (I didn’t want to use bindings to position individual Text items.) I tried adding > > QT+=quick-private > #include > > and managed to spit out a few glyphs, but realized that our layout API is a little cumbersome (and I found a bug while I was at it, which has since been fixed if memory serves), and figured I’d need more time than I thought to get it working well. So then I tried using QQuickTextNode instead, which works now (on 5.7 branch). But it’s not the fastest possible way to do simple left-to-right labelling, so I should probably go back to the first way at some point. And if you haven’t, you should try it too, and then be careful what kind of public API you wish for. ;-) > >> This cripples custom controls capabilities and forces me to explain to >> customers about Qt limitations. >> >> So how can we get the header file for QQmlEngine changed for 5.7 > What is that about? > >> feature freeze to add those 3 function declarations and un-sandbox >> QSGTextRect >> and still pass maintainer acceptance all by Monday? > If nobody started that yet, that means it’s potentially 5.8 material, right? And as soon as dev is branched for 5.7, it implies that any further development on dev branch is actually for 5.8. So someone could potentially have a full half-year cycle to make the existing private APIs decent, and/or write the new stuff, debug it, document it, do API review, use it in some pet application(s), and catch all the gotcha’s. Assuming that everyone involved can be persuaded that it actually ought to be public at all, within that time frame, or assuming that somebody finds the time to implement APIs which are definitely good enough to make public and support over the long term. (I would like to actually, but my main goal for 5.8 is the set of new pointer handlers, which is notoriously time-consuming stuff: it’s hard to get reviewers to be interested and have sufficient attention span, autotests take a lot of work, etc.) > >> Cheers, >> >> md >> >> >> On Wed, Jan 27, 2016 at 2:30 AM, Knoll Lars wrote: >>> Hi everybody, >>> >>> we’re slightly past the originally planned date for the feature freeze, for various reasons (new stuff being open sourced, license change and being late with 5.6). But I believe most things should be in place now to do the feature freeze for 5.7 next Monday. >>> >>> There are currently three exceptions to the freeze: >>> >>> * ok to finish the printing support in web engine >>> * ok for BTLE support for Linux in qtconnectivity (merge neard branch) >>> * Modules that are flagged as TP can also have some more time >>> >>> If anybody else has a feature he believes absolutely has to make it to 5.7, get it done until Monday or talk to me :) >>> >>> Cheers, >>> Lars >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Interest mailing list >> Interest at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest From konstantin at podsvirov.pro Wed Jan 27 20:26:12 2016 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 27 Jan 2016 22:26:12 +0300 Subject: [Development] [DaD] New and Updated Modules and New Installers Message-ID: <816171453922772@web20m.yandex.ru> Hello, dear developers! Once again, I apologize for using your lists, but my project still don't have your list :-) Time passes and Dad's Project develops. I have over 2 years building and share a few, I think interesting modules. Let me remind you that the official Dad's House on the Internet: http://dad.podsvirov.pro I have prepared and laid out the releases for 2014 and 2015. Here are the special installers: http://download.podsvirov.pro/installers/dad-0.2.0-windows-vc12x86-2014.exe http://download.podsvirov.pro/installers/dad-0.2.0-windows-vc12x64-2014.exe and http://download.podsvirov.pro/installers/dad-0.3.0-windows-vc12x86-2015.exe http://download.podsvirov.pro/installers/dad-0.3.0-windows-vc12x64-2015.exe Versions of modules in these installers frozen and will not change if not necessary. On the website you can compare the components and the versions of relevant modules for installers (links Details). Installers stable/testing/unstable continue to evolve. As always, questions and suggestions are welcome. The project is in Beta stage. For errors I would be grateful. If you use my installers and proved to be helpful in your project, then write about their experiences. (sorry for possible mistakes in text) -- Regards, Konstantin Podsvirov From kenya888 at gmail.com Thu Jan 28 02:02:53 2016 From: kenya888 at gmail.com (Takahiro Hashimoto) Date: Thu, 28 Jan 2016 10:02:53 +0900 Subject: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 In-Reply-To: <20160127084501.5922898.15143.57533@theqtcompany.com> References: <2718327.vc9pWrFWa0@finn> <20160127084501.5922898.15143.57533@theqtcompany.com> Message-ID: <3557170.VdLPpuROPq@xps13> Hi, Thank you Marco for your quick fix:) On 2016年1月27日水曜日 8時45分03秒 JST Hausmann Simon wrote: > Ok, I had another look. I don't think find_if is new in C++11: > > ‎http://en.cppreference.com/w/cpp/algorithm/find > > It seems find_if_not is, but not find_if. So I think what we see here is‎ > simply a compiler bug perhaps? As Marco's workaround, setting local types to the args of template class (std::find_if in this case) comes from C++11, I think. http://www.stroustrup.com/C++11FAQ.html#local-types Regards. Takahiro > > Thanks to Marco it seems that we have a workaround: > > https://codereview.qt-project.org/#/c/147484/ > > ‎So I don't have the impression that C++11 code can slip through the CI for > the 5.6 branches. However if you do discover an incidence please holler :) > > Simon > > Original Message > From: Olivier Goffart > Sent: Monday, January 18, 2016 16:26 > To: development at qt-project.org > Cc: Rex Dieter > Subject: Re: [Development] qtdeclarative-5.6.0-beta build failure on rhel6 > > On Montag, 18. Januar 2016 08:31:01 CET Rex Dieter wrote: > > I'm trying to build(bootstrap) qt-5.6.0-beta stack on rhel6, and have run > > into a build failure in qtdeclarative, > > > > > beta/tools/qmlimportscanner/main.cpp:376: error: no matching function for > > call to 'find_if(QList::const_iterator, > > std::find_if is new in C++11 > And it was used in https://codereview.qt-project.org/125853/ in the 5.6 > which still does not require C++11. > > Apparently the CI does not try to build this with non-c++11 enabled > compilers? > > -- > 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 > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Thu Jan 28 03:56:42 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 27 Jan 2016 18:56:42 -0800 Subject: [Development] New KDE Free Qt Foundation agreement and changes to Qt In-Reply-To: References: <578CF287-C1BC-4F31-9DA6-78F75157DD72@theqtcompany.com> <844431453898063@web12o.yandex.ru> Message-ID: <3225820.EM3vnNNE3H@tjmaciei-mobl4> On Wednesday 27 January 2016 12:37:36 Knoll Lars wrote: > >Just to clarify things: does this change affect QtWebKit? > > No, only modules that are going to be part of the official Qt 5.7. And QtWebKit contains 3rd-party code anyway, so we can't change its licensing, ever. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tony.sarajarvi at theqtcompany.com Thu Jan 28 09:02:30 2016 From: tony.sarajarvi at theqtcompany.com (=?iso-8859-1?Q?Saraj=E4rvi_Tony?=) Date: Thu, 28 Jan 2016 08:02:30 +0000 Subject: [Development] Setting up test server for QtNetwork tests In-Reply-To: <280901453911418@web22o.yandex.ru> References: <280901453911418@web22o.yandex.ru> Message-ID: Hi That manual is probably the only official one we have. Up until Qt 5.5 we've been using that one ourselves as well. We did have a work in progress version on top of Ubuntu 12.04: https://gitorious.org/qtqa/tosarajas-sysadmin-nts.git/?p=qtqa:tosarajas-sysadmin-nts.git;a=blob;f=README.network_test_server.txt;h=2b745d077e98f2cf64c4ab8e0391e8e0cbf51118;hb=HEAD But as newer versions of backend services fixed various things, our autotests weren't fixed to handle the situation. Thus we were stuck with the old one. Now in Qt 5.6 we use yet another one, and sadly I have no knowledge what it contains. It's on my todo list to figure out. Most likely a mixture of the two above. -Tony > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On > Behalf Of Konstantin Tokarev > Sent: 27. tammikuuta 2016 18:17 > To: development at qt-project.org > Subject: [Development] Setting up test server for QtNetwork tests > > Hello, > > What is the recommended (and possibly easiest) way to set up test server > for QtNetwork? > > I've found manual [1]. Is it the preferred way? If so, is Ubuntu 10.04 required, > or other versions (e.g., 12.04 or 14.04) may be used as well? > > Isn't there any ready-to-use VirtualBox or Docker image with test server? > > [1] > http://code.qt.io/cgit/qtqa/sysadmin.git/tree/README.network_test_serve > r.txt > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From denis.shienkov at gmail.com Thu Jan 28 10:46:39 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Thu, 28 Jan 2016 12:46:39 +0300 Subject: [Development] Status of QtMultimedia module Message-ID: Hi Qt developers. During a long time I see that a development of QtMultimedia module is stalled... Tons of bugs are not considered at all, and a code-review commits keeps in reviews at monts without touching/response... Besides, many of QtMultimedia's API are not implemented yet, and are just as stubs, that do nothing. So, my question is: what state of QtMultimedia module? what are perspectives? Have you resources to support this module? BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From hrabowski at clausmark.com Thu Jan 28 10:47:21 2016 From: hrabowski at clausmark.com (Maximilian Hrabowski) Date: Thu, 28 Jan 2016 10:47:21 +0100 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf Message-ID: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> Hi, our application has an auto-update feature that allows to download and install a new version of the application. The update package includes everything, also Qt. The only permanent files are a launcher executable and a config file that points to the real application folder. The folder which contains the launcher is usually not writable by the user so the this application folder can be located anywhere on the system. The primary target platform is windows. Our application uses qt plugins, qt webengine etc. so we need to rely on a proper qt.conf file so any plugins and especially the QWebEngineProcess.exe is found. Since on Windows qt.conf is looked up in 1. :/qt/etc/qt.conf 2. applicationDirPath()+/qt.conf it is not found since the applicationDirPath() points to the folder of the launcher. What we need is a way to look up the qt.conf at another location as well. Of course i could patch Qt myself to do what i like but i target a solution that would qualify to become part of qt and i would be willing to contribute this feature. However, before do this i would like to discuss how this could be achieved and if there is any chance this feature could be accepted in qt. I thought about the following ways (order gives my personal opinion’s priority): 1. Add a new public API: static void QLibraryInfo::setQtConfFilePath( const QString& filePath) which defaults to ":/qt/etc/qt.conf“ and is used in QSettings *QLibraryInfoPrivate::findConfiguration() instead of the hard-coded path. 2. Also lookup qt.conf in all of QLibraryInfo::libraryPaths() (this is how we got the plugins found) 3. introduce an environment variable that points to the qt.conf similar to the one of QWebEngineProcess.exe Please comment. Cheers, Maximilian -- Maximilian Hrabowski Clausmark GmbH Tel: +49 (721) 98963941 Clausmark - The creators of BeeCore and Bee4IT -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4293 bytes Desc: not available URL: From Simon.Hausmann at theqtcompany.com Thu Jan 28 10:56:18 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 28 Jan 2016 09:56:18 +0000 Subject: [Development] Status of QtMultimedia module In-Reply-To: References: Message-ID: Hi, I can't response to the aspect of which bugs are considered and how code reviews happen, but regarding your statement of the development being stalled: I'm counting 37 landed changes in January 2016 until today, that's more than a change per day. I can also see changes going in regularly in the months before January. I suspect that what's bothering you is that the focus of development is not where you would like it to be - is that accurate? Simon ________________________________ From: Development on behalf of Denis Shienkov Sent: Thursday, January 28, 2016 10:46 To: development at qt-project.org Subject: [Development] Status of QtMultimedia module Hi Qt developers. During a long time I see that a development of QtMultimedia module is stalled... Tons of bugs are not considered at all, and a code-review commits keeps in reviews at monts without touching/response... Besides, many of QtMultimedia's API are not implemented yet, and are just as stubs, that do nothing. So, my question is: what state of QtMultimedia module? what are perspectives? Have you resources to support this module? BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Thu Jan 28 11:01:53 2016 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 28 Jan 2016 13:01:53 +0300 Subject: [Development] Setting up test server for QtNetwork tests In-Reply-To: References: <280901453911418@web22o.yandex.ru> Message-ID: <2766151453975313@web4o.yandex.ru> 28.01.2016, 11:02, "Sarajärvi Tony" : > Hi > > That manual is probably the only official one we have. Up until Qt 5.5 we've been using that one ourselves as well. > We did have a work in progress version on top of Ubuntu 12.04: https://gitorious.org/qtqa/tosarajas-sysadmin-nts.git/?p=qtqa:tosarajas-sysadmin-nts.git;a=blob;f=README.network_test_server.txt;h=2b745d077e98f2cf64c4ab8e0391e8e0cbf51118;hb=HEAD > > But as newer versions of backend services fixed various things, our autotests weren't fixed to handle the situation. Thus we were stuck with the old one. > > Now in Qt 5.6 we use yet another one, and sadly I have no knowledge what it contains. It's on my todo list to figure out. Most likely a mixture of the two above. That's sad - I wanted to fix a bug in 5.6 but it does not make sense to add tests when you cannot run them. (Bug only affects behavior of request with SynchronousRequestAttribute which is not public, so I haven't reported it yet) > > -Tony > >>  -----Original Message----- >>  From: Development [mailto:development-bounces at qt-project.org] On >>  Behalf Of Konstantin Tokarev >>  Sent: 27. tammikuuta 2016 18:17 >>  To: development at qt-project.org >>  Subject: [Development] Setting up test server for QtNetwork tests >> >>  Hello, >> >>  What is the recommended (and possibly easiest) way to set up test server >>  for QtNetwork? >> >>  I've found manual [1]. Is it the preferred way? If so, is Ubuntu 10.04 required, >>  or other versions (e.g., 12.04 or 14.04) may be used as well? >> >>  Isn't there any ready-to-use VirtualBox or Docker image with test server? >> >>  [1] >>  http://code.qt.io/cgit/qtqa/sysadmin.git/tree/README.network_test_serve >>  r.txt >> >>  -- >>  Regards, >>  Konstantin >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From oswald.buddenhagen at theqtcompany.com Thu Jan 28 11:38:26 2016 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 28 Jan 2016 11:38:26 +0100 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf In-Reply-To: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> References: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> Message-ID: <20160128103826.GA22098@troll08.it.local> On Thu, Jan 28, 2016 at 10:47:21AM +0100, Maximilian Hrabowski wrote: > 1. Add a new public API: static void QLibraryInfo::setQtConfFilePath( const QString& filePath) which defaults to ":/qt/etc/qt.conf“ and is used in QSettings *QLibraryInfoPrivate::findConfiguration() instead of the hard-coded path. > 2. Also lookup qt.conf in all of QLibraryInfo::libraryPaths() (this is how we got the plugins found) > 3. introduce an environment variable that points to the qt.conf similar to the one of QWebEngineProcess.exe > > Please comment. > you should contribute to https://bugreports.qt.io/browse/QTBUG-14150 getting fixed. that (specifically, subtask https://bugreports.qt.io/browse/QTBUG-15234) will make everything relative to the location of qtcore (or ideally, relative to the particular library which is doing the resource lookup). this will ultimately cause the disappearance of qt.conf, which sounds a lot better to me than either of your options. From edward.welbourne at theqtcompany.com Thu Jan 28 11:54:02 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 28 Jan 2016 10:54:02 +0000 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf In-Reply-To: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> References: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> Message-ID: Maximilian Hrabowski (28 January 2016 10:47): > What we need is a way to look up the qt.conf at another location as well. [...] > I thought about the following ways (order gives my personal opinion’s priority): > > 1. Add a new public API: static void QLibraryInfo::setQtConfFilePath( > const QString& filePath) which defaults to ":/qt/etc/qt.conf“ and is > used in QSettings *QLibraryInfoPrivate::findConfiguration() instead of > the hard-coded path. How does this help in your scenario ? How would your launcher get to know what path to use ? > 2. Also lookup qt.conf in all of QLibraryInfo::libraryPaths() (this is > how we got the plugins found) Potentially problematic if plugins might install a qt.conf that isn't what your application needs. > 3. introduce an environment variable that points to the qt.conf > similar to the one of QWebEngineProcess.exe Why isn't this first ? I would generally expect an environment variable to take precedence over all other configuration options except command-line options. Eddy. From fromqt at tungware.se Thu Jan 28 12:03:53 2016 From: fromqt at tungware.se (Henry Skoglund) Date: Thu, 28 Jan 2016 12:03:53 +0100 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf In-Reply-To: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> References: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> Message-ID: <56A9F599.4090205@tungware.se> Hi, this is the same problem that the Qt installation program has, it solves it by binary patching your copy of Qt5Core.dll when it installs Qt onto your computer (e.g. set qt_prfxpath="C:\Qt\5.5\msvc2013"). Maybe you can to the same? Or perhaps a more viable long-range solution is to introduce a r/w API to Qt's resource system, so that instead of patching Qt5Core.dll it would be possible to patch the contents of the embedded ":/qt/etc/qt.conf" resource file inside your .exe file. (That would imply it isn't zipped when compiled and also that ample patch space is provided, as it is done in Qt5Core.dll for the qt_prfxpath property.) Rgrds Henry On 2016-01-28 10:47, Maximilian Hrabowski wrote: > Hi, > > our application has an auto-update feature that allows to download and > install a new version of the application. The update package includes > everything, also Qt. The only permanent files are a launcher executable > and a config file that points to the real application folder. The folder > which contains the launcher is usually not writable by the user so the > this application folder can be located anywhere on the system. The > primary target platform is windows. > > Our application uses qt plugins, qt webengine etc. so we need to rely on > a proper qt.conf file so any plugins and especially the > QWebEngineProcess.exe is found. > > Since on Windows qt.conf is looked up in > 1. :/qt/etc/qt.conf > 2. applicationDirPath()+/qt.conf > it is not found since the applicationDirPath() points to the folder of > the launcher. > > What we need is a way to look up the qt.conf at another location as > well. Of course i could patch Qt myself to do what i like but i target a > solution that would qualify to become part of qt and i would be willing > to contribute this feature. > > However, before do this i would like to discuss how this could be > achieved and if there is any chance this feature could be accepted in qt. > > I thought about the following ways (order gives my personal opinion’s > priority): > > 1. Add a new public API: static void QLibraryInfo::setQtConfFilePath( > const QString& filePath) which defaults to ":/qt/etc/qt.conf“ and is > used in QSettings*QLibraryInfoPrivate::findConfiguration() instead of > the hard-coded path. > 2. Also lookup qt.conf in all of QLibraryInfo::libraryPaths() (this is > how we got the plugins found) > 3. introduce an environment variable that points to the qt.conf similar > to the one of QWebEngineProcess.exe > > Please comment. > > Cheers, > Maximilian > > -- > Maximilian Hrabowski > > Clausmark GmbH > Tel: +49 (721) 98963941 > Clausmark - The creators of BeeCore and Bee4IT > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From hrabowski at clausmark.com Thu Jan 28 13:00:11 2016 From: hrabowski at clausmark.com (Maximilian Hrabowski) Date: Thu, 28 Jan 2016 13:00:11 +0100 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf In-Reply-To: References: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> Message-ID: <36094EB8-CCC5-4716-9D03-721DD933514A@clausmark.com> > Am 28.01.2016 um 11:54:02 schrieb Welbourne Edward : > > Maximilian Hrabowski (28 January 2016 10:47): >> What we need is a way to look up the qt.conf at another location as well. > [...] >> I thought about the following ways (order gives my personal opinion’s priority): >> >> 1. Add a new public API: static void QLibraryInfo::setQtConfFilePath( >> const QString& filePath) which defaults to ":/qt/etc/qt.conf“ and is >> used in QSettings *QLibraryInfoPrivate::findConfiguration() instead of >> the hard-coded path. > > How does this help in your scenario ? > How would your launcher get to know what path to use ? The launcher looks up the root path of the application bundle, loads the dll from there and then passes the path to a „package_main()“ function as parameter. So location is known in the dll and is use to setup library paths, etc. and would also be used to specify the qt.conf location inside the bundle directory. > >> 2. Also lookup qt.conf in all of QLibraryInfo::libraryPaths() (this is >> how we got the plugins found) > > Potentially problematic if plugins might install a qt.conf that isn't > what your application needs. I have full control of the content of my application bundle and the libraryPath list is „cleaned up“ before instantiating QApplication to only contain paths into the bundle directory. So at least for me this could happen. Can you please give an example where this could cause trouble? > >> 3. introduce an environment variable that points to the qt.conf >> similar to the one of QWebEngineProcess.exe > > Why isn't this first ? > I would generally expect an environment variable to take precedence over > all other configuration options except command-line options. You are right, that an environment variable should be considered first. But I think one of the three possible solutions is enough. I did not mean to implement all three in this order. For me the environment variable is the solution that i like least. Maximilian -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4293 bytes Desc: not available URL: From hrabowski at clausmark.com Thu Jan 28 13:13:52 2016 From: hrabowski at clausmark.com (Maximilian Hrabowski) Date: Thu, 28 Jan 2016 13:13:52 +0100 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf In-Reply-To: <20160128103826.GA22098@troll08.it.local> References: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> <20160128103826.GA22098@troll08.it.local> Message-ID: > Am 28.01.2016 um 11:38:26 schrieb Oswald Buddenhagen : > > On Thu, Jan 28, 2016 at 10:47:21AM +0100, Maximilian Hrabowski wrote: >> 1. Add a new public API: static void QLibraryInfo::setQtConfFilePath( const QString& filePath) which defaults to ":/qt/etc/qt.conf“ and is used in QSettings *QLibraryInfoPrivate::findConfiguration() instead of the hard-coded path. >> 2. Also lookup qt.conf in all of QLibraryInfo::libraryPaths() (this is how we got the plugins found) >> 3. introduce an environment variable that points to the qt.conf similar to the one of QWebEngineProcess.exe >> >> Please comment. >> > you should contribute to > https://bugreports.qt.io/browse/QTBUG-14150 getting fixed. > that (specifically, subtask https://bugreports.qt.io/browse/QTBUG-15234) QTBUG-15234 seems still be under discussion, right? > will make everything relative to the location of qtcore This is indeed the best solution. I assume this solution could not be achieved before Qt 6?! Maybe this would be another choice to get it to work with Qt 5.6 or at least Qt 5.7: 4. Determine the path from the current dll location as described in QtBUG-15234 at Permalink > (or ideally, > relative to the particular library which is doing the resource lookup). > this will ultimately cause the disappearance of qt.conf, which sounds a > lot better to me than either of your options. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4293 bytes Desc: not available URL: From edward.welbourne at theqtcompany.com Thu Jan 28 13:20:00 2016 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 28 Jan 2016 12:20:00 +0000 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf In-Reply-To: <36094EB8-CCC5-4716-9D03-721DD933514A@clausmark.com> References: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> , <36094EB8-CCC5-4716-9D03-721DD933514A@clausmark.com> Message-ID: >>> 2. Also lookup qt.conf in all of QLibraryInfo::libraryPaths() (this is >>> how we got the plugins found) >> >> Potentially problematic if plugins might install a qt.conf that isn't >> what your application needs. > > I have full control of the content of my application bundle and the > libraryPath list is „cleaned up“ before instantiating QApplication > to only contain paths into the bundle directory. So at least for me > this could happen. Can you please give an example where this could > cause trouble? I was imagining you meant third-party plugins that might be in random places. I take it you actually mean plugins that are part of your package, so now I see why this won't be a problem. > I think one of the three possible solutions is enough. Ah - I see - your list was of candidates (of which to implement one) in preference order, rather than of places an application can find qt.conf, in search order. Then I can see why you would prefer the others over an environment variable. See Ossi's mail, though, for the https://bugreports.qt.io/browse/QTBUG-15234 solution, that hopefully makes reconfiguring the qt.conf search path redundant, Eddy. From Simon.Hausmann at theqtcompany.com Thu Jan 28 13:34:57 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 28 Jan 2016 12:34:57 +0000 Subject: [Development] Setting up test server for QtNetwork tests In-Reply-To: <280901453911418@web22o.yandex.ru> References: <280901453911418@web22o.yandex.ru> Message-ID: Hi, In principle that manual is still correct. There was work going on towards automating the setup for everyone through the use of a vagrant template that would call puppet, etc. do to the installation. I believe that was still part of a work-in-progress branch in qtbase, but it hasn't hit any development branch yet. The server used in production is basically created from this manual, but it's not automatically kept up-to-date from the puppet tree in gerrit. However if you have changes to the setup there, please let us know (CC in gerrit) and I think that we can apply these to the server in production. Simon ________________________________________ From: Development on behalf of Konstantin Tokarev Sent: Wednesday, January 27, 2016 17:16 To: development at qt-project.org Subject: [Development] Setting up test server for QtNetwork tests Hello, What is the recommended (and possibly easiest) way to set up test server for QtNetwork? I've found manual [1]. Is it the preferred way? If so, is Ubuntu 10.04 required, or other versions (e.g., 12.04 or 14.04) may be used as well? Isn't there any ready-to-use VirtualBox or Docker image with test server? [1] http://code.qt.io/cgit/qtqa/sysadmin.git/tree/README.network_test_server.txt -- Regards, Konstantin _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at theqtcompany.com Thu Jan 28 13:37:14 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 28 Jan 2016 12:37:14 +0000 Subject: [Development] Setting up test server for QtNetwork tests In-Reply-To: References: <280901453911418@web22o.yandex.ru>, Message-ID: Regarding the server that is used for Qt 5.6 and onwards: It is an exact clone of the virtual machine that ran in Jenkins with no changes to the services, but it is in a different virtual network segment. The virtual segment is the same as the virtual machines that run the tests, and that has proven to improve the reliability of network test execution dramatically. Simon ________________________________________ From: Development on behalf of Sarajärvi Tony Sent: Thursday, January 28, 2016 9:02 To: Konstantin Tokarev; development at qt-project.org Subject: Re: [Development] Setting up test server for QtNetwork tests Hi That manual is probably the only official one we have. Up until Qt 5.5 we've been using that one ourselves as well. We did have a work in progress version on top of Ubuntu 12.04: https://gitorious.org/qtqa/tosarajas-sysadmin-nts.git/?p=qtqa:tosarajas-sysadmin-nts.git;a=blob;f=README.network_test_server.txt;h=2b745d077e98f2cf64c4ab8e0391e8e0cbf51118;hb=HEAD But as newer versions of backend services fixed various things, our autotests weren't fixed to handle the situation. Thus we were stuck with the old one. Now in Qt 5.6 we use yet another one, and sadly I have no knowledge what it contains. It's on my todo list to figure out. Most likely a mixture of the two above. -Tony > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On > Behalf Of Konstantin Tokarev > Sent: 27. tammikuuta 2016 18:17 > To: development at qt-project.org > Subject: [Development] Setting up test server for QtNetwork tests > > Hello, > > What is the recommended (and possibly easiest) way to set up test server > for QtNetwork? > > I've found manual [1]. Is it the preferred way? If so, is Ubuntu 10.04 required, > or other versions (e.g., 12.04 or 14.04) may be used as well? > > Isn't there any ready-to-use VirtualBox or Docker image with test server? > > [1] > http://code.qt.io/cgit/qtqa/sysadmin.git/tree/README.network_test_serve > r.txt > > -- > Regards, > Konstantin > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From rpzrpzrpz at gmail.com Thu Jan 28 14:07:24 2016 From: rpzrpzrpz at gmail.com (mark diener) Date: Thu, 28 Jan 2016 07:07:24 -0600 Subject: [Development] [Interest] 5.7 feature freeze In-Reply-To: <1D403F5B-429F-4814-B3CF-883463017365@digia.com> References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> <1D403F5B-429F-4814-B3CF-883463017365@digia.com> Message-ID: Shawn: I went back an re-read your comments. How do I submit something for Private API in 5.7 after feature-freeze date? This may be the mechanism that gives me time to try to code my feature addition and get it into the continous integration system and NOT be required to do the work before feature freeze 5.7 on Monday. Thanks, md On Wed, Jan 27, 2016 at 10:15 AM, Rutledge Shawn wrote: > >> On 27 Jan 2016, at 13:34, mark diener wrote: >> >> The other major problem is that QQuickItem does not allow for >> QSGTextRect, so updatePaintNode CANNOT have text rendering >> in coordination with QSGGeometry. The current recommendation is to >> try to coordinate using signals between 2 different QQuickItems, 1 >> with text, the other >> with graphical geometry. This is a restriction that appears to have >> occurred by chance. > > That’s not the right class name AFAICT, but you mean you want public C++ API to populate text nodes into the scene graph, right? Following the pattern that QSGSimpleRectNode and QSGSimpleTextureNode are public. Yes this has been a sore thumb for quite some time. > > Meanwhile, you can use private API. If we make it public, then we are committed to keeping it compatible from now on, so I think that’s why the text-related nodes have not been made public so far: fear of losing flexibility to evolve. > > We know that text rendering in Qt Quick needs to be more efficient. What if that involves some refactoring? > > And text rendering is complex, more or less depending on how fancy layout you need. So I think in the long term we need some lower-level stuff, like a Glyph object in some QtQuick module (for putting FontAwesome icons [and future color-font icons!] on tool buttons, and selecting them by name rather than by unicode ID), and a PlainText item restricted to left-to-right rendering in a single font and color (no character spans, no markup, no harfbuzz, no RTL, but maybe with tab stops), as long as such an approach actually speeds up the common case. Maybe such simple classes will be easier to make public, too, because they will have thin API. (And then I would like to use the PlainText item to build a wicked-fast plain-text TableView.) > > But, I did this https://codereview.qt-project.org/#/c/125753/ because in addition to being private, QQuickTextNode wasn’t even exported from the module; that must have been an oversight. But that’s for 5.7. So at least you can work at the level of Items rather than scene-graph nodes, using private C++ API. And there is also private API for manipulating the scene graph nodes. This came up for me when I wanted to label the tick marks on the axes of a line graph. (I didn’t want to use bindings to position individual Text items.) I tried adding > > QT+=quick-private > #include > > and managed to spit out a few glyphs, but realized that our layout API is a little cumbersome (and I found a bug while I was at it, which has since been fixed if memory serves), and figured I’d need more time than I thought to get it working well. So then I tried using QQuickTextNode instead, which works now (on 5.7 branch). But it’s not the fastest possible way to do simple left-to-right labelling, so I should probably go back to the first way at some point. And if you haven’t, you should try it too, and then be careful what kind of public API you wish for. ;-) > >> This cripples custom controls capabilities and forces me to explain to >> customers about Qt limitations. >> >> So how can we get the header file for QQmlEngine changed for 5.7 > > What is that about? > >> feature freeze to add those 3 function declarations and un-sandbox >> QSGTextRect >> and still pass maintainer acceptance all by Monday? > > If nobody started that yet, that means it’s potentially 5.8 material, right? And as soon as dev is branched for 5.7, it implies that any further development on dev branch is actually for 5.8. So someone could potentially have a full half-year cycle to make the existing private APIs decent, and/or write the new stuff, debug it, document it, do API review, use it in some pet application(s), and catch all the gotcha’s. Assuming that everyone involved can be persuaded that it actually ought to be public at all, within that time frame, or assuming that somebody finds the time to implement APIs which are definitely good enough to make public and support over the long term. (I would like to actually, but my main goal for 5.8 is the set of new pointer handlers, which is notoriously time-consuming stuff: it’s hard to get reviewers to be interested and have sufficient attention span, autotests take a lot of work, etc.) > >> >> Cheers, >> >> md >> >> >> On Wed, Jan 27, 2016 at 2:30 AM, Knoll Lars wrote: >>> Hi everybody, >>> >>> we’re slightly past the originally planned date for the feature freeze, for various reasons (new stuff being open sourced, license change and being late with 5.6). But I believe most things should be in place now to do the feature freeze for 5.7 next Monday. >>> >>> There are currently three exceptions to the freeze: >>> >>> * ok to finish the printing support in web engine >>> * ok for BTLE support for Linux in qtconnectivity (merge neard branch) >>> * Modules that are flagged as TP can also have some more time >>> >>> If anybody else has a feature he believes absolutely has to make it to 5.7, get it done until Monday or talk to me :) >>> >>> Cheers, >>> Lars >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Interest mailing list >> Interest at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/interest > From dangelog at gmail.com Thu Jan 28 14:13:51 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Thu, 28 Jan 2016 14:13:51 +0100 Subject: [Development] [Interest] 5.7 feature freeze In-Reply-To: References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> <1D403F5B-429F-4814-B3CF-883463017365@digia.com> Message-ID: On Thu, Jan 28, 2016 at 2:07 PM, mark diener wrote: > How do I submit something for Private API in 5.7 after feature-freeze date? I'm sorry, but you can't add new features (even private) after the feature freeze. That's the point of a freeze, after all. Just submit in dev, get it merged, and it will be in the first useful Qt release. Cheers, -- Giuseppe D'Angelo From andre at familiesomers.nl Fri Jan 29 09:04:44 2016 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Fri, 29 Jan 2016 09:04:44 +0100 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf In-Reply-To: <36094EB8-CCC5-4716-9D03-721DD933514A@clausmark.com> References: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> <36094EB8-CCC5-4716-9D03-721DD933514A@clausmark.com> Message-ID: <56AB1D1C.6010904@familiesomers.nl> Op 28/01/2016 om 13:00 schreef Maximilian Hrabowski: >> Why isn't this first ? >> I would generally expect an environment variable to take precedence over >> all other configuration options except command-line options. > You are right, that an environment variable should be considered first. But I think one of the three possible solutions is enough. I did not mean to implement all three in this order. For me the environment variable is the solution that i like least. > Wouldn't that open up a can of worms in terms of security of the application? If setting an environment variable is enough to change what libs get loaded and you can point to arbitrary different libs, that means injecting your own code in other peoples applications becomes really easy, right? I think you could use that to get rights escalation. André From Kai.Koehne at theqtcompany.com Fri Jan 29 09:10:47 2016 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Fri, 29 Jan 2016 08:10:47 +0000 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf In-Reply-To: <56AB1D1C.6010904@familiesomers.nl> References: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> <36094EB8-CCC5-4716-9D03-721DD933514A@clausmark.com> <56AB1D1C.6010904@familiesomers.nl> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On > Behalf Of Andre Somers > Sent: Friday, January 29, 2016 9:05 AM > To: development at qt-project.org > Subject: Re: [Development] Modify QLibraryInfo to support any default > location of qt.conf > > > > Op 28/01/2016 om 13:00 schreef Maximilian Hrabowski: > >> Why isn't this first ? > >> I would generally expect an environment variable to take precedence > >> over all other configuration options except command-line options. > > You are right, that an environment variable should be considered first. But > I think one of the three possible solutions is enough. I did not mean to > implement all three in this order. For me the environment variable is the > solution that i like least. > > > Wouldn't that open up a can of worms in terms of security of the > application? If setting an environment variable is enough to change what > libs get loaded and you can point to arbitrary different libs, that means > injecting your own code in other peoples applications becomes really easy, > right? I think you could use that to get rights escalation. The can is already open in this case. You can set PATH, LD_LIBRARY_PATH, QML_IMPORT_PATH .... Regards Kai From g.scheikl at avibit.com Fri Jan 29 10:34:15 2016 From: g.scheikl at avibit.com (Gerhard Scheikl) Date: Fri, 29 Jan 2016 10:34:15 +0100 Subject: [Development] RTSP H264 under Windows Message-ID: <1505491.6VBvx5HKVi@pc12.avibit.com> Hi! We are trying to display an RTSP stream under Windows. For the video encoding, h264 is used. On the GUI side we are using the QML MediaPlayer component. Unfortunately, we don't see any video output nor do we get any error. VLC is able to playback the stream on the same machine. Should this work? Is h264 over RTSP supported under Windows? Thanks. Best regards Gerhard From Simon.Hausmann at theqtcompany.com Fri Jan 29 11:42:17 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Fri, 29 Jan 2016 10:42:17 +0000 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf In-Reply-To: References: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> <36094EB8-CCC5-4716-9D03-721DD933514A@clausmark.com> <56AB1D1C.6010904@familiesomers.nl>, Message-ID: You're right, the can is open right now. Apple is working on closing that can under our feet (see the DYLD_* variable unsetting upon exec in 10.11). I wouldn't be surprised if that trend continues elsewhere :) Simon ________________________________________ From: Development on behalf of Koehne Kai Sent: Friday, January 29, 2016 9:10 To: André Somers; development at qt-project.org Subject: Re: [Development] Modify QLibraryInfo to support any default location of qt.conf > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On > Behalf Of Andre Somers > Sent: Friday, January 29, 2016 9:05 AM > To: development at qt-project.org > Subject: Re: [Development] Modify QLibraryInfo to support any default > location of qt.conf > > > > Op 28/01/2016 om 13:00 schreef Maximilian Hrabowski: > >> Why isn't this first ? > >> I would generally expect an environment variable to take precedence > >> over all other configuration options except command-line options. > > You are right, that an environment variable should be considered first. But > I think one of the three possible solutions is enough. I did not mean to > implement all three in this order. For me the environment variable is the > solution that i like least. > > > Wouldn't that open up a can of worms in terms of security of the > application? If setting an environment variable is enough to change what > libs get loaded and you can point to arbitrary different libs, that means > injecting your own code in other peoples applications becomes really easy, > right? I think you could use that to get rights escalation. The can is already open in this case. You can set PATH, LD_LIBRARY_PATH, QML_IMPORT_PATH .... Regards Kai _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at theqtcompany.com Fri Jan 29 11:45:06 2016 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Fri, 29 Jan 2016 10:45:06 +0000 Subject: [Development] RTSP H264 under Windows In-Reply-To: <1505491.6VBvx5HKVi@pc12.avibit.com> References: <1505491.6VBvx5HKVi@pc12.avibit.com> Message-ID: Judging from responses on the internet like https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/4ac87f5f-b8c5-471a-a424-55c0fff04eac/using-the-media-foundation-sdk-to-parse-rtsp-streams?forum=mediafoundationdevelopment I have the impression that the Media Foundation in Windows does not support h264 payloads in RTSP. Not sure there's much we can do on the Qt side about that :) Simon ________________________________________ From: Development on behalf of Gerhard Scheikl Sent: Friday, January 29, 2016 10:34 To: development at qt-project.org Subject: [Development] RTSP H264 under Windows Hi! We are trying to display an RTSP stream under Windows. For the video encoding, h264 is used. On the GUI side we are using the QML MediaPlayer component. Unfortunately, we don't see any video output nor do we get any error. VLC is able to playback the stream on the same machine. Should this work? Is h264 over RTSP supported under Windows? Thanks. Best regards Gerhard _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jedrzej.nowacki at theqtcompany.com Fri Jan 29 12:48:58 2016 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 29 Jan 2016 12:48:58 +0100 Subject: [Development] Setting up test server for QtNetwork tests In-Reply-To: References: <280901453911418@web22o.yandex.ru> Message-ID: <1530322.fDOniKW1dn@42> On Thursday 28 of January 2016 12:37:14 Hausmann Simon wrote: > Regarding the server that is used for Qt 5.6 and onwards: It is an exact > clone of the virtual machine that ran in Jenkins with no changes to the > services, but it is in a different virtual network segment. It is exactly the same, minus puppet that caused a test failure every quarter by restarting services. Cheers, Jędrek From g.scheikl at avibit.com Fri Jan 29 13:26:53 2016 From: g.scheikl at avibit.com (Gerhard Scheikl) Date: Fri, 29 Jan 2016 13:26:53 +0100 Subject: [Development] Setting up test server for QtNetwork tests In-Reply-To: <1530322.fDOniKW1dn@42> References: <280901453911418@web22o.yandex.ru> <1530322.fDOniKW1dn@42> Message-ID: <4825421.i719NNHee5@pc12.avibit.com> On Friday 29 January 2016 14:45:06 Simon Hausmann wrote: > Judging from responses on the internet like [...] > I have the impression that the Media Foundation in Windows does not support > h264 payloads in RTSP. Not sure there's much we can do on the Qt side about > that :) Would it be possible to use a different backend on Windows? E.g. DirectShow or gstreamer? Thanks Best regards Gerhard From eskil.abrahamsen-blomfeldt at theqtcompany.com Fri Jan 29 13:48:24 2016 From: eskil.abrahamsen-blomfeldt at theqtcompany.com (Eskil A. Blomfeldt) Date: Fri, 29 Jan 2016 13:48:24 +0100 Subject: [Development] Status of QtMultimedia module In-Reply-To: References: Message-ID: <56AB5F98.6010202@theqtcompany.com> On 28. jan. 2016 10:46, Denis Shienkov wrote: > Hi Qt developers. > > During a long time I see that a development of QtMultimedia module is > stalled... Tons of bugs are not considered at all, and a code-review > commits keeps in reviews at monts without touching/response... > Besides, many of QtMultimedia's API are not implemented yet, and are > just as stubs, that do nothing. > > So, my question is: what state of QtMultimedia module? what are > perspectives? Have you resources to support this module? Hi, Qt Multimedia is actively maintained, yes, but lately we have been focusing more on mending platform gaps and improving the DirectShow backend than on inventing new features, since we think it's important to make the current APIs work well before we develop new ones. I do know that there are bugs coming in that we would like to fix but have not had time for yet, so maybe it's currently progressing a bit slower than you would prefer. We hope to improve this by increasing the focus in the time to come. -- Eskil -------------- next part -------------- An HTML attachment was scrubbed... URL: From ahartmetz at gmail.com Fri Jan 29 14:54:59 2016 From: ahartmetz at gmail.com (Andreas Hartmetz) Date: Fri, 29 Jan 2016 14:54:59 +0100 Subject: [Development] Request for API freeze exception to fix an important bug Message-ID: <6735248.mp0sDMSJ8N@z25> Hello, while investigating session saving problems in KDE I found that the big underlying problem is that QGuiApplication::commitData() can't be prevented from trying to close windows. It does that to see if they refuse (ignore the close event), and if they do, it's interpreted as the application canceling logout. That gives poor man's session managament to applications that don't explicitly implement any real session management. It also essentially breaks applications that do implement full session management. This behavior is very old (has been present at least as early as Qt 2.3.2), but what is new in Qt5 is that it can't be disabled. That is becasue one could override Q[Gui]Application::commitData() before Qt5, but not anymore. One now just connects to the commitDataRequest() signal. So, how to fix it? Simple and (very) ugly: Add API to disable the closing of windows in commitData(). Because session saving is IMHO pretty important for KDE, I'm asking for an exception to add API to 5.6 to fix it. The change request is at: https://codereview.qt-project.org/#/c/146566/ As should be obvious from the patch, it does nothing if the new API isn't used. Cheers, Andreas From denis.shienkov at gmail.com Fri Jan 29 15:20:25 2016 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Fri, 29 Jan 2016 17:20:25 +0300 Subject: [Development] Status of QtMultimedia module In-Reply-To: <56AB5F98.6010202@theqtcompany.com> References: <56AB5F98.6010202@theqtcompany.com> Message-ID: Ok, many thanks for the info. I have no more any questions. :) BR, Denis 2016-01-29 15:48 GMT+03:00 Eskil A. Blomfeldt < eskil.abrahamsen-blomfeldt at theqtcompany.com>: > > > On 28. jan. 2016 10:46, Denis Shienkov wrote: > > Hi Qt developers. > > During a long time I see that a development of QtMultimedia module is > stalled... Tons of bugs are not considered at all, and a code-review > commits keeps in reviews at monts without touching/response... Besides, > many of QtMultimedia's API are not implemented yet, and are just as stubs, > that do nothing. > > So, my question is: what state of QtMultimedia module? what are > perspectives? Have you resources to support this module? > > > Hi, > > Qt Multimedia is actively maintained, yes, but lately we have been > focusing more on mending platform gaps and improving the DirectShow backend > than on inventing new features, since we think it's important to make the > current APIs work well before we develop new ones. > > I do know that there are bugs coming in that we would like to fix but have > not had time for yet, so maybe it's currently progressing a bit slower than > you would prefer. We hope to improve this by increasing the focus in the > time to come. > > -- Eskil > > > _______________________________________________ > 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 Jan 29 17:54:53 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 29 Jan 2016 08:54:53 -0800 Subject: [Development] Modify QLibraryInfo to support any default location of qt.conf In-Reply-To: References: <7CDAC69F-743A-4263-BDB4-EBA717AFD571@clausmark.com> Message-ID: <3309678.SWA2fglXv8@tjmaciei-mobl4> On Friday 29 January 2016 10:42:17 Hausmann Simon wrote: > You're right, the can is open right now. Apple is working on closing that > can under our feet (see the DYLD_* variable unsetting upon exec in 10.11). > I wouldn't be surprised if that trend continues elsewhere ld-linux.so ignores the LD_* variables if the application is setuid or setgid. See the GNU extension function secure_getenv. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Jan 29 17:55:54 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 29 Jan 2016 08:55:54 -0800 Subject: [Development] Request for API freeze exception to fix an important bug In-Reply-To: <6735248.mp0sDMSJ8N@z25> References: <6735248.mp0sDMSJ8N@z25> Message-ID: <2964919.TQnYXRWvjP@tjmaciei-mobl4> On Friday 29 January 2016 14:54:59 Andreas Hartmetz wrote: > So, how to fix it? Simple and (very) ugly: Add API to disable the > closing of windows in commitData(). Because session saving is IMHO > pretty important for KDE, I'm asking for an exception to add API to 5.6 > to fix it. The API isn't frozen in 5.6 yet. So yes, you can add it. Just be very careful. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rpzrpzrpz at gmail.com Fri Jan 29 21:08:31 2016 From: rpzrpzrpz at gmail.com (mark diener) Date: Fri, 29 Jan 2016 14:08:31 -0600 Subject: [Development] [Interest] 5.7 feature freeze In-Reply-To: References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> <1D403F5B-429F-4814-B3CF-883463017365@digia.com> Message-ID: Hello devs: Guiseppe & Shawn: The best I can hope to do is submit skeleton code pre-feature freeze with No-op code and then fill in the rest once I can spend some quality time on all of the tool chain configuration. Tried to follow http://wiki.qt.io/Qt_Contribution_Guidelines but I am getting slammed by git/gerrit errors and some sort of commit hook. If any dev feels like submitting a patch with the following code, I am attaching the 4 changed source files from: >From Qt source code retrieved by the following command: git clone git://code.qt.io/qt/qtdeclarative.git I added NO-OP functions in the proper format to the following 4 files. /qtdeclarative/src/qml/qml/qqmlengine.h /qtdeclarative/src/qml/qml/qqmlengine.cpp /qtdeclarative/src/qml/qml/qqmltypeloader.cpp /qtdeclarative/src/qml/qml/qqmltypeloader_p.h Those functions are called: bool addComponentToCache(const QString& moduleName,int version_major, int version_minor,const QString& componentName,QQmlComponent& component,QList *errors); bool removeComponentFromCache(const QString& moduleName,int version_major, int version_minor,const QString& componentName,QList *errors); bool isComponentLoadedInCache(const QString& importName,int version_major, int version_minor,const QString& componentName) ; Thank you, md On Thu, Jan 28, 2016 at 7:13 AM, Giuseppe D'Angelo wrote: > On Thu, Jan 28, 2016 at 2:07 PM, mark diener wrote: >> How do I submit something for Private API in 5.7 after feature-freeze date? > > I'm sorry, but you can't add new features (even private) after the > feature freeze. That's the point of a freeze, after all. Just submit > in dev, get it merged, and it will be in the first useful Qt release. > > Cheers, > -- > Giuseppe D'Angelo -------------- next part -------------- A non-text attachment was scrubbed... Name: qqmlengine.cpp Type: text/x-c++src Size: 83107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qqmlengine.h Type: text/x-chdr Size: 5426 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qqmltypeloader_p.h Type: text/x-chdr Size: 18305 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: qqmltypeloader.cpp Type: text/x-c++src Size: 87700 bytes Desc: not available URL: From dangelog at gmail.com Fri Jan 29 21:33:59 2016 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Fri, 29 Jan 2016 21:33:59 +0100 Subject: [Development] [Interest] 5.7 feature freeze In-Reply-To: References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> <1D403F5B-429F-4814-B3CF-883463017365@digia.com> Message-ID: On Fri, Jan 29, 2016 at 9:08 PM, mark diener wrote: > > Tried to follow http://wiki.qt.io/Qt_Contribution_Guidelines but I am > getting slammed by git/gerrit errors and some sort of commit hook. If you can get online on IRC (Freenode, #qt-labs) you may find people to help solve your issue, btw. We can't contribute copyrightable code on behalf of other people... Cheers, -- Giuseppe D'Angelo From thiago.macieira at intel.com Fri Jan 29 21:41:22 2016 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 29 Jan 2016 12:41:22 -0800 Subject: [Development] [Interest] 5.7 feature freeze In-Reply-To: References: <5E004474-9393-41BF-85E2-F386FB11A23B@theqtcompany.com> Message-ID: <4204803.8Q1osgOMPg@tjmaciei-mobl4> On Friday 29 January 2016 14:08:31 mark diener wrote: > The best I can hope to do is submit skeleton code pre-feature freeze > with No-op code and then > fill in the rest once I can spend some quality time on all of the tool > chain configuration. That's not acceptable for feature freeze. All features landing in the dev branch, at any point in time, must be complete, documented, unit-tested and carrying examples whenever possible. If you can't get that done by Monday, don't rush it. There will be another release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ahartmetz at gmail.com Sat Jan 30 10:11:40 2016 From: ahartmetz at gmail.com (Andreas Hartmetz) Date: Sat, 30 Jan 2016 10:11:40 +0100 Subject: [Development] Request for API freeze exception to fix an important bug In-Reply-To: <2964919.TQnYXRWvjP@tjmaciei-mobl4> References: <6735248.mp0sDMSJ8N@z25> <2964919.TQnYXRWvjP@tjmaciei-mobl4> Message-ID: <76537988.KpgcA8rD98@z25> On Freitag, 29. Januar 2016 08:55:54 CET Thiago Macieira wrote: > On Friday 29 January 2016 14:54:59 Andreas Hartmetz wrote: > > So, how to fix it? Simple and (very) ugly: Add API to disable the > > closing of windows in commitData(). Because session saving is IMHO > > pretty important for KDE, I'm asking for an exception to add API to > > 5.6 to fix it. > > The API isn't frozen in 5.6 yet. So yes, you can add it. Just be very > careful. Thanks. That's nice. I guessed that the branching of 5.6 (next Monday) - or earlier - was where the API would freeze, so almost now given that most developers don't work on weekends. From marc.mutz at kdab.com Sun Jan 31 00:38:41 2016 From: marc.mutz at kdab.com (Marc Mutz) Date: Sun, 31 Jan 2016 00:38:41 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths In-Reply-To: References: <201601051352.06816.marc.mutz@kdab.com> <201601221046.25376.marc.mutz@kdab.com> Message-ID: <201601310038.42104.marc.mutz@kdab.com> On Friday 22 January 2016 22:51:30 Kevin Kofler wrote: > Marc Mutz wrote: > > Judging from the comments on my blog post from 2010(!), when they hear > > QList people first think std::list (ie. linked list). Then they see that > > there's also a QLinkedList and start thinking that QList is something > > like std::deque. And then, if they are lucky, they realise it isn't > > that, either. Because both of those std containers guarantee stability > > of references under appends, as does QList _by default_. > > It's funny, because having learned C++ mostly together with Qt, I just see > std::list and std::deque as terse and incomplete names, and so std::list is > what I think is incorrectly named, not QList. :-) Qt would never approve a > name like "deque" in an API review! > > Sure, Qt 3's QList was also a linked list, but I have internalized the Qt 4 > changes by now. It's funny, because having learned C++ mostly together with Qt, and having ported Qt code from Qt 2 to Qt 3 and Qt 4 and 5, I find solace in the API stability of the STL. So we seem to have the same background, but have drawn different conclusions. Interesting. Maybe I have ported Qt containers one too many times. > >> Everything else is a blatant API abuse. > > > > Tell that to the authors of QToolBox and QDataWidgetMapper (off the top > > of my head). Better yet: put code where your mouth is and fix that > > blatant API abuse. I'll be more than happy to give you a +2 on that one. > > Oh, there's code inside Qt that sits on references into containers? Ewww! > > >> undeprecate QtAlgorithms > > > > And this is where I stop taking you seriously, sorry. You can demand such > > nonsense, but if you do, _do_ the work yourself. Go. Implement those 80+ > > algorithms from the STL for Qt. Or play god deciding which are the ones > > "no- one will ever need" or "should never use" - IYHO. > > I'd already be happy with those that were (are, actually) already there. > I'd rather have 10-20 common algorithms with a convenient API than 80+ > obscure ones that force me to use iterators (especially the boilerplate > .begin() and .end() iterators that will be used in 99+% of the cases – > copy&paste programming sucks). I don't like how you demand work from others, but don't want to do any work on Qt yourself. I note that you have not, yet, submitted a change to remove those QList uses that make use of stability-of-references. Please make sure you do. It's sufficient to fix QToolBox (Page, iirc) and QDataWidgetMapper (WidgetMapper). The more the merrier, though. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From kevin.kofler at chello.at Sun Jan 31 00:32:38 2016 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 31 Jan 2016 00:32:38 +0100 Subject: [Development] Question about QCoreApplicationData::*_libpaths References: <201601051352.06816.marc.mutz@kdab.com> <201601221046.25376.marc.mutz@kdab.com> <201601310038.42104.marc.mutz@kdab.com> Message-ID: Marc Mutz wrote: > It's funny, because having learned C++ mostly together with Qt, and having > ported Qt code from Qt 2 to Qt 3 and Qt 4 and 5, I find solace in the API > stability of the STL. So we seem to have the same background, but have > drawn different conclusions. Interesting. Maybe I have ported Qt > containers one too many times. Well, this is one of the reasons why I think Qt containers should stay as is, with CoW, with the current QList, etc. (The main other reason is that I don't see them as being broken in any way. If it ain't broke, don't fix it.) > I don't like how you demand work from others, but don't want to do any > work on Qt yourself. > > I note that you have not, yet, submitted a change to remove those QList > uses that make use of stability-of-references. Please make sure you do. > It's sufficient to fix QToolBox (Page, iirc) and QDataWidgetMapper > (WidgetMapper). The more the merrier, though. I can have a look, but I don't want to make any promises, I have lots of stuff on my plate, and fixing Qt code in classes whose source code I have (probably) never even looked at yet is not the most inviting task. Kevin Kofler