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
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 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
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 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 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 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
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
53 matches
Mail list logo
