Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Sunday 22 February 2015 05:47:41 Kevin Kofler wrote: Rafael Roquetto wrote: That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a relatively new release), and BlackBerries. I personally would have loved to remove support for 6.5.0, since it is based on an old gcc version that can barely keep up with latest C++ developments (and keep giving me maintenance headaches from time to time). But strategically (read, comercially) speaking, this is still not possible - QNX 6.5.0 is still widely deployed. The move to 6.6.0 is happening at a slow pace - probably much slower than the time it will take us to reach Qt 5.7. One of the many reasons for that is that many of those systems running QNX are homologated and changing/upgrading involves lots of different process apart from the technical stuff. Can't you target the older OS with a newer compiler? That approach is working just fine for RHEL (see the Red Hat Developer Toolset). Technically yes for QNX, not so for WinEC7. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Plans for Qt 5.6
On 21 February 2015 at 18:38, Konstantin Ritt ritt...@gmail.com wrote: 2015-02-21 22:05 GMT+04:00 Richard Moore r...@kde.org: On 21 February 2015 at 17:34, Konstantin Ritt ritt...@gmail.com wrote: 2015-02-21 21:30 GMT+04:00 Richard Moore r...@kde.org: Here's an outline of stuff I'd like to see get done in the Qt 5.6 time frame: * Complete removal of openssl 0.9.8 support This has been unsupported for a while and was really only retained since it is the only version apple ship on OS X (though they don't actually recommend using it). Qt 5.5 introduces the new SecureTransport backend for SSL so there's now no good reason to continue having all the ifdefs. Openssl 0.9.8 will reach EOL in December anyway. In addition to removing the support from the sources, I suspect this will involve some changes to how the library is searched for when we use dlopen. To me, it looks like a subject for 5.5. Why not? 5.5 is already feature frozen. The SecureTransport backend has been already introduced - that's a feature, a dep. library version bump is not :) Well, IMO. This way we have a whole release cycle for people to try the SecureTransport backend and report any problems, much as I'd love to remove the 0.9.8 code already (after all I've already said I won't support it quite some time ago) I think this is a reasonable balance. Cheers Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Rafael Roquetto wrote: That would mean you would also deprecate QNX 6.5.0, 6.6.0 (which is a relatively new release), and BlackBerries. I personally would have loved to remove support for 6.5.0, since it is based on an old gcc version that can barely keep up with latest C++ developments (and keep giving me maintenance headaches from time to time). But strategically (read, comercially) speaking, this is still not possible - QNX 6.5.0 is still widely deployed. The move to 6.6.0 is happening at a slow pace - probably much slower than the time it will take us to reach Qt 5.7. One of the many reasons for that is that many of those systems running QNX are homologated and changing/upgrading involves lots of different process apart from the technical stuff. Can't you target the older OS with a newer compiler? That approach is working just fine for RHEL (see the Red Hat Developer Toolset). Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 14:09:09 Rafael Roquetto wrote: On Fri, Feb 20, 2015 at 08:00:17AM -0800, Thiago Macieira wrote: On Friday 20 February 2015 16:44:28 Cristian Adam wrote: There is another option for QNX, use libstdc++ from GCC and not libcpp from Dinkumware. But then again Rafael knows more about this: http://www.foundry27.com/sf/go/projects.qt/discussion.general.topc21981 Is it not possible to have applications using only libstdc++? The problem with libstdc++ is -- I guess, without being told -- its licence. It's a GPLv3 + exception library, so it has implications for device manufacturers. That's why QNX won't default to it. In turn, applications and Qt switching to it means full ABI break. In addition to that, things like harfbuzz and other libs shipped as part of the SDP are built against libcpp (dinkum), meaning that we need to stick with it if we want to link against those libs (as Qt does). The best approach is likely to be for us to work with QNX to point out where their dinkumware libcpp has problems with specific examples, as we are doing regarding the recent constexpr support issue. I'm sure QNX will be happy to get pointers as to where they can make improvements to be more standard compliant. Regards, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qtLibraryTarget output changed from Qt 5.3.2 to Qt 5.4.0
Done. https://bugreports.qt.io/browse/QTBUG-44595 Have a good weekend! On 20 February 2015 at 13:22, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com wrote: On Fri, Feb 20, 2015 at 01:07:07PM +0200, William Hallatt wrote: On 20 February 2015 at 11:58, Oswald Buddenhagen oswald.buddenha...@theqtcompany.com wrote: i presume the right approach would be admitting defeat, making a new internal function for qt, and restoring qtLibraryTarget() to its qt4 behavior. Would you like me to log a bug? well, why not. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
Just want to throw in my foreach key/value loop implementation, as an
extension of foreach, which I did years ago just as a proof of
concept.
http://codereview.stackexchange.com/questions/11681/
It allows you to do:
foreachkv(auto key, auto value, map) {
// do sth with key / value
}
Its implementation follows straight out of how Q_FOREACH is implemented,
just adding another for-loop. I only implemented the GCC version back
then, though.
On 20.02.2015 18:53, Matthew Woehlke wrote:
On 2015-02-20 07:10, Иван Комиссаров wrote:
Sorry for interupting the discussion, but i saw mentioning of a
range-based-for, so i have a question. std::map/unordered_map uses
std::pair as a value type, and map::iterator::operator* returns
reference
to a pair, while Qt doesn't have an underlying struct and operator*
returns
ref to T (without a Key). So, using range-based-for (and foreach) with
Qt
containers doesn't allow to have an access to a key.
Should this behavior be changed in the future (yes, this breaks source
compatibility)?
No. No need. (Also... note that foreach doesn't give you keys either.)
You can instead wrap the container in an iterator wrapper that gives
you
iterators rather than values. (I have code somewhere, but not sure I
have permission to share it.) No SIC, and you can still iterate
directly
over values.
It's not entirely unlike the trick to do:
for (auto const i : qtIndexRange(5))
...and looks like:
for (auto const i : qtEnumerate(map))
Maybe it would be nice for Qt to provide one or both of these?
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Friday 20 February 2015 08:02:50 Thiago Macieira wrote: On Friday 20 February 2015 09:49:57 Olivier Goffart wrote: I already have added Q_DECL_OVERRIDE to all the examples in qtbase/examples. The examples are currently compiled as part of CI, but maybe we should start using lambda and auto in the examples and disabling the compilation of them on old compiler. Also, what about enabling C++11/14 by default on new projects? https://codereview.qt-project.org/106797 Or alternatively, making the CONFIG+=c++11 enabled by default or so. Agreed and I would also say that it's perfectly acceptable for new features and especially new modules to require those compiler features. Is that an actual rule or your opinion? There have been times that we would have liked to have been able to use C++11 in Qt3D. But, at the same time I'm very aware it would rule out WinCE from our list of possible targets at present. Cheers, Sean -- Dr Sean Harmer | sean.har...@kdab.com | Managing Director UK Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Deprecating BlackBerry Playbook support
Done on: https://codereview.qt-project.org/#/c/105971/ https://codereview.qt-project.org/#/c/105992/ https://codereview.qt-project.org/#/c/105994/ @Ossi, since downmerge happens on Monday, is it safe to assume this will land on 5.5? Thanks, Rafael On Fri, Feb 06, 2015 at 01:55:05PM -0200, Rafael Roquetto wrote: Hello, Unless anyone is willing to help, I would like to propose deprecating and consequently removing BlackBerry Playbook code from Qt sources. This would mainly affect the QNX plugin. Reasons: - the Playbook NDK is old and its compiler does not keep up with newest C++11 improvements inside Qt Code. - the Playbook NDK diverges considerably from the standard BB10 NDK, making it non-trivial to keep a common codebase. - It's a defunct platform. - Maintenance time is limited. If anyone objects, please raise your hands. Cheers, Rafael -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] SSL Plans for Qt 5.6
Here's an outline of stuff I'd like to see get done in the Qt 5.6 time frame: * Complete removal of openssl 0.9.8 support This has been unsupported for a while and was really only retained since it is the only version apple ship on OS X (though they don't actually recommend using it). Qt 5.5 introduces the new SecureTransport backend for SSL so there's now no good reason to continue having all the ifdefs. Openssl 0.9.8 will reach EOL in December anyway. In addition to removing the support from the sources, I suspect this will involve some changes to how the library is searched for when we use dlopen. * As I've been trying to for ages, I'd like to get the support for OCSP and OCSP stapling implemented. * If possible, I'd like to get the rework of the ssl errors API discussed at last years QtCS implemented. Cheers Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Plans for Qt 5.6
2015-02-21 21:30 GMT+04:00 Richard Moore r...@kde.org: Here's an outline of stuff I'd like to see get done in the Qt 5.6 time frame: * Complete removal of openssl 0.9.8 support This has been unsupported for a while and was really only retained since it is the only version apple ship on OS X (though they don't actually recommend using it). Qt 5.5 introduces the new SecureTransport backend for SSL so there's now no good reason to continue having all the ifdefs. Openssl 0.9.8 will reach EOL in December anyway. In addition to removing the support from the sources, I suspect this will involve some changes to how the library is searched for when we use dlopen. To me, it looks like a subject for 5.5. Why not? Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Plans for Qt 5.6
On 21 February 2015 at 18:30, Richard Moore r...@kde.org wrote: Openssl 0.9.8 will reach EOL in December anyway. In addition to removing the support from the sources, I suspect this will involve some changes to how the library is searched for when we use dlopen. As well as 1.0.0. Should we make Qt 5.6 require 1.0.1 directly? -- Giuseppe D'Angelo ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Saturday 21 February 2015 09:06:13 Sean Harmer wrote: On Friday 20 February 2015 08:02:50 Thiago Macieira wrote: On Friday 20 February 2015 09:49:57 Olivier Goffart wrote: I already have added Q_DECL_OVERRIDE to all the examples in qtbase/examples. The examples are currently compiled as part of CI, but maybe we should start using lambda and auto in the examples and disabling the compilation of them on old compiler. Also, what about enabling C++11/14 by default on new projects? https://codereview.qt-project.org/106797 Or alternatively, making the CONFIG+=c++11 enabled by default or so. Agreed and I would also say that it's perfectly acceptable for new features and especially new modules to require those compiler features. Is that an actual rule or your opinion? There have been times that we would have liked to have been able to use C++11 in Qt3D. But, at the same time I'm very aware it would rule out WinCE from our list of possible targets at present. It's been a rule that you can require C++11 core language for some new features. The only example of a C++11 Standard Library feature dependency is the use of std::chrono, which is guarded by SD-6 __has_include(chrono). It's up to you: do you think you're going to unduly limit your audience by using said feature? If so, don't do it. As Marc says, C++98 support costs more. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Saturday 21 February 2015 10:46:41 Sebastian Lehmann wrote: Its implementation follows straight out of how Q_FOREACH is implemented, just adding another for-loop. I only implemented the GCC version back then, though. Hi Sebastian I upgraded Q_FOREACH for 5.4 to make it more readable and optimisable. You may want to take a look at the new version. Mostly because it broke yours, as I removed QForeachContainer::brk. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Plans for Qt 5.6
On Saturday 21 February 2015 18:06:47 Richard Moore wrote: On 21 February 2015 at 17:54, Giuseppe D'Angelo dange...@gmail.com wrote: On 21 February 2015 at 18:30, Richard Moore r...@kde.org wrote: Openssl 0.9.8 will reach EOL in December anyway. In addition to removing the support from the sources, I suspect this will involve some changes to how the library is searched for when we use dlopen. As well as 1.0.0. Should we make Qt 5.6 require 1.0.1 directly? I suspect enterprise distros etc. will continue to support 1.0.0 for a while. I'm not sure of the level of adoption of 1.0.1 at the moment, so I was erring on the side of caution. Any feedback on this is welcome. And with CII supporting OpenSSL now, I don't think we should have a problem with old versions getting updates. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Plans for Qt 5.6
2015-02-21 22:05 GMT+04:00 Richard Moore r...@kde.org: On 21 February 2015 at 17:34, Konstantin Ritt ritt...@gmail.com wrote: 2015-02-21 21:30 GMT+04:00 Richard Moore r...@kde.org: Here's an outline of stuff I'd like to see get done in the Qt 5.6 time frame: * Complete removal of openssl 0.9.8 support This has been unsupported for a while and was really only retained since it is the only version apple ship on OS X (though they don't actually recommend using it). Qt 5.5 introduces the new SecureTransport backend for SSL so there's now no good reason to continue having all the ifdefs. Openssl 0.9.8 will reach EOL in December anyway. In addition to removing the support from the sources, I suspect this will involve some changes to how the library is searched for when we use dlopen. To me, it looks like a subject for 5.5. Why not? 5.5 is already feature frozen. The SecureTransport backend has been already introduced - that's a feature, a dep. library version bump is not :) Well, IMO. Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Plans for Qt 5.6
On 21 February 2015 at 17:34, Konstantin Ritt ritt...@gmail.com wrote: 2015-02-21 21:30 GMT+04:00 Richard Moore r...@kde.org: Here's an outline of stuff I'd like to see get done in the Qt 5.6 time frame: * Complete removal of openssl 0.9.8 support This has been unsupported for a while and was really only retained since it is the only version apple ship on OS X (though they don't actually recommend using it). Qt 5.5 introduces the new SecureTransport backend for SSL so there's now no good reason to continue having all the ifdefs. Openssl 0.9.8 will reach EOL in December anyway. In addition to removing the support from the sources, I suspect this will involve some changes to how the library is searched for when we use dlopen. To me, it looks like a subject for 5.5. Why not? 5.5 is already feature frozen. Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda
On Saturday 21 February 2015 09:11:57 Sean Harmer wrote: The best approach is likely to be for us to work with QNX to point out where their dinkumware libcpp has problems with specific examples, as we are doing regarding the recent constexpr support issue. I'm sure QNX will be happy to get pointers as to where they can make improvements to be more standard compliant. Stop shipping Dinkumware and go for either libstdc++ (GPLv3+exception) or for libc++ (MIT). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] SSL Plans for Qt 5.6
On Saturday 21 February 2015 22:38:03 Konstantin Ritt wrote: The SecureTransport backend has been already introduced - that's a feature, a dep. library version bump is not Major behaviour change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
