On Monday 10 June 2024 21:51:21 GMT-7 Marc Mutz via Development wrote:
> - change `char` to be consistently U8 (in case it wasn't obvious, this
>_silently_ breaks (probably large amounts of) existing code - _now_,
>independent on the second step here (keep behaviour or also phase out
>c
On 10.06.24 23:13, Thiago Macieira wrote:
> On Monday 10 June 2024 05:39:26 GMT-7 Marc Mutz via Development wrote:
>> Since there are four bugs³ in QString::arg() that are all fixed by the
>> existing patch chain porting the whole thing to QAnyStringView, and
>> since the medium-term goal is to dep
On Monday 10 June 2024 05:39:26 GMT-7 Marc Mutz via Development wrote:
> Since there are four bugs³ in QString::arg() that are all fixed by the
> existing patch chain porting the whole thing to QAnyStringView, and
> since the medium-term goal is to deprecate use of char for characters
> and char[]
Hi Arno,
there has been no further development on making QObjectBindableProperty public,
or much work at all when it comes to extending bindable properties and their
usage inside Qt. The most substantial feature was an external contribution to
support QBindable from non-QProperty based properties,
> 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
Hi,
TL;DR:
- QASV(char) is UTF-8, but QChar(char) is L1
- propose to fix QASV, not QChar
- iow: char literals remain L1, not become UTF-8
- but char[] remains UTF-8
- propose to deprecate char and char[] literals for u8 and _L1 in Qt 7
(= make QT_NO_CAST_FROM_ASCII the default)
While
Hey everyone,
in our codebase, we have a lot of property setters with side-effects.
We'd still like to introduce bindable properties - they're awesome!
However, QObjectBindableProperty/QProperty require trivial setters, so
that doesn't work for us. Qt uses Q_OBJECT_COMPAT_PROPERTY internally
Volker Hilsheimer (10 June 2024 10:38) wrote:
> We added QT_TECH_PREVIEW_API to 6.7 after 6.7.0 (because the tag
> wasn’t available in time for 6.7.0) so that we can see that difference
> when we remove it against from 6.8 (with the intention of informing
> reviewers about that change), and that’s
We added QT_TECH_PREVIEW_API to 6.7 after 6.7.0 (because the tag wasn’t
available in time for 6.7.0) so that we can see that difference when we remove
it against from 6.8 (with the intention of informing reviewers about that
change), and that’s now completely invisible.
Also header changes in 6