Re: [Development] first (was: Re: C++20 @ Qt)
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 meaningful for timeouts, but not > for intervals (QTimer with Forever interval?). In other words, use the std::chrono::duration types but not the std::chrono::time_point types. > - if we take qint64, then internally have to construct a chrono type >from it, it means Qt code is responsible for checking for overflow >(chrono::milliseconds need not support the full 64-bit range), >creating an artificial error state that wouldn't exist if we only >accepted chrono types. Add to qglobal.cpp: static_assert(sizeof(std::chrono::milliseconds::rep) == 8); We should do this anyway. > So, chrono types are > - more future-proof > - safer (both as in less possible errors in the implementation, as well >as more type-safe in the caller) > - self-explanatory (w.r.t. granularity) > - more expressive Agreed. > So, I suggest to port all duration-related APIs to , and make > the primary implementation, not vice versa. In any case, ndo ot > add 64-bit timeouts (ns granularity like QDeeadlineTimer is ok, because > std::chrono::nanoseconds has at least a 64-bit representation). Do not > add new integer-based duration properties. Use QDeadlineTimer if > 'Forever' is a valid value (e.g. timeouts). Agreed. Thanks for bringing this up in the mailing list. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt TextToSpeech: Adding dependency to Qt Multimedia - ok?
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 smime.p7s Description: S/MIME cryptographic signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt TextToSpeech: Adding dependency to Qt Multimedia - ok?
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 compatibility guarantee per se, IMO. The guarantee is against the Qt framework itself, not against individual libraries in it. We also don't allow upgrading individual Qt modules, for instance. Anyhow, you could consider making the dependency optional at configure time. Then users who don't need it could still configure without qtmultimedia - no idea whether this is worth the hassle though. Regards Kai ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Do we need VS2019 for Qt 6.6?
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.microsoft.com/en-us/visualstudio/releases/2019/servicing-vs201 9 But VS2022 is 14 months old. So do we need both of them? No answer. Is that because: a) no one cares, so we can drop it. b) no one knows, so we can't drop it. Sorry for the delay. We need some more time to figure out if 2019 is still needed for 6.6. We will let you (and the mailing list) know later this week. Cheers, Olli ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake UNITY_BUILD ( QTBUG-109394 )
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_BUILD is documented to not play well with CMAKE_EXPORT_COMPILE_COMMANDS. This might hurt users of clangd (using clangd with Qt's sources). -- Jörg Bornemann | The Qt Company ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt TextToSpeech: Adding dependency to Qt Multimedia - ok?
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 almost all, with the notable exception of Slackware), if you upgrade Qt TextToSpeech to a version that requires and is linked to Qt Multimedia, it will automatically install Qt Multimedia as a dependency if it was not already installed (or upgrade it to the required version if it was installed in an older version). Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] first (was: Re: C++20 @ Qt)
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++ stuff together.
Since 2018, in QTBUG-67383, we have users complaining about the limited
range of int milliseconds arguments:
> Now QTimer::start(int msec) accepts only int values which corresponds
> to ~ 24 days as maximum time interval.
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 meaningful for timeouts, but not
for intervals (QTimer with Forever interval?).
- it's name doesn't exactly lend itself for use in APIs (why pass a
timer to a timer?)
- it always has nanosecond resolution. Most of our APIs have
millisecond resolution. Unless we want to change them all to ns
resolution, any function using QDT must document the real
granularity of the duration, and the rounding mode from ns. In
contrast, passing 1ns to a function taking chrono::milliseconds
simply fails to compile,forcing the caller to be explicit about what
he wants (chrono::floor, chrono::ceil, duration_cast, ...).
- we do support chrono types in many APIs, and we want to support them
in all APIs that deal with duration, as 1s is just so much more expressive
than '1000'. The integer-based APIs should be considered legacy
support. At some point, we might want to deprecate them, and then the
chrono overloads become the main implementation, anyway, so we might
just go there directly.
- if we take qint64, then internally have to construct a chrono type
from it, it means Qt code is responsible for checking for overflow
(chrono::milliseconds need not support the full 64-bit range),
creating an artificial error state that wouldn't exist if we only
accepted chrono types.
- if we take a chrono type, then shoehorn it through a legacy int
overload, we lose the range provided by the chrono types and
requested by users
So, chrono types are
- more future-proof
- safer (both as in less possible errors in the implementation, as well
as more type-safe in the caller)
- self-explanatory (w.r.t. granularity)
- more expressive
So, I suggest to port all duration-related APIs to , and make
the primary implementation, not vice versa. In any case, ndo ot
add 64-bit timeouts (ns granularity like QDeeadlineTimer is ok, because
std::chrono::nanoseconds has at least a 64-bit representation). Do not
add new integer-based duration properties. Use QDeadlineTimer if
'Forever' is a valid value (e.g. timeouts).
There's no rush, we need to get the plumbing in QtCore right, first.
Comments?
Thanks,
Marc
--
Marc Mutz
Principal Software Engineer
The Qt Company
Erich-Thilo-Str. 10 12489
Berlin, Germany
www.qt.io
Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen
Sitz der Gesellschaft: Berlin,
Registergericht: Amtsgericht Charlottenburg,
HRB 144331 B
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
[Development] Qt TextToSpeech: Adding dependency to Qt Multimedia - ok?
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 bits are in - sample rate, channel count, and sample format. We have a class in Qt that nicely encapsulates this kind of information: QAudioFormat from Qt Multimedia. However, Qt TextToSpeech as reintroduced in Qt 6.4 does not generally depend on Qt Multimedia. It depends on it for the Windows Media engine (“winrt”) and for the flite engine on Linux, as from those engines we anyway get the PCM data that we then play ourselves via QAudioSink. For other engines - the two engines on macOS, the Android engine, the SAPI engine on Windows, and the “speech-dispatcher” engine on Linux - we don’t depend on Qt Multimedia today. So the dependency to Qt Multimedia is listed as an “OPTIONAL_COMPONENT” in the build system of Qt TextToSpeech. Adding an API that uses QAudioFormat to the public QTextToSpeech class, or adding the dependency to all engines, would add this as a “REQUIRED" dependency though. 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. 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. Applications that get deployed with a bundled Qt don’t have a problem anyway - they can include Qt Multimedia in that bundle, or continue to ship the old Qt TextToSpeech. The alternative is to either not use Qt Multimedia types where they aren’t used already, which means essentially duplicating QAudioFormat (and perhaps other types in the future); or to craft a separate "Qt TextToPCM” module with the new functionality. Both seem rather silly. What do you think? I’m not aware of any precedence to this particular scenario in recent history, but maybe there have been cases. Perhaps we only want to promise binary compatibility for Qt as a whole (on https://wiki.qt.io/Qt-Version-Compatibility, somewhat outdated, we limit the promises to Qt Essentials, which Qt TextToSpeech is not). Volker ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake UNITY_BUILD ( QTBUG-109394 )
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://bugreports.qt.io/browse/QTBUG-109394 and https://bugreports.qt.io/browse/PYSIDE-2155 give you an idea what to do. As for Shawn asking whether the concatenation is deterministic; in my experience, it is. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
