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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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.
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,
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
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
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
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
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
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
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
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?
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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.
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
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.
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++
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
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
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
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
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
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
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
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
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
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
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.
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.
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
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,
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
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,
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
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
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
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
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
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.
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
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
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
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
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
] 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
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
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
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
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
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
: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
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?
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.
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
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
* 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
1 - 100 of 105 matches
Mail list logo