Both the "removal of LTS" and "removal of offline installers" serve as
evidence that Tuukka Turunen doesn't care about the Free
Software/Culture movement. In both cases he is actively hurting the
open source side of Qt in order to promote the business side. The work
is already being done to create
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
This merged just now 邏 Will update wiki tomorrow.
Apologies for not getting this finished earlier, and thanks for the flexibility
Cheers,
Volker
From: Jani Heikkinen
Sent: Wednesday, February 5, 2020 12:29:27 PM
To: Volker Hilsheimer ; Edward Welbourne
https://codereview.qt-project.org/c/qt/qtbase/+/285791
> But ok otherwise. So +1-1=0.
Interesting.
Best regards,
Timur.
From: Development on behalf of Thiago
Macieira
Sent: Wednesday, February 5, 2020 7:43 PM
To: development@qt-project.org
Subject: Re:
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
Correct, to avoid breaking old connection syntax silently (with warnings not
noticed in code).
Now, please enumerate those many modules you are talking about? There are 4
classes in
QtNetwork doing similar changes (not touching a tricky signal, but a getter)
and I, as the
maintainer of
Please remove me from this mailing list as it is clogging up my inbox.
Many thanks.
Sent from my iPad
--
CONFIDENTIALITY NOTICE:
The contents of this email message and any
attachments are intended solely for the addressee(s) and may contain
confidential and/or privileged information and
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
It seems like everyone agrees that we need to keep and improve the asynchronous
APIs in Qt 6.
Since there are already tasks for each of proposed changes, let’s move more
detailed discussions about each item to the relevant task. They are all linked
to
> -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] [Development] HEADS-UP: Qt 5.15
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…
> -Original Message-
> From: Eskil Abrahamsen Blomfeldt
> Sent: keskiviikko 5. helmikuuta 2020 13.06
> To: Edward Welbourne ; Jani Heikkinen
> ; Lars Knoll ; Volker Hilsheimer
>
> Cc: Qt development mailing list ;
> releas...@qt-project.org
> Subject: Re: [Development] [Releasing]
> -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: Qt 5.15 Feature Freeze is
> in
> 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
There was already a patch which did this, for the getter:
https://codereview.qt-project.org/c/qt/qtbase/+/286089
Fra: Development på vegne av Alexander
Akulich
Sendt: Wednesday, February 5, 2020 11:04:35 AM
Til: Jani Heikkinen
Kopi: Qt development mailing list
Emne: Re: [Development]
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. I thought that the same
convention is to use '-ed' verbs in signal names.
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
>
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 to prepare the patch right now, whether it 'll be accepted
or
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
QAbstractSocket::error(SocketError) signal to errorOccured() to align
it with
> A "Qt style" "RAII handle" is a QObject parent at creation time.
> There is no double deletion in this context, *only* when you start
> to sprinkle in other ownership models, i.e. deviate from "Qt style".
No.
There are many places in our API that expect or return plain QObject
pointers and
29 matches
Mail list logo
