On 17.03.25 20:09, Jøger Hansegård via Development wrote:
[...]
> I agree that it would be nice to have a compiler error but given that
> QStringList behaves the same way as std::vector, I am not sure it is a bug.
For the specific case of QList, we could take first and last by
reference, prevent
Thanks for your answers! So it's a lethal combo of string literals and
iterators, something to keep in mind when writing C++.
Rgrds Henry
n 2025-03-17 20:09, Jøger Hansegård wrote:
Obviously I am doing something wrong when setting o4 but it would be nice if I
could get a compile error...
Hi
On Monday, 17 March 2025 13:39:42 Pacific Daylight Time Mathias Hasselmann via
Development wrote:
> To avoid bloating you code with QString{}, QStringLiteral{} or
> QLatin1String{} boilerplate after enabling QT_NO_CAST_FROM_ASCII you
> also might consider using UTF-16 string literals (u"your text"
I really want to highlight Igors advice to define QT_NO_CAST_FROM_ASCII.
It really removes countless traps when using Qt, and will give you a
much more pleasant experience.
To avoid bloating you code with QString{}, QStringLiteral{} or
QLatin1String{} boilerplate after enabling QT_NO_CAST_FROM
> Obviously I am doing something wrong when setting o4 but it would be nice if
> I could get a compile error...
Hi Henry,
Yes, this recently confused me as well, and here is what I found:
The issue is that QStringList("g","goessouth") behaves the same way as
std::vector(“g","goessouth"). In b
Hi,
This is a really unfortunate (and all too common) case...
o4 is invoking the QList(InputIterator, InputIterator) constructor, with
the `InputIterator` type being deduced as `const char *`. This is a
valid iterator type with traits specialization and everything, so this
constructor is a me
Hello, there are a more than one way to initialize a QStringList but
sometimes they are not equal, consider this console app:
main.cpp:
#include
#include "qcommandlineparser.h"
#include "qdebug.h"
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
QCommandLineParser lp
On Monday, 17 March 2025 01:28:44 Pacific Daylight Time Jani Heikkinen via
Development wrote:
> In the release branches, we got lots of 'nice-to-have's' picked in, which
> doesn't belong to the release branch at all.
Sometimes those nice-to-haves are dependencies for a must-have later in the
tre
On Monday, 17 March 2025 01:11:59 Pacific Daylight Time Marc Mutz via
Development wrote:
> I don't know how this goes in other modules, but in qtbase, I have been
> bitten so many times in the last weeks by missing cherry-picks that the
> issue needs some discussion. I don't want to step on any pa
Dennis has done a lot of great work on the Grpc module, I expect he'll take
good care of it going forward too.
+1
Mårten
From: Development On Behalf Of Alexey
Edelev via Development
Sent: torsdag 13. mars 2025 14:44
To: Qt development mailing list
Subject: [Development] Nominating Dennis Obe
I vote for +1, Dennis Oberst is doing great work with Qt GRPC module.
Regards,
Tatiana
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On 3/14/25 5:49 PM, Marc Mutz via Development wrote:
TL;DR: do _not_ approve patches that do not "pick-to:" according to
QUIP-16 or explain in the commit message why they deviate.
This reads as if QUIP-16 would require us cherry-picking to a lower branch.
The wording, however, is:
"Changes th
Hi, and thanks for the input!
QQuickImageProvider is an interface that returns rasterized images and is very
specifically for use with the Image component. It doesn't have support for
returning encoded files in any format (it doesn't have any requestPNG() or
requestJPEG(), and I don't think it
> -Original Message-
> From: Development On Behalf Of Volker
> Hilsheimer via Development
> Sent: maanantai 17. maaliskuuta 2025 9.59
> To: Marc Mutz ; development@qt-project.org
> Subject: Re: [Development] On Pick-to: and QUIP-16
>
>
> Marc,
>
> QUIP-16 documents what kinds of changes
On 17.03.25 08:58, Volker Hilsheimer wrote:
>> On 14 Mar 2025, at 17:49, Marc Mutz via Development
>> wrote:
>>
>> Hi,
>>
>> TL;DR: do _not_ approve patches that do not "pick-to:" according to
>> QUIP-16 or explain in the commit message why they deviate.
>>
>> Long version:
>>
>> Just a reminder
On 17.03.25 08:10, Jörg Bornemann wrote:
> On 3/14/25 5:49 PM, Marc Mutz via Development wrote:
>
>> TL;DR: do _not_ approve patches that do not "pick-to:" according to
>> QUIP-16 or explain in the commit message why they deviate.
>
> This reads as if QUIP-16 would require us cherry-picking to a
> On 14 Mar 2025, at 17:49, Marc Mutz via Development
> wrote:
>
> Hi,
>
> TL;DR: do _not_ approve patches that do not "pick-to:" according to
> QUIP-16 or explain in the commit message why they deviate.
>
> Long version:
>
> Just a reminder that QUIP-16¹ gives detailed instructions how far
17 matches
Mail list logo
