Re: [Development] How qAsConst and qExchange lead to qNN
On Thu, Nov 10, 2022 at 03:55:39PM +, Marc Mutz via Development wrote: > Hi Ivan, > > On 10.11.22 11:03, Ivan Solovev via Development wrote: > > I wonder how your NOI-everywhere suggestion will work with the > > signal/slot connections? Specially for the case when > > Qt::QueuedConnection is
Re: [Development] How qAsConst and qExchange lead to qNN
[ TL;DR : Qt API should use QString foo() const; void setFoo(const QString &); Neither QStringView nor C++20 changes this. ] On Wed, Nov 09, 2022 at 10:52:15AM +, Marc Mutz via Development wrote: > Hi Ulf, > > On 09.11.22 08:18, Ulf Hermann via Development wrote: > >> I don't wa
Re: [Development] How qAsConst and qExchange lead to qNN
On Thursday, 10 November 2022 10:40:35 PST Giuseppe D'Angelo via Development wrote: > On 09/11/2022 20:25, Thiago Macieira wrote: > > Our API should default to passing QStrings for simplicity and not to > > confuse> > > the user. The fact that I cannot wrote: > >foo(u"bar'); > > > > if foo t
Re: [Development] How qAsConst and qExchange lead to qNN
On 09/11/2022 20:25, Thiago Macieira wrote: Our API should default to passing QStrings for simplicity and not to confuse the user. The fact that I cannot wrote: foo(u"bar'); if foo takes a QString is MESSED UP. Is this because we deliberately didn't add a QString(const char16_t *) constr
Re: [Development] How qAsConst and qExchange lead to qNN
> 1. It doesn't, obviously. If you emit signals, any signal argument must >be owning, or QueuedConnection cannot be used. Given that C++20 >requires us to mark up views and non-owning ranges (enable_view, >enable_borrowed_range), I'm confident that we could detect attempts >to creat
Re: [Development] How qAsConst and qExchange lead to qNN
Hi Ivan, On 10.11.22 11:03, Ivan Solovev via Development wrote: > I wonder how your NOI-everywhere suggestion will work with the > signal/slot connections? Specially for the case when > Qt::QueuedConnection is used (explicitly or implicitly). That's a very good question, thanks. As a first rea
Re: [Development] Getting "REMOTE HOST IDENTIFICATION HAS CHANGED" when pushing a commit to gerrit
Good! https://lists.qt-project.org/pipermail/development/2022-November/043229.html Volker > On 10 Nov 2022, at 16:29, Fusion Future wrote: > > Hi Qt people, > > I am getting this error "REMOTE HOST IDENTIFICATION HAS CHANGED" when trying > to push a commit to Qt gerrit. Not sure what happen
[Development] Getting "REMOTE HOST IDENTIFICATION HAS CHANGED" when pushing a commit to gerrit
Hi Qt people, I am getting this error "REMOTE HOST IDENTIFICATION HAS CHANGED" when trying to push a commit to Qt gerrit. Not sure what happened, is my network in danger? ``` > git push gerrit HEAD:refs/for/dev @@@ @WARNING: REMOTE H
[Development] Code-Review
Hi everyone, who can inspect this patch? https://codereview.qt-project.org/c/qt/qtbase/+/442088 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] [Announce] Qt Creator 9 RC released
2022-11-10
Thread
List for announcements regarding Qt releases and development via Announce via Development
We are happy to announce the release of Qt Creator 9 RC! https://www.qt.io/blog/qt-creator-9-rc-released -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Re: [Development] How qAsConst and qExchange lead to qNN
Hi Marc, >> I would like to know how that is supposed to work in practice. We have a >> lot of public API dealing with Qt containers all over. What are you >> going to do to, for example, to >> >> void addActions(const QList &actions); >> >> in qwidget.h? What should it look like when we're d
Re: [Development] (was: Re: C++20 @ Qt)
On 10.11.22 09:25, Marc Mutz via Development wrote: > Given that Integrity seems to be the only tool-chain missing > in dev, I propose the following policy going forward: > > > To detect post-C++17 library features, we require that exists. Proposed change: https://codereview.qt-project.org/c/
Re: [Development] (was: Re: C++20 @ Qt)
Hi, Given that Integrity seems to be the only tool-chain missing in dev, I propose the following policy going forward: > To detect post-C++17 library features, we require that exists. That means that if does not exist, we will not detect post-C++17 library features on that platform, even i
