Re: [Development] Qt LTS & C++11 plans

[Marc Mutz]

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

[Marc Mutz]

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

[Olivier Goffart]

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

[Thiago Macieira]

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

[Marc Mutz]

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

[Thiago Macieira]

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

[Thiago Macieira]

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

[Thiago Macieira]

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

[Knoll Lars]

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

[Olivier Goffart]

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

[Thiago Macieira]

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

[Knoll Lars]

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

[Knoll Lars]

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

[Marc Mutz]

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

[Thiago Macieira]

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

[Sorvig Morten]

 On 18 Aug 2015, at 07:46, Thiago Macieira thiago.macie...@intel.com 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

[Ziller Eike]

 On Aug 18, 2015, at 08:49, Thiago Macieira thiago.macie...@intel.com 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

[Thiago Macieira]

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

[Jake Petroules]

 On Aug 17, 2015, at 10:46 PM, Thiago Macieira thiago.macie...@intel.com 
 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

[Knoll Lars]

On 18/08/15 09:56, 
development-bounces+lars.knoll=theqtcompany@qt-project.org on behalf of 
Sorvig Morten development-bounces+lars.knoll=theqtcompany@qt-project.org 
on behalf of morten.sor...@theqtcompany.com wrote:




 On 18 Aug 2015, at 07:46, Thiago Macieira thiago.macie...@intel.com 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

[Thiago Macieira]

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

[Thiago Macieira]

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)

[Thiago Macieira]

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)

[Thiago Macieira]

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)

[Andre Somers]

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)

[André Somers]

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)

[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

Re: [Development] Qt LTS C++11 plans (CopperSpice)

[Kevin Kofler]

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)

[Thiago Macieira]

On Wednesday 22 July 2015 16:47:21 Olivier Goffart wrote:
  template typename Key, typename T
  using QMapKey, T = QMapComparatorKey, T, qMapLessThanKeyKey;
 
 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)

[Olivier Goffart]

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 typename Key, typename T
 using QMapKey, T = QMapComparatorKey, T, qMapLessThanKeyKey;

This is still source incompatible (because of forward declarations) and binary 
incompatible too.

 
 Note however that a function taking QMapFoo, Bar is *not* the same as a
 function taking QMapComparatorFoo, Bar, qMapLessThanKeyFoo. 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)

[Ansel Sermersheim]

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 (CopperSpice)

[Gunnar Roth]

Hi Ansel.
 Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim 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)

[Thiago Macieira]

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 QMapCaseInsensitiveString,
  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)

[Thiago Macieira]

On Tuesday 21 July 2015 18:10:27 Ansel Sermersheim wrote:
 The most common use case of this is creating a QMapQString, X 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 QMapCaseInsensitiveString, X.

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)

[Ansel Sermersheim]

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)

[Ansel Sermersheim]

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 QMapQString, X 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 QMapCaseInsensitiveString, X.

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)

[Marc Mutz]

On Tuesday 21 July 2015 19:53:14 Gunnar Roth wrote:
 Hi Ansel.
 
  Am 21.07.2015 um 19:06 schrieb Ansel Sermersheim 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.

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 marc.m...@kdab.com | 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)

[Giuseppe D'Angelo]

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)

[Thiago Macieira]

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)

[Ansel Sermersheim]

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 
an...@copperspice.com 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)

[Ansel Sermersheim]

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 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.
 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)

[Marc Mutz]

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 marc.m...@kdab.com | 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)

[Pau Garcia i Quiles]

On Tue, Jul 21, 2015 at 10:26 PM, Ansel Sermersheim an...@copperspice.com
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)

[Ansel Sermersheim]

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 QMapQString, X 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)

[Ansel Sermersheim]

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)

[Thiago Macieira]

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 typename Key, typename T 
using QMapKey, T = QMapComparatorKey, T, qMapLessThanKeyKey;

Note however that a function taking QMapFoo, Bar is *not* the same as a 
function taking QMapComparatorFoo, Bar, qMapLessThanKeyFoo. 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)

[Thiago Macieira]

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)

[Thiago Macieira]

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

[Thiago Macieira]

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::atomicfunction_pointer and std::atomicconst 
T* fail to compile. Can be fixed by a one-line change, casting to (void*). We 
hit both cases in QtCore:

qlogging.cpp: static QBasicAtomicPointervoid (QtMsgType, const char*) 
msgHandler = Q_BASIC_ATOMIC_INITIALIZER(qDefaultMsgHandler);

qobject_p.h: QAtomicPointerconst int 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

[Thiago Macieira]

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

[Thiago Macieira]

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

[Thiago Macieira]

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

[Thiago Macieira]

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)

[charleyb123 .]

 snip, shared pointers


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)

[Thiago Macieira]

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)

[Simon Hausmann]

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)

[Bo Thorsen]

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)

[Thiago Macieira]

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)

[Milian Wolff]

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) GmbHCo 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

[Thiago Macieira]

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 (CopperSpice)

[Ansel Sermersheim]

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)

[Milian Wolff]

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) GmbHCo 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)

[Marc Mutz]

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 marc.m...@kdab.com | 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)

[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.


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)

[Thiago Macieira]

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)

[charleyb123 .]

  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

[Sune Vuorela]

On 2015-06-26, Olivier Goffart oliv...@woboq.com 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)

[Konstantin Tokarev]

30.06.2015, 23:38, Bernhard priv...@bernhard-lindner.de:
  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)

[Julien Blanc]

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

[Thiago Macieira]

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 (CopperSpice)

[Ansel Sermersheim]

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)

[Thiago Macieira]

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)

[Thiago Macieira]

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

[Olivier Goffart]

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)

[Ansel Sermersheim]

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 (CopperSpice)

[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!

-- 
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 (CopperSpice)

[Thiago Macieira]

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

[Thiago Macieira]

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)

[Cristian Adam]

On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira thiago.macie...@intel.com
 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=10t=7
___
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]

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)

[Thiago Macieira]

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)

[Alejandro Exojo]

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)

[Thiago Macieira]

On Tuesday 30 June 2015 23:09:59 Cristian Adam wrote:
 On Tue, Jun 30, 2015 at 10:01 PM, Thiago Macieira thiago.macie...@intel.com
  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)

[Olivier Goffart]

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

[Francesco Riosa]

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 (CopperSpice)

[Ansel Sermersheim]

 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

[Kevin Kofler]

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

[Thiago Macieira]

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

[Al-Khanji Louai]

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

[Thiago Macieira]

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

[Thiago Macieira]

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

[Olivier Goffart]

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

[Daniel Teske]

On Thursday 25 Jun 2015 12:09:54 Knoll Lars wrote:
 On 25/06/15 11:43, Teske Daniel daniel.te...@theqtcompany.com wrote:
 
 
  * WEC7 not supported anymore, WEC2013 supported
 
 So what is the time frame for dropping WEC2013? Because that's the time
 Qt 
 will be stuck with MSVC2012.
 
 
 WEC2013 just came out. I’m afraid we’ll be stuck with it for some time.
 
Right, that's what I expected, I'm guessing the expectation is that it'll be 
supported for years. 

We need to prioritize moving towards modern C++. The C++ world is changing.We 
cannot be stuck on a compiler that has only a minimal set of C++11 features, 
if we want Qt to stay relevant.

So, I'm against making WEC2013 a supported platform.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans

[Cristian Adam]

On Thu, Jun 25, 2015 at 1:04 PM, Knoll Lars lars.kn...@theqtcompany.com
wrote:



 Well, please tell me where this is such a big problem that we *have to
 have* VS2013 when it comes to our APIs. For our implementation inside Qt,
 we can work with slightly older compilers. It’s not the end of the world
 and our users wouldn’t even notice.

 Cheers,
 Lars


There is always CopperSpice http://www.copperspice.com/ 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.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans

[Bubke Marco]

Wrapping Qt container around standard container is quite a good idea to 
interact with other code. So Qt Container would be standard container + COW. 
One of the complains I hear very often is that Qt is an island and sadly in 
many cases I must agree. I think we should discuss the integration of the new 
library features too.

Cheers, Marco


From: development-bounces+marco.bubke=theqtcompany@qt-project.org 
development-bounces+marco.bubke=theqtcompany@qt-project.org on behalf of 
Cristian Adam cristian.a...@gmail.com
Sent: Thursday, June 25, 2015 1:18 PM
To: Knoll Lars
Cc: development@qt-project.org
Subject: Re: [Development] Qt LTS  C++11 plans

On Thu, Jun 25, 2015 at 1:04 PM, Knoll Lars 
lars.kn...@theqtcompany.commailto:lars.kn...@theqtcompany.com wrote:


Well, please tell me where this is such a big problem that we *have to
have* VS2013 when it comes to our APIs. For our implementation inside Qt,
we can work with slightly older compilers. It's not the end of the world
and our users wouldn't even notice.

Cheers,
Lars


There is always CopperSpicehttp://www.copperspice.com/ 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.

Cheers,
Cristian.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans

[Knoll Lars]

On 25/06/15 12:43, Teske Daniel daniel.te...@theqtcompany.com wrote:

On Thursday 25 Jun 2015 12:09:54 Knoll Lars wrote:
 On 25/06/15 11:43, Teske Daniel daniel.te...@theqtcompany.com wrote:
 
 
  * WEC7 not supported anymore, WEC2013 supported
 
 So what is the time frame for dropping WEC2013? Because that's the time
 Qt 
 will be stuck with MSVC2012.
 
 
 WEC2013 just came out. I’m afraid we’ll be stuck with it for some time.
 
Right, that's what I expected, I'm guessing the expectation is that it'll
be 
supported for years.

Right. But at some point the question will come on which Qt version we
support the platform.
 

We need to prioritize moving towards modern C++. The C++ world is
changing.We 
cannot be stuck on a compiler that has only a minimal set of C++11
features, 
if we want Qt to stay relevant.

There’s always a difference between enabling our users to use more modern
C++11 features and us using those ourselves inside our product. Inside the
Qt frameworks, we've always been more conservative in using features
unconditionally that are not supported everywhere.

When we went through the compatibility list during QtCS, it looked like we
can start using quite a few C++11 features unconditionally even with
VS2012. This gives us a much better baseline than what we had previously.


So, I'm against making WEC2013 a supported platform.

Well, please tell me where this is such a big problem that we *have to
have* VS2013 when it comes to our APIs. For our implementation inside Qt,
we can work with slightly older compilers. It’s not the end of the world
and our users wouldn’t even notice.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans

[Knoll Lars]

On 25/06/15 11:43, Teske Daniel daniel.te...@theqtcompany.com wrote:

 * WEC7 not supported anymore, WEC2013 supported
So what is the time frame for dropping WEC2013? Because that's the time
Qt 
will be stuck with MSVC2012.

WEC2013 just came out. I’m afraid we’ll be stuck with it for some time.

Cheers,
Lars

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Qt LTS C++11 plans

[Thiago Macieira]

On Thursday 25 June 2015 13:55:00 Bubke Marco wrote:
 Wrapping Qt container around standard container is quite a good idea to
 interact with other code. So Qt Container would be standard container +
 COW. One of the complains I hear very often is that Qt is an island and
 sadly in many cases I must agree. I think we should discuss the integration
 of the new library features too.

That's a Qt 6 discussion.

Wrapping the std containers with COW will introduce another level of 
indirection to the data, which is probably the worst of all solutions. If 
we're going to use the std containers in any capacity, we'll have to ditch COW 
completely.

-- 
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

[Thiago Macieira]

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

Re: [Development] Qt LTS C++11 plans

[Daniel Teske]

 * WEC7 not supported anymore, WEC2013 supported
So what is the time frame for dropping WEC2013? Because that's the time Qt 
will be stuck with MSVC2012.

daniel

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development