Hi.
I tried to start a similar discussion in October [0], but there was no real
conclusion apart from "let's decide on a case-by-case basis".
My idea was that we can at least use the new to-be-removed approach on the
APIs that we consider wrong or dangerous. But the reality is that we cannot
agre
> error: "qtmochelpers.h not found or too old.”
Should be fixed by https://codereview.qt-project.org/c/qt/qtscxml/+/604244
--
Ivan
From: Development on behalf of Volker
Hilsheimer via Development
Sent: Thursday, November 14
nt on behalf of Nicolas
Fella via Development
Sent: Thursday, 24 October 2024 19:36
To: development@qt-project.org
Subject: Re: [Development] Deprecated vs deprecated-to-be-removed APIs in Qt
Am 24.10.24 um 16:32 schrieb Ivan Solovev via Development:
Hi,
following up on the Deprecation vs Compa
> Here's another one: formatting of floating point types.
>
> That's a hard pass on the Standard Library implementations. We already carry
> code for this in the form of libdoubleconversion, so unless we can ditch that
> in favour of the Standard Library content, we shouldn't use both, which would
t-like tr()
On Thursday 24 October 2024 03:22:55 Pacific Daylight Time Ivan Solovev via
Development wrote:
> > Unfortunately, I think we'll need the entire parsing and constructing done
> > from scratch.
>
> IMO, we could benefit from the new syntax, if we could build our
> imp
Hi,
following up on the Deprecation vs Compatibility discussion from
the Qt Contributor Summit [0], I implemented a macro that allows to mark
the APIs as deprecated and to-be-removed in the Next Major Release [1].
[0]: https://wiki.qt.io/QtCS2024_Deprecate
[1]: https://codereview.qt-project.org/
Hi Volker,
> From my understanding, the idea behind the std::format framework would be
> to have a “cardinality" type for which we can implement a special formatter,
> allowing “whatever” to be in the format specification.
True, but the custom formatter specialization is called when the argument
.org; Volker Krause; albert astals cid
Cc: Ivan Solovev
Subject: Re: [Development] format-like tr()
On Wednesday 23 October 2024 02:22:51 Pacific Daylight Time Ivan Solovev via
Development wrote:
> Hi Thiago,
>
> first of all, could you please clarify, how do you see the potentia
Hi Thiago,
first of all, could you please clarify, how do you see the potential
implementation?
Do you think that we can reuse some of the things that std::format
provides, or do we need to write everything from scratch?
For my patches that add std::format support to QByteArray(View),
I implement
Hi Thiago,
Do I understand it correctly that the approach with constexpr functions will
allow us to solve the problems with moc (point 2 from the first e-mail
of the thread)?
If yes, then I think we should try to implement that approach, and do not
introduce a separate class for 64-bit QFlags.
>
Hi,
> I have a side question for this discussion(raised by Ivan in personal
> conversation):
> Should we also force the -fexec-charset= for the gcc-like compilers?
> Currently we use the system default one, which in most cases is UTF-8.
actually, I raised this question in the personal conversati
331 B
From: Development on behalf of Thiago
Macieira
Sent: Friday, June 7, 2024 6:25 PM
To: development@qt-project.org
Subject: Re: [Development] std::format support for Qt string types
On Friday 7 June 2024 08:40:33 GMT-7 Ivan Solovev via Development wrote:
> IIUC, the
> I would like to fix
> QASV(char) to mean QASV(QChar(char)), not redefine char literals as
> UTF-8 and break many more users (QASV is relatively new; QChar(char) and
> QString::arg(char) are there since before Qt 4).
>
> What do you think?
+1 for this proposal.
I do not think that QASV(char) pro
PM
To: development@qt-project.org
Subject: Re: [Development] std::format support for Qt string types
On Friday 7 June 2024 01:53:55 GMT-7 Ivan Solovev via Development wrote:
> Note that currently the standard does not allow to mix char and wide char
> strings, so something like this will no
Hi
> I think we should conceptually separate formatting from printing on a
> terminal. std::format isn't _just_ for printing on terminals
I agree. But the same question about encoding to be used is still valid here.
> What do you mean by "readable" here?
I was mostly thinking about "readable in
Hi,
I'm now working on introducing std::format support for some of the Qt types.
I decided to start with the variety of Qt string types, and I have some open
question regarding the implementation that I want to discuss.
First, I'd like to give a very short summary of my understanding of how
std::
+1
Best regards,
Ivan
From: Development on behalf of Alexey
Edelev via Development
Sent: Thursday, May 30, 2024 8:46 AM
To: development@qt-project.org
Subject: [Development] Nominating Dennis Oberst for approver rights
Hi all,
I would like to nominate Denni
> The ABI functions can return one of these other types:
> bool (for equality comparisons)
> int (for non-partial ordering)
> QPartialOrdering (for partial ordering)
IIUC, returning QPartialOrdering is exactly what we want to avoid, due to the
std::partial_ordering -> QPartialOrdering (and re
@ Qt)
On 13.11.23 17:15, Thiago Macieira wrote:
> On Monday, 13 November 2023 01:34:08 PST Ivan Solovev via Development wrote:
>> Thiago wrote:
>>> The problem is that QPartialOrdering::Unordered has been in our ABI since
>>> 6.1 and we can't change that any more.
>
Thiago wrote:
> The problem is that QPartialOrdering::Unordered has been in our ABI since 6.1
> and we can't change that any more.
Well, Marc already suggested a solution for this problem.
Let's just introduce Qt::{strong,weak,partial}_ordering and deprecate
QPartialOrdering
in favor of the new t
Marc wrote:
> Why do you say it only applies to partial ordering? Do we already match
> the values, other than that of std::partial_ordering::unordered?
Yes, we do.
Thiago wrote:
> We can also just be evil and use bit_cast
Why is that evil? Reading about std::bit_cast, this can be an option, if
> I think it's acceptable for us to change the return type of a function so long
> as it's getting a new mangling.
Well, it would be easily achievable for the template methods, but not for the
inline hidden friend helper methods.
As immediate solution that comes to my mind is to add a third argume
+1
--
Ivan Solovev
Senior Software Engineer
The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenbur
Hi,
I'd like to discuss one more topic regarding the C++20 comparison.
Can we allow an `auto` return type in helper functions and the three-way
comparison implementation for the built-in types?
The idea is that these methods can return `Q*Ordering` types in C++17 mode, and
`std::*_ordering` type
So, let me give another update.
The chaing ending in https://codereview.qt-project.org/c/qt/qtbase/+/508464
passed a full pre-check in the CI.
It implements the macros in terms of helper functions ``comparesEqual()``
and ``compareThreeWay()``.
The macros are documented as internal for now.
It als
144331 B
From: Development on behalf of Ivan
Solovev via Development
Sent: Thursday, September 21, 2023 11:10 AM
To: development@qt-project.org
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
> See my other email: the (1) is not discovera
ch-Thilo-Str. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
From: Development on behalf of Ivan
Solovev
> I have just rebased the chain on top of the latest dev and fixed the issue
> with qfloat16 and -Wfloat-equal.
> Now it builds fine for me locally on Linux with GCC. Started a full pre-check
> in the CI to test other configurations.
> I'll keep an eye on the pre-check results and try to fix any ot
Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On 20.09.23 14:42, Ivan Solovev via Development wrote:
> We have deprecated qSwap()
FTR:
We did _not_ deprecate qSwap(). We banned it from inline Qt code when we
know we can use one of the other ways:
- lhs.swap(rhs);
- s
Hi,
> Given the state of https://codereview.qt-project.org/c/qt/qtbase/+/481410/3
> right now (needs rebase, doesn’t build with either C++17 or C++20 for me on
> macOS with apple’s clang)
I have just rebased the chain on top of the latest dev and fixed the issue with
qfloat16 and -Wfloat-equal
wap`s at the global scope and stop there. Since it found something, it
will not consider ADL.
If you have more, let's hear it.
Thanks,
Marc
On 17.08.23 19:41, Thiago Macieira wrote:
> On Monday, 14 August 2023 03:16:37 PDT Ivan Solovev via Development wrote:
>>> What I meant is that
Hi,
> I see two fixes for this;
> - Keep the documentation API fix separate from the header file fix, and only
> merge it when Qt 6.9 got branched.
> This requires 'someone' to follow up on these things, though, more than a
> year after the deprecation decision has been made.
This approach will
> I would therefore propose to remove the file from qt5.git:
+1 from my side.
I believe I simply do not have the clang-format tool installed on my system,
because it usually breaks the formatting of the patches, not improves them.
> One way to address these problems, especially for new devs or dr
+1
--
Ivan Solovev
Senior Software Engineer
The Qt Company GmbH
Erich-Thilo-Str. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenbur
o
Macieira
Sent: Tuesday, August 1, 2023 5:11 PM
To: development@qt-project.org
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Tuesday, 1 August 2023 01:55:05 PDT Ivan Solovev via Development wrote:
> > BTW, this needs to integrate with QEqualityOperatorForT
0 comparisons @ Qt (was: Re: C++20 @ Qt)
On Monday, 31 July 2023 02:36:41 PDT Ivan Solovev via Development wrote:
>> Basically, what you suggest is that for every pair of comparable Qt
>> types we would need to double the amount of work that we do - provide
>> not only the helper fun
144331 B
From: Thiago Macieira
Sent: Wednesday, July 26, 2023 5:18 PM
To: development@qt-project.org
Cc: Ivan Solovev
Subject: Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)
On Wednesday, 26 July 2023 02:58:51 PDT Ivan Solovev via Development wrote:
&g
ftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
From: Thiago Macieira
Sent: Tuesday, July 25, 2023 4:42 PM
To: development@qt-project.org
Cc: Ivan Solovev
Subject: Re: [D
o-Str. 10
12489 Berlin, Germany
ivan.solo...@qt.io
www.qt.io
Geschäftsführer: Mika Pälsi,
Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht
Charlottenburg, HRB 144331 B
____________
From: Thiago Macieira
Sent: Tuesday, July 25, 2023 2:11
Hi,
let me try to revive the discussion, because we want the C++20 comparison task
to be finished for Qt 6.7.
> > And we have the calling convention:
> > lhs.O(rhs);
> > Qt::O(lhs, rhs); // if you know the type
> >
> > using Qt::O;
> > O(lhs, rhs);
> > . // if you don't
>
Hi,
> Second, it's also easy to forget that since there's no receiver/context,
> the connection is always forced to be *direct*, which complicates things
> if multiple threads are involved.
I'm not a module maintainer, but I remember fixing a bug in Qt Bluetooth which
was caused by exactly this
> (*) That macro that does nothing until C++20 anyway, so I’d also add the
> support for the optional string-literal that C++20 also introduces..
Our tests actually show that this macro provides an expected warning on most of
the compilers that we use in the CI, even in C++17 mode.
IIRC, in my
Hi Jani,
> 3 exception requests so far:
> - C++20 comparison: exception request accepted
> - container-assign epic: exception request rejected
I think it's the other way around - the container-assign epic is accepted, and
the C++20 comparison is rejected.
Best regards,
Ivan
PM
To: development@qt-project.org
Subject: Re: [Development] Requesting Feature Freeze Exception for C++20
comparison
On Friday, 2 June 2023 05:18:57 PDT Ivan Solovev via Development wrote:
> I'd like to request a Feature Freeze exception for the C++20 comparison
> task, due to the
Hi,
I'd like to request a Feature Freeze exception for the C++20 comparison task,
due to the last-minute discussions about the names of the helper functions to
be used. This is important because these helper functions are intended to be
exposed as public API.
The task is https://bugreports.qt.
Hi!
+1 to all suggestions
Best regards,
Ivan
From: Development on behalf of Marc Mutz
via Development
Sent: Tuesday, May 9, 2023 8:51 AM
To: qt-dev
Subject: [Development] Proposing changes to https://wiki.qt.io/Qt_Coding_Style
Hi,
I'd like to propose the fo
Hi,
+1 to the approach suggested by Kai.
Having comments would be very helpful, but I do not think that we need a
separate comment field for each entry.
Best regards,
Ivan
From: Development on behalf of Kai Köhne
via Development
Sent: Tuesday, February 14,
Hi,
Should the example updates be picked to 6.5, or is it only a 6.6 thing?
Is there any general guideline from the Release Team?
Best regards,
Ivan
From: Development on behalf of Kimmo
Leppälä via Development
Sent: Wednesday, January 18, 2023 10:51 AM
To: deve
Hi Jani,
I'm not sure that I understand your proposal.
Currently we have FF on the 9th of December, and the release in March. So, it's
roughly 3 months between FF and release.
Now you propose to shift FF to January (I assume, also around 10th ), and the
release to April. That gives the same 3 m
Hi Thiago,
> Now at https://codereview.qt-project.org/c/qt/qtbase/+/444222
Thanks for sharing it!
> In fact, I came up with a better solution yesterday after sending this email:
move the support to QUuid. This allows us to have the new (mostly) source-
compatible API in place and simply move the
Hi Thiago,
> I was working on extended integers and added qint128 and quint128 to qglobal.h
(qtypes.h)
Can you provide a link to your WIP patch? I tried to search but couldn't find
it in gerrit.
> it's used in the API, with a constructor and a toUInt128(), but that's
all. It's also not document
> 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
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
53 matches
Mail list logo
