Re: [Development] Qt LTS & C++11 plans
On Monday 23 November 2015 09:59:43 Olivier Goffart wrote: > Anyway, i'd like to start the white list with std::enable_if https://codereview.qt-project.org/142782 proposal to add std::hash, too: https://codereview.qt-project.org/142791 -- 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Monday 23 November 2015 14:40:38 Marc Mutz wrote: > > The white list can be obtained by doing 'git grep "std::"' :-) > > > > > > > > Anyway, i'd like to start the white list with std::enable_if > > I'd like to add , too. And std::declval<>. > > All of enable_if, declval, and type_traits don't enter the ABI, even though > they are part of the API (correct?). Then please add this info to the wiki page on library coding conventions. -- 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] Qt LTS & C++11 plans
On Monday 23 November 2015 09:59:43 Olivier Goffart wrote: > On Friday 13. November 2015 10:37:25 Thiago Macieira wrote: > > One more thing: I'd like a whitelist of features that have been tested > > and are known to work on all platforms. > > The white list can be obtained by doing 'git grep "std::"' :-) > > Anyway, i'd like to start the white list with std::enable_if I'd like to add , too. And std::declval<>. All of enable_if, declval, and type_traits don't enter the ABI, even though they are part of the API (correct?). I'd also like to discuss deprecating QPair for std::pair. The standard prescribes the layout of a std::pair, so I don't see how two implementations can be binary incompatible. In particular, the optimisation of boost's compressed_pair, which takes advantage of the empty base class optimisation to squash empty element types, doesn't seem to be allowed for std::pair. (In general, though, I'd -1 any new API using QPair or std::pair instead of a hand-made small struct, unless the latter isn't possible (in generic code, say)). 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Friday 13. November 2015 10:37:25 Thiago Macieira wrote: > One more thing: I'd like a whitelist of features that have been tested and > are known to work on all platforms. The white list can be obtained by doing 'git grep "std::"' :-) Anyway, i'd like to start the white list with std::enable_if -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Saturday 14 November 2015 20:42:18 Marc Mutz wrote: > On Friday 13 November 2015 19:25:54 Thiago Macieira wrote: > > On Wednesday 11 November 2015 08:43:57 Knoll Lars wrote: > > > Fully agree to that. But as long as we can’t execute autotests on all > > > platforms in the CI someone will need to manually check those on some of > > > the target platforms if we extend the set of features used. > > > > They can be added to config.tests/unix/stl. > > Why (just) 'unix'? That's where it's always been. config.tests/common didn't show up until 5.0. -- 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] Qt LTS & C++11 plans
On Friday 13 November 2015 19:25:54 Thiago Macieira wrote: > On Wednesday 11 November 2015 08:43:57 Knoll Lars wrote: > > Fully agree to that. But as long as we can’t execute autotests on all > > platforms in the CI someone will need to manually check those on some of > > the target platforms if we extend the set of features used. > > They can be added to config.tests/unix/stl. Why (just) 'unix'? -- 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Tuesday 10 November 2015 20:22:28 Knoll Lars wrote: > At least for now, I don't want us to rely too much on standard library > features in our APIs (ie. Using these types in the APIs we expose to our > users). > > But I am not opposed to using any of these features in our implementation, > if they work on all platforms we currently support with Qt 5.7. Hi Lars To confirm: some of the use we're talking about is in public headers, such as std::enable_if and . They don't affect our API and ABI, but they require the user to have the ability in question in order to compile their application. I don't think this changes your recommendation, but I wanted to clarify. One more thing: I'd like a whitelist of features that have been tested and are known to work on all platforms. -- 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] Qt LTS & C++11 plans
On Wednesday 11 November 2015 08:43:57 Knoll Lars wrote: > Fully agree to that. But as long as we can’t execute autotests on all > platforms in the CI someone will need to manually check those on some of > the target platforms if we extend the set of features used. They can be added to config.tests/unix/stl. -- 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] Qt LTS & C++11 plans
On 11/11/15 00:41, "Development on behalf of Marc Mutz" wrote: >On Tuesday 10 November 2015 19:43:35 Olivier Goffart wrote: >> Likewise, Marc is trying to use std::declval and type traits >> in exception specification [https://codereview.qt-project.org/140132/] > >declval is in use for exception specifications since at least 5.5 (in QPair). > >As for type_traits, please note that for many of them, there is no other way >to get at the information (std::is_trivial*, std::is_polymorphic, even some >std::is_nothrow_constructible, because a seemingly equivalent noexcep operator >(say, noexcept(T(std::declval()) also includes the dtor). > >I propose that whatever we decide here is checked for in machine-readable form >in tst_compiler. Fully agree to that. But as long as we can’t execute autotests on all platforms in the CI someone will need to manually check those on some of the target platforms if we extend the set of features used. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Tuesday 10 November 2015 19:43:35 Olivier Goffart wrote: > Likewise, Marc is trying to use std::declval and type traits > in exception specification [https://codereview.qt-project.org/140132/] declval is in use for exception specifications since at least 5.5 (in QPair). As for type_traits, please note that for many of them, there is no other way to get at the information (std::is_trivial*, std::is_polymorphic, even some std::is_nothrow_constructible, because a seemingly equivalent noexcep operator (say, noexcept(T(std::declval()) also includes the dtor). I propose that whatever we decide here is checked for in machine-readable form in tst_compiler. 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Tuesday 10 November 2015 12:10:17 Thiago Macieira wrote: > The problem is that the Standard Library in use is not always the one > provided with the compiler. See the cases of libstdc++ with Clang and > Dinkumware with QNX's GCC. > > If we're going to use certain Standard Library features that weren't > previously checked with Q_COMPILER [*], I'd like a survey of our target > platforms to confirm the features are present and work, then we can produce > a whitelist. FYI Five months ago, Mozilla *added* a tuple class instead of using std::tuple: https://bugzilla.mozilla.org/show_bug.cgi?id=1163328 Quoting the proposal above: > The C++11 standard library has them (std::tuple), but since we can't use > that yet, I propose adding one to MFBT. -- 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] Qt LTS & C++11 plans
On 10/11/15 19:43, "Olivier Goffart" wrote: >On Tuesday 23. June 2015 10:17:40 Knoll Lars wrote: >[...] >> Qt 5.7: >> * New compiler baseline with gcc 4.7 and VC++ 2012 >> * Enable and use the C++11 features supported by these compilers >> unconditionally > >By "C++11 features", do you mean only core language feature, or can we also >use standard library features. The core language features are certainly ok. Standard library features is something where we've always been a bit more careful, as the level of support for them from different standard library implementations has unfortunately been somewhat orthogonal to the compiler discussion (see the discussion about atomics a few weeks ago). At least for now, I don't want us to rely too much on standard library features in our APIs (ie. Using these types in the APIs we expose to our users). But I am not opposed to using any of these features in our implementation, if they work on all platforms we currently support with Qt 5.7. > >For example I would like to use std::enable_if instead of QtPrivate::QEnableIf >[https://codereview.qt-project.org/140266] >Clang would then gives better error messages because it knows about it. > >I would also want to use the type traits such as std::is_trivial and >std::is_trivially_copyable >[https://codereview.qt-project.org/140476] > >Likewise, Marc is trying to use std::declval and type traits >in exception specification [https://codereview.qt-project.org/140132/] > >Not to mention that we already use directly things like std::move or >std::forward. > >Since all of these are C++11 features supported by these compiler, I would >assume that we can use them unconditionally. We should check that these features work and are supported on all the platforms we target with 5.7. If they are, I'm ok to use them. The usual suspects that could cause issues are VS2012 (WEC2013), QNX 6.6, and RHEL. Ideally, we could simply let the CI decide whether the feature works, but unfortunately I don't think we're currently running auto tests for QNX or WEC. So we'll know whether things compile on those platforms, but we don't know whether they work without someone actually trying it out. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Tuesday 10 November 2015 19:43:35 Olivier Goffart wrote: > Since all of these are C++11 features supported by these compiler, I would > assume that we can use them unconditionally. The problem is that the Standard Library in use is not always the one provided with the compiler. See the cases of libstdc++ with Clang and Dinkumware with QNX's GCC. If we're going to use certain Standard Library features that weren't previously checked with Q_COMPILER [*], I'd like a survey of our target platforms to confirm the features are present and work, then we can produce a whitelist. [*] The following Standard Library features were already checked: 1) by Q_COMPILER_ATOMICS 2) std::move and std::forward, by Q_COMPILER_RVALUE_REFS 3) by Q_COMPILER_INITIALIZER_LISTS -- 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] Qt LTS & C++11 plans
On 04/11/15 15:31, "Albert Astals Cid" wrote: >On Tue, Jun 23, 2015 at 12:17 PM, Knoll Lars > wrote: >> Qt 5.6: >> >> * We make 5.6 a long term supported release > >Any plan on how long will be that "long term"? 2 years? 5 years? 3 years was the current thinking. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Tuesday 23. June 2015 10:17:40 Knoll Lars wrote: [...] > Qt 5.7: > * New compiler baseline with gcc 4.7 and VC++ 2012 > * Enable and use the C++11 features supported by these compilers > unconditionally By "C++11 features", do you mean only core language feature, or can we also use standard library features. For example I would like to use std::enable_if instead of QtPrivate::QEnableIf [https://codereview.qt-project.org/140266] Clang would then gives better error messages because it knows about it. I would also want to use the type traits such as std::is_trivial and std::is_trivially_copyable [https://codereview.qt-project.org/140476] Likewise, Marc is trying to use std::declval and type traits in exception specification [https://codereview.qt-project.org/140132/] Not to mention that we already use directly things like std::move or std::forward. Since all of these are C++11 features supported by these compiler, I would assume that we can use them unconditionally. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Tue, Jun 23, 2015 at 12:17 PM, Knoll Lars wrote: > Qt 5.6: > > * We make 5.6 a long term supported release Any plan on how long will be that "long term"? 2 years? 5 years? Cheers, Albert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Tuesday 18 August 2015 07:56:24 Sorvig Morten wrote: > > Choices: > > 1) drop the ability to build Qt and applications using an old XCode > > 2) keep qatomic_x86.h for OS X. > > > > > > > > So, Mac people: is it ok to drop OS X 10.8 as a *build* platform? This > > should not affect using it as a target. > > CI testing may be sufficient reason to keep Qt building on 10.8, unless we > have/gain the the capability to have separate “build” and “test” machines. That's a good point. Anyway, the build error is weird, since there's no reason for the problems to start happening in the commit they're happening. Either they were already there and nothing should be compiling, or they shouldn't be showing up. I'll try to modify tst_qatomicinteger to see if it helps. -- 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] Qt LTS & C++11 plans
On 18/08/15 09:56, "development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of Sorvig Morten" wrote: > >> On 18 Aug 2015, at 07:46, Thiago Macieira wrote: >> >> On Monday 13 July 2015 18:44:40 Thiago Macieira wrote: >>> On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote: The only compiler I currently know that will have problems with this is the Intel compiler on OS X when using libc++ older than Subversion r215305. Unfortunately, _LIBCPP_VERSION has been at value 1101 since way before that change. To restore functionality, I will revert 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev. >>> >>> Upon further investigation, it turns out that ICC has worked around the >>> libc++ problem since version 15.0 by providing its own std::atomic >>> implementation when __clang__ is defined (probably a mistake and should >>> have been a check for _LIBCPP_VERSION). >> >> Looks like std::atomic that came with the latest XCode that still runs on OS >> X >> 10.8 is also broken with Clang. >> >> Choices: >> 1) drop the ability to build Qt and applications using an old XCode >> 2) keep qatomic_x86.h for OS X. >> >> So, Mac people: is it ok to drop OS X 10.8 as a *build* platform? This >> should >> not affect using it as a target. > >CI testing may be sufficient reason to keep Qt building on 10.8, unless we >have/gain the the capability to have separate “build” and “test” machines. Longer term, we could add that capability, but we don't have it yet, and the focus for the CI is on other, more important items currently. I'd say we keep it building on 10.8 for now, and use qatomic_x86. IIRC the file was anyway still being used by at least one other platform. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
> On 18 Aug 2015, at 07:46, Thiago Macieira wrote: > > On Monday 13 July 2015 18:44:40 Thiago Macieira wrote: >> On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote: >>> The only compiler I currently know that will have problems with this is >>> the Intel compiler on OS X when using libc++ older than Subversion >>> r215305. Unfortunately, _LIBCPP_VERSION has been at value 1101 since way >>> before that change. To restore functionality, I will revert >>> 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev. >> >> Upon further investigation, it turns out that ICC has worked around the >> libc++ problem since version 15.0 by providing its own std::atomic >> implementation when __clang__ is defined (probably a mistake and should >> have been a check for _LIBCPP_VERSION). > > Looks like std::atomic that came with the latest XCode that still runs on OS > X > 10.8 is also broken with Clang. > > Choices: > 1) drop the ability to build Qt and applications using an old XCode > 2) keep qatomic_x86.h for OS X. > > So, Mac people: is it ok to drop OS X 10.8 as a *build* platform? This should > not affect using it as a target. CI testing may be sufficient reason to keep Qt building on 10.8, unless we have/gain the the capability to have separate “build” and “test” machines. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
> On Aug 18, 2015, at 08:49, Thiago Macieira wrote: > > On Monday 17 August 2015 23:25:05 Jake Petroules wrote: >> I haven't a clue why people would bother using old OS X platforms for >> development, *especially* now that they don't charge for it. Plus I think >> submitting to app stores requires the latest Xcode anyways so there's >> another point against it. > > Right. In the past, the thinking was that people wouldn't upgrade because it > would require them to pay for it. That reason is now gone. > > They may still complain if the newer versions of OS X no longer run on some > older hardware. But isn't it true that all 64-bit capable Intel Mac can run > the latest OS X? Or is there any hardware that would have upgraded to 10.8 > but > not further? 10.9 did not increase hardware requirements: 10.8: https://support.apple.com/en-us/HT202575 10.9: https://support.apple.com/en-us/HT201364 > > -- > 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 -- Eike Ziller, Senior Software Engineer | The Qt Company Digia Germany 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Monday 17 August 2015 23:25:05 Jake Petroules wrote: > I haven't a clue why people would bother using old OS X platforms for > development, *especially* now that they don't charge for it. Plus I think > submitting to app stores requires the latest Xcode anyways so there's > another point against it. Right. In the past, the thinking was that people wouldn't upgrade because it would require them to pay for it. That reason is now gone. They may still complain if the newer versions of OS X no longer run on some older hardware. But isn't it true that all 64-bit capable Intel Mac can run the latest OS X? Or is there any hardware that would have upgraded to 10.8 but not further? -- 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] Qt LTS & C++11 plans
> On Aug 17, 2015, at 10:46 PM, Thiago Macieira > wrote: > > On Monday 13 July 2015 18:44:40 Thiago Macieira wrote: >> On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote: >>> The only compiler I currently know that will have problems with this is >>> the Intel compiler on OS X when using libc++ older than Subversion >>> r215305. Unfortunately, _LIBCPP_VERSION has been at value 1101 since way >>> before that change. To restore functionality, I will revert >>> 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev. >> >> Upon further investigation, it turns out that ICC has worked around the >> libc++ problem since version 15.0 by providing its own std::atomic >> implementation when __clang__ is defined (probably a mistake and should >> have been a check for _LIBCPP_VERSION). > > Looks like std::atomic that came with the latest XCode that still runs on OS > X > 10.8 is also broken with Clang. > > Choices: > 1) drop the ability to build Qt and applications using an old XCode > 2) keep qatomic_x86.h for OS X. > > So, Mac people: is it ok to drop OS X 10.8 as a *build* platform? This should > not affect using it as a target. > -- > 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 I haven't a clue why people would bother using old OS X platforms for development, *especially* now that they don't charge for it. Plus I think submitting to app stores requires the latest Xcode anyways so there's another point against it. -- Jake Petroules - jake.petroules at petroules.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Monday 13 July 2015 18:44:40 Thiago Macieira wrote: > On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote: > > The only compiler I currently know that will have problems with this is > > the Intel compiler on OS X when using libc++ older than Subversion > > r215305. Unfortunately, _LIBCPP_VERSION has been at value 1101 since way > > before that change. To restore functionality, I will revert > > 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev. > > Upon further investigation, it turns out that ICC has worked around the > libc++ problem since version 15.0 by providing its own std::atomic > implementation when __clang__ is defined (probably a mistake and should > have been a check for _LIBCPP_VERSION). Looks like std::atomic that came with the latest XCode that still runs on OS X 10.8 is also broken with Clang. Choices: 1) drop the ability to build Qt and applications using an old XCode 2) keep qatomic_x86.h for OS X. So, Mac people: is it ok to drop OS X 10.8 as a *build* platform? This should not affect using it as a target. -- 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] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 28 July 2015 06:19:03 Andre Somers wrote: > > The section 2 says "grants the Foundation [...] the right and license, to > > use, copy, duplicate [...] any and all existing and future Qt Free > > Edition releases ..." > > So, the foundation has the right, but not the obligation to do so. So > they probably will, but that's not an automatic given. Thanks for the > link and quote. Well, the passage is legalese for saying that the Foundation gets all rights to the source code. What the Foundation does with the source code is its own decision. It can: a) do nothing and let the code die b) release it to an open source project under BSD licence c) ditto, but using LGPL d) give it to a company to commercialise it under the dual licensing scheme again e) something else, but the options b, c,and d are the most likely ones The important thing to note is that the source code reverting to the Foundation does not imply neither the end of either the open source project nor the end of commercial licensing. -- 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] Qt LTS & C++11 plans (CopperSpice)
On 27-7-2015 18:21, Thiago Macieira wrote: > On Monday 27 July 2015 08:01:53 André Somers wrote: >> I am not a lawer and I don't know the wording of the KDE Free Qt >> Foundation agreement, but are you sure that in case that agreement is >> triggered the verion you branched off off will fall under that licence >> and be the one that will be released under BSD? I'm just wondering if >> all versions would retroactively be relicenced or just the current >> code... _If_ it is the latter, you have a problem in your CLA, as you >> may not have the right to do the BSD relicencing you promissed seeing >> that you forked Qt 4 and not 5... > https://www.kde.org/community/whatiskde/images/nokia-agreement-3.jpg > > The section 2 says "grants the Foundation [...] the right and license, to use, > copy, duplicate [...] any and all existing and future Qt Free Edition releases > ..." > So, the foundation has the right, but not the obligation to do so. So they probably will, but that's not an automatic given. Thanks for the link and quote. André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Monday 27 July 2015 08:01:53 André Somers wrote: > I am not a lawer and I don't know the wording of the KDE Free Qt > Foundation agreement, but are you sure that in case that agreement is > triggered the verion you branched off off will fall under that licence > and be the one that will be released under BSD? I'm just wondering if > all versions would retroactively be relicenced or just the current > code... _If_ it is the latter, you have a problem in your CLA, as you > may not have the right to do the BSD relicencing you promissed seeing > that you forked Qt 4 and not 5... https://www.kde.org/community/whatiskde/images/nokia-agreement-3.jpg The section 2 says "grants the Foundation [...] the right and license, to use, copy, duplicate [...] any and all existing and future Qt Free Edition releases ..." -- 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] Qt LTS & C++11 plans (CopperSpice)
Op 27-7-2015 om 03:47 schreef Ansel Sermersheim: > On 7/26/15 3:01 PM, Kevin Kofler wrote: >> Ansel Sermersheim wrote: >>> We do in fact have a CLA in place. However, our CLA has one single >>> purpose. In the event that Qt is re-licensed under a BSD style license >>> (whether due to the KDE Free Qt Foundation or some other reason), we >>> will re-license CopperSpice under that same license. That is the only >>> permission we ask from contributors. >> That in turn allows everyone else, or even you, to take the code >> proprietary, so in the case this clause is triggered (which depends on Qt, >> i.e., neither on you nor on the contributor), it is functionally equivalent >> to a CLA allowing proprietary relicensing. > There is one fundamental difference between the CopperSpice and Qt > licensing situation. > > In the (unlikely) event that CopperSpice becomes BSD licensed, it > becomes BSD licensed for everyone. This means anyone, anywhere, has > equal rights to make changes and profit from them. > > This is very different from one particular entity owning the right to > profit from an open source project. The argument between GPL-style vs > BSD-style licenses is as old as the hills, but both licenses do treat > all contributors equally. > > Ansel Sermersheim > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development I am not a lawer and I don't know the wording of the KDE Free Qt Foundation agreement, but are you sure that in case that agreement is triggered the verion you branched off off will fall under that licence and be the one that will be released under BSD? I'm just wondering if all versions would retroactively be relicenced or just the current code... _If_ it is the latter, you have a problem in your CLA, as you may not have the right to do the BSD relicencing you promissed seeing that you forked Qt 4 and not 5... André ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On 7/26/15 3:01 PM, Kevin Kofler wrote: > Ansel Sermersheim wrote: >> We do in fact have a CLA in place. However, our CLA has one single >> purpose. In the event that Qt is re-licensed under a BSD style license >> (whether due to the KDE Free Qt Foundation or some other reason), we >> will re-license CopperSpice under that same license. That is the only >> permission we ask from contributors. > That in turn allows everyone else, or even you, to take the code > proprietary, so in the case this clause is triggered (which depends on Qt, > i.e., neither on you nor on the contributor), it is functionally equivalent > to a CLA allowing proprietary relicensing. There is one fundamental difference between the CopperSpice and Qt licensing situation. In the (unlikely) event that CopperSpice becomes BSD licensed, it becomes BSD licensed for everyone. This means anyone, anywhere, has equal rights to make changes and profit from them. This is very different from one particular entity owning the right to profit from an open source project. The argument between GPL-style vs BSD-style licenses is as old as the hills, but both licenses do treat all contributors equally. Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
Ansel Sermersheim wrote: > We do in fact have a CLA in place. However, our CLA has one single > purpose. In the event that Qt is re-licensed under a BSD style license > (whether due to the KDE Free Qt Foundation or some other reason), we > will re-license CopperSpice under that same license. That is the only > permission we ask from contributors. That in turn allows everyone else, or even you, to take the code proprietary, so in the case this clause is triggered (which depends on Qt, i.e., neither on you nor on the contributor), it is functionally equivalent to a CLA allowing proprietary relicensing. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Wednesday 22 July 2015 16:47:21 Olivier Goffart wrote: > > template > > using QMap = QMapComparator>; > > This is still source incompatible (because of forward declarations) and > binary incompatible too. Oops! You're right. -- 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] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 21. July 2015 16:03:56 Thiago Macieira wrote: > On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote: > > Il 21/07/2015 20:37, Thiago Macieira ha scritto: > > > As opposed to qMapLessThanKey? Do you mean two QMap with the same key > > > could > > > have different comparators? > > > > Why not? > > Not passing judgement. I was only asking for clarification, since that was > the only feature that Ansel mentioned and, depending on the actual change, > is not a feature at all since QMap alreaydy supported it. > > > Too bad that adding a template parameter to QMap is a huge SiC, as > > people forward declare it with two template arguments, and we never > > provided headers for forward declarations... :( > > We can fix that with C++11 template aliases. > > template > using QMap = QMapComparator>; This is still source incompatible (because of forward declarations) and binary incompatible too. > > Note however that a function taking QMap is *not* the same as a > function taking QMapComparator>. The two > types are not the same, even though they are. Anyway, If one need to do advanced usages, one could use std::map. Re-implementing the standard library is not a goal of Qt. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On 7/21/15 3:15 PM, Marc Mutz wrote: > On Tuesday 21 July 2015 22:26:17 Ansel Sermersheim wrote: >> As to your question about relicensing, can you please elaborate on what >> this is referring to? As long as Qt is covered by the current license, >> we can not relicense CopperSpice since we are bound by the terms of the >> licenses under which we forked the code. > You own the copyright to those parts which you added. Come GPL4, you might > conceivably want to use that license. Assuming TQC releases its code under > GPL4, too, which it can, that leaves your own original work. Assuming it's > just you and Barbara, you won't have problems. But if you have 200 > contributors, half of which vanished from the face of the earth after a few > months of being active, you will have a harder time to track every contributor > down and get approval for the relicensing from each of them. It's why many > Free Software projects require some form of copyright assignment, incl. the > Godfather of GPL projects, GNU. As we mentioned, we have several people testing CopperSpice as well as others asking about how to contribute to the project. We certainly look forward to having an active development community. We do in fact have a CLA in place. However, our CLA has one single purpose. In the event that Qt is re-licensed under a BSD style license (whether due to the KDE Free Qt Foundation or some other reason), we will re-license CopperSpice under that same license. That is the only permission we ask from contributors. > You seem to say that Copperspice is in some sense more free than Qt, because > of the missing CLA, but you may have locked yourself into a set of licenses > forever, like the Linux kernel did (and it's anyone's guess whether Linus is > *actually* happy with the GPL v2 and being stuck with it forever, or whether > dropping the "or later" clause secretly gnaws at his conscience, after all he > also publicly condemns C++ and then goes to write his diving app in Qt/C++ :) Just to be clear, we are not opposed to a CLA and as noted above we have one as well. We simply did not feel comfortable contributing under the Qt Company CLA for reasons which we have previously stated. We do understand and appreciate the logic and the financial reasons that led to the Qt Company CLA. Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 21 July 2015 18:32:09 Ansel Sermersheim wrote: > On 7/21/15 6:23 PM, Thiago Macieira wrote: > > Right, we usually work around this by having QMap > X>. > Certainly possible to do, but sometimes quite awkward depending on the > situation. Agreed. > > I don't see the need to do the same for QHash. How often do people need a > > different comparator and/or a different hashing function for a given class > > type? > I have in the past used non-standard hashing and equality functions for > std::unordered_map, but I will admit it is far less common. Can you share why you needed that? -- 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] Qt LTS & C++11 plans (CopperSpice)
On 7/21/15 6:23 PM, Thiago Macieira wrote: > On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote: >> The most common use case of this is creating a QMap that is >> sorted case insensitively. The STL allows this for std::map, and coming >> to Qt from a background of standard C++ I was amazed that this very >> common use case was not supported. > Right, we usually work around this by having QMap. Certainly possible to do, but sometimes quite awkward depending on the situation. > This is something we should fix or 6.0, if we can accept the source > compatibility break against forward declarations of QMap. > > I don't see the need to do the same for QHash. How often do people need a > different comparator and/or a different hashing function for a given class > type? I have in the past used non-standard hashing and equality functions for std::unordered_map, but I will admit it is far less common. Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On 7/21/15 4:03 PM, Thiago Macieira wrote: > On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote: >> Il 21/07/2015 20:37, Thiago Macieira ha scritto: >>> As opposed to qMapLessThanKey? Do you mean two QMap with the same key >>> could >>> have different comparators? >> Why not? > Not passing judgement. I was only asking for clarification, since that was the > only feature that Ansel mentioned and, depending on the actual change, is not > a feature at all since QMap alreaydy supported it. We brought this change up as representative of the kind of things that are being done. For a more comprehensive list check out the overview documentation on our website: http://www.copperspice.com/docs/cs_overview/index.html Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote: > The most common use case of this is creating a QMap that is > sorted case insensitively. The STL allows this for std::map, and coming > to Qt from a background of standard C++ I was amazed that this very > common use case was not supported. Right, we usually work around this by having QMap. This is something we should fix or 6.0, if we can accept the source compatibility break against forward declarations of QMap. I don't see the need to do the same for QHash. How often do people need a different comparator and/or a different hashing function for a given class type? -- 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] Qt LTS & C++11 plans (CopperSpice)
On 7/21/15 11:37 AM, Thiago Macieira wrote: > On Tuesday 21 July 2015 10:06:52 Ansel Sermersheim wrote: >> We would like to announce our release of CopperSpice 1.1.0. We have >> added and changed several things including a modification to to QMap to >> user defined comparisons. > As opposed to qMapLessThanKey? Do you mean two QMap with the same key could > have different comparators? The qMapLessThanKey solution does not help at all if you want to create a user defined sort order for a class that already has a defined ordering. The most common use case of this is creating a QMap that is sorted case insensitively. The STL allows this for std::map, and coming to Qt from a background of standard C++ I was amazed that this very common use case was not supported. Ansel Sermersheim ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Wednesday 22 July 2015 00:15:19 Marc Mutz wrote: > You own the copyright to those parts which you added. Come GPL4, you might > conceivably want to use that license. Assuming TQC releases its code under > GPL4, too, which it can, that leaves your own original work. Assuming it's > just you and Barbara, you won't have problems. But if you have 200 > contributors, half of which vanished from the face of the earth after a few > months of being active, you will have a harder time to track every > contributor down and get approval for the relicensing from each of them. > It's why many Free Software projects require some form of copyright > assignment, incl. the Godfather of GPL projects, GNU. To be fair, those projects often limit the set of licences that the code can be relicensed under. For example, KDE requires all inbound contributions to be either: GPLv2, GPLv3 or later GPLv2, GPLv3 or any later version by a decision of the KDE e.V. That is, even if the e.V. wanted to, it could not relicense under, say, the Apache licence version 2. It has to be an upgrade of the GPL. The KDE Free Qt Foundation requires relicensing under the terms of the BSD licence. No other. Other projects may limit to licenses approved by the Open Source Initiative. Some others may say OSI approved *and* copyleft. In the specific case of the Qt Project CLA, it makes no judgement. It can be any license, including non-open source ones. Which is the case. And since I'm being fair: the CLA is required by the KDE Free Qt Foundation, since The Qt Company has to have the rights to relicense everything under the BSD license. The only other option would be to have all inbound contributions under the BSD licence. -- 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] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 21 July 2015 12:21:35 Ansel Sermersheim wrote: > Hi Gunnar, > > We used to say "Qt" which we thought was the name of the project. We > were asked to use the name "The Qt Project". We do not mind changing > how we address the company and the library. Since we meant to harm may > we suggest this be conveyed to others a little more gently. The point is that there's a difference between: Qt the product, the framework, the libraries Qt Project the open source project organised to develop Qt The Qt Company the company that holds the rights under the CLA and the trademark to Qt And, for that matter, Qt Creator the IDE (lots of people come on IRC and say something about Qt, when they meant Qt Creator) > I am not a lawyer but this language is very clear. It may not be The Qt > Company policy or practice to accept changes into the commercial version > only, but if I were to sign the CLA I would be granting them the right, > irrevocably and perpetually. Since these rights are transferable I have > no recourse if the license is transferred to another entity who uses my > contribution in a way I did not intend. That's actually common practice. The commercial version is identical to the open source version in functionality and codebase. The reverse is required by the KDE Free Qt Foundation: everything released commercially must be present in the open source version (at least, as long as it's Android or X11, but in practice it is the case for all platforms). It makes no sense to keep two separate trees. Even when Trolltech had pieces of functionality that weren't present in the open source version, Trolltech kept a single tree. The release scripts simply removed some files before the release. That hasn't been the case since March 2009. When the Git repositories opened. > Most open source development communities are structured in such a way > that all participants have equal rights. The Qt Company is in a position > to exercise additional rights not enjoyed by the rest of the Qt > community. This is certainly a legal and enforceable position. However, > it bothers many members of the larger open source community including > myself. Understandable. For us, it's a trade-off: the community accepts giving The Qt Company some extra rights in exchange for them employing a large chunk of the work force, including the entirety of the QA team and running the entire CI system and infrastructure for us. > We have talked with other developers and read discussions about this for > over a decade. Many members of the larger open source community, > including myself, are not comfortable with this clause. -- 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] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote: > Il 21/07/2015 20:37, Thiago Macieira ha scritto: > > As opposed to qMapLessThanKey? Do you mean two QMap with the same key > > could > > have different comparators? > > Why not? Not passing judgement. I was only asking for clarification, since that was the only feature that Ansel mentioned and, depending on the actual change, is not a feature at all since QMap alreaydy supported it. > Too bad that adding a template parameter to QMap is a huge SiC, as > people forward declare it with two template arguments, and we never > provided headers for forward declarations... :( We can fix that with C++11 template aliases. template using QMap = QMapComparator>; Note however that a function taking QMap is *not* the same as a function taking QMapComparator>. The two types are not the same, even though they are. -- 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] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 21 July 2015 22:26:17 Ansel Sermersheim wrote: > As to your question about relicensing, can you please elaborate on what > this is referring to? As long as Qt is covered by the current license, > we can not relicense CopperSpice since we are bound by the terms of the > licenses under which we forked the code. You own the copyright to those parts which you added. Come GPL4, you might conceivably want to use that license. Assuming TQC releases its code under GPL4, too, which it can, that leaves your own original work. Assuming it's just you and Barbara, you won't have problems. But if you have 200 contributors, half of which vanished from the face of the earth after a few months of being active, you will have a harder time to track every contributor down and get approval for the relicensing from each of them. It's why many Free Software projects require some form of copyright assignment, incl. the Godfather of GPL projects, GNU. You seem to say that Copperspice is in some sense more free than Qt, because of the missing CLA, but you may have locked yourself into a set of licenses forever, like the Linux kernel did (and it's anyone's guess whether Linus is *actually* happy with the GPL v2 and being stuck with it forever, or whether dropping the "or later" clause secretly gnaws at his conscience, after all he also publicly condemns C++ and then goes to write his diving app in Qt/C++ :) IANAL, yadda, yadda, 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Tue, Jul 21, 2015 at 10:26 PM, Ansel Sermersheim wrote: As to your question about relicensing, can you please elaborate on what > this is referring to? As long as Qt is covered by the current license, > we can not relicense CopperSpice since we are bound by the terms of the > licenses under which we forked the code. > > I think the actual question(s) were: - Are you and Barbara developing CopperSpice full-time, part-time or just on your spare time? - How do you sustain development of CopperSpice? Support & services to Qt4 delopers? You use it only for your own (paid-for) projects? Venture Capital? No funding at all, just hobby? And I would repeat the question Milian asked: why did you fork Qt4 instead of Qt5? -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
Hi Marc, We do own copperspice.com, .org, .net, and .info. We set .com up as the primary site for no particular reason. There is no question that making money is of value. However, our main goal at this time is to develop CopperSpice and share it with the community. We believe money will follow but it is not our primary goal or direction. We have a few beta testers, an excellent project mentor, a couple of people contributing changes, and we are working with someone on the packaging process with various unix distributions As to your question about relicensing, can you please elaborate on what this is referring to? As long as Qt is covered by the current license, we can not relicense CopperSpice since we are bound by the terms of the licenses under which we forked the code. Ansel Sermersheim On 7/21/15 12:36 PM, Marc Mutz wrote: > On Tuesday 21 July 2015 19:53:14 Gunnar Roth wrote: >> Hi Ansel. >> >>> Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim : >>> >>> gives the Qt Project the freedom to take any and all submissions and >>> incorporate them into the closed source version >> Do not mix up commercial license with closed source, all code you >> contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules >> AND the commercial license. Btw. It is not Qt Project , it is Qt Company. > Note how it's copperspice._com_, not .org :) Will be interesting to see how > they want to make money off their project. Or how they deal with the problem > of relicensing once they grow to 200 instead of 2 developers... > > Thanks, > Marc > ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 21 July 2015 20:52:05 Giuseppe D'Angelo wrote: > Il 21/07/2015 20:37, Thiago Macieira ha scritto: > > As opposed to qMapLessThanKey? Do you mean two QMap with the same key > > could have different comparators? > > Why not? Suppose you want to have maps sorting by different criteria, > especially if the type doesn't have proper semantics for operator< and > thus shouldn't have one defined (e.g. complex numbers). > > Too bad that adding a template parameter to QMap is a huge SiC, as > people forward declare it with two template arguments, and we never > provided headers for forward declarations... :( It's spelled _s_t_d_:_:_m_a_p_ :) -- 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
Hi Gunnar, We used to say "Qt" which we thought was the name of the project. We were asked to use the name "The Qt Project". We do not mind changing how we address the company and the library. Since we meant to harm may we suggest this be conveyed to others a little more gently. As to your comment regarding licensing, I will quote from the current Qt CLA, Section 3.1: Subject to the terms and conditions of this Agreement, Licensor hereby grants, in exchange for good and valuable consideration, the receipt and sufficiency of which is hereby acknowledged, to The Qt Company a sublicensable, irrevocable, perpetual, worldwide, non-exclusive, royalty-free and fully paid-up copyright and trade secret license to reproduce, adapt, translate, modify, and prepare derivative works of, publicly display, publicly perform, sublicense, make available and distribute Licensor Contribution(s) and any derivative works thereof under license terms of The Qt Company’s choosing including any Open Source Software license. I am not a lawyer but this language is very clear. It may not be The Qt Company policy or practice to accept changes into the commercial version only, but if I were to sign the CLA I would be granting them the right, irrevocably and perpetually. Since these rights are transferable I have no recourse if the license is transferred to another entity who uses my contribution in a way I did not intend. Most open source development communities are structured in such a way that all participants have equal rights. The Qt Company is in a position to exercise additional rights not enjoyed by the rest of the Qt community. This is certainly a legal and enforceable position. However, it bothers many members of the larger open source community including myself. We have talked with other developers and read discussions about this for over a decade. Many members of the larger open source community, including myself, are not comfortable with this clause. Ansel Sermersheim On 7/21/15 10:53 AM, Gunnar Roth wrote: Hi Ansel. Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim mailto:an...@copperspice.com>>: gives the Qt Project the freedom to take any and all submissions and incorporate them into the closed source version Do not mix up commercial license with closed source, all code you contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules AND the commercial license. Btw. It is not Qt Project , it is Qt Company. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
Il 21/07/2015 20:37, Thiago Macieira ha scritto: As opposed to qMapLessThanKey? Do you mean two QMap with the same key could have different comparators? Why not? Suppose you want to have maps sorting by different criteria, especially if the type doesn't have proper semantics for operator< and thus shouldn't have one defined (e.g. complex numbers). Too bad that adding a template parameter to QMap is a huge SiC, as people forward declare it with two template arguments, and we never provided headers for forward declarations... :( Cheers, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company | Tel: UK +44-1625-809908 KDAB - The Qt Experts smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 21 July 2015 10:06:52 Ansel Sermersheim wrote: > We would like to announce our release of CopperSpice 1.1.0. We have > added and changed several things including a modification to to QMap to > user defined comparisons. As opposed to qMapLessThanKey? Do you mean two QMap with the same key could have different comparators? > Our view as well as the view from many other developers, is that the CLA > gives the Qt Project the freedom to take any and all submissions and > incorporate them into the closed source version. We feel this goes > against the share and share alike principle of community based open > source software. True. It's intended instead to support the "virtuous cycle" that Trolltech talked about: the commercial version helps fund the development of the open source version. Shut down the commercial version and the well runs dry. We wouldn't be able to sustain the development pace we currently have. All other attempts at funding exclusively through extra services have failed and have not produced nearly as much funds as the licensing business. > From the countless local developers in the Silicon Valley area we have > communicated with, Qt is not typically viewed as a community project. > There is nothing inherently wrong with this approach, it just did not > fit our paradigm. You have to qualify what you mean by "community project". As long as you do that, it should be no problem. > We are speaking at CPPCon in September and our intent is simply to > explain the CLA did not work for us. The main purpose of our > presentation is to present CopperSpice and offer C++ developers an > alternative GUI library. That's fine. We just ask that you don't say "CLA means not a community project". There are quite a few people and companies that don't like CLAs (I work for one -- getting Intel to sign the Qt Project CLA took 8 months). Their existence is an understandable reason to not contribute to a project. But please don't say we're not a community. -- 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] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 21 July 2015 19:53:14 Gunnar Roth wrote: > Hi Ansel. > > > Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim : > > > > gives the Qt Project the freedom to take any and all submissions and > > incorporate them into the closed source version > > Do not mix up commercial license with closed source, all code you > contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules > AND the commercial license. Btw. It is not Qt Project , it is Qt Company. Note how it's copperspice._com_, not .org :) Will be interesting to see how they want to make money off their project. Or how they deal with the problem of relicensing once they grow to 200 instead of 2 developers... 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
Hi Ansel. > Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim : > > gives the Qt Project the freedom to take any and all submissions and > incorporate them into the closed source version Do not mix up commercial license with closed source, all code you contribute will be licensed under GPL,LGPL V2.1 or V3 for newer modules AND the commercial license. Btw. It is not Qt Project , it is Qt Company. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
We would like to announce our release of CopperSpice 1.1.0. We have added and changed several things including a modification to to QMap to user defined comparisons. We have a timeline others may be interested in viewing in our overview documentation. We will have API documentation uploaded by Aug 15. http://www.copperspice.com/docs/cs_overview/timeline.html Barbara spent a good deal of time reviewing the CLA for Qt. We appreciate the work Thiago and Lars have done on the CLA and contribution guidelines. On every thread she read and with people she spoke with, there was always several who expressed concerns. We even had a nice chat with Tobias Hunger about this issue. Our view as well as the view from many other developers, is that the CLA gives the Qt Project the freedom to take any and all submissions and incorporate them into the closed source version. We feel this goes against the share and share alike principle of community based open source software. From the countless local developers in the Silicon Valley area we have communicated with, Qt is not typically viewed as a community project. There is nothing inherently wrong with this approach, it just did not fit our paradigm. We are speaking at CPPCon in September and our intent is simply to explain the CLA did not work for us. The main purpose of our presentation is to present CopperSpice and offer C++ developers an alternative GUI library. Ansel On 7/3/15 12:52 AM, Simon Hausmann wrote: > On Monday, June 29, 2015 10:51:25 PM Ansel Sermersheim wrote: >>> There is always CopperSpice the Qt fork which uses C++11. They've >>> got rid of moc and plan to replace Qt containers with std ones. >>> Afterwards maybe they will add support for namespaces to their >>> peppermill source convertor utility. >> I am one of the developers of CopperSpice and I would like to >> elaborate on our project. Our initial release of CopperSpice was in >> July 2014 with our target audience being our local C++ Users Group in >> the San Francisco Bay area. We wanted to explore the interest in >> CopperSpice and obtain feedback regarding the steps we took to remove >> moc. Our full presentation in February 2015 was well received and >> attended by several prominent people. > I for one welcome your efforts. I think it's great that you're trying out new > things on the shoulders of Qt. To me this feels healthy and I'm at this point > not worried about fragmentation. Experimentation is something we should > encourage, even if those experiments happen in deep core parts of the > framework. I'm also glad to see that you're sharing your work with the rest of > the development community on github. > > It would be great if some of your improvements, some of your innovations could > - in the future - find their way back to Qt. It's not evident at this point > how exactly, but I think it would be good to keep it in the back of our heads. > > > That said, I did see the slides of your presentation in February 2015 and I am > disappointed about the slide with the heading "Why we developed CopperSpice". > It says that one of the reasons was that "Libraries not developed as a true > open source project". This is disappointing for me to read. Thiago, Lars and > others who have worked on the governance rules of Qt have done tremendous work > to establish the true open source umbrella, especially by learning from other > projects and taking the experience into account when formulating the > contribution and governance guidelines. > > I hope that in future presentations of your project you are not going to give > your audience the impression that Qt is not a true open source project. > > > Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote: > The only compiler I currently know that will have problems with this is the > Intel compiler on OS X when using libc++ older than Subversion r215305. > Unfortunately, _LIBCPP_VERSION has been at value 1101 since way before that > change. To restore functionality, I will revert > 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev. Upon further investigation, it turns out that ICC has worked around the libc++ problem since version 15.0 by providing its own std::atomic implementation when __clang__ is defined (probably a mistake and should have been a check for _LIBCPP_VERSION). However, its implementation is broken. I've just reported two bugs against version 16.0 beta. One bug can be easily worked around[1] but the other[2] isn't easy. I've made sure to report that one as a Critical issue, so let's hope there's an update released, fixing the issue, before 5.7 is out. [1] Issue id 6000117277: std::atomic's constructor is missing "constexpr". Note how libc++'s outside of Clang is too (https://llvm.org/bugs/show_bug.cgi?id=24114) [2] Issue id 6000117300: std::atomic and std::atomic fail to compile. Can be fixed by a one-line change, casting to (void*). We hit both cases in QtCore: qlogging.cpp: static QBasicAtomicPointer msgHandler = Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler); qobject_p.h: QAtomicPointer argumentTypes; -- 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] Qt LTS & C++11 plans
On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote: > Qt 5.6: > > * We make 5.6 a long term supported release > * We still support C++98 compilers in this release (for the last time), > i.e. We keep the 5.5 compiler baseline > * WEC7 will be still supported > * QNX 6.5 is not supported anymore > * Qt Quick1 and Qt WebKit are not part of the release (but we test that > the sources compile against 5.6) > * We keep Qt Script for this release, it’ll be gone in 5.7 as well Summary of changes: https://codereview.qt-project.org/121026C++11 default in user applications https://codereview.qt-project.org/121141Enable C++14 or C++1z in Qt itself https://codereview.qt-project.org/121142Drop QNX 6.5 and libstdc++/OS X https://codereview.qt-project.org/121145Remove macx-g++* mkspecs > Qt 5.7: > > * New compiler baseline with gcc 4.7 and VC++ 2012 > * Enable and use the C++11 features supported by these compilers > unconditionally > * WEC7 not supported anymore, WEC2013 supported > * Probably remove support for older Android, Mac and Linux versions as > well (to be discussed) https://codereview.qt-project.org/121144Require C++11 atomics (except MSVC) https://codereview.qt-project.org/121146Remove support for MSVC < 2012 https://codereview.qt-project.org/121147Remove -no-c++11 option -- 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] Qt LTS & C++11 plans
On Wednesday 08 July 2015 14:53:23 Thiago Macieira wrote: > On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote: > > So here's the plan: > > * Qt 5.6: will use std::atomic, if available > > * Qt 5.7: will use std::atomic unconditionally > > Well, first snag: MSVC has no support for constexpr, so it won't work. > > The above should read then: > * Qt 5.7: will use std::atomic unconditionally, except with MSVC Done. The 5.7 commit is available for comment: https://codereview.qt-project.org/121144 -- 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] Qt LTS & C++11 plans
On Wednesday 08 July 2015 13:42:12 Thiago Macieira wrote: > So here's the plan: > * Qt 5.6: will use std::atomic, if available > * Qt 5.7: will use std::atomic unconditionally Well, first snag: MSVC has no support for constexpr, so it won't work. The above should read then: * Qt 5.7: will use std::atomic unconditionally, except with MSVC -- 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] Qt LTS & C++11 plans
On Wednesday 08 July 2015 13:43:16 Thiago Macieira wrote: > On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote: > > Qt 5.6: > > > > * We make 5.6 a long term supported release > > * We still support C++98 compilers in this release (for the last time), > > i.e. We keep the 5.5 compiler baseline > > * WEC7 will be still supported > > * QNX 6.5 is not supported anymore > > * Qt Quick1 and Qt WebKit are not part of the release (but we test that > > the sources compile against 5.6) > > * We keep Qt Script for this release, it’ll be gone in 5.7 as well > > Another thing: we should turn on C++11 support by default for user > applications as of 5.6. > > You can undo this by: > > CONFIG -= c++11 > > You can add this now to your code. https://codereview.qt-project.org/121023 https://codereview.qt-project.org/121022 I was nice made -std=gnu++11 the default instead of -std=c++11 :-) -- 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] Qt LTS & C++11 plans
On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote: > Qt 5.6: > > * We make 5.6 a long term supported release > * We still support C++98 compilers in this release (for the last time), > i.e. We keep the 5.5 compiler baseline > * WEC7 will be still supported > * QNX 6.5 is not supported anymore > * Qt Quick1 and Qt WebKit are not part of the release (but we test that > the sources compile against 5.6) > * We keep Qt Script for this release, it’ll be gone in 5.7 as well Another thing: we should turn on C++11 support by default for user applications as of 5.6. You can undo this by: CONFIG -= c++11 You can add this now to your code. -- 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] Qt LTS & C++11 plans
On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote: > Qt 5.7: > > * New compiler baseline with gcc 4.7 and VC++ 2012 > * Enable and use the C++11 features supported by these compilers > unconditionally BTW, there's one more C++11 feature I'd like to use unconditionally starting in Qt 5.7: atomics. They've been supported since Clang 3.1, ICC 13.0, GCC 4.7, MSVC 2012. This is needed because our assembly apparently has problems, as in QTBUG-46949 (see especially https://bugreports.qt.io/browse/QTBUG-46949?focusedCommentId=285873#comment-285873 ). I don't want to maintain non-x86 assembly anymore. So here's the plan: * Qt 5.6: will use std::atomic, if available * Qt 5.7: will use std::atomic unconditionally In any case, this is a net improvement: ArchQt assembly GCC 4.9 atomics All all are lock-free all sizes are supported ARMv5 4-byte only, Linux-only out-of-line, lock-free on Linux ARMv6 4-byte only 4-byte inline, others out-of-line ARMv7A, v7M, v8 all sizes all sizes inline and lock-free IA-64 all sizes all sizes inline and lock-free MIPS32 4-byte only 1 through 4 bytes inline MIPS64 4- and 8-bytes only all sizes inline and lock-free x86 1-4 bytes only all sizes inline and lock-free x86-64 all sizes all sizes inline and lock-free There is no case where the Qt inline, lock-free assembly would be replaced by non-lock-free code. On ARMv5, there's a slight drop in performance as the inline assembly is replaced by an out-of-line function call, that's all. Any architecture not listed above (notably AArch64) is only supported by qatomic_cxx11.h and qatomic_gcc.h, so either this is a no-op for them, or net improvement by supporting more sizes and not doing a full barrier. I've only tested with GCC 4.9. I'm pretty sure support in GCC 4.8 is the same. However, GCC 4.7 is not very good at atomics anywhere except on x86. I don't care. You can easily upgrade to 4.8 to get better (non-full barrier for everything) performance. The only compiler I currently know that will have problems with this is the Intel compiler on OS X when using libc++ older than Subversion r215305. Unfortunately, _LIBCPP_VERSION has been at value 1101 since way before that change. To restore functionality, I will revert 1b961e8b5d508d054e31c0050f27891606714393 after 5.6 branches off from dev. -- 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] Qt LTS & C++11 plans (CopperSpice)
On Friday 03 July 2015 09:42:54 Milian Wolff wrote: > The above statement is far to broad to leave it uncommented. First, and > foremost, the only place where Qt does not play nicely with smart pointers > are QObject-inherited classes. This is true, but at the same time not a > big deal as its parent-child ownership model has proven itself over the > past twenty years. I'm not saying it's better than smart pointers, just > that it's not much different. And furthermore, Qt is so much more than > QObject inherited classes, and your own types in an application are also > only QObjects if really necessary. All of the rest you can put into smart > pointers if you want to, and Qt even offers it own fair share of smart > pointers that are being used internally and externally (i.e. for C++98 > projects). That said, there are a couple of places where smart use of smart pointers could improve Qt API. For example, a lot of I/O code takes a QIODevice*, but does not transfer ownership. Which means those classes often have a getter that gives you that QIODevice *. The problem is that there are other places that are QIODevice factories, like QNAM (QNetworkReply). Is there anything that would help people know when a pointer's ownership is transferred instead of just the documentation? Probably std::unique_ptr. -- 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] Qt LTS & C++11 plans (CopperSpice)
> > > Bo Thorsen sayeth: > This answer is going to be one big IMHO. > > Anything that stops people from throwing shared pointers all over the > code is A Good Thing. As someone once said: Shared pointers are a > solution in search of a problem. > > Scoped pointers are fine, but shared pointers indicate a lack of > handling of responsibility and ownership, which indicates bad design. > This. Thank you, Bo. We regularly see issues with "new-grads" that seem to think that naked pointers should no longer exist, and all things should be std::unique_ptr or std::shared_ptr. OMFG. My assertion is that Design is: (1) What objects should exist. (2) Who owns them. (3) There is no "Number Three" ...and, we almost never have a good reason to use shared pointers. For you to use this as a reason for forking Qt is a very bad indication. > I'm curious how much of the CopperSpice motivation is this, or other things like signals-on-templates and removal of moc. (I no longer need signals-on-templates, but many years ago I thought I did.) I must say, some of the CopperSpice decisions are very clever (heavy use of preprocessor to generate unique IDs that would otherwise be handled by moc). I similarly thought the Woboq guys with their moc-removal approach was quite clever, and these are two very different examples of a "possible-future-direction-of-Qt" that I think is quite healthy for our community to discuss. I appreciate the CopperSpice guys talking about their decisions and rationale on their design approach, and hope they will remain active in these forums. It's quite clear to me that some of the very dramatic moves occuring in C++14/17, including possible modules, and some of the new TMP capabilities open up options that we never previously could consider. And, it seems that some of these patterns and directions remain somewhat "unexplored" or otherwise represent "new territory" for consideration. --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Monday, June 29, 2015 10:51:25 PM Ansel Sermersheim wrote: > > There is always CopperSpice the Qt fork which uses C++11. They've > > got rid of moc and plan to replace Qt containers with std ones. > > Afterwards maybe they will add support for namespaces to their > > peppermill source convertor utility. > > I am one of the developers of CopperSpice and I would like to > elaborate on our project. Our initial release of CopperSpice was in > July 2014 with our target audience being our local C++ Users Group in > the San Francisco Bay area. We wanted to explore the interest in > CopperSpice and obtain feedback regarding the steps we took to remove > moc. Our full presentation in February 2015 was well received and > attended by several prominent people. I for one welcome your efforts. I think it's great that you're trying out new things on the shoulders of Qt. To me this feels healthy and I'm at this point not worried about fragmentation. Experimentation is something we should encourage, even if those experiments happen in deep core parts of the framework. I'm also glad to see that you're sharing your work with the rest of the development community on github. It would be great if some of your improvements, some of your innovations could - in the future - find their way back to Qt. It's not evident at this point how exactly, but I think it would be good to keep it in the back of our heads. That said, I did see the slides of your presentation in February 2015 and I am disappointed about the slide with the heading "Why we developed CopperSpice". It says that one of the reasons was that "Libraries not developed as a true open source project". This is disappointing for me to read. Thiago, Lars and others who have worked on the governance rules of Qt have done tremendous work to establish the true open source umbrella, especially by learning from other projects and taking the experience into account when formulating the contribution and governance guidelines. I hope that in future presentations of your project you are not going to give your audience the impression that Qt is not a true open source project. Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Thursday, July 02, 2015 10:09:13 PM Ansel Sermersheim wrote: > On 7/2/15 2:23 PM, Milian Wolff wrote: > > On Thursday 02 July 2015 23:00:43 Bernhard wrote: > >> Unfortunately adding signals of the template’s type is exactly what I > >> would > >> have needed several times. In that case there is no clean solution. I > >> once > >> added QVariant based signals as a workaround but that was ridiculous. In > >> modern times having powerful C++ generic programming features it is a > >> shame > >> that QObject doesn’t support this. IMHO this is one of the features (like > >> C++11) that need to be introduced in Qt as fast as possible if it should > >> not appear old-fashioned soon. > > > > You can use C++11 (and even C++14 and newer) with Qt just fine. Heck, it > > even uses a lot of C++11 features internally. So what exactly do you mean > > by the above? > > Yes, you can use C++11 in your application. Our viewpoint is that Qt > developers should be able to use C++11 internally in the project. They > are slated to allow most of C++11 like decltype, rvalue references, and > lambdas in 2016. However, things like constexpr will still not be allowed. What was your reasoning behind forking the archaic Qt 4 instead of a recent Qt 5 which already uses a ton of C++11? Esp. note how it does use constexpr when available for many value types, thanks to the hard work by Marc. Also, considering that you were not working on the internals of Qt (or did you?), I find your reasoning above highly amusing. Forking Qt just to use C+ +11 for its internal development won't give users of the framework any value (quite the contrary, as Thiago pointed out many times). Also, as it's a fork, it won't affect us Qt developers at all, as we will stick to the original. > More importantly, there are many features of C++11 you cannot use in > your application like smart pointers. Ok, you can use them, but you > cannot use them to interact with Qt. To a modern C++ programmer this > comes across as a significant limitation. The above statement is far to broad to leave it uncommented. First, and foremost, the only place where Qt does not play nicely with smart pointers are QObject-inherited classes. This is true, but at the same time not a big deal as its parent-child ownership model has proven itself over the past twenty years. I'm not saying it's better than smart pointers, just that it's not much different. And furthermore, Qt is so much more than QObject inherited classes, and your own types in an application are also only QObjects if really necessary. All of the rest you can put into smart pointers if you want to, and Qt even offers it own fair share of smart pointers that are being used internally and externally (i.e. for C++98 projects). Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
Den 03-07-2015 kl. 07:09 skrev Ansel Sermersheim: > > > On 7/2/15 2:23 PM, Milian Wolff wrote: >> On Thursday 02 July 2015 23:00:43 Bernhard wrote: >>> Unfortunately adding signals of the template’s type is exactly what I would >>> have needed several times. In that case there is no clean solution. I once >>> added QVariant based signals as a workaround but that was ridiculous. In >>> modern times having powerful C++ generic programming features it is a shame >>> that QObject doesn’t support this. IMHO this is one of the features (like >>> C++11) that need to be introduced in Qt as fast as possible if it should >>> not appear old-fashioned soon. >> >> You can use C++11 (and even C++14 and newer) with Qt just fine. Heck, it even >> uses a lot of C++11 features internally. So what exactly do you mean by the >> above? > > Yes, you can use C++11 in your application. Our viewpoint is that Qt > developers should be able to use C++11 internally in the project. They > are slated to allow most of C++11 like decltype, rvalue references, and > lambdas in 2016. However, things like constexpr will still not be allowed. > > More importantly, there are many features of C++11 you cannot use in > your application like smart pointers. Ok, you can use them, but you > cannot use them to interact with Qt. To a modern C++ programmer this > comes across as a significant limitation. This answer is going to be one big IMHO. Anything that stops people from throwing shared pointers all over the code is A Good Thing. As someone once said: Shared pointers are a solution in search of a problem. Scoped pointers are fine, but shared pointers indicate a lack of handling of responsibility and ownership, which indicates bad design. For you to use this as a reason for forking Qt is a very bad indication. Bo. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Thursday 02 July 2015 22:09:13 Ansel Sermersheim wrote: > Yes, you can use C++11 in your application. Our viewpoint is that Qt > developers should be able to use C++11 internally in the project. They > are slated to allow most of C++11 like decltype, rvalue references, and > lambdas in 2016. However, things like constexpr will still not be allowed. You have Microsoft to thank for that. Dropping something like 40% of our userbase is not worth constexprs. > More importantly, there are many features of C++11 you cannot use in > your application like smart pointers. Ok, you can use them, but you > cannot use them to interact with Qt. To a modern C++ programmer this > comes across as a significant limitation. On the other hand, existing Qt programmers will feel right at home and their existing applications will continue to run. -- 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] Qt LTS & C++11 plans (CopperSpice)
On 7/2/15 2:23 PM, Milian Wolff wrote: > On Thursday 02 July 2015 23:00:43 Bernhard wrote: >> Unfortunately adding signals of the template’s type is exactly what I would >> have needed several times. In that case there is no clean solution. I once >> added QVariant based signals as a workaround but that was ridiculous. In >> modern times having powerful C++ generic programming features it is a shame >> that QObject doesn’t support this. IMHO this is one of the features (like >> C++11) that need to be introduced in Qt as fast as possible if it should >> not appear old-fashioned soon. > > You can use C++11 (and even C++14 and newer) with Qt just fine. Heck, it even > uses a lot of C++11 features internally. So what exactly do you mean by the > above? Yes, you can use C++11 in your application. Our viewpoint is that Qt developers should be able to use C++11 internally in the project. They are slated to allow most of C++11 like decltype, rvalue references, and lambdas in 2016. However, things like constexpr will still not be allowed. More importantly, there are many features of C++11 you cannot use in your application like smart pointers. Ok, you can use them, but you cannot use them to interact with Qt. To a modern C++ programmer this comes across as a significant limitation. Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Thursday 02 July 2015 23:00:43 Bernhard wrote: > Unfortunately adding signals of the template’s type is exactly what I would > have needed several times. Then you should have used Boost.Signals. Qt is not the only C++ library out there, and asking it to be everything for everyone is unreasonable. That said, in my experience, if you want signals on templates, you're usually going it wrong. You probably intend to use it far away from the GUI layout, maybe even in your cenral data model (!= QAbstractItemModel here). Overuse of signal-slots can make a program very hard to understand, and possibly also slow. If you don't believe, I invite you to study pre-Akonadi KMail code. 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On 7/2/15 2:00 PM, Bernhard wrote: > Unfortunately adding signals of the template’s type is exactly what I > would have needed several times. In that case there is no clean > solution. I once added QVariant based signals as a workaround but that > was ridiculous. In modern times having powerful C++ generic programming > features it is a shame that QObject doesn’t support this. IMHO this is > one of the features (like C++11) that need to be introduced in Qt as > fast as possible if it should not appear old-fashioned soon. This is exactly one of the major reasons that we started CopperSpice. When working with the Model/View framework there are many situations where one wants to use a templated model. It's possible to get the same end result with some creative use of multiple inheritance, but it is a very unpleasant hack. Given several comments we have seen, it sounds like this is not the direction Qt is going for many years if at all. Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Thursday 02 July 2015 23:00:43 Bernhard wrote: > Unfortunately adding signals of the template’s type is exactly what I would > have needed several times. In that case there is no clean solution. I once > added QVariant based signals as a workaround but that was ridiculous. In > modern times having powerful C++ generic programming features it is a shame > that QObject doesn’t support this. IMHO this is one of the features (like > C++11) that need to be introduced in Qt as fast as possible if it should > not appear old-fashioned soon. You can use C++11 (and even C++14 and newer) with Qt just fine. Heck, it even uses a lot of C++11 features internally. So what exactly do you mean by the above? Bye -- Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Thursday 02 July 2015 23:00:43 Bernhard wrote: > Unfortunately adding signals of the template’s type is exactly what I would > have needed several times. In that case there is no clean solution. I once > added QVariant based signals as a workaround but that was ridiculous. In > modern times having powerful C++ generic programming features it is a shame > that QObject doesn’t support this. IMHO this is one of the features (like > C++11) that need to be introduced in Qt as fast as possible if it should > not appear old-fashioned soon. The problem in doing this is how to create the meta object so that runtime reflection works. Using the template parameter(s) inside the class leads to HUGE complexity. Think of something horribly complex: you're probably only two orders of magnitude away from the real complexity. One way of doing this would be to drop the meta object and the runtime reflection. That would also get rid of QtScript, QtQml, QtDBus, ActiveQt, QtWebKit's registering of QObjects, etc. It's a complete non-starter. Another way is to do it like CopperSpice is doing, by way of boilerplate macros and manual runtime registration, at the expense of making the code (subjectively) harder to read and of runtime cost. Qt's current[1] meta object system is *entirely* read-only, shared memory, except for the QMetaObject structure itself, which is read-only data with local relocations[2]. This is much beyond pure C++: we're investigating performance, code size, data size, relocation count, etc. [1] Current, because it wasn't so before Qt 4. So you see that this has 15 years of learnings applied. [2] Local relocations, as opposed to global relocations, are much faster to resolve, as they have no symbol name to be looked up. Also, local relocations disappear on position-dependent code, which we'll get back to allowing once GCC introduces the necessary options. PS: I've just got an idea for getting rid of the relocations on Linux/x86-64... I need to check if there's a way of doing it before Qt 6. -- 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] Qt LTS & C++11 plans (CopperSpice)
Unfortunately adding signals of the template’s type is exactly what I would have needed several times. In that case there is no clean solution. I once added QVariant based signals as a workaround but that was ridiculous. In modern times having powerful C++ generic programming features it is a shame that QObject doesn’t support this. IMHO this is one of the features (like C++11) that need to be introduced in Qt as fast as possible if it should not appear old-fashioned soon. -- Kind Regards Bernhard Lindner Von: development-bounces+private=bernhard-lindner...@qt-project.org [mailto:development-bounces+private=bernhard-lindner...@qt-project.org] Im Auftrag von Julien Blanc Gesendet: Mittwoch, 1. Juli 2015 09:16 An: development@qt-project.org Betreff: Re: [Development] Qt LTS & C++11 plans (CopperSpice) Le mardi 30 juin 2015 à 22:37 +0200, Bernhard a écrit : > For example, with moc removed we support template classes that inherit > from QObject. Wow. I would (almost) kill for having that feature in Qt! You can work around it quite easily. What doesn’t work is adding new signals / slots inside a template class. So just add a base class declaring these signals/slots, and make your template class inherits from it. Unless you wan’t to use the template class as signal/slots arguments, this works fine. Regards, Julien ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Thursday 02 July 2015 17:48:59 Thiago Macieira wrote: > On Thursday 02 July 2015 10:44:14 Marc Mutz wrote: > > D-pointers are not called Compiler Firewalls for nothing. Just compare > > assembly generated from use of QColor (which doesn't even have a > > d-pointer, but is mostly out-of-line anyway) with that generated for > > QRgb. > > That's not a fair comparison. QRgb is not a class, it's a typedef to > unsigned int. It's equivalent to what a fully inline QColorRGB(A)8 should compile to, modulo compiler bugs. If you don't like the comparision to QRgb, s/QRgb/QRgba64/, which _is_ a class. 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Thursday 02 July 2015 10:44:14 Marc Mutz wrote: > D-pointers are not called Compiler Firewalls for nothing. Just compare > assembly generated from use of QColor (which doesn't even have a d-pointer, > but is mostly out-of-line anyway) with that generated for QRgb. That's not a fair comparison. QRgb is not a class, it's a typedef to unsigned int. -- 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] Qt LTS & C++11 plans
On Thursday 02 July 2015 03:02:51 Thiago Macieira wrote: > [*] getting a d pointer does not mean getting rid of the private members. > See the Qt 6 task for QDateTime, for example. It's also possible to have > classes with no d pointer, but you need to be absolutely sure there's no > chance of extension for the next 10 years. I would qualify it as "add a d-pointer if you envision further extensions that you could implement now but choose not to." Even so, always keep in mind that you can always create a new type instead of extending an existing one. Taking QColor as an example, it would have been perfectly ok (and even better design, imo) to start with QColorRGB8 and QColorHSV8, and when HSL support is added, make a new QColorHSL8, and with 16-bit support, add -16 classes. There's a reason QColor isn't used in low-level API (instead, QRgb is used), and that is its complexity (just look at op== if you don't believe). HSL or 16-bit support can anyway not be used by an app without active code changes, and thus a recompile. And if you want a color type as a black-box pass-through, you can use QVariant, or a more specialised QAnyColor. IMO, d-pointers should be added to polymorphic classes, because by their very nature, they can receive updates to behaviour without a user having to recompile. And else to value classes where you know there will be updates in the future, and having a separate class for it is not an option. D-pointers are not called Compiler Firewalls for nothing. Just compare assembly generated from use of QColor (which doesn't even have a d-pointer, but is mostly out-of-line anyway) with that generated for QRgb. For QColor, the optimiser is all but disabled. And this stuff matters. No-one is using C++ to get the performance they can have with Java or C#. And one of the advantages of C++ is that user-defined types can enjoy the performance of built-in types, and don't have to _be_ a compiler firewall. We have erred too much on the side of the d-pointer, in the past. We should be more conscious of its negative effects. At the same time, we have been very bad at creating small classes. Maybe because reviews would blindly ask for a d-pointer, then? I don't know. Those we have are pretty good, don't get me wrong. We just have too little of them. QGradientStop is a QPair. That's just lazy. It should be a struct { qreal step; QColor color }, or, maybe, because Q*Animation classes have the same need, a more generically-named { step, value }, so one can easily write them as templates: template struct QStop { qreal step; Value value; }; using QGradientStop = QStop; using QGraphicsItemAnimation::PositionStop = QStop; ... Nothing of the above contradicts Thiago in any way. It's just Qt's historic bias to lots of pimpls that I'd like to shift. 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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Wednesday 01 July 2015 21:03:21 Sune Vuorela wrote: > I think we mostly avoid QPair in api's (because it is generally not very > documenting in API). I don't see why std::tuple is any different. I agree with Sune here. Please create your struct with the types in question and proper names. And that's only for very simple structs. Anything more complex should get a d pointer[*] and become a value-type class. Examples: QNetworkAddressEntry, QNetworkCookie, etc. [*] getting a d pointer does not mean getting rid of the private members. See the Qt 6 task for QDateTime, for example. It's also possible to have classes with no d pointer, but you need to be absolutely sure there's no chance of extension for the next 10 years. -- 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] Qt LTS & C++11 plans
On 2015-06-26, Olivier Goffart wrote: > Can we have function that takes or return std::function, std::tuple, > std::unique_ptr, std::vector? While I can see the advantage of std::function, I'm not sure why we would use the remaining ones in API ? Thiago already mentioned that he didn't like std::vector. I think we mostly avoid QPair in api's (because it is generally not very documenting in API). I don't see why std::tuple is any different. /Sune ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
> > > For example, with moc removed we support template classes that inherit> > > from QObject. > > Wow. I would (almost) kill for having that feature in Qt! > > You can work around it quite easily. What doesn’t work is adding new > signals / slots inside a template class. So just add a base class declaring > these signals/slots, and make your template class inherits from it. > > Unless you wan’t to use the template class as signal/slots arguments, this > works fine. > > Regards, > > Julien > +1. I do that a lot: QObject <= MyClass <= MyTemplate <= MyClassDerived --charley ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
30.06.2015, 23:38, "Bernhard" : >> For example, with moc removed we support template classes that inherit >> from QObject. > > Wow. I would (almost) kill for having that feature in Qt! http://www.labri.fr/perso/guenneba/code/ppmoc.php No C++11 required (code was written in 2008 or earlier) -- Regards, Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
Le mardi 30 juin 2015 à 22:37 +0200, Bernhard a écrit : > > For example, with moc removed we support template classes that inherit > > from QObject. > > Wow. I would (almost) kill for having that feature in Qt! > You can work around it quite easily. What doesn’t work is adding new signals / slots inside a template class. So just add a base class declaring these signals/slots, and make your template class inherits from it. Unless you wan’t to use the template class as signal/slots arguments, this works fine. Regards, Julien ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Wednesday 01 July 2015 00:49:19 Olivier Goffart wrote: > On Tuesday 30. June 2015 22:37:24 Bernhard wrote: > > > For example, with moc removed we support template classes that inherit > > > from QObject. > > > > Wow. I would (almost) kill for having that feature in Qt! > > You can do that with moc. > > https://codereview.qt-project.org/49864/ > > There was a discussion about it on the mailinglist at the time, but nobody > expressed much interest in having that feature. The feature is probably affected by the -fvisibility-inlines-hidden issue too. -- 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] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 30 June 2015 19:40:55 Ansel Sermersheim wrote: > > Unless you're going to rewrite the entire GUI, widgets, networking and > > other libraries from scratch, you're not going to get exception-safety. > > Yes, many parts will need to be redone and we are starting with the > container classes. You may be underestimating the effort required. You'll need to spend a couple of man-decades of work to get this done... > >> These are some of the limitations that frustrated us when using Qt in an > >> existing codebase. > > > > You're making trade-offs. One of them, given your presentation, is that > > there's no current version of MSVC that will work with your codebase. > > Another is that you're replacing a code generator by a lot of boilerplate > > macros. > > We do not feel that requiring a compiler to support C++11 is > unreasonable. Our main issues with MSVC is with constexpr and expression > SFINAE. MS has added partial support of constexpr for MSVC 2015, > although they are still reported to have a few issues. They will get > there eventually. No word yet on when expression SFINAE will be added. And that's where we disagree. We feel that we have to be pragmatic and support compilers that people have access to. This is exactly why this thread started. I'm not saying you can't do what you're doing. I'm simply saying it's a trade- off. You're trading a potentially large userbase for the ability to use those C++11 features. > Yes, we make use of macros as macros were intended to be used. We > strongly believe the syntax for our macros is concise and clean, and > that this tradeoff is worthwhile. No doubt you do. But I still disagree. My opinion is that a code generator is far preferable to boilerplate macros. -- 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] Qt LTS & C++11 plans (CopperSpice)
On 6/30/15 1:01 PM, Thiago Macieira wrote: > On Tuesday 30 June 2015 09:37:59 Ansel Sermersheim wrote: >> Our goal with CopperSpice is to use modern C++ internally to leverage >> everything we can from the language. We want developers of CopperSpice >> applications to have the full power of C++ available in all parts of >> their code. For example, with moc removed we support template classes >> that inherit from QObject. We support passing method pointers as signal >> arguments. > > You need to use -fvisibility-inlines-hidden and retry. I don't think your > solution works under those circumstances. As we mentioned we have already changed parts of the CopperSpice registration system. This will be released within the next month or so. We are definitely aware of -fvisibility-inlines-hidden, and we will look into supporting it. >> We are going to fully support exceptions, and make >> exception safety guarantees where possible. > > Unless you're going to rewrite the entire GUI, widgets, networking and other > libraries from scratch, you're not going to get exception-safety. Yes, many parts will need to be redone and we are starting with the container classes. >> These are some of the limitations that frustrated us when using Qt in an >> existing codebase. > > You're making trade-offs. One of them, given your presentation, is that > there's > no current version of MSVC that will work with your codebase. Another is that > you're replacing a code generator by a lot of boilerplate macros. We do not feel that requiring a compiler to support C++11 is unreasonable. Our main issues with MSVC is with constexpr and expression SFINAE. MS has added partial support of constexpr for MSVC 2015, although they are still reported to have a few issues. They will get there eventually. No word yet on when expression SFINAE will be added. Yes, we make use of macros as macros were intended to be used. We strongly believe the syntax for our macros is concise and clean, and that this tradeoff is worthwhile. Ansel CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 30. June 2015 22:37:24 Bernhard wrote: > > For example, with moc removed we support template classes that inherit > > from QObject. > > Wow. I would (almost) kill for having that feature in Qt! You can do that with moc. https://codereview.qt-project.org/49864/ There was a discussion about it on the mailinglist at the time, but nobody expressed much interest in having that feature. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 30 June 2015 23:09:59 Cristian Adam wrote: > On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira > wrote: > > > > > > You're making trade-offs. One of them, given your presentation, is that > > there's > > no current version of MSVC that will work with your codebase. Another is > > that > > you're replacing a code generator by a lot of boilerplate macros. > > Visual Studio 2015 will have constexpr fixed [1] and it should compile > CopperSpice. It's still not working in MSVC 2015 RC1. I'd be wary of relying on RTM fixing it if it's still not fixed yet. > The replacement of qmake with autotools in CopperSpice makes things very > hard to > test with Visual Studio. It seems CMake is being under evaluation [2]. > > The combination of CMake and ninja is quite effective. Autotools is backwards direction. Everyone moves *away* from Autotools, not towards it (except people who had no buildsystem in the first place). -- 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] Qt LTS & C++11 plans (CopperSpice)
On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira wrote: > > You're making trade-offs. One of them, given your presentation, is that > there's > no current version of MSVC that will work with your codebase. Another is > that > you're replacing a code generator by a lot of boilerplate macros. > > Visual Studio 2015 will have constexpr fixed [1] and it should compile CopperSpice. The replacement of qmake with autotools in CopperSpice makes things very hard to test with Visual Studio. It seems CMake is being under evaluation [2]. The combination of CMake and ninja is quite effective. Cheers, Cristian. [1] http://blogs.msdn.com/b/vcblog/archive/2015/04/29/c-11-14-17-features-in-vs-2015-rc.aspx [2] http://forum.copperspice.com/viewtopic.php?f=10&t=7 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
> For example, with moc removed we support template classes that inherit > from QObject. Wow. I would (almost) kill for having that feature in Qt! -- Regards Bernhard Lindner ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Tuesday 30 June 2015 18:16:34 Olivier Goffart wrote: > On Friday 26. June 2015 08:41:11 Thiago Macieira wrote: > > On Friday 26 June 2015 11:59:11 Olivier Goffart wrote: > > > However, it is questionable if even this works. We already rely on the > > > standard library ABI in QException. And most users will have to > > > recompile > > > everything if they want to change standard library anyway. > > > > std::exception is compatible between libc++ and libstdc++, so that doesn't > > count. > > Ok. (But by luck... another version might not) s/luck/design/ > Anyway, you did not answer the actual question. Are you against changing the > policy or not? I am, for several reasons. For the container types, please use the Qt ones, for API consistency and familiarity. I don't want to see API using std::vector, period. Since we're talking about *ABI*, it stands to reason we're talking about mandatory features, so outside of any #ifdefs that may change between Qt's build and the user application's. That means any such feature depending on a C++11 library feature should be protected by a configure-time check and a #define in qconfig.h. Given our horrible configure script and configure.exe source code, writing such checks are difficult and time-consuming. More likely than not, we'll get it wrong. And finally, I am against it because libc++ and libstdc++ co-existence is still a goal, even on OS X. -- 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] Qt LTS & C++11 plans (CopperSpice)
On Tuesday 30 June 2015 09:37:59 Ansel Sermersheim wrote: > Our goal with CopperSpice is to use modern C++ internally to leverage > everything we can from the language. We want developers of CopperSpice > applications to have the full power of C++ available in all parts of > their code. For example, with moc removed we support template classes > that inherit from QObject. We support passing method pointers as signal > arguments. You need to use -fvisibility-inlines-hidden and retry. I don't think your solution works under those circumstances. > We are going to fully support exceptions, and make > exception safety guarantees where possible. Unless you're going to rewrite the entire GUI, widgets, networking and other libraries from scratch, you're not going to get exception-safety. > We are working on > redesigning the QObject lifetime model so that it works smoothly with > C++11 smart pointers. I researched that 4 or 5 years ago and I found two problems: First, you must either choose to use smart pointers everywhere or not at all. You can't pick and choose, which is what caused most of the problems. Second, and most importantly, all the QWidget-derived classes share state with their parent widgets. You MUST delete the children when the parent is getting deleted, which is incompatible with smart pointers. Like I said above for exceptions, you'll need to redesign the entire stack to get support for smart pointers here. > These are some of the limitations that frustrated us when using Qt in an > existing codebase. You're making trade-offs. One of them, given your presentation, is that there's no current version of MSVC that will work with your codebase. Another is that you're replacing a code generator by a lot of boilerplate macros. And, critically, like I mentioned above, is that I don't think your solution works with -fvisibility-inlines-hidden, due to taking and comparing addresses of inline functions. -- 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] Qt LTS & C++11 plans (CopperSpice)
On 6/29/15 11:37 PM, Alejandro Exojo wrote: > El Tuesday 30 June 2015, Ansel Sermersheim escribió: >> Our September release of CopperSpice will include changes to the >> contain library, reimplementation of atomic types, our new changes >> to the MetaObject System registration, full API documentation, ?? >> >> We would like to encourage developers to attend CPPCon to learn >> about modern C++ and where it is going. For more information please >> check out the following video. >> >> http://cppcon.org/2015promo/ > > Can you explain which are your long term plans? Given that you > renamed all the classes and modules (or so I understood), this is > full source incompatible, and it doesn't seem like you want to sync > again with the original Qt (applications might include a large file > full of typedefs, but applying to CopperSpice any bugfix patch found > in Qt seems completely manual). Some developers experiment with > their own branches to research or have fun, which is great, but > seems like you are aiming to be a full new project. We renamed the libraries to avoid naming conflicts with the Qt libraries when CS and Qt are installed on the same system. We have not renamed the classes, and our intention is to keep source compatibility as much as possible. Some incompatible changes were unavoidable, particularly the signal / slot declaration syntax. Our goal with CopperSpice is to use modern C++ internally to leverage everything we can from the language. We want developers of CopperSpice applications to have the full power of C++ available in all parts of their code. For example, with moc removed we support template classes that inherit from QObject. We support passing method pointers as signal arguments. We would like to support multiple inheritance properly. We would like the CsGui classes to work seamlessly with STL containers, and to add things like reverse iterators to the CS container library to bring it in line with the STL. We are going to fully support exceptions, and make exception safety guarantees where possible. We are working on redesigning the QObject lifetime model so that it works smoothly with C++11 smart pointers. These are some of the limitations that frustrated us when using Qt in an existing codebase. Thank you very much for your question, Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Friday 26. June 2015 08:41:11 Thiago Macieira wrote: > On Friday 26 June 2015 11:59:11 Olivier Goffart wrote: > > However, it is questionable if even this works. We already rely on the > > standard library ABI in QException. And most users will have to recompile > > everything if they want to change standard library anyway. > > std::exception is compatible between libc++ and libstdc++, so that doesn't > count. Ok. (But by luck... another version might not) Anyway, you did not answer the actual question. Are you against changing the policy or not? -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
El Tuesday 30 June 2015, Ansel Sermersheim escribió: > Our September release of CopperSpice will include changes to the > contain library, reimplementation of atomic types, our new changes to > the MetaObject System registration, full API documentation, ?? > > We would like to encourage developers to attend CPPCon to learn about > modern C++ and where it is going. For more information please check > out the following video. > > http://cppcon.org/2015promo/ Can you explain which are your long term plans? Given that you renamed all the classes and modules (or so I understood), this is full source incompatible, and it doesn't seem like you want to sync again with the original Qt (applications might include a large file full of typedefs, but applying to CopperSpice any bugfix patch found in Qt seems completely manual). Some developers experiment with their own branches to research or have fun, which is great, but seems like you are aiming to be a full new project. -- Alex (a.k.a. suy) | GPG ID 0x0B8B0BC2 http://barnacity.net/ | http://disperso.net ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On 6/29/15 10:59 PM, Thiago Macieira wrote: > On Monday 29 June 2015 22:51:25 Ansel Sermersheim wrote: >> I would like to clarify, we did not use anything from the Woboq >> blog posting as others have speculated. We had moc removed from >> CopperSpice a year earlier than the release of this blog. We are >> also not associated with the Trinity Project. > > Out of curiosity: > > You've removed moc, but what's your replacement for rcc? I hope I understand your question correctly. By removing moc and not using qmake, we were able to remove all the bootstrap code from CsCore. This allowed us to build rcc simply linking with CsCore. We did not see any reason to replace rcc at this time. Our goal was to allow developers to use CopperSpice without altering their build systems. Since the resource system is not mandatory we did not feel like an alternative to rcc was required. >> We would like to encourage developers to attend CPPCon to learn >> about > > Maybe Meeting C++ will get better luck. Most of the Qt developers > live in Europe. I encourage you to submit your session there. > > By the way, you're also welcome to discuss your ideas in this mailing > list. We're not against new C++ techniques, but we want to support > existing deployments, so we have to be a little more pragmatic on our > choices. > Thank you for your warm welcome and encouragement. Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans (CopperSpice)
On Monday 29 June 2015 22:51:25 Ansel Sermersheim wrote: > I would like to clarify, we did not use anything from the Woboq blog > posting as others have speculated. We had moc removed from CopperSpice > a year earlier than the release of this blog. We are also not > associated with the Trinity Project. Out of curiosity: You've removed moc, but what's your replacement for rcc? > We would like to encourage developers to attend CPPCon to learn about Maybe Meeting C++ will get better luck. Most of the Qt developers live in Europe. I encourage you to submit your session there. By the way, you're also welcome to discuss your ideas in this mailing list. We're not against new C++ techniques, but we want to support existing deployments, so we have to be a little more pragmatic on our choices. -- 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] Qt LTS & C++11 plans (CopperSpice)
> There is always CopperSpice the Qt fork which uses C++11. They've > got rid of moc and plan to replace Qt containers with std ones. > Afterwards maybe they will add support for namespaces to their > peppermill source convertor utility. I am one of the developers of CopperSpice and I would like to elaborate on our project. Our initial release of CopperSpice was in July 2014 with our target audience being our local C++ Users Group in the San Francisco Bay area. We wanted to explore the interest in CopperSpice and obtain feedback regarding the steps we took to remove moc. Our full presentation in February 2015 was well received and attended by several prominent people. Our intent was to formally announce CopperSpice at CPPCon in September. Oddly, once we submitted a proposal for speaking at CPPCon, someone in Europe decided to post information about CopperSpice on reddit. As of today I can announce we have been approved to speak about CopperSpice at CPPCon. The current version of CopperSpice supports the full Qt Metaobject System, requires C++11, and includes CsCore, CsGui, CsPhonon, as well as CsScript, and CsWebkit. We have CsDBus partially ported, however more time has been spent on other libraries. It will be available in our September release. I would like to clarify, we did not use anything from the Woboq blog posting as others have speculated. We had moc removed from CopperSpice a year earlier than the release of this blog. We are also not associated with the Trinity Project. As a consequence of our presentation in February we have modified parts of the internal registration code to better implement reflection. We will be making a few more changes before this is released. Our September release of CopperSpice will include changes to the contain library, reimplementation of atomic types, our new changes to the MetaObject System registration, full API documentation, ?? We would like to encourage developers to attend CPPCon to learn about modern C++ and where it is going. For more information please check out the following video. http://cppcon.org/2015promo/ Our thanks go out to Trolltech, Nokia, and Digia for all the work they have done. Ansel Sermersheim CopperSpice Co-Founder www.copperspice.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
Il 29/06/2015 02:02, Thiago Macieira ha scritto: SNIP >> In fact, it is already a big problem for us that it is being deprecated at >> all. QtWebEngine is not an adequate replacement, neither for developers >> (insufficient API), nor for packagers (bundling Chromium that itself bundles >> dozens of libraries makes this a completely unacceptable package for at >> least Fedora and Debian). But even if it were, applications are not going >> to be ported to it overnight. > Chromium devs are willing to talk about unbundling. Have you reached out to > them? > sorry for the intrusion, about unbundling a good number of bundled libraries can be unbundled, gentoo do this, search "remove_bundled_libraries.py" in the following ebuild (bash script) https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/chromium/chromium-45.0.2438.3.ebuild most but not _all_ are libs are unbundled, maybe more hands on problem could help reaching perfection ;) good luck SNIP ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Monday 29 June 2015 01:22:17 Kevin Kofler wrote: > GNU/Linux distributions will require QtWebKit to keep compiling for a LONG > time to go. You'd do everyone a service and stop that soon, as shipping a web engine that is not receiving security updates is a dangerous thing to do. Applications that depend on it will need to be ported away from it or dropped from the repository, unfortunately. > In fact, it is already a big problem for us that it is being deprecated at > all. QtWebEngine is not an adequate replacement, neither for developers > (insufficient API), nor for packagers (bundling Chromium that itself bundles > dozens of libraries makes this a completely unacceptable package for at > least Fedora and Debian). But even if it were, applications are not going > to be ported to it overnight. Chromium devs are willing to talk about unbundling. Have you reached out to them? > We cannot just ship the LTS Qt because some applications will definitely > require the latest Qt, and having 2 different Qt 5.x versions around is NOT > going to work. Unlike the average application developer, we have MANY > applications and libraries to care about, and they need to be able to work > together. Fortunately, you will be able to compile QtWebKit and QtScript 5.6 with some future versions of Qt. As long as someone is testing then and supplying build fixes, it should work. QtQuick1 will stop working soon after 5.6 due to its immense use of Qt private API. -- 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] Qt LTS & C++11 plans
Bo Thorsen wrote: > With an LTS release that has almost all of the modules of the Qt 5 > lifetime, I'd be fine with dropping the compilation requirements of > webkit and quick1 from 5.7. > > IMO that's the benefit that an LTS support should give - to allow us to > completely drop support for old modules. This gives the option of > shifting resources from keeping f.e. webkit compiling with the latest > version to keeing it running with the LTS release. GNU/Linux distributions will require QtWebKit to keep compiling for a LONG time to go. In fact, it is already a big problem for us that it is being deprecated at all. QtWebEngine is not an adequate replacement, neither for developers (insufficient API), nor for packagers (bundling Chromium that itself bundles dozens of libraries makes this a completely unacceptable package for at least Fedora and Debian). But even if it were, applications are not going to be ported to it overnight. We cannot just ship the LTS Qt because some applications will definitely require the latest Qt, and having 2 different Qt 5.x versions around is NOT going to work. Unlike the average application developer, we have MANY applications and libraries to care about, and they need to be able to work together. Kevin Kofler ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Friday 26 June 2015 11:59:11 Olivier Goffart wrote: > However, it is questionable if even this works. We already rely on the > standard library ABI in QException. And most users will have to recompile > everything if they want to change standard library anyway. std::exception is compatible between libc++ and libstdc++, so that doesn't count. -- 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] Qt LTS & C++11 plans
On Friday 26 June 2015 06:12:53 Al-Khanji Louai wrote: > What they did was to move registration of meta object content to runtime. > They basically have structs with static variables and they rely on > initialization of these variables at program start-up. It's a lot of macro > magic and relies on things like __LINE__ to create unique tokens. > > The info above is based on this presentation, the meta object stuff is > covered from slide 20 onwards: > https://docs.google.com/presentation/d/1Sxei-Em6cnYbE0Zj16j6gwF4SIvGJIE_1tb > 4P78RN3o/edit?usp=sharing I see, thanks. It doesn't work with -fvisibility-inlines-hidden. -- 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] Qt LTS & C++11 plans
On Tuesday 23. June 2015 10:17:40 Knoll Lars wrote: > Qt 5.6: > > * We make 5.6 a long term supported release > * We still support C++98 compilers in this release (for the last time), > i.e. We keep the 5.5 compiler baseline > * WEC7 will be still supported > * QNX 6.5 is not supported anymore > * Qt Quick1 and Qt WebKit are not part of the release (but we test that > the sources compile against 5.6) > * We keep Qt Script for this release, it’ll be gone in 5.7 as well > > Qt 5.7: > > * New compiler baseline with gcc 4.7 and VC++ 2012 > * Enable and use the C++11 features supported by these compilers > unconditionally > * WEC7 not supported anymore, WEC2013 supported > * Probably remove support for older Android, Mac and Linux versions as > well (to be discussed) +1 There is another point we need to decide on (for Qt 5.7), is whether or not we relax the policy not to use the standard library in our ABI. Can we have function that takes or return std::function, std::tuple, std::unique_ptr, std::vector? Currently we don't allow it, and this makes it possible to change the underlying standard library without breaking binary compatibility. (Qt can link to one standard library, and the application to another. Or, if they use inline namespace, the namespace can change provided that both old and new symbols are still in the library.) However, it is questionable if even this works. We already rely on the standard library ABI in QException. And most users will have to recompile everything if they want to change standard library anyway. We currently do not have a general purpose std::function (there is QtPrivate::QSlotObjectBase, but it is not as good as std::function implementations). I believe it is better to use std::function than trying to reinvent our own. So should we allow standard library types in our ABI? Nobody seemed to be opposed in the "Notes from Modern C++ session" thread. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
What they did was to move registration of meta object content to runtime. They basically have structs with static variables and they rely on initialization of these variables at program start-up. It's a lot of macro magic and relies on things like __LINE__ to create unique tokens. The info above is based on this presentation, the meta object stuff is covered from slide 20 onwards: https://docs.google.com/presentation/d/1Sxei-Em6cnYbE0Zj16j6gwF4SIvGJIE_1tb4P78RN3o/edit?usp=sharing I don't think they did anything to the container classes, but I haven't looked. Cheers, Louai > -Original Message- > From: development-bounces+louai.al-khanji=theqtcompany.com@qt- > project.org [mailto:development-bounces+louai.al- > khanji=theqtcompany@qt-project.org] On Behalf Of Thiago Macieira > Sent: Thursday, June 25, 2015 7:03 PM > To: development@qt-project.org > Subject: Re: [Development] Qt LTS & C++11 plans > > On Thursday 25 June 2015 13:18:17 Cristian Adam wrote: > > They've got rid of moc and plan to replace Qt containers with std > ones. > > If they got rid of moc, then they also got rid of QtDBus, QtScript and > QtQml. > That doesn't sound like a "fork of Qt". > > Getting rid of moc is waiting for SG7 from the standards committee to > come up > with a language reflection feature. At the current pace, it might > happen as a > TS for C++2x, so we may be able to start using it in Qt around 2025. > > And if they replaced Qt containers with std ones, what replaced QString? > Because the standard ones are nowhere near feature parity with QString. > Unfortunately, CopperSpice's documentation is offline, so I can't tell. > > Doesn't seem like a serious project to me. That sounds a lot like TQt > from the > Trinity Project... > > -- > 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt LTS & C++11 plans
On Tuesday 23 June 2015 10:17:40 Knoll Lars wrote: > Qt 5.6: > > * We make 5.6 a long term supported release > * We still support C++98 compilers in this release (for the last time), > i.e. We keep the 5.5 compiler baseline > * WEC7 will be still supported > * QNX 6.5 is not supported anymore > * Qt Quick1 and Qt WebKit are not part of the release (but we test that > the sources compile against 5.6) > * We keep Qt Script for this release, it’ll be gone in 5.7 as well > > Qt 5.7: > > * New compiler baseline with gcc 4.7 and VC++ 2012 > * Enable and use the C++11 features supported by these compilers > unconditionally > * WEC7 not supported anymore, WEC2013 supported > * Probably remove support for older Android, Mac and Linux versions as > well (to be discussed) https://codereview.qt-project.org/115267 I've updated the 5.5.0 changelog to reflect this discussion. By effect of requiring Clang 3.2 for the C++11 features, we also require XCode 5.0, which in turn removes OS X 10.7 support from 5.7. -- 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