; -Original Message-
>> From: Development On Behalf Of
>> Jani Heikkinen
>> Sent: torstai 6. helmikuuta 2020 10.03
>> To: Mitch Curtis ; Lars Knoll ;
Yulong
>> Bai
>> Cc: Qt development mailing list ;
>> releas.
t;> Jani Heikkinen
>> Sent: torstai 6. helmikuuta 2020 10.03
>> To: Mitch Curtis ; Lars Knoll ; Yulong
>> Bai
>> Cc: Qt development mailing list ;
>> releas...@qt-project.org
>> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
>
> To: Mitch Curtis ; Lars Knoll ; Yulong
> Bai
> Cc: Qt development mailing list ;
> releas...@qt-project.org
> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
>
> > -Original Message-
> > From: Mitch Curtis
&
On Thursday, 6 February 2020 05:51:17 PST Alex Blasche wrote:
> Either option solves the ambiguity. What's more important to our users - a
> consistent naming convention or an early warning/compile error when
> adopting Qt 6?
False dichotomy. Both are important and both are achievable.
--
On Wednesday, 5 February 2020 15:34:27 PST Alexander Akulich wrote:
> Do we want to sort out all overloads of error() signal/getter in all
> (essential?) modules for Qt 6?
>
> For example, Qt Multimedia still has more than a dozen public classes
> with such overloads (of a signal and a getter) in
I started to work on the error() signal renaming here:
https://codereview.qt-project.org/q/topic:%22error-occured%22
On Wed, Feb 5, 2020 at 10:12 PM Thiago Macieira
wrote:
>
> On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
l ; Volker Hilsheimer
>>
>> Cc: Qt development mailing list ;
>> releas...@qt-project.org
>> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze
is
>> in effect now
>>
>>
>> On 05.02.2020 11:50, Edw
On 05.02.2020 11:50, Edward Welbourne asked:
Do we allow changes approved before feature freeze to get past the
Coin hurdle, even if that happens after FF ? How much fixing of
the change (if it turns out to have problems integrating) is
acceptable, before we declare that it's
> Edward Welbourne
> > Alexander Akulich (6 February 2020 16:33) asked:
> > Are we going to provide some Qt5 → Qt6 migration tool?
>
> https://codereview.qt-project.org/c/qt/qtrepotools/+/289121
>
> > It is trivial to grep the sources for
> > "SIGNAL(error(QAbstractSocket::SocketError))" and
Qt development mailing list ;
>> releas...@qt-project.org
>> Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
>> in effect now
>>
>>
>> On 05.02.2020 11:50, Edward Welbourne wrote:
>>> Jani Heikkinen (5 February 2020 06:42)
>>&
Den tors 6 feb. 2020 kl 20:36 skrev André Pönitz :
>
> On Thu, Feb 06, 2020 at 01:51:17PM +, Alex Blasche wrote:
> >
> > > -Original Message- From: Development
> > > On Behalf Of Thiago Macieira
> > >
> > > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > > > On
On Thu, Feb 06, 2020 at 01:51:17PM +, Alex Blasche wrote:
>
> > -Original Message- From: Development
> > On Behalf Of Thiago Macieira
> >
> > On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
> > >
> > > wrote:
Alexander Akulich (6 February 2020 16:33) asked:
> Are we going to provide some Qt5 → Qt6 migration tool?
https://codereview.qt-project.org/c/qt/qtrepotools/+/289121
> It is trivial to grep the sources for
> "SIGNAL(error(QAbstractSocket::SocketError))" and print a warning
> about the dangerous
Are we going to provide some Qt5 → Qt6 migration tool? It is trivial
to grep the sources for "SIGNAL(error(QAbstractSocket::SocketError))"
and print a warning about the dangerous Qt4-style connection.
___
Development mailing list
> -Original Message-
> From: Alexander Akulich
> On Thu, Feb 6, 2020 at 4:52 PM Alex Blasche wrote:
> >
> > Considering that our naming convention for error() signals is inconsistent
> anyway, I favour an approach that highlights API changes early.
>
> The convention can not be
On Thu, Feb 6, 2020 at 4:52 PM Alex Blasche wrote:
>
> Considering that our naming convention for error() signals is inconsistent
> anyway, I favour an approach that highlights API changes early.
The convention can not be inconsistent. It can either do not exist
("we have no convention, so
> -Original Message-
> From: Development On Behalf Of
> Thiago Macieira
>
> On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> > On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
> >
> > wrote:
> > > The correct signal for an error situation is errorOccurred, like in
>
> -Original Message-
> From: Mitch Curtis
> Sent: keskiviikko 5. helmikuuta 2020 15.40
> To: Jani Heikkinen ; Lars Knoll ;
> Yulong Bai
> Cc: Volker Hilsheimer ; Qt development mailing list
> ; releas...@qt-project.org
> Subject: RE: [Releasing] [Development] H
Do we want to sort out all overloads of error() signal/getter in all
(essential?) modules for Qt 6?
For example, Qt Multimedia still has more than a dozen public classes
with such overloads (of a signal and a getter) in 5.15 and dev.
___
Development
: Lars Knoll ; development@qt-project.org
; releas...@qt-project.org
Subject: RE: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in
effect now
> -Original Message-
> From: Volker Hilsheimer
> Sent: keskiviikko 5. helmikuuta 2020 13.10
> To: Edward Welbourne
Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in
effect now
On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
>
> wrote:
> > The correct signal for an error situation is errorOccurred, like i
On Wednesday, 5 February 2020 08:03:45 PST Shawn Rutledge wrote:
> It defeats the purpose of deprecation to do that before you are ready. It’s
> something to be done later, to verify that you really have gotten rid of
> all uses of the old API. “Later” should not be as long a time as it has
>
On Wednesday, 5 February 2020 09:41:58 PST Alexander Akulich wrote:
> On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
>
> wrote:
> > The correct signal for an error situation is errorOccurred, like in
> > QLocalSocket and QProcess.
>
> Actually both QLocalSocket and QAbstractSocket renamed the
of QtNetwork, prefer it this way.
Best.
From: Development on behalf of Alexander
Akulich
Sent: Wednesday, February 5, 2020 6:41 PM
To: Thiago Macieira
Cc: Qt development mailing list
Subject: Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in
effect
On Wed, Feb 5, 2020 at 6:58 PM Thiago Macieira
wrote:
>
> The correct signal for an error situation is errorOccurred, like in
> QLocalSocket and QProcess.
Actually both QLocalSocket and QAbstractSocket renamed the "error()"
getter to keep using "error()" signal as opposed to many other Qt
On Wed, Feb 5, 2020 at 7:29 PM Alexander Akulich
wrote:
>
> On Wed, Feb 5, 2020 at 1:11 PM Ville Voutilainen
> wrote:
> >
> > Isn't that an ABI break?
>
> Yep; this is what we're doing here (we're deprecating and sorting out
> the API to break the ABI in Qt 6).
(I thought that it is obvious,
On Wed, Feb 5, 2020 at 1:11 PM Ville Voutilainen
wrote:
>
> Isn't that an ABI break?
Yep; this is what we're doing here (we're deprecating and sorting out
the API to break the ABI in Qt 6).
___
Development mailing list
Development@qt-project.org
It seems "feature freeze" != "API freeze" and the API review for 5.15
is still "to be done", so we still can raise the objection at the
right time for Qt 5.15.
The API consistency is one of the biggest advantages of Qt and I
really hope that we won't stop caring about it.
On Wed, Feb 5, 2020 at
> On 5 Feb 2020, at 16:31, Edward Welbourne wrote:
>
> Shawn Rutledge (5 February 2020 14:14)
>> So I’m strongly in favor of continuing to do deprecations as long as
>> possible. A deprecation is not something that can break existing
>> functionality, so it’s no real risk as long as we’re
On Wednesday, 5 February 2020 02:12:06 PST Alexander Akulich wrote:
> Oh, I'm sorry for the spam! You already renamed error() getter to
> sockerError() [1], so the issue is not relevant now.
> It's a bit unfortunate to see such diversity in the API. error()
> getter seems to be a convention in Qt.
Shawn Rutledge (5 February 2020 14:14)
> So I’m strongly in favor of continuing to do deprecations as long as
> possible. A deprecation is not something that can break existing
> functionality, so it’s no real risk as long as we’re sure we really
> want to deprecate it.
A deprecation can break
> -Original Message-
> From: Releasing On Behalf Of Jani
> Heikkinen
> Sent: Wednesday, 5 February 2020 6:37 AM
> To: Lars Knoll ; Yulong Bai
> Cc: Volker Hilsheimer ; Qt development mailing list
> ; releas...@qt-project.org
> Subject: Re: [Releasing] [Develo
On 5 Feb 2020, at 13:04, Jani Heikkinen
mailto:jani.heikki...@qt.io>> wrote:
We are doing time based releases so if new feature misses the deadline there
will be next one coming after few months. It might be quite long time for
unique feature but on the other hand it isn't really that long…
e: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
>
>
> On 05.02.2020 11:50, Edward Welbourne wrote:
> > Jani Heikkinen (5 February 2020 06:42)
> >> Why this is so important that we should get the exception & go in after
> FF?
>
> -Original Message-
> From: Volker Hilsheimer
> Sent: keskiviikko 5. helmikuuta 2020 13.10
> To: Edward Welbourne
> Cc: Jani Heikkinen ; Lars Knoll ;
> development@qt-project.org; releas...@qt-project.org
> Subject: Re: [Development] [Releasing] HEADS-UP: Q
> On 5 Feb 2020, at 11:50, Edward Welbourne wrote:
>
> On 4 Feb 2020, at 16:56, Volker Hilsheimer wrote:
I’ve been struggling a bit more than expected with getting the
implementation of "move a file or directory to the trash" pass
CI. It’s a popular feature request:
On 05.02.2020 11:50, Edward Welbourne wrote:
> Jani Heikkinen (5 February 2020 06:42)
>> Why this is so important that we should get the exception & go in after FF?
> Do we allow changes approved before feature freeze to get past the Coin
> hurdle, even if that happens after FF ? How much fixing
On 4 Feb 2020, at 16:56, Volker Hilsheimer wrote:
>>> I’ve been struggling a bit more than expected with getting the
>>> implementation of "move a file or directory to the trash" pass
>>> CI. It’s a popular feature request:
>>>
>>> https://bugreports.qt.io/browse/QTBUG-47703
>>>
>>> The basic
] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in
effect now
What I'm talking about is to repeat [1] for QAbstractSocket [2] as a
last-minute change for Qt 5.15.
If such a patch is not acceptable for 5.15, is it still acceptable for
Qt 6 (in terms of Qt 5.15/6.0 compatibility policy)?
I'm going
gt; > sound that well to me either; as written before all known features should
> > > be in Alpha...
> > >
> > > br,
> > > Jani
> > >
> > >
> > > ____
> > > From: Lars Knoll
> &g
On Wed, 5 Feb 2020 at 11:44, Alexander Akulich
wrote:
>
> Hi all,
>
> does the 5.15 feature freeze mean that we can not adjust signal names
> anymore? IIRC it was said that "deprecated-free" code for Qt 5.15
> will/should be compatible with Qt 6.
>
> IIRC there was an intention to rename
>
features should be in
> > Alpha...
> >
> > br,
> > Jani
> >
> >
> >
> > From: Lars Knoll
> > Sent: Tuesday, February 4, 2020 8:41 PM
> > To: Volker Hilsheimer
> > Cc: Jani Heikkinen; Qt deve
> From: Lars Knoll
> Sent: Tuesday, February 4, 2020 8:41 PM
> To: Volker Hilsheimer
> Cc: Jani Heikkinen; Qt development mailing list; releas...@qt-project.org
> Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is
> in effect now
>
> >
ling list; releas...@qt-project.org
Subject: Re: [Releasing] [Development] HEADS-UP: Qt 5.15 Feature Freeze is
in effect now
> On 4 Feb 2020, at 16:56, Volker Hilsheimer wrote:
>
>> On 3 Feb 2020, at 06:35, Jani Heikkinen wrote:
>>
>> Hi all,
>>
>> Qt
> On 4 Feb 2020, at 16:56, Volker Hilsheimer wrote:
>
>> On 3 Feb 2020, at 06:35, Jani Heikkinen wrote:
>>
>> Hi all,
>>
>> Qt 5.15 Feature Freeze is in effect now. So no new features in '5.15'
>> anymore. Please update Qt 5.15 new features page
>>
45 matches
Mail list logo
