Alex Blasche wrote:
> 2.) An alternative might be to make this change in one go for Qt 7. We
> would keep Qt 6.x on the status quo but start adding compatible
> replacement APi with an absolute change at 7.0 (ifdefs or typedefs come to
> mind). Users would only be burdened one time (though it being
Hi Volker,
>
>From: Development on behalf of Volker
>Hilsheimer
>I agree that it would be great if users of Qt could flip on aggressive compile
>options to get warnings about narrowing-conversions.
>But again, is that worth it? And is that more importa
Qt 6.3 status:
- Qt 6.3.2 preparations still ongoing
* All needed fixes should be in and final dependency update round ongoing
* Target is to release Qt 6.3.2 as soon as possible
** latest estimation Fri 9th September
Qt 6.4 status:
- Qt 6.4.0 Beta4 released
- Branching from '6.4' to '
> On 5 Sep 2022, at 19:15, Marc Mutz wrote:
>
> Hi,
>
> Experience shows that we'll have many, many, many things to consider come Qt
> 7. And as Qt 6 has shown, such trivialities will be left by the wayside. So,
> playing the devil's advocate here: if this work is too much for Qt 6.x, what
>
Volker Hilsheimer (5 September 2022 17:31) wrote:
>> We have virtual functions that take int and could potentially be fed
>> by the return value of container.size() (or generally need to be able
>> to handle values >2G), so should take a qsizetype (say,
>> QAbstractItemModel::insertRows, overridden
