Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

2020-02-07 Thread Edward Welbourne
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

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

2020-02-07 Thread Tuukka Turunen
Hi, In practice we also do have some slack in the schedule exactly to allow sorting everything out. Unfortunately it is often not long enough, but we have delay in getting the alpha out. I do agree that we should include the features that are ready in time - and I do not think there are many

Re: [Development] Nominating André Hartmann for maintainer for QCanBus API

2020-02-07 Thread Alex Blasche
Its been a while and I lost track of this thead. Congratulations to André. I recorded the change of maintainership in https://wiki.qt.io/Maintainers -- Alex From: Development on behalf of Alex Blasche Sent: Tuesday, 26 November 2019 09:36 To:

Re: [Development] The future of smart pointers in Qt API

2020-02-07 Thread Eike Ziller
QList is most definitely a typedef to QVector in Qt/dev: https://code.qt.io/cgit/qt/qtbase.git/tree/src/corelib/tools/qcontainerfwd.h > On 6. Feb 2020, at 20:20, Иван Комиссаров wrote: > > Wait, what?? When did that decision was made? > > I am tired fixing performance bugs induced be the

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

2020-02-07 Thread Mark De Wit
> 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

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

2020-02-07 Thread Eskil Abrahamsen Blomfeldt
On 05.02.2020 13:04, Jani Heikkinen wrote: > >> -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 ; >>

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

2020-02-07 Thread Alexander Akulich
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

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

2020-02-07 Thread Thiago Macieira
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

Re: [Development] The future of smart pointers in Qt API

2020-02-07 Thread Matthew Woehlke
On 07/02/2020 03.14, Eike Ziller wrote: > QList is most definitely a typedef to QVector in Qt/dev: What happened to providing a container type with guaranteed indirect storage? There remains no such type in STL. Last I saw, I thought we were going to provide that... -- Matthew

Re: [Development] [Releasing] HEADS-UP: Qt 5.15 Feature Freeze is in effect now

2020-02-07 Thread Thiago Macieira
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. --

Re: [Development] Using SSE/NEON in Qt 6

2020-02-07 Thread Thiago Macieira
On Thursday, 6 February 2020 03:45:51 PST Lars Knoll wrote: > Hi, > > We’ve seen that in a couple of places things like matrix operations are a > CPU bottleneck. Being able to provide SSE/NEON optimised versions of some > of those operations could help significantly. > On x86/x64, we require