Le ven. 9 août 2024 à 01:56, Mike Trahearn <
miketrahe...@imagineuisoftware.com> a écrit :
> To Ulf’s point,
>
> You would indeed not be able to restore a previous value using text:
> fooObject?.title ?? text because it will have been overwritten whenever
> fooObject?.title yields a valid value.
>
Thiago Macieira wrote:
> All of KDE libraries and applications, for example, don't care about MSVC
> compatibility
Huh, since when?
Last I checked, there were people building KDE Frameworks and several KDE
Applications with MSVC (as well as with MinGW, but there are a few reasons
why they do no
To Ulf’s point,
You would indeed not be able to restore a previous value using text:
fooObject?.title ?? text because it will have been overwritten whenever
fooObject?.title yields a valid value.
The most reasonable solution therefore is to use the Binding element which is
designed to restore t
On Thursday 8 August 2024 11:22:39 GMT-7 Thiago Macieira wrote:
> My solution is to have moc parse a new declaration Q_DECLARE_FLAGS64, which
> indicates the flag is 64-bit, and then generate different data. I have not
> implemented Q_FLAGS64 or Q_ENUM64 yet.
An alternative solution I am looking i
See https://codereview.qt-project.org/c/qt/qtbase/+/580778
I'm working on the ability to support 64-bit QFlags. My solution for that is
to have QFlags64 and keep sizeof(QFlags) == 4 for any T. I have two reasons
for that choice:
1) BC of QFlags in existing structures and parameters
I want to av
