On Monday, 23 January 2023 05:06:13 PST Marc Mutz via Development wrote:
> Instead of changing to qint64 timeouts, as suggested, we should use
> chrono types. Here's why:
>
> - we do have QDeadlineTimer, which implicitly converts from chrono
>types, but
>- it has a Forever state, which is
On Monday, 23 January 2023 07:07:06 PST Kai Köhne via Development wrote:
> We also don't allow upgrading individual Qt modules, for instance.
qtwebengine being the exception, but indeed.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Cloud Software Architect - Intel DCAI Cloud Engineering
Hi,
> -Original Message-
> From: Development On Behalf Of
> [...]
> This is a binary compatibility breakage of sorts. Applications that were
> linked
> against Qt 6.4 or Qt 6.5, and want to run against Qt 6.6 won’t work unless Qt
> Multimedia is present.
This doesn't violate the binary
Hey Thiago,
On 22/01/2023 17:15, Thiago Macieira wrote:
On Tuesday, 17 January 2023 14:07:42 PST Thiago Macieira wrote:
The reason is that it is failing to parse a constant expression.
VS2019 is still supported by MSFT in "Mainstream" mode and will be for over
a year from today:
https://learn.
On 1/23/23 10:20, Friedemann Kleint via Development wrote:
As for Shawn asking whether the concatenation is deterministic; in my
experience, it is.
The concatenation is determinic and depends on the file order in the
CMake files and the batch size.
One ugliness I've noticed: CMAKE_UNITY_BU
Volker Hilsheimer via Development wrote:
> The question is whether this is a significant problem in practice. On
> Linux distributions, we can probably assume that Qt Multimedia is present
> if Qt TextToSpeech is present.
On almost all distributions (all those that do dependency tracking, which is
Hi,
TL;DR:
- don't use qin64 for durations
- use QDeadlineTimer for timeouts
- use chrono::{milli,micro,nano,}seconds for everything that doesn't have
Forever state
- don't implement chrono via integer overloads, do it the other way around
Not really C++20, rather C++11, but let's keep the C++
Hi,
I recently prototyped a few frequently requested features for Qt TextToSpeech,
in particular the ability to capture the generated audio data as a QByteArray
with the PCM bits. However, a QByteArray with PCM bits isn’t very usable unless
we also inform the client code which format those PCM
Hi,
thank you for the reponses; so we conclude that we should support it and use it
partially in COIN, ideally for slow platforms. I will try to focus on qtbase
and qttools. qtdeclarative would also be a worthy goal; would someone be up for
it? Basically the changes linked to
https://bugreport
