On Friday, 6 September 2019 09:39:32 PDT Edward Welbourne wrote:
> Thiago Macieira (6 September 2019 16:58)
>
> > I also don't understand what we need to reduce. Having the current stable,
> > current post-feature-freeze and the current in-development branches have
> > always been the norm. The on
06.09.2019, 20:28, "Thiago Macieira" :
> On Friday, 6 September 2019 09:04:09 PDT Giuseppe D'Angelo via Development
> wrote:
>> I was actually proposing option A, to avoid clashes. The Qt:: namespace
>> at the moment is simply too big to reasonably claim that there will be
>> no conflicts. A f
On 2019-09-06 19:26, Thiago Macieira wrote:
On Friday, 6 September 2019 09:04:09 PDT Giuseppe D'Angelo via
Development
wrote:
I was actually proposing option A, to avoid clashes. The Qt::
namespace
at the moment is simply too big to reasonably claim that there will be
no conflicts. A few examp
On Friday, 6 September 2019 09:04:09 PDT Giuseppe D'Angelo via Development
wrote:
> I was actually proposing option A, to avoid clashes. The Qt:: namespace
> at the moment is simply too big to reasonably claim that there will be
> no conflicts. A few examples that come into mind: Qt::horizontal,
>
Thiago Macieira (6 September 2019 16:58)
> I also don't understand what we need to reduce. Having the current stable,
> current post-feature-freeze and the current in-development branches have
> always been the norm. The only new thing is the Qt 6 branch ("dev"), which
> does not need frequent merg
Il 06/09/19 16:27, Mutz, Marc via Development ha scritto:
Let's name the options, as I see them (new additions welcome!):
([NS::] in the below means that namespace is inline)
A) We can keep the existing Qt namespace, then types would be named
[Qt::]Qt::Alignment, [Qt::]QString, [Qt::]QLineEdit,
Spam detection software, running on the system "mx.qt-project.org",
has identified this incoming email as possible spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
C
On Friday, 6 September 2019 02:26:43 PDT Mutz, Marc via Development wrote:
> Qt can already, optionally, be configured into a user-specified
> namespace (QT_BEGIN_NAMESPACE/QT_END_NAMESPACE, -qtnamespace), and this
> is one of the build configurations in the CI, so we're reasonably sure
> it works.
On Friday, 6 September 2019 04:59:02 PDT Tuukka Turunen wrote:
> Target is to reduce the merge steps after no further patch releases planned
> for Qt 5.13.
That's circular thinking, because you're saying that 5.13.3 is not planned.
Let's do it the other way around then: put 5.13.3 in the plan, wi
On 2019-09-06 14:34, Lars Knoll wrote:
On 6 Sep 2019, at 14:10, Giuseppe D'Angelo via Development
wrote:
Il 06/09/19 11:26, Mutz, Marc via Development ha scritto:
The change is SC, and makes namespaced and non-namespaced builds
behave
the same.
Small question: the claim here is that the ch
On 06.09.2019 14:34, Lars Knoll wrote:
>
> Wouldn’t that pull all the enum value in the current Qt namespace into the
> users namespace?
I imagine code like in qnamespace.h would be a special case which would
not be 'inline'. It then couldn't use Q_{BEGIN,END}_NAMESPACE, but that
should be f
> On 6 Sep 2019, at 14:10, Giuseppe D'Angelo via Development
> wrote:
>
> Il 06/09/19 11:26, Mutz, Marc via Development ha scritto:
>> The change is SC, and makes namespaced and non-namespaced builds behave
>> the same.
>
> Small question: the claim here is that the change is SC; however below
Integrations
* qt5 5.12 and 5.13 are healthy, the last submodule update integrated at 2 days
ago
* qt5 5.14:
* ongoing: https://codereview.qt-project.org/c/qt/qt5/+/272221 , hope
it could finish a bit later tonight
* previous integrated submodule update is 8 days ago.
* qt5 dev:
Il 06/09/19 11:26, Mutz, Marc via Development ha scritto:
The change is SC, and makes namespaced and non-namespaced builds behave
the same.
Small question: the claim here is that the change is SC; however below
it's pointed out that there may be slight differences in name lookup (in
some supe
Hi,
Target is to reduce the merge steps after no further patch releases planned for
Qt 5.13. One option would be to agree that at certain point 5.13 goes into
cherry pick mode, if not closed. That can be reached also by having 5.14 as
the stable branch after 5.13.2 is branched. 5.13 could be
Hi Marc,
Could you elaborate a bit, what the real value of this change?
I'm asking, because there are only cons I see now:
1) Adding inline after namespace *implicitly* throws all symbols to the
global (or outer) namespace, which, potentially might lead to name
clashes. For example, the follow
Hi,
I would like to propose to make the existing Qt namespace inline and
move all of Qt's declarations into it.
== TL;DR: ==
Qt can already, optionally, be configured into a user-specified
namespace (QT_BEGIN_NAMESPACE/QT_END_NAMESPACE, -qtnamespace), and this
is one of the build configurat
Tuuka proposed closing 5.13 early.
Thiago wants it to stay open until a month short of 5.14.0's release.
On Thursday, 5 September 2019 08:51:40 PDT Tuukka Turunen wrote:
>> That is probably quite close to Qt 5.13.2 timing. If we release it in mid
>> October we have about a month to Qt 5.14.0. Of c
18 matches
Mail list logo
