Hi,
Following QUIP-2, I’d like to nominate Alexei Cazacov
for approver rights within The Qt Project. Since he joined The Qt Company in
May 2024, he has been doing excellent work on the documentation of Qt.
I fully trust that he will use his approver rights diligently.
His Gerrit Dashboard: ht
Hi,
this idea of 'embedding' was discussed a while ago, but seems to have major
limitations:
https://bugreports.qt.io/browse/QTBUG-83396
Citing Olli:
"I had a look at embedding the natvis files into Qt's pdb files and ran
into
https://developercommunity.visualstudio.com/content/problem/2
Hi,
The colors got recently adapted to better match other qt.io pages, and also
improve readability. That has little to do with Qt Framework vs Qt Group
though. On the contrary, you might notice that the new dark theme actually uses
a green instead of blue for links!
Related task: https://bugr
Hi,
I don't feel strongly about '\since 5.x' , or '\since 4.y '. Given that it
doesn't show up in the
generated documentation, it is IMO of little value, and I was
happily approving such changes in the past. But it's also true that it doesn't
cost us much
to keep these lines, so if people that
Hi,
Let me add a bit of a bigger picture here.
I think we all share the goal of making the Qt Framework and tools as
high-quality and robust as possible. We've also been continuously investing in
this, be it on the technical side or on the process side. But the world is
changing, and the expec
Hi,
We have quite a few Qt examples and tutorials that share assets (images,
sources, ...) via relative paths in the file system. That is, there's often a
'shared' directory that multiple examples use by relative paths (see e.g.
https://code.qt.io/cgit/qt/qtdeclarative.git/tree/examples/quick/
Hi Volker!
> From: Volker Hilsheimer
> Sent: Tuesday, March 5, 2024 10:40
> To: Kai Köhne
> Cc: development@qt-project.org
> Subject: Re: [Development] Extending qt_attribution.json files to mark
> provisioned components
>
>
>
>> On 4 Mar 2024, at
Hi Marc,
I've nothing against using '#pragma once' for private/internal headers.
But you said you mainly want to have this to differentiate between different
types of headers. If this is the motivation, I think we can make this
differentiation even more explicit. For instance, public headers co
Hi,
I suggest extending our qt_attribution.json format to explicitly mark
third-party components not part of the Qt sources, like
https://doc.qt.io/qt-6/qtmultimedia-attribution-ffmpeg.html.
QUIP-7 change:
https://codereview.qt-project.org/c/meta/quips/+/545126?usp=search
qtattributionsscanne
> MSVC2019 and MSVC2022 is supposed to be compatible. So in theory at least
> packages made with MSVC2022 is still usable for MSVC2019 as well. It is just a
> question of which compiler we use to generate the binaries with.
That's not the case, at least according to Microsoft
(https://learn.micro
Hi,
also a reminder from my side: When checking out any API changes, please also
check the API _documentation_.
A good start for this is https://doc-snapshots.qt.io/qt6-6.7/newclasses67.html
New API
* Is it documented, and marked with \since?
* Is the documentation in good shape (grammar, styl
Hi,
QDoc needs to parse C++ sources to actually generate the API documentation.
This requires a build where
the modules are actually configured. This explains some of the warnings you see
- Qt WebEngine, Qt PDF cannot be built on MinGW, and likewise Qt Wayland
(Compositor).
Anyway, like Paul s
Hi,
Eddy and Ivan did a great job in documenting how to formally deprecate API in
at https://wiki.qt.io/Deprecation . It's not only giving you the right macros
to use ... it also contains some suggestions for which version to do it.
About the Qt version to deprecate an API for, the page says:
Hi,
I suggest extending QUIP 13 [1] with a paragraph explaining that we shouldn't
pre-declare Qt types in Qt examples:
https://codereview.qt-project.org/c/meta/quips/+/503709
For the reasoning: While it's good practice to pre-declare referenced types in
header files in our tools and Qt library
Hi,
I've been reviewing some of the Qt 6.6 API diff's lately, focusing on the API
documentation. And frankly speaking, there was (and still is) a lot to improve
...
In particular, if you are the original *reviewer of any public API change*,
please check:
* Is there documentation for *new publ
Not an GCC expert, but this is the code that emits the warning in GCC:
https://github.com/gcc-mirror/gcc/blob/66be6ed81f369573824f1a8f5a3538a63472292f/gcc/attribs.cc#L1818
First argument for warning() is 0 ... which explains why it cannot be easily
disabled with say -Wno-ignored-attributes.
I t
> The question you must answer is why git
> submodule update isn't checking those
> commits out for those submodules.
>
> Anyway, why are you checking out 6.2.4 using Git?
That's the key: qtlocation and qtspeech weren't part of 6.2 qt5.git. So when
switching from dev to 6.2.4, 'git checkout' lea
> I followed what you said, build qminimal manually.
> However, after that, it still failed to build docs target.
Like I said in a previous mail, you need qminimal and qsqlite (at least if you
don't use latest dev). So make this:
cmake --build . --parallel 4 --target qminimal qsqlite
cmake -
> so running
> $ ninja qdoc qtattributionsscanner
> qhelpgenerator.
> should hopefully be sufficient
Actually both are dependencies of the doc target. And since
https://codereview.qt-project.org/c/qt/qttools/+/494893, just running
configure
cmake --build . docs
should be enough. If you're u
> From: Development on behalf of Yang Fan
>
> Sent: Thursday, July 20, 2023 3:55 AM
> To: Cristian Adam
> Cc: development@qt-project.org
> Subject: Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW
>
> I wanted to point out that MSYS2 offers precompiled packages of Qt6 in
> four di
> -Original Message-
> From: Development On Behalf Of
> Hasselmann Mathias via Development
> Subject: Re: [Development] Support for *Notes and UpstreamFiles fields in
> qt_attributions.json files
>
> Hi,
>
> Just to make ensure all options are considered: How about the elephant in the
>
Hi,
Does moving the information closer to the code make sense? Most of the
information provided in the wiki is already part of the qt_attribution.json
files that we use to generate the official documentation about third party
modules. What’s missing is the ‘process untrusted content’ flag, whic
> -Original Message-
> From: Edward Welbourne
> Sent: Wednesday, February 15, 2023 10:45 AM
> To: Kai Köhne
> Cc: Development@qt-project.org
> Subject: Re: Support for *Notes and UpstreamFiles fields in
> qt_attributions.json
> files
>
> Kai Köhne (15 February 2023 08:50) replied:
> > d
> -Original Message-
> From: Development On Behalf Of Ulf
> Hermann via Development
> Subject: Re: [Development] Support for *Notes and UpstreamFiles fields in
> qt_attributions.json files
>
> YAML is really quite terrible. If we're going to switch, let's choose
> something
> else.
>
>
Hi Eddy,
> -Original Message-
> From: Development On Behalf Of
> Edward Welbourne via Development
> Sent: Tuesday, February 14, 2023 3:14 PM
> To: Development@qt-project.org
> Subject: [Development] Support for *Notes and UpstreamFiles fields in
> qt_attributions.json files
>
> Hi all,
>
Hi,
We’ve been looking into this. I’m convinced now that the data Vladimir was
looking at on the server side is the one shown in the “Compiler Information” in
the Telemetry view of Qt Creator. This is the compiler Qt Creator was built
with though, not the compiler that Qt Creator uses for compi
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
> -Original Message-
>[...]
> > MANDATORY
> >
> > Do not use QT_BEGIN_NAMESPACE ... QT_END_NAMESPACE for example
> types. This namespace is exclusively for types in the Qt libraries.
>
> This is broken. How is one going to correctly forward declare Qt names
> in a namespaced build of
28 matches
Mail list logo
