On 3/15/24 18:09, Marc Mutz via Development wrote:
I like simple rules. "Overrides should have the same access level as the
initial virtual function." is a simple rule.
But it makes no sense in general. The base class is the interface, and
overrides should have the least possible visibility
On 9/15/23 09:36, Kai Köhne via Development wrote:
The methods are formally marked as deprecated for Qt 6.10. But the methods are
already in the '-obsolete' page for Qt 6.6, which leaves the API in a weird
in-between state.
Radical idea: Treat all deprecated functions as if they didn't
On 2/2/23 16:38, Vladimir Minenko wrote:
In 2022 and 2023, around 24M builds ran on Windows in around 600K unique
installations worldwide which had at least 10 builds in this period of time.
Not even a single one used MSVC2022.
That's difficult to believe. I'm inclined to think the version
On 1/18/23 19:56, A. Pönitz wrote:
As a data point, even at it's height of .ui usage, Qt Creator (which is
a "namespace aware" code base, see https://wiki.qt.io/Qt_In_Namespace)
needed the QT_*_NAMESPACE for about 30 of its >200 .ui classes, and
that in the presence of ~680 places where it was
On 1/12/23 01:24, Thiago Macieira wrote:
On Wednesday, 11 January 2023 15:29:11 PST Jon Trulson wrote:
Will these be returning at some point?
No.
Out of curiosity: Who gains what by removing branches?
Christian
___
Development mailing list
On 11/22/22 22:27, A. Pönitz wrote:
I'd like to nominate Marcus Tillmanns as an approver for the Qt project.
+1
Christian
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
On 10/10/22 17:13, Thiago Macieira wrote:
The biggest problem we used to have was installing builds that had
include
paths pointing to both the source and installation directory. With
preprocessor guards, only one of the two would actually get included; with
#pragma once, the files are actually
