[Development] Qt Examples need to be self-contained

[Kai Köhne via Development]

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/shared). My 
suggestion is to officially ban this, and

  *
either duplicate the relevant sources and assets in the respective example 
directories, or
  *
create a static 'QtModuleExamplesPrivate' library that is built as part of Qt, 
and can be referenced by these examples - something we already discussed & 
implemented before e.g. for sharing icons.

Proposed change in QUIP-13  is at 
https://codereview.qt-project.org/c/meta/quips/+/546086

Why this change? Qt Creator 13 will get a feature to shorten build paths by 
creating Junction Points (basically symbolic links) on Windows. This is to 
prevent file paths and build command lines from becoming too long, an issue 
that has been a never-ending source of frustration especially for new users on 
Windows

The issue of long file paths breaking builds is something that has been 
impeding users since forever. It became even more urgent though in the last 
years due to the deep nested structures that Qt Quick and the relevant tooling 
endorses (see e.g. https://bugreports.qt.io/browse/QTBUG-117413). Its root 
cause can arguably only be fixed on Microsoft's side - but chances for this are 
IMO slim ... So, shortening build paths as part of Qt Creator seems our best 
'general' cure for now. As the build path will however not be the source path, 
navigating across the file system with things like

  #include "../../../../shared/shared.h"

will break.

If we agree on this, we would prepare matching bug reports for affected 
examples.

Regards

Kai

PS: To be clear, this is not something we still have to fix for Qt 6.7.0.  For 
now, the use of Junction points in Qt Creator is still opt-in. When we fix 
examples, we should still backport them to older Qt versions though.


--

Kai Köhne, Director R | The Qt Company



The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin

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

Re: [Development] Extending qt_attribution.json files to mark provisioned components

[Kai Köhne via Development]

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 14:42, Kai Köhne via Development 
>>  wrote:
>>
>> 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
>> qtattributionsscanner change: 
>> https://codereview.qt-project.org/c/qt/qttools/+/545098
>>
>>
>> Let me know what you think.
>
>Commented on the review, but also here, slightly more prosaic:
>
>Being able to document 3rd party components that are included in Qt because we 
>provision and package them as part of the pipeline is a good idea. Both from 
>an 
> SBOM perspective, and because there are advantages in having a standardized, 
> descriptive, machine-readable documentation of all dependencies that any Qt 
> module 
> has. The question is whether the goal is for us to mark *all* 3rd party 
> components that way.
>
> E.g. we provision, compile and link against, and then package the runtime 
> libraries for FFmpeg or SQL client libraries. The provenance of those should 
> clearly be 
> documented in something less obscure than a (power)shell-script in 
> qt5.git/coin/provisioning.

Indeed. I still hope we can facilitate vcpkg as a more structured/easier to 
detect way than some provisioning script, but this is only making slow progress 
for a variety
of reasons. Btw, we also have the option to put in the qt_attribution.json 
files inside qt5/coin by now, so that it is nearer the actual provisioning code.

> But what about system libraries and SDKs where we don’t ship the runtime 
> (either because we expect those to be available on the target, because of 
> licensing, or 
> because we can dynamically detect the presence of the runtime and fail 
> gracefully). Those SDKs might have inline functions in their headers, 
> generating executable 
> code in a Qt artefact that we do deploy. 

In general, I think we should be as transparent as reasonably possible. But 
that approach with manually maintained qt_attribution.json files obviously has 
it's limits. 
I think it's hopeless to document e.g. single  copyrights of transitive Linux 
header dependencies this way ... We're actually also looking into build system 
tooling
for SBOM's that could automate the process.

For now, I'm seeing the qt_attribution.json files as a pragmatic approach for 
bigger items where the license actually mandates notifications and 
attributions, like the 
mentioned ffmpeg backend plugin.

> Or the tools that come with those SDKs might generate code that ends up 
> compiled into Qt. So strictly speaking, we should 
> list those as well, even though our Qt package doesn’t include any artefacts 
> from those?

Should we work towards completeness? Yes. But let's not block ourselves by 
perfectionism. Even the relevant SBOM standards acknowledge
that there will in practice always be a grey area, and allow indicating that 
there are 'known unknowns'.

Kai
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Using '#pragma once' instead of include guards?

[Kai Köhne via Development]

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 could get a

  // This header is part of the public Qt API.

comment. Much like the 'We mean it', or 'pragma once', syncqt could enforce 
this for public headers, and error out if it's used for non-public ones.

Kai


From: Development  on behalf of Marc Mutz 
via Development 
Sent: Thursday, February 29, 2024 11:02
To: development@qt-project.org 
Subject: Re: [Development] Using '#pragma once' instead of include guards?

Hi,

DL;DR: Use #pragma once in all non-installed headers

The question recently came up "what is a private header". And the answer
isn't just "_p.h, of course". We have tons of headers that are "private"
without being marked as such with _p.h and "We mean it." comment.

The first realization is that there are degrees of privateness: We have
the installed private headers, and then we have non-installed/able
headers, e.g. in plugins, or tools.

So we have
- public installed headers (subject to SC and BC, syncqt and
headerscheck runs on them)
- semi-public installed headers (like above, but not subject to SC (but
BC) (_impl.h, stuff in QtPrivate namespaces, qNN, ...)
- private installed headers (not subject to SC/BC/headersclean, but
syncqt runs on them, must have "We mean it." comment)
- private non-installed headers (not subject to any constraint, not even
syncqt runs on them)

We can now look at what signs we currently have available that guide a
reader to learn which kind of header he's looking at.

For the first, we have only location in $SRCDIR.

For the second, we have _impl.h and/or "We mean it." comment.

For the third, which is easiest to distinguish, we have _p.h and "We
mean it." comment. This is enforced by syncqt, which is why we can rely
on it 100%.

For the last one, we again have just the location in $SRCDIR.

The problem is, obviously, that the first and last cases are nearly
indistinguishable and require non-local reasoning to answer.

I think we have improve on this.

With Volker's email we gave ourselves permission to use #pragma once for
"non-SDK" (= non-installed) headers, and banned it for installed
headers. So if we could make syncqt complain if a processed (=
installable) header contains #praga once, we could then flip the coin
and use an actual #pragma once as a static assertion that the header is
not installed/able.

If we do this going forward, we can then easily distinguish the four
header kinds:

- public installed headers have a traditional header guard
- semi-public installed headers ditto, except that have _impl.h suffix
or "We mean it" comment
- private installed headers ditto, _p.h suffix and "We mean it" comment
- non-installed/able headers have #pragma once

I've implemented the check in syncqt.cpp and ported xcb over, see
https://codereview.qt-project.org/q/topic:pragma-once

I'm not suggesting to do such a port for all plugins. XCB is just a test
balloon, but we might want to apply the #pragma once trick for new code
going forward.

Thanks,
Marc

On 12.10.22 12:35, Volker Hilsheimer via Development wrote:
>
>> On 11 Oct 2022, at 22:11, Thiago Macieira  wrote:
>>
>> On Tuesday, 11 October 2022 12:25:13 PDT Kyle Edwards via Development wrote:
>>> Speaking as co-maintainer of CMake, we have effectively required #pragma
>>> once to build CMake itself since August 2017, we officially codified
>>> this as policy in September 2020, and we will soon be writing a
>>> clang-tidy plugin to enforce this in our CI. We have not received any
>>> complaints about it. Just my $0.02.
>>
>> Thanks for the information. This confirms what we already knew that all 
>> systems
>> and compilers where Qt would be compiled do support it.
>>
>> However, neither Qt Creator nor CMake are libraries. They are not comparable.
>
>
> Thanks all for sharing your insights and digging up the previous discussions 
> as well.
>
> The summary of all this then seems to be:
>
> - ok to use '#pragma once’ in headers that are not designed to be included by 
> Qt users, i.e. in tools, applications, examples and demos, tests
> - for everything else, in particular for public and, for consistency’s sake - 
> private headers in Qt, we continue to use conventional include guards
>
> Rationale: #pragma once is not well enough defined and not part of the 
> standard, and we cannot make any assumptions about how Qt is installed, used 
> as part of a larger SDK etc. So best to stay conservative.
>
> If that’s not entirely off, then I’d like to put this into 
> https://wiki.qt.io/Coding_Conventions [1], preempting perhaps a new thread on 
> this topic in a few years.
>
> Volker
>
> [1]: And since that page seems rather outdated - e.g. we do use dynamic_cast 
> in Qt today, and the 

[Development] Extending qt_attribution.json files to mark provisioned components

[Kai Köhne via Development]

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
qtattributionsscanner change: 
https://codereview.qt-project.org/c/qt/qttools/+/545098


Let me know what you think.

Regards

Kai



--

Kai Köhne, Director R | The Qt Company



The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin

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

Re: [Development] Let's drop MSVC 2019 for dev (6.8)

[Kai Köhne via Development]

> 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.microsoft.com/en-us/cpp/porting/binary-compat-2015-2017?view=msvc-170):
 
 You can mix binaries built by different versions of the v140, v141, v142, 
and v143 toolsets. However, you must link by using a toolset at least as recent 
as the most recent binary in your app. 

As almost all Qt users link against the Qt libraries, they need to, therefore, 
use at least the Microsoft Compiler version that the CI uses.

Kai
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] HEADS-UP: Qt 6.7 API change review

[Kai Köhne via Development]

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, style, completeness)? 
* Is it interlinked with related API, and related overview documentation?
* Should it be mentioned on https://doc-snapshots.qt.io/qt6-6.7/whatsnew67.html?

Deprecated API
* Is the API also deprecated in the documentation (including the Qt version it 
is first deprecated)?
* Is it explained why it is deprecated, or what to use instead?
* Should it be mentioned on https://doc-snapshots.qt.io/qt6-6.7/whatsnew67.html?

If in doubt, please file a bug on JIRA or reach out to one of the documentation 
writers.

Thanks!

Kai


From: Development  on behalf of Jani 
Heikkinen via Development 
Sent: Friday, January 5, 2024 6:49
To: development@qt-project.org
Subject: [Development] HEADS-UP: Qt 6.7 API change review

Hi!



Qt 6.7 API Change Review is finally started, see 
https://bugreports.qt.io/browse/QTBUG-119952

generated diffs are here:

  *   https://codereview.qt-project.org/q/topic:api-change-review-6.7
  *   https://codereview.qt-project.org/q/topic:qml_api_review_6.7



Please review the diffs as soon as possible.



br,

Jani

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Lots of qdoc-related warning messages when building 'docs' target in Qt-6.6.0?

[Kai Köhne via Development]

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 said, there are also some warnings even in the official 
builds ...

Kai


From: Development  on behalf of Haowei Hsu 

Sent: Sunday, October 22, 2023 5:21
To: Paul Wicking
Cc: development@qt-project.org
Subject: Re: [Development] Lots of qdoc-related warning messages when building 
'docs' target in Qt-6.6.0?

Hello, Paul.

I've read https://doc.qt.io/qt-6/qdoc-warnings.html, but still don't figure it 
out.
BTW, I also tried to build docs of Qt-6.5.3, and still encountered the same 
problem. For example:

C:/Test/qt-everywhere-src-6.5.3/qtbase/src/gui/image/qicon.cpp:1152: (qdoc) 
warning: Can't link to 'fallbackIconTheme()'
C:/Test/qt-everywhere-src-6.5.3/qtbase/src/gui/image/qicon.cpp:1171: (qdoc) 
warning: Can't link to 'fallbackIconTheme()'
C:/Test/qt-everywhere-src-6.5.3/qtbase/src/gui/kernel/qaction.cpp:139: (qdoc) 
warning: Can't link to 'Qt Widgets - Application Example'

and

C:/Test/qt-everywhere-src-6.5.3/qtdoc/doc/src/qtmodules.qdoc:4: (qdoc) warning: 
Can't link to 'Qt PDF'
C:/Test/qt-everywhere-src-6.5.3/qtdoc/doc/src/qtmodules.qdoc:4: (qdoc) warning: 
Can't link to 'Qt WebEngine'
C:/Test/qt-everywhere-src-6.5.3/qtdoc/doc/src/qtmodules.qdoc:4: (qdoc) warning: 
Can't link to 'Qt Wayland Compositor'
C:/Test/qt-everywhere-src-6.5.3/qtdoc/doc/src/wayland-and-qt.qdoc:4: (qdoc) 
warning: Can't link to 'Qt Wayland Compositor'

You can see the full logs in attachment: 
LOG-still-has-the-qdoc-warning-in-qt-6.5.3.txt
Therefore, I think this problem might not be a bug.
Instead, I think it's probably because I missed something, but I don't know 
which part is missing.
Could it be that I forgot to add some paths to a specific environment variable?

---
Haowei Hsu
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] How to document API only deprecated in future Qt versions

[Kai Köhne via Development]

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:

 When deprecating an old API in favor of a new one, it is a kindness to 
client code
 maintainers to set the version at which the deprecation takes effect to a 
future version,
 such as three minor versions after the new API was added, to give ample 
time to adapt 
 to it. All the same, you must prepare all of Qt's code for the transition 
promptly, as if
 the deprecation took effect as soon as its commit integrated. 

I see why this 'conservative' approach is beneficial. Projects like Qt Creator 
tend to support multiple Qt versions, and immediately deprecating an old API in 
the same version the replacement API got added makes this hard to handle.\

Anyhow, it creates a challenge for documentation. Take e.g.

https://doc-snapshots.qt.io/qt6-6.6/qtfuture-obsolete.html

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.

I see two fixes for this;
- Keep the documentation API fix separate from the header file fix, and only 
merge it when Qt 6.9 got branched. This requires 'someone' to follow up on 
these things, though, more than a year after the deprecation decision has been 
made.
- Deprecate the API already _in the documentation_ for 6.6, but only follow up 
with the compiler warning in Qt 6.10. 

I'm actually in favor of the second approach; documentation is mostly read when 
writing _new_ code, and that should already be written with the new API. But 
it's not something we've done so far, IMO.

Do you agree? 

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin
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] Avoid QT_BEGIN_NAMESPACE..QT_END_NAMESPACE in Qt examples

[Kai Köhne via Development]

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 sources, the need to deal with 'çustom 
namespaced' Qt (QT_BEGIN_HEADER, QT_END_HEADER, QT_FORWARD_DECLARE_CLASS) makes 
this rather ugly for Qt examples. It furthermore gives bad precedence to Qt 
users, who might 'cargo-cult' the magic macros in their sources. Finally, as 
the Qt examples are rather small, the benefits of this optimization are 
neglectable.

Happy to hear any feedback, either here or, preferably, in the Gerrit commit.

Kai

[1]: https://contribute.qt-project.org/quips/13

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin
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] Documenting API changes in Qt Framework

[Kai Köhne via Development]

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 public API*, and does it mention the first Qt 
version the API got added to?
* Is the documentation for *newly deprecated API* reflecting this, and does it 
mention the first Qt version the API got deprecated in?

Here's how to add version information for _added_ API:

* Modules, classes, types, functions:  '\since 6.6'
* Enums: \value [since 6.6] XYZ

For _deprecated_ API:

* Modules, classes, types, functions: '\deprecated [6.6]'
* (deprecated enums for now have to be marked in text)

If in doubt, add someone from the Qt Documentation Team as a reviewer.

There's also the API Review before a release like it's currently ongoing for 
6.6.0. There we have up-to-date documentation at https://doc-snapshots.qt.io/ 
which you can check. So again, if you're reviewing public API changes, please 
consider whether the documentation is complete and correct, and that any 
changes are marked for the Qt version it applies to.

Thanks for your consideration!

Regards

Kai


--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin
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

Re: [Development] On the use of the inline keyword

[Kai Köhne via Development]

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 therefore don't see an easy way to disable this specific warning.

Regards


From: Development  on behalf of Hasselmann 
Mathias via Development 
Sent: Friday, August 25, 2023 10:34
To: development@qt-project.org
Subject: Re: [Development] On the use of the inline keyword

Am 24.08.2023 um 21:42 schrieb Thiago Macieira:

> That warning looks like a bug in the compiler instead. So if there's no ill-
> effect, I'd just disable and ignore it.

Seems like an easy fix, but breaks user code that explicitly enables
this warning. Guess ignoring is not a good option, if one cares about
user experience.

Ciao
Mathias

--
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] How to use `init-repository` properly to clean up the working tree after checking out?

[Kai Köhne via Development]

> 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' leaves the submodules alone.

Haowei, you seem to have found the solution yourself previously: git clean 
-xfdf. Or just clone Qt 6.2.4 (and other branches/tags) in a separate git 
checkout directory.

But why do you want to build the documentation for Qt 6.2.4 yourself, in the 
first place? All the commits need to go into dev anyhow ...

Kai
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Failed to run configure.bat in qt/qt5 repository on Windows?

[Kai Köhne via Development]

> 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 --build . --parallel 4 docs 

Regards

Kai


From: Development  on behalf of Haowei Hsu 

Sent: Tuesday, August 22, 2023 7:45
To: Cristian Adam
Cc: Qt development mailing list
Subject: Re: [Development] Failed to run configure.bat in qt/qt5 repository on 
Windows?

Hello, Cristian.

What happens if you try to build it manually?
$ cmake --build . --target qminimal
[327/327 4.8/sec] Linking CXX shared module 
qtbase\plugins\platforms\qminimal.dll

I followed what you said, build qminimal manually.
However, after that, it still failed to build docs target.
The following commands are what I test:

  1.  git status
  2.  rmdir /s/q build
  3.  where gcc
  4.  set PATH=D:\Repo\tmp\mingw64\bin;%PATH%
  5.  where gcc
  6.  gcc --version
  7.  mkdir build\mingw-release && chdir build\mingw-release
  8.  ..\..\configure.bat -release -developer-build -submodules 
qtbase,qt5compat,qtsvg,qtimageformats,qtshadertools,qtdeclarative,qttools,qtquicktimeline,qtquick3d,qtserialport
 -nomake examples -nomake tests -- -DCMAKE_PREFIX_PATH=D:/Repo/tmp/libclang 
-DCMAKE_IGNORE_PREFIX_PATH=C:/Strawberry/c
  9.  cmake --build . --parallel 4 --target qttools
  10. cmake --build . --parallel 4 --target qminimal
  11. cmake --build . --parallel 4 --target docs (failed)

You can see the attachment with the full log: 
log-failed-to-build-docs-after-qminimal.txt

---
Haowei Hsu
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Failed to run configure.bat in qt/qt5 repository on Windows?

[Kai Köhne via Development]

> 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 using a slightly older checkout of qttools, you 
might still need to run

  cmake --build docs qsqlite qminimal 

though.

Regards

Kai
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [RFCs] Migrate from GCC MinGW to LLVM MinGW

[Kai Köhne via Development]

> 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 different environments: CLANGARM64, MINGW64, CLANG64, and
> UCRT64. In my opinion, simply switching among Qt's official precompiled
> packages and toolchains doesn't seem to carry significant benefits.

Well, it's about making a sane default for the users of the online installer. I 
appreciate the choices MSYS2 offers you, but supporting the 4 different 
variants in the Qt online installer would put even more stress on our CI. 
There's also a danger in offering too many choices, especially to users new to 
Windows ("curse of choice"). 

> Instead, learning how MSYS2 provides precompiled packages for multiple 
> toolchains seems to be a more fruitful approach. Alternatively, just 
> providing support such as mkspecs for users to compile on their own 
> could also be sufficient.

Such build recipes are notoriously hard to make bullet-proof, especially on 
Windows - and arguably one of the reasons why MSYS2 exists. So again, I'd 
rather select one toolchain we can support that works for most of our users. 
For the users that need a different choice, there's luckily MSYS2 :)

My 2 cents,

Kai
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files

[Kai Köhne via Development]

> -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
> room?
> How about "simply" implementing JSONC (JSON with Comments) in Qt's JSON
> parser instead?
> 
> * People wonder regularly when they learnm that there are no comments in
> JSON.
> * JSONC is used by popular software like VSCode and TypeScript.
> * The runtime parsers of PowerShell, .NET, and probably others already
> support
>    it out of the box. For JavaScript and Python there are drop-in libraries.
> * A MIT licensed implementation with examples and tests can be found here:
>    https://github.com/Microsoft/node-jsonc-parser

Supporting this in QJson would be nice, indeed. This could be an additional 
mode, like described in https://bugreports.qt.io/browse/QTBUG-44226 . 

Anyhow, given that this wasn't high priority so far, I wouldn't like to wait 
for it. Even if we get such a JSON mod at one point, there is arguably little 
harm in having the extra Comment field.

So, to wrap up: Let's go for the Comment field, as this fixes the immediate 
need. Extending our JSON support to allow comments, or even switching to an 
alternative file system is something we can still consider mid-term.

Regards

Kai 
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Security-relevant 3rd party components bundled with Qt

[Kai Köhne via Development]

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, which is easy 
to add:

https://codereview.qt-project.org/c/meta/quips/+/461983

Tell me what you think.

Regards

kai

From: Development  On Behalf Of Volker 
Hilsheimer via Development
Sent: Friday, January 20, 2023 9:58 AM
To: development@qt-project.org
Subject: Re: [Development] Security-relevant 3rd party components bundled with 
Qt

On 1 Nov 2022, at 09:55, Volker Hilsheimer via Development 
mailto:development@qt-project.org>> wrote:

On 20 Sep 2022, at 14:47, Volker Hilsheimer 
mailto:volker.hilshei...@qt.io>> wrote:
[…]

Those components should then be watched closer, and always get updated to the 
latest version, perhaps even for patch releases. To that end, I’ve started to 
collect a list of such components on

https://wiki.qt.io/Third_Party_Code_in_Qt

and would appreciate if you could have a look and add missing components to 
that page, esp if you are in charge of some of them. I’ve included a column 
that describes what kind of patches we apply when we update the 3rd party code 
(and this is perhaps a good opportunity to see if all of those are still 
necessary).


Hi again,


Thanks for populating that page with information about 3rd party components 
processing untrusted content.

As a next step, could those of you who are upgrading such components as part of 
the release process, please provide links to the respective upstream, and 
instructions on what is involved in the upgrading of the bundled sources?

Hi,

That page still misses information for a lot of 3rd party modules about where 
to find the upstream and the update instructions. That makes it very difficult 
for our release team to follow up on the 3rd party update.

Third Party Code in Qt - Qt Wiki
wiki.qt.io
[favicon.ico]

We need information about

QtNetwork:
- public suffix list

QtGui:
- harfbuzz-ng
- libpng, libjpeg
- sqlite

Qt Imageformats:
- libwebp

Qt Multimedia
- ffmpeg
- eigen
- pffft
- resonance audio

Qt Quick3D
- assimp
- tinyexr


Thanks,
Volker

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files

[Kai Köhne via Development]

> -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:
> > did you intentionally sent this off-list?
> 
> oops - no, outlook's UI tricked me :-(
> And, in fact, it just did it again, although I'm sure I hit Reply All this 
> time.
> Manually adding development to CC...
> 
> For the benefit of everyone else, my reply is below, after the bit of Kai's 
> earlier
> mail, that I quoted:
> 
> >>> Anyhow, I wonder whether it wouldn't suffice to have _one_ comments
> >>> field, instead of a dedicated UpstreamFiles field, and *Notes fields
> >>> for every single entry. E.g.
> >>>
> >>> {
> >>>   "Comments": [
> >>>  "Upstream files were copied from:",
> >>>  "   src/dir1, src/dir2",
> >>>  "The license and copyright was derived from dist/LICENSE.txt"
> >>>   ]
> >>> }
> >>>
> >>> The benefit I see is that qtattributionsscanner (and any other JSON
> >>> tool that might be used by others) has only to care about one
> >>> additional field, not multiple ones.
> 
> Edward Welbourne (Tuesday, February 14, 2023 7:37 PM) had written:
> >> I see the case for it, but it comes at the cost of all the comments
> >> being in one place, not each comment next to the part of the content it
> relates to.
> >>
> >> If someone is updating one of many data in an attribution and the
> >> comments aren't close at hand, both the author of the change and the
> >> reviewers may fail to notice the detail that the comment mentions
> >> that makes it obvious they're doing something wrong.
> >>
> >> That's not a fatal argument: each attribution is fairly short, so
> >> putting the comments in the middle should make it easy to see them
> >> when looking at any of the lines they relate to.  None the less,
> >> comments and documentation belong close to the code they relate to ...
> 
> > Well, you can also achieve this by duplicating comment fields:
> >
> > {
> >   "Comment": "Upstream files are src/x.cpp, include/y.h",
> >   "Files": [ "x.cpp", "y_p.h"]
> >   "Comment": "Copyright info is from dist/COPYING",
> >   "Copyright": "Copyright (C) 2023 Joe Doe"
> > }
> 
> The problem with that is that I was given to understand that duplicated keys 
> is
> actually malformed JSON - perhaps I misunderstood.  If that's legitimate JSON,
> then I'm fine with just one.

To my understanding it's valid JSON, at least from the syntax side. From 
https://www.ecma-international.org/publications-and-standards/standards/ecma-404/
 :

  The JSON syntax does not impose any restrictions on
  the strings used as names, *does not require that name strings be unique*, 
and does not assign any
  significance to the ordering of name/value pairs. These are all semantic 
considerations that may be defined by
  JSON processors or in specifications defining specific uses of JSON for data 
interchange

And the JSON parsers I tested (Python, Qt) don't treat it as an error, either. 
There seems to be some online linters like https://jsonlint.com/ that complain 
about it, tough.

> > I just don't see the point of dedicated fields if the whole purpose is
> > to ignore them in the tooling.
> 
> Well, there's more tooling to consider - someone, at least, has run a JSON-
> validation checker on some qt_attributions.json files and submitted patches to
> fix issues reported there (like line-breaks instead of \n; and I think that's 
> where
> I heard about duplicate keys being invalid) - and in any case there are
> developers who need to read it, who may benefit from the keys having names
> that makes clear which tooling-relevant keys they relate to.

Right. But this can also work the other way: If we ever come around to 
formalizing a json-schema, then having to list all the *Notes fields 
complicates things, too.

I'm still for the KISS principle and go for one Comment field. If we have a 
need for more 'local' fields in some cases, let's just allow duplicating these. 
We can always reconsider this in the future.

Kai

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files

[Kai Köhne via Development]

> -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.
> 
> Basically, YAML is extremely complex, ambiguous, and incompatible between
> different versions. See for example
> https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell for
> an in-depth explanation.
> 
> Toml seems to be popular these days.

I'd be open to all kinds of formats if we'd start on a green field. But we're 
not, and I don't think reimplementing qtattributionsscanner + redo the build 
system integration + convert all existing qt_attributionsscanner.json files to 
a new format is worth the time. Unless, of course, somebody volunteers 

Regards 

Kai

-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Support for *Notes and UpstreamFiles fields in qt_attributions.json files

[Kai Köhne via Development]

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,
> 
> Having taken part in various third-party updates and felt a need to leave 
> notes
> for those who will do the same in future, I have run up against JSON not 
> having
> a comment format.  To work round that, I propose to allow some fields to be
> included in a qt_attribution.json file for that purpose.  As a general 
> pattern, I
> propose allowing ${Field}Notes for any ${FIELD} that already exists; and a
> separate UpstreamFiles field, corresponding to the Files one, to list where in
> the upstream source tree to find the files that are to be copied.

First, let's agree that JSON sucks for the task at hand. It doesn't have any 
explicit support for comments, and no support for multi-line strings (though 
our implementation tolerates this).

Anyhow, I wonder whether it wouldn't suffice to have _one_ comments field, 
instead of a dedicated UpstreamFiles field, and *Notes fields for every single 
entry. E.g.

{
  "Comments": [
 "Upstream files were copied from:",
 "   src/dir1, src/dir2",
 "The license and copyright was derived from dist/LICENSE.txt"
  ]
}

The benefit I see is that qtattributionsscanner (and any other JSON tool that 
might be used by others) has only to care about one additional field, not 
multiple ones.

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?

[Kai Köhne via Development]

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 compiling programs 
locally! So, all this says is that official Qt Creator releases are still done 
with MSVC 2019 compiler.

Mystery solved, I guess 

Kai

From: Development  On Behalf Of Adam Light
Sent: Thursday, February 2, 2023 5:46 PM
To: Vladimir Minenko 
Cc: Qt development mailing list 
Subject: Re: [Development] Do we need VS2019 for Qt 6.6?


On Thu, Feb 2, 2023 at 7:39 AM Vladimir Minenko via Development 
mailto:development@qt-project.org>> 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. The most widely installed is MSVC2019 v29 
followed by v28. Most installations (around 250K) are on Qt 6.2. Qt 5.15 has 
around 60K installations.


Everyone at my small company has been using Qt Creator on Windows to build our 
application using the VS2022 tools for a minimum of 2+ months, some of us much 
longer. I couldn't find the telemetry setting you mentioned, so perhaps we all 
disabled the feature, though that would be surprising.

We build Qt ourselves (also with MSVC 2022) so if this requires that the Qt be 
an official build perhaps your statistics are missing us.

Adam
-- 
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt TextToSpeech: Adding dependency to Qt Multimedia - ok?

[Kai Köhne via Development]

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] New Qt example development guideline and revamping examples

[Kai Köhne via Development]

> -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 Qt without using those macros? 

Option 1: Do not forward declare the Qt type, but just include the right Qt 
header.
Option 2: Use QT_BEGIN_NAMESPACE..QT_END_NAMESPACE, but only for Qt types, 
_not_ for all header content.

The rule just says that wrapping all of your headers with QT_BEGIN_NAMESPACE, 
QT_END_NAMESPACE is a misfeature which shouldn't be cargo-culted.
> Is there perhaps
> a more comprehensive discussion regarding how to write examples that
> cope with namespaced Qt builds?

Personally, I wouldn't even mind if Qt examples wouldn't compile with a 
namespaced Qt (-qtnamespace configure argument), because I feel it's a somewhat 
specialist feature. But alas, we have at least one CI configuration that builds 
with -qtnamespace and Qt examples, so we might as well keep it working.

(A nasty feature of uic is btw that it also does generate C++ code inside 
QT_BEGIN_NAMESPACE, QT_END_NAMESPACE. That is, if you have a .ui file for a 
Dialog, and you want to pre-declare the type generated by uic, you have to also 
put it in QT_BEGIN_NAMESPACE, QT_END_NAMESPACE, which is a bit surprising to me 
. Anyhow, changing this is probably not worth the breakages anymore ...

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Stickman animation example removed from qtbase in Qt 6

[Kai Köhne]

> From: Development  On Behalf Of Shawn 
> Rutledge
>
>> On 2022 Aug 17, at 09:57, Rasool, Ansar  
>> wrote:
>>
>> Hi All, 
>> 
>> It seems that Stickman and many other widget animation examples from qtbase 
>> has been removed in Qt6 as compared to Qt5. Is there any particular reason 
>> behind the removal of these examples?
> 
> They were moved into the qtscxml repository.  
> https://codereview.qt-project.org/q/qtbug-80316

They don't show up in the Qt Creator welcome screen anymore though, which 
points to a packaging problem: https://bugreports.qt.io/browse/QTBUG-105721

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: move Qt provisioning scripts and 3rd party components into a dedicated repo

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Volker Hilsheimer
> [...]
> I think that’s by far the exception though. Most 3rd party components we
> use have well defined, stable APIs.

I think it's the other way round, at least if you go by the number of
qt_attribution.json entries 

Checking only Qt Core, we list about 18 third-party code attributions. Only
3 of them can be configured to use a system library instead.

Anyhow, the examples with proper upstream project + a build system are arguably
the bigger ones,  and the ones that are interesting from the security 
perspective 
(ZLIB, PCRE2). But don't expect that we get rid of even the majority of 
third-party
attributions  by saying 'we use system libs'.

Also, let's not forget the elephant in the room: Chromium, and the myriad of 
further
dependencies it ships itself. I wouldn't hold my breath for them to provide a 
stable API :/

> We can expect that a system that runs Qt has a system libpng.so. We don’t
> need to build libpng sources into Qt just because our build environment
> doesn’t have libpng-dev provisioned.

Though luck on Windows  We need to find a solution there. This might be
Conan, vcpkg, or our own build system. But we really shouldn't make the 
steps to get a working copy of Qt on Windows even more elaborate than it is
right now.

> Yop. Nothing is going to happen immediately. If we can agree that the goal is
> worthy the effort it will take, then setting up a new submodule where we
> can experiment with some of the obvious candidates (zlib, libpng, freetype)
> will probably find the new tangles :)

I'm all for experimenting with these.

Let's set up some requirements though:

- We need a setup on Windows that is practical
- We need a solution for _all_ supported platforms + compilers, including 
cross-compilation
- static builds still need to be supported (so that the third-party lib is 
statically 
  linked into a static Qt)

My expectation is that we must still maintain our own forks for almost all 
3rd-party libs, if
only for supporting exotic platforms + build system issues. But I'd be happy to 
be shown otherwise.

For Windows specifically: My understanding is that we want to use separate 
third-party
.dll's wherever possible, also for the official binaries that we provide. Mind 
you that this will break
a lot of customer deployment scripts, and potentially can cause some dll hell. 
It also doesn't make Qt appear lightweight when you must deploy 10+ dll's for a 
"hello world" :/

Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nominating Andreas Eliasson as Approver

[Kai Köhne]

Hi,

I'd like to propose Andreas Eliasson as an Qt Project Approver.

Dashboard: https://codereview.qt-project.org/dashboard/1009951

Andreas started working on Qt documentation only in February. But since then, 
he did already quite some documentation related patches in various Qt modules. 
He has also been actively reviewing other people's documentation patches. So, I 
see little reason to wait much longer before making him an approver, also 
because getting another documentation approver would be handy in the upcoming 
vacation season 

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin
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

Re: [Development] [Interest] Issues with latest Qt MaintenanceTool and Kaspersky

[Kai Köhne]

> -Ursprüngliche Nachricht-
> [...]
> Is there a reason to be using a vbs file ? In windows a running executable
> cannot replace itself, but it can rename itself. [...]

Hi Julien,

I don't know the exact reasons why the .vbs approach was chosen. I now filed 
https://bugreports.qt.io/browse/QTIFW-2625 with your suggestion, maybe the 
Installer Team wants to give it a try 

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] Issues with latest Qt MaintenanceTool and Kaspersky

[Kai Köhne]

Hi,

> Are deferredrenamekERbOS.vbs and deferredrenameQIoNFA.vbs included in the 
> MaintenanceTool package?

They are not _included_ in the MaintenanceTool package. Anyhow, 
"deferredrenameXX.vbs”are temporary files the MaintenaceTool.exe writes to 
schedule an update of itself. That is, because on Windows an executable cannot 
be replaced when it is running, the MaintenanceTool.exe

  *   Saves the new MaintenanceTool.exe in parallel
  *   Writes above .vbs file, and starts it
  *   Stops itself

The .vbs script will then every second try to replace the original .exe file, 
and – after being successful – restarting the MaintenanceTool.


Why Kaspersky now starts to complain about it: No idea :/ Anyhow, we had false 
positives about the MaintenanceTool before, the best process to fix it is 
probably to report the false positive to Kaspersky: 
https://support.kaspersky.com/viruses/answers/1870 . Would you like to do that 
(since you still have the temporary files, I assume)?

Regards

Kai

Von: Interest  Im Auftrag von Nibedit Dey
Gesendet: Dienstag, 3. Mai 2022 22:06
An: development@qt-project.org; inter...@qt-project.org
Betreff: [Interest] Issues with latest Qt MaintenanceTool and Kaspersky

Hello Qt Team,

I just ran the updater using the MaintenanceTool. After the update, the 
MaintenanceTool got listed as malware by Kaspersky Anti-Virus and removed from 
the system.
Refer to the screenshot below:
[cid:image001.png@01D85F92.23A1F470]

[cid:image002.png@01D85F92.23A1F470]

I have been using both Qt and KAV together for the last several years without 
any issues.
Are deferredrenamekERbOS.vbs and deferredrenameQIoNFA.vbs included in the 
MaintenanceTool package?
Why suddenly did the anti-virus start listing it as malware? Has anyone else 
observed this?

Thanks & Regards,
Nibedit
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt UDL operators

[Kai Köhne]

> From: Development  On Behalf Of Sona 
> Kurazyan
> Sent: Wednesday, March 30, 2022 3:44 PM
> To: Marc Mutz ; development@qt-project.org
> Subject: [Development] Qt UDL operators
>
> [...]
> As you can see, https://codereview.qt-project.org/c/qt/qtbase/+/401604 raised 
> a lot of discussion, and not everyone felt comfortable with deprecating (and 
> later removing) the “q”-prefixed UDLs.
> To summarize the discussion, I see following options:
> 
> 1. deprecate  _qs, _qba, add Qt::StringLiterals::{_s, _ba}, as suggested 
> above (https://codereview.qt-project.org/c/qt/qtbase/+/401308 + 
> https://codereview.qt-project.org/c/qt/qtbase/+/401604)
> 2. keep _qs, _qba, add_qL1 and remove Qt::StringLiterals::_L1 
> (https://codereview.qt-project.org/c/qt/qtbase/+/402948 + 
> https://codereview.qt-project.org/c/qt/qtbase/+/402950)
> 3. keep _qs, _qba, add _qL1, keep Qt::StringLiterals::_L1, add 
> Qt::StringLiterals::{_s, _ba} 
> (https://codereview.qt-project.org/c/qt/qtbase/+/402948 + 
> https://codereview.qt-project.org/c/qt/qtbase/+/401308)
> 
> I personally prefer the 1st option, but it would be nice to hear more 
> opinions/concerns and decide how to proceed. 

If you use the "Qt Quick Application" wizard in any recent Qt Creator, and 
selected a Qt 6 version as minimally required version, the generated main.cpp 
code will contain code like 

  const QUrl url(u"qrc:/myproject/main.qml"_qs);

Deprecating the u""_qs will mean that we break the most basic user 'hello 
world' projects utilizing this wizard. I therefore think it's too late to 
deprecate u""_qs any time soon.

My 2 cents,

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Giuseppe D'Angelo via Development
> [...]
> For instance, QtTestLib is not under BC promises. Various modules in their
> "Tech preview" state weren't. I really don't know about the specific module...

This is tracked in https://doc.qt.io/qt-6/qtmodules.html . Qt Quick Test and Qt 
Test have an explicitly stated exception there.  Qt Wayland does not.

Regards

Kai 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Blog post about contributions to Qt repositories in 2021

[Kai Köhne]

Hi,

I played with the git commits that went into qt5.git / qt-creator.git 
repositories , and have written a blog post about the contributors who are not 
working for The Qt Company:

https://www.qt.io/blog/top-contributors-to-qt-project-in-2021

Enjoy! For those interested, here's the script I used to get the numbers:

https://git.qt.io/kakoehne/qtprojectstats/-/blob/main/qtprojectstatistics.py

Regards

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Str. 10, D-12489 Berlin
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

Re: [Development] Documentation of new Qt features in qtdoc

[Kai Köhne]

> From: Development  On Behalf Of Edward 
> Welbourne
> Sent: Monday, November 22, 2021 8:08 PM
> To: Shawn Rutledge ; Oswald Buddenhagen 
> 
> Cc: development@qt-project.org
> Subject: Re: [Development] Documentation of new Qt features in qtdoc
>
[...]
> Shawn Rutledge (22 November 2021 15:56) added:
>> ChangeLog entries from the git log may often be badly-worded or be 
>> written badly for the audience that’s going to read them, but I think 
>> we should still start from those, for the sake of completeness.
>
> I think the aim here is to make them (and all scripts with delusions of 
> collecting them into a useful release story) redundant in any case.

That was not the scope of my proposal though.

The [Change Log] entries are used for the release notes, which are stored since 
a while in qtreleasenotes.git. See e.g. 
https://code.qt.io/cgit/qt/qtreleasenotes.git/tree/qt/6.2.0/release-note.md . 
Release notes are produced for every feature and patch level release, and are 
automatically generated from the git log.

The "What's New" pages in the documentation are separate: 
https://doc-snapshots.qt.io/qt6-dev/whatsnew62.html . We add these only for 
minor versions.

Now there's obviously some duplication between these two, and I'm sure there's 
people who doubt whether we need both. But my suggestion was just about the 
What's New page, not the ChangeLog.

Kai

--- Begin Message ---
> On 20 Nov 2021, at 01:12, Oswald Buddenhagen  
> wrote:
>
> On Fri, Nov 19, 2021 at 03:11:57PM +, Kai Koehne wrote:
>> Can we agree to document new features in Qt 6.3 and following released 
>> directly in qtdoc.git?
>>
> won't this cause conflict hell during release finalization? the turnaround 
> time for submitting patches is still quite unreasonable for contended areas.
>
> it might work better if the update is done through a single collectively 
> edited change. with gerrit's online editing functionality, this wouldn't even 
> be much more cumbersome than editing the wiki.
> that would mean that jani would have post a link to a change he started 
> instead of a wiki page as he did so far.


I’m in favour of having a single place for the What’s New documentation, and 
the documentation is the right place, so +1 for that.

But I share Ossi’s concern. Knowing how many of those changes happen late in 
the process, ending up with lots of them causing constant merge conflicts for 
everyone is going to suck.

So, having a change that everyone can edit using gerrit's web UI is a good 
proposal. +1 to that as well.


Volker

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
--- End Message ---
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Documentation of new Qt features in qtdoc

[Kai Köhne]

Hi,

Can we agree to document new features in Qt 6.3 and following released directly 
in qtdoc.git?

We have traditionally been using wiki.qt.io to collect new features in a Qt 
release, see for instance https://wiki.qt.io/New_Features_in_Qt_6.2. At some 
time before a release, we started to transform this into 'proper' 
documentation: https://doc.qt.io/qt-6/whatsnew62.html . Anyhow, this is a 
manual process, creating additional work, and we sometimes miss things... 

I'd like to therefore suggest that, from Qt 6.3 onwards, we start documenting 
new features in qdoc from the get-go:

https://code.qt.io/cgit/qt/qtdoc.git/tree/doc/src/whatsnew/whatsnew63.qdoc

We btw got a lot better in keeping the doc snapshots up to date. So usually, 
merged commits show up on doc-snapshots.qt.io within a couple of hours ...


Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Documentation test builds in CI

[Kai Köhne]

Hi Topi,

Great news! This should save us quite some time hunting down qdoc errors 

Kai

From: Development  On Behalf Of Topi Reiniö
Sent: Thursday, October 21, 2021 9:41 PM
To: development@qt-project.org
Subject: [Development] Documentation test builds in CI

Hello!
The testing cycle in Qt's CI now includes a documentation build step for 
submodules of the qt5 repository, in dev branch. What this means is that 
integrations may fail if they introduce new documentation warnings as reported 
by QDoc, and you are greeted with a "Documentation check failed" message in 
gerrit.

To resolve the reported issues, check the documentation on QDoc warnings at 
https://doc.qt.io/qt/qdoc-warnings.html - If you can't figure it out, add 
someone from the documentation team as a reviewer (always a good move when 
touching docs) and we'll do our best to help.

To temporarily disable the doc checks for a module that's under active 
development with a high commit inflow, remove the step from 
/coin/module_config.yaml.

Notes:

  * Testing for broken links is omitted as dependencies to other Qt's 
documentation modules are not available for the test build. These linking 
issues are detected as part of our daily snapshot builds and handled separately.

  * qt/qtbase and qt/qttools already have this step enabled. We're enabling it 
for the rest of the modules as we clear them of existing warnings. This may 
take a bit of time as we also need to update the qtbase dependency for some of 
the less-frequently trafficked repos.

Cheers,

Topi Reiniö | Principal Documentation Engineer | The Qt Company
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] MSVC warnings in Qt module code now fatal

[Kai Köhne]

Hi,

Just a heads up that yesterday 
https://codereview.qt-project.org/c/qt/qtbase/+/356259 went into dev. This 
makes builds with -warnings-are-errors actually fail for MSVC compiler warnings 
again.

I tested a local qt5.git build beforehand. Anyhow, if you still run into a 
submodule where integrations now fail in the CI, either fix or disable the 
individual warning... or do

set(QT_REPO_NOT_WARNINGS_CLEAN TRUE)

For the whole module, though this should obviously just be a hotfix.

Regards

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Renamed: Running a service for Qt community

[Kai Köhne]

> From: Development  On Behalf Of Benjamin 
> TERRIER
> Subject: Re: [Development] Renamed: Running a service for Qt community
> 
> On Thu, 20 May 2021 at 17:18, Jason H  wrote:
>
>> Anyway, these issues aren't insurmountable, apparently they can be changed 
>> with the stroke of a pen. (Where is Qt's Open Governance? - still think I 
>> misunderstood what that was about)
>
> Since TQC alone can decide that the Qt Project won't release Qt 5.15.3+  
> without consulting the mailing list and going through the lazy consensus 
> decision process, I think it's safe to say that Open Governance is dead.

I don't claim that the LTS decision was fully in line with the Open Governance 
process as stated in https://quips-qt-io.herokuapp.com/quip-0002.html .

But Open Governance is IMO serving the purpose of steering the development of 
the Qt code quite well. I think we can do better in also discussing designs etc 
on the mailing list, but well...
 
> Can we conclude that contributions from outside the company are going to be 
> nearly
> non-existent?

I hope not  You can check out some statistics about code contributions at 
qt-project.org . There's also Thiago's generated statistics : 
https://macieira.org/~thiago/qt-stats/current/ .

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Freenode's IRC

[Kai Köhne]

> -Original Message-
> From: Jason H  
> Subject: Re: RE: [Development] Changes to Freenode's IRC
>
>
> > Can we agree to keep the bashing out of this channel?
>
> You raise important questions. First, what is "bashing", and where is it 
> appropriate? Or, as I see my behavior, where is being critical of Digia 
> appropriate?

I see you're quite interested in continuing discussing the LTS change, and Qt 
6.0. Anyhow, I don't think there's much more to say for now.  So, my wish is 
just that we keep discussions on topic. Furthermore, I hope that you, when you 
notice things like ads being shown on doc.qt.io, bring them forward with some 
goodwill regarding the people who are responsible for this.

Thanks for considering,

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Freenode's IRC

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of Jason H
> Sent: Wednesday, 19 May 2021 17:26
> To: giuseppe.dang...@kdab.com
> Cc: development@qt-project.org
> Subject: Re: [Development] Changes to Freenode's IRC
> 
> Aren't all the kids these days moving to Discord? Slack is inefficient as the 
> history is rolling unless you pay for more.
> 
> I would worry about moving it under Digia (tQtCo), because I'd expect them to 
> encumber the access to it(paywall, ads, tracking, etc*). I don't trust them.

TQtC (my employer) already runs all the critical infrastructure for the Qt 
Project, as well as employing a large part of the developers. But running a 
chat server ... no, that would require too much trust.

> Perhaps the KDE people would operate the Discord infrastructure?
>
> * Before you laugh, and say that is crazy, consider that the online Qt Docs 
> search results now have ads: 
> https://doc.qt.io/qt-5/search-results.html?q=camera shows 4 ads for me.  And 
> I don't know of any other toolkit who serves their documentation with ads. 
> Take for example mozdev: 
> https://developer.mozilla.org/en-US/search?q=camera shows 0 ads. React, 0 
> ads. I figure it's only a matter of time until the actual documentation pages 
> have ads too. (There may be good reasons for ads, but it's still not a good 
> look.)

It's true that the embedded search on doc.qt.io sometimes shows ads. But it's 
not the result of evil TQtC making heaps of money with ads. It's just a 
side-effect of using google for embedded search, and has been like that since 
years (if not decades)  ... We have actually recently started to look into it 
(again), see https://bugreports.qt.io/browse/QTWEBSITE-723 if you want to get 
updates.

Can we agree to keep the bashing out of this channel?

Thanks

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Raising minimum CMake version to 3.16 for Qt6

[Kai Köhne]

> -Original Message-
> I'm not really remembering at the moment. The development hosts were
> already set to GCC9 for 6.0. So maybe GCC8 works, but we're not testing it
> anywhere (and that makes it basically unsupported). 

Well, we're still building things on Windows with gcc 8.1. See e.g.

https://testresults.qt.io/logs/qt/qt5/de93708ae5d95f77df85a130b5de546b2d46c1fe/WindowsWindows_10x86_64WindowsWindows_10x86_64Mingwqtci-windows-10-x86_64-52-d843faInsignificantTests_Sccache/d76ebc5a537502304acc418e6270be882de2a953/build_1620360977/log.txt.gz

> agent:2021/05/07 04:24:49 build.go:379: Building for: win32-g++ (x86_64, CPU 
> features: cx16 mmx sse sse2 sse3)
> agent:2021/05/07 04:24:49 build.go:379: Compiler: gcc 8.1.0

So it might have regressed in Unix specific parts, but overall we still support 
gcc 8.1.

Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] New git submodule qlitehtml in qttools/dev

[Kai Köhne]

Hi,

Last Friday, https://codereview.qt-project.org/c/qt/qttools/+/342108 integrated 
into qttools/dev, and subsequently into the qtools checkout in qt5.git/dev.

This adds a git submodule to qttools, that in turn uses another git submodule. 
So if you have configure/CMake failures in qttools/dev, please run

  git submodule update --init --recursive

inside qttools.

Regards

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
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

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Joerg Bornemann
> Gesendet: Freitag, 26. Februar 2021 13:36
> An: Elvis Stansvik 
> Cc: Macieira, Thiago ; Qt development mailing
> list 
> Betreff: Re: [Development] Qt 6 co-installability with Qt 5
> 
> On 2/24/21 8:54 AM, Elvis Stansvik wrote:
> 
> > I guess it rules out installing to e.g. a FAT-formatted USB-stick, but
> > I don't know if that's a thing. Could be considered an edge case and
> > documented not to work.
> 
> With https://codereview.qt-project.org/c/qt/qtbase/+/336652 a copy is made
> if a hard-link cannot be created.

Right, but that is at configure time, this doesn’t help with the online 
installer. 

If we go down this route, we should arguably check in the online installer 
whether the target folder is on an NTFS partition, and back out if not. One 
more complication ... :/

Regards

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> Von: Development  Im Auftrag von Lisandro 
> Damián Nicanor Pérez Meyer
> Gesendet: Mittwoch, 17. Februar 2021 13:33
> An: development@qt-project.org
> Betreff: Re: [Development] Qt 6 co-installability with Qt 5
>
> Hi!
> El mié., 17 feb. 2021 05:33, Joerg Bornemann  
> escribió: 
>
> On 2/17/21 12:47 AM, Lisandro Damián Nicanor Pérez Meyer wrote:
>
>> Kai: we the maintainers have been asking for the right solution since 
> the Qt3 to Qt4 switch.
>
> Obviously not with enough fervor to convince people and in the case of 
> Qt6 mch too late in the release process.
>
> In fact the most difficult people to convince are within tqtc. And no, we 
> have been asking for this change, specifically for qt6, 
> since at very least 2019. And they where no small threads.

That might have less to do with the fact we work for The Qt Company, but more 
with the fact that a) you ask us to do the work, and b) to maintain it 

Anyhow, now that we've been both venting our frustration a bit: As Joerg 
already pointed out, I'm completely fine with the patch he has prepared, and 
certainly do hope that distributions make use of it. I'm just disagreeing with 
the request that the Qt documentation need also state 'qmake6' everywhere, and 
that the Qt SDK (as provided by the online installer) needs to contain 
'qmake6', too. 

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Jyrki Yli-Nokari
> Gesendet: Dienstag, 16. Februar 2021 06:10
> An: development@qt-project.org
> Betreff: Re: [Development] Qt 6 co-installability with Qt 5
> 
> Thiago is right. Qt’s biggest problem is the barrier of entry. User facing 
> tools
> must work as documented.

Well, let's just realize that, by renaming qmake to qmake6 everywhere 
(including in the documentation), we actually create some confusion for our 
existing users, too. Also, I think adding version numbers to the name of tools 
is just no good user experience, and creates unnecessary friction when 
switching between Qt versions.

To be honest, the whole discussion feels to me that we are being held hostage 
right now for the fraction of Linux users that cannot use update-alternatives 
(because they are not administrators). If having different names of tools is 
such a big problem, why wasn't this addressed by now in Linux itself?

And again, this is not something limited to Qt. Last time I checked, the 
executable to run Python 3 on Windows is python.exe, not python3.exe. On Debian 
at least it's python3. This hasn't blocked Python from being perceived as 
overall beginner friendly ...

So, I would stick to qmake as canonical name, also in the documentation. We can 
mention that it's sometimes called qmake6 on Linux. But forcing everyone to 
change their habit and scripts just for the sake of consistency with a fraction 
of the users that use a global installation on Linux, and do not use 
update-alternatives, is IMO not a good move.

My 2 cents,

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Commercial-only LTS phase starts: Closing the 5.15 branch(es) on 5th January

[Kai Köhne]

> -Original Message-
> [...]
> So why do we even ship 3rd parties with Qt in the current form if we 
> can't be bother to update them promptly (for bug fixes, security fixes, and 
> the like)?
> Wouldn't it be better to just provide a script (cmake's external 
> project, recipe, conan build file, vcpkg, choco, WHATEVER) so that the 
> user can download the latest version of 3rd parties automatically? Or 
> just NOT provide them and push the problem onto the user?

Using a dependency manager is actually the plan: 
https://bugreports.qt.io/browse/QTBUG-73760 . Last year we looked into Conan 
for some third-party code, but didn't follow through on it yet, mostly due to 
just too many other things on the plate ...

Note however, that most of the third-party code we have right now are not 
standalone libraries that can easily be maintained and built outside of Qt. So 
https://doc.qt.io/qt-6/licenses-used-in-qt.html will still be a significant 
list for the foreseeable future, and we should treat security issues in them 
the same way we treat security issues in Qt code.

Regards

Kai

PS: Giuseppe, something in your mails tells Outlook to only to reply to you 
personally, and not to the list, even if I use Reply to All. Other mails are 
not affected...
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Thursday, December 10, 2020 3:48 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt 6 co-installability with Qt 5
> 
> On Wednesday, 9 December 2020 23:24:00 PST Kai Köhne wrote:
> > Consistency is important, but is it really so that people struggle
> > with realizing that 'linguist' is 'linguist6' in their local Linux 
> > installation?
> >
> > If this is really a problem we can consider just mentioning both names
> > in the documentation.
> 
> We should mention only one: linguist6.

I disagree.

Anyhow, we only talk about 'Qt Linguist' in the documentation, not 
linguist(qt-)?6?(.exe)? , or Qt Linguist.app. So this point is actually mood, 
at least for Qt Linguist 


Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Lisandro Damián Nicanor Pérez Meyer
> [...]
> > We do that already, it's just not enough for user-facing applications. I'll 
> > be
> more verbose on the bug report if needed.
> 
> The problem of options 2 and 3 are that they do not talk about
> documentation. Documentation should call user-facing tools with the 6 prefix
> too. That also means that it will change in other operative systems, so
> symlinks might not be the real cross platform solution.

Consistency is important, but is it really so that people struggle with 
realizing that 'linguist' is 'linguist6' in their local Linux installation?

If this is really a problem we can consider just mentioning both names in the 
documentation.

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Long-lived P1 issues

[Kai Köhne]

> From: Development  On Behalf Of NIkolai 
> Marchenko
> Sent: Friday, December 4, 2020 9:45 AM
> Subject: Re: [Development] Long-lived P1 issues
>
>> Currently, there are 1175 open P1 issues in the QTBUG project.  583 of those 
>> issues had that priority set more than one year ago,  
>
> I am not saying no one ever fixes those, but given the premise of this 
> thread. The "promise" of every PX description is certainly > broken enough 
> _in general_ that my rewording is more accurate than official one.

I think your interpretation is wrong. During this year we managed to close 1849 
P1 issues in QTBUG [1]. At the same time 1966 P1 issues got reported [2]. So we 
indeed have a growing top-line of P1 tasks, and arguably also an issue with 
long-standing P1's. 

But for a new P1 that gets reported today, the chance that it gets closed in a 
timely manner is still rather high. 

Also, a lot of effort in 2020 was going into 6.0. I do expect we'll put some 
more focus on the bug backlog in 2021.

Kai

[1]: Obtained by JQL query 'project = QTBUG AND PRIORITY = "P1: Critical" AND 
resolutiondate >= 2020-01-01'
[2]: Obtained by JQL query 'project = QTBUG AND PRIORITY = "P1: Critical" AND 
createdDate >= 2020-01-01'
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Long-lived P1 issues

[Kai Köhne]

> -Original Message-
>[...]
> > (Clicking the ? button next to the priority field in Jira shows the
> > following definition for P1: "Urgent and Important, will STOP the
> > release if matched with set FixVersion field. This includes
> > regressions from the last version that are not edge cases; Data loss;
> > Build issues; All but the most unlikely crashes/lockups/hanging;
> > Serious usability issues and embarrassing bugs & Bugs critical to a
> > deliverable.")
> 
> Was there any outcome from this discussion? Like, re-evaluating priority
> levels and what they mean in terms of release blockers?

I don't think there was any sort of decision or consensus. Which means we keep 
working with the status quo, as documented in 
https://bugreports.qt.io/secure/ShowConstantsHelp.jspa?#PriorityLevels

I suggest to simplify P3, P4 descriptions though to

  P2: Important, should be fixed.
  P3: Should be fixed.

(the mentioning that they don't block a release probably stems from a time 
where P1 meant blocking the release. This is not the case anymore, so what's 
the point in highlighting that a P2, P3 doesn't block a release?).

Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt Assistant (was: RE: Qt 6 co-installability with Qt 5)

[Kai Köhne]

> -Original Message-
> From: Kai Pastor, DG0YT 
> Sent: Thursday, November 19, 2020 8:27 AM
> To: Kai Köhne ; development@qt-project.org
> Subject: Re: [Development] Qt 6 co-installability with Qt 5
> 
> Am 19.11.20 um 08:20 schrieb Kai Köhne:
> >> Am 18.11.20 um 15:50 schrieb Kai Köhne:
> >>> FYI, we've been taking assistant out of Qt 6.0.
> >>> https://bugreports.qt.io/browse/QTBUG-86746 . It's not depending on
> >>> any particular Qt version, so my suggestion is to resurrect it (if
> >>> there's enough demand) outside of qt5.git.
> >> Could you please clarify: Can building Qt Asistant be enabled by a
> >> configuration option? Is it still build as part of CI?
> > Currently not. I think it should be completely removed from qttools -
> disabling the build was just the quickest way for the 6.0 release.
> 
> I wouldn't mind if Assistant would actually be moved to a different 
> repository.
> But so far, it is only a suggestion.

Yes, because the priority Is currently to get Qt 6.0 out.

> >> Now with all Qt help links changed to the online version, how is Qt
> >> Assistant/QTextBrowser limiting Qt's documentation at all, justifying
> >> its removal from the build (so late in the Qt 6 release process)?
> > The reason why we removed Qt Assistant in the beta phase is that I don't
> think it should be part of Qt 6.
> 
> Do you want to remove it from "Qt 6", from "Qt 6.0", or from "Qt 6.0.0"?

For Qt 6. I just don't see a good reason that Qt Assistant should be shipped 
and built as part of the Qt libraries.
 
> There has been no deprecation of this Qt feature AFAIK.

Alright, I see now that we should probably have discussed this on this mailing 
list beforehand, my fault. 

Still, I think that removing of Qt Assistant in Qt 6.0 is only a 'blocker' for 
the developers that ship Qt Assistant binaries as a help viewer for their own 
content. If you are one of them, please speak up at 
https://bugreports.qt.io/browse/QTBUG-88406 , so we can prioritize accordingly.

For users that use Qt Assistant to browse Qt documentation, it's a mere 
inconvenience, with multiple alternatives available. 

Regards

Kai


PS: I'll probably start a separate discussion about Qt Linguist soon (but only 
after Qt 6.0 is out). The same reasoning applies there, just that Qt Linguist 
shares code with lupdate and the other command line tools, so it wasn't that 
easy to remove for now.

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of Kai
> Pastor, DG0YT via Development
> Sent: Thursday, November 19, 2020 7:03 AM
> To: development@qt-project.org
> Subject: Re: [Development] Qt 6 co-installability with Qt 5
> 
> Am 18.11.20 um 15:50 schrieb Kai Köhne:
> > FYI, we've been taking assistant out of Qt 6.0.
> > https://bugreports.qt.io/browse/QTBUG-86746 . It's not depending on
> > any particular Qt version, so my suggestion is to resurrect it (if
> > there's enough demand) outside of qt5.git.
> 
> Could you please clarify: Can building Qt Asistant be enabled by a
> configuration option? Is it still build as part of CI?

Currently not. I think it should be completely removed from qttools - disabling 
the build was just the quickest way for the 6.0 release.

> Now with all Qt help links changed to the online version, how is Qt
> Assistant/QTextBrowser limiting Qt's documentation at all, justifying its
> removal from the build (so late in the Qt 6 release process)?

The reason why we removed Qt Assistant in the beta phase is that I don't think 
it should be part of Qt 6.

Regards

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 6 co-installability with Qt 5

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
>> On Tuesday, 17 November 2020 00:46:32 PST Joerg Bornemann wrote:
>> It is certainly possible to add a further configure option a la
>>  -qt-executable-suffix -qt6
>> to move the burden from the packagers to Qt's build system and ensure 
>> consistent Qt installation layouts across distributions.> That's a good 
>> solution, so long as the packages built from qt.io also use it.
> Can we count on that?

Why should the packages in the online installer change? They are hardly ever 
installed into some general directory.

Also, this most likely will set us back in the release process. Doing 
large-scale renames at RC time is just asking for trouble. Let's consider this 
in time for Qt 7.

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Installer/Marketplace/Package Manager

[Kai Köhne]

Hi Giuseppe,

I agree that the current situation is somewhat complicated. But the approach 
piloted at https://www.qt.io/blog/qt-6-additional-libraries-via-package-manager 
hopefully will help to tell a more aligned story in the future, at the price of 
(temporarily) adding yet another way of getting libraries (add mandatory xkcb 
link here).

Let me explain where we're coming from, and why the new approach will hopefully 
allow the Qt ecosystem to grow, and also allow for more flexible setups than 
it's traditionally possible with our online installer setup.

The primary channel we have for distributing Qt to our users is currently the 
online installer. It provides always the latest Qt packages, prebuilt for the 
most common platforms/compilers. Anyhow, it's clear by now that this approach 
of providing binary packages built by The Qt Company has its limits. Just from 
the effort side (both human and CI), we cannot endlessly add packages to a 
'monolithic' Qt release, and still expect to make releases on time. Also, 
because a lot of modules also use internal API, it's hard to support packages 
that are released independently of the main Qt, or do support different Qt 
versions in one package. This all puts a limit on the growth and flexibility of 
what typical users (without additional effort) can get as 'Qt' in the online 
installer.

So for some of the packages, we decided it's easier to distribute them as 
source only. Anyhow, it's not convenient to find, use, and build these, 
especially if you're used to just use the online installer.

With the approach in 
https://www.qt.io/blog/qt-6-additional-libraries-via-package-manager we want to 
overcome some of these limitations, bringing the online installer and source 
packages closer together. Qt users will get additional libraries through the 
online installer. But instead of a pre-built package, they get a Conan recipe 
that allows them to build things locally, in their specific environment for 
their selected Qt version.

If this approach works out, we should arguably leverage it for many more Qt 
Addons. Anyhow, we're arguably very late in the game for 6.0, so the aim is to 
pilot it with some modules first.

Hope this explains the big picture a bit.

Regards

Kai

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Giuseppe D'Angelo via Development
> Gesendet: Freitag, 30. Oktober 2020 12:35
> An: development@qt-project.org
> Betreff: [Development] Installer/Marketplace/Package Manager
> 
> Hi,
> 
> referring to
> 
> > https://www.qt.io/blog/qt-6-additional-libraries-via-package-manager
> 
> it looks like that the situation regarding Qt binary packaging and 
> distribution
> around the time 6.0 will be shipped will look like this:
> 
> 
> 1) Binary (*) Qt Essentials from the installer, OSS+Comm
> - QtCore, QtWidgets, QtQML, etc.
> 
> 2) Binary (*) Qt Addons from the installer, OSS+Comm
> - QtSQL, QtQuick3D, etc.
> 
> 3) Binary (*) extras from the installer, OSS+Comm
> - QtCreator, MinGW, OpenSSL, CMake, etc.
> 
> 4) Source and/or binary Qt Addons from the Marketplace, OSS+Comm
> - QtPDF, QtCharts, etc.
> 
> 4a) Non-software products from the Marketplace
> - E.g. TQC Trainings
> 
> 5) Source Qt Addons from the Package Manager, OSS(+Comm?)
> - Qt3D, QtImageFormats
> - to be built manually
> 
> 
> (*) One can install the source, but they're for debugging, one doesn't
> build them
> 
> Am I getting the complete picture? And am I the only one who finds this
> extremely confusing? How is the decision regarding what-goes-where made?
> 
> 
> Thanks,
> 
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company
> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
> KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] http://download.qt.io/new_archive/qt/

[Kai Köhne]

Hi,

We noticed the same. It seems a sync'ing issue, I created 
https://bugreports.qt.io/browse/QTQAINFRA-3944.

Kai

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Konstantin Tokarev
> Gesendet: Freitag, 2. Oktober 2020 14:41
> An: Qt Project Development Mailing-List 
> Betreff: [Development] http://download.qt.io/new_archive/qt/
> 
> Hello,
> 
> Seems like a lot of files were removed today from
> http://download.qt.io/new_archive/qt/
> Was it intentional? Are these archives available somewhere else?
> 
> --
> Regards,
> Konstantin
> 
> ___
> 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] "Examples and demos" component in Jira (QTBUG project)

[Kai Köhne]

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Santtu Ahonen
> Betreff: Re: [Development] "Examples and demos" component in Jira (QTBUG
> project)
> 
> Retiring the component would be a massive loss of data and alignment
> between projects. This before retirement proposal we should have a plan on
> how to manage this area properly. Granted, this is a messy area without clear
> ownership thus we can argue on what team / who should be the owner of the
> component.
>
> In fact the component combines two different use cases (Examples and
> Demos) and it is not helping that different Qt projects have differently named
> components for the same overall use case.

Well, then I'm wondering what the loss of alignment is 

> In Product Management we use quite a lot of these Demo components to
> track demos we need to create for specific customer verticals or events,
> marketing needs etc. Our master board is here:
> https://bugreports.qt.io/secure/RapidBoard.jspa?rapidView=83

The filter query for this very board is: 

component in (Demo, Demos, "Demo Design (internal)", "Demo Implementation 
(internal)", DemosAndPresentations, "Examples and Demos", Examples) OR labels 
in (example, examples, Examples)

So the fix for QTBUG is easy: Tag the JIRA issues you're interested in in QTBUG 
with 'example' label. Or even better, extend the query and use a more 
descriptive label like 'pm_demo'. Because I actually doubt that the various 
bugs we have currently reported against the 'Examples and Demos' component are 
really regularly reviewed by PM.

> If we touch this area I'd be welcoming on splitting the Examples and Demos in
> to two separate use cases but this is not an issue for just QTBUG project, 
> this
> goes across the board and over several projects. 

If we ever get properly maintained demos into QTBUG back (with clear 
responsibility) then I'm certainly not against it.

Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [baremetal] Integration of bare-metal C-SPY debugger from IAR EW to QtCreator

[Kai Köhne]

Hi Denis,

Thanks for the initiative! Give us some time to raise the matter with them 

Kai

Von: Development  Im Auftrag von Denis 
Shienkov
Gesendet: Mittwoch, 26. August 2020 08:38
An: development@qt-project.org
Cc: Qt HJK 
Betreff: Re: [Development] [baremetal] Integration of bare-metal C-SPY debugger 
from IAR EW to QtCreator


PING
24.08.2020 12:48, Denis Shienkov пишет:

Hi guys,

Recently in a Qt press release from 15 Apr 2020:

* 
https://www.qt.io/press/the-qt-company-and-iar-systems-collaborate-to-deliver-streamlined-development-of-ui-applications

states that the Qt-company have planns to collaborate with the IAR Systems 
company for the MCU devices.

I have long planned to add support for debugger (seems, it's called C-SPY 
debugger) from IAR EW to the BareMetal QtCreator plugin to make possible to 
debug the different MCU's using the HW debuggers.

But, a problem is that the IAR EW does not provide the public API documentation 
described the integration process for its debugger to the custom IDE's.

It provides the ready binary plugins only for the Eclipse IDE:

* http://eclipse-update.iar.com/

So, as you have planns to collaborate with the IAR Systems, then, could you 
please ask them to provide a such documentation? In this case I can try to 
start the integration for IAR debugger &&
QtC (I even can do it under NDA if necessary).

What do you think? :)

PS: I already did the Keil debugger && QtC integration for the ARM architecture 
and some HW debuggers. So, next step is IAR EW. :)


BR,
Denis




___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Where's the dev headers check and -Werror build?

[Kai Köhne]

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Thiago Macieira
> Gesendet: Mittwoch, 26. August 2020 04:58
> An: development@qt-project.org
> Betreff: [Development] Where's the dev headers check and -Werror build?
> 
> https://codereview.qt-project.org/c/qt/qtbase/+/309273 (dev) integrated
> without error. But the cherry-pick of the exact same change to 5.15 in
> https://codereview.qt-project.org/c/qt/qtbase/+/311495 failed due to -
> Werror.
> 
> So where is the dev one?

The commit in dev did actually run headerscheck on the commit, see the log in 
https://testresults.qt.io/coin/api/results/qt/qtbase/ed4664dfc3b08939ec451a1de608568314025380/LinuxRHEL_7_6x86_64LinuxRHEL_7_6x86_64GCCqtci-linux-RHEL-7.6-x86_64-34a8a7UseLegacyInstructions/1f08413e0479bcc3881893430e643bea52af79e8/build_1598371237/log.txt.gz
 . 

Both command lines contain -Werror=float-equal -Werror. Different operating 
systems / compilers (and different other options) are used though. The Linux 
configuration with -headerscheck in dev is currently run on RHEL_7_6, while in 
5.12 (where the error is , not 5.15) it's openSUSE 42.3.

Regards

Kai
 
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] ChangeLog script will need adaptation to cherry-pick model

[Kai Köhne]

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Betreff: Re: [Development] ChangeLog script will need adaptation to cherry-
> pick model
> 
> Jani Heikkinen (11 August 2020 07:09)
> > if the correct behavior is the first one then the script doesn't need any
> change?
> 
> That sounds plausible for everything after the first release of each branch, 
> but
> less convincing for the .0 release: when Qt 6.0 is released, surely we don't
> want to repeat all the change log notes from 5.15.0 to 5.15.x (whatever our
> last release before 6.0 may be) in the 6.0 release notes (especially as many 
> of
> those are deprecations of things removed in 6.0). 

IMO 6.0 is a rather special case in this regard, that anyhow will need quite 
some editorial work.

> Likewise, when 6.1 is
> released, we don't want to repeat the release notes after 6.0.0 up to
> whichever 6.0.x is current when 6.1.0 comes out.  Or, at the very least, we
> probably only want the edited highlights,

From the users point of view listening all changes from 6.0.0 onwards in 6.1.0 
is IMO easier to grasp and work with than following some 'all changes in 6.1.x' 
hint. It indeed means we have some text repetition, but does that cause any 
harm? 

The only downside is that editorial changes will need to be done twice, but 
well ... 

Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Stepping down as QtWebChannel maintainer

[Kai Köhne]

Hi,

Thanks Arno for stepping up! 

+1 from my side for both nominations (Approver and Maintainer).

And thanks, Milian, for having created & maintained the module for such a long 
time 

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> Arno Rehn
> Gesendet: Mittwoch, 17. Juni 2020 15:20
> An: Milian Wolff ; development@qt-project.org;
> psykai1...@googlemail.com; frank.meerkoet...@basyskom.com
> Betreff: Re: [Development] Stepping down as QtWebChannel maintainer
> 
> [...]
> IIRC this is not the first time that Integrity creates trouble for people. 
> Can we
> just drop it for QtWebChannel? Or maybe move QtWebChannel to be an add-
> on in Qt6?

I think we should indeed just not test Integrity for qtwebchannel: 
https://bugreports.qt.io/browse/QTQAINFRA-3834

About the status of Qt WebChannel: It's already an add-on in Qt 5. It's 
currently not planned for the Qt 6.0 release (according to 
https://wiki.qt.io/Checklist_for_Qt_6.0_inclusion). Anyhow, I think it's a 
valuable module, so I do personally hope it will be available soon also for Qt 
6.

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Switch the main "Qt Build System"

[Kai Köhne]

> -Ursprüngliche Nachricht-
> Von: Development  Im Auftrag von
> [...]
> To build autotests, -DFEATURE_developer_build=ON will do that right?  And
> there are also BUILD_TESTING and QT_NO_MAKE_TESTS so what’s the
> relationship?

It's currently the same as with qt 5:

 *  FEATURE_developer_build does (among other things) enable tests 
(BUILD_TESTING) by default, for most platforms.
 * QT_NO_MAKE_TESTS defines whether a default build will build the tests; the 
default is OFF (so a mere ninja/jom ... will build all tests)

Question is whether this is actually what we want in Qt 6, see  
https://bugreports.qt.io/browse/QTBUG-84471 for some discussion.

Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Documenting Qt 6 API breakages

[Kai Köhne]

Hi,

We should start documenting the API changes that Qt 6.0 brings soon. This will 
allow getting people getting an overview, help early adopters, and will give us 
time to improve the documentation before the release.

Now I see that there are different paths taken:
- Eskil and others have started listing changes in a page in the qtdoc 
repository, https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html 
- I created a skeleton for Qt Core changes in the qtbase repository: 
https://codereview.qt-project.org/c/qt/qtbase/+/299664 . 

I wasn't aware of the existing page in qtdoc; Anyhow, from past experience I 
prefer having the documentation nearby the actual code. I therefore would like 
move the existing sections about Qt Quick, Qt OpenGL to the respective module 
documentation and let https://doc-snapshots.qt.io/qt6-dev/sourcebreaks.html 
just link to the module documentation pages.

Thoughts?

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] MaintenanceTool and/or InstallerFramework horribly insecure?

[Kai Köhne]

Hi Konrad,

thanks for the report. Volker forwarded it to the qt-project security mailing 
list. Feel free to send further security related issues there.

> When I call MaintenanceTool to install another version of Qt it wants to
sudo into root when it starts to download Qt components.  It still asks
for the sudo password if I quit while selecting components!

I assume you start a new installer here (not the MaintenanceTool of an existing 
installation). Is that really during the download, or in the extractio phase? 
Can you maybe create a bug report and attach the installation log (you can 
start the installer with --verbose)?

> Worse, if I normally have sudo set to NOPASSWD then it does not even ask, it 
> just switches!

This is now tracked in https://bugreports.qt.io/browse/QTIFW-1794

> The temporary directory installerResources has access rights 0557. Other
> directories are group-writable.

There indeed seems to be an issue in the rights of some directories (though I 
personally don't have the 0557 rights). Whether this is an IFW or packaging bug 
needs to be investigated further.

Kai


From: Development  on behalf of Konrad 
Rosenbaum 
Sent: Thursday, May 21, 2020 9:14 PM
To: development@qt-project.org
Subject: [Development] MaintenanceTool and/or InstallerFramework horribly   
insecure?

Hi,


I thought what the heck, lets update the pre-compiled Qt components on
my computer. Apart from making me jump through the Qt Account hoop, I'm
not sure whether this is deliberate (nefariously or incompetently) or
just broken (please tell me it is a simple bug!):


OS: Linux, Debian (testing), amd64

Installation-Directory of Qt: $HOME/Qt of the user running MaintenanceTool

MaintenanceTool version: 3.2.2-0-202003121118


When I call MaintenanceTool to install another version of Qt it wants to
sudo into root when it starts to download Qt components. It still asks
for the sudo password if I quit while selecting components! Worse, if I
normally have sudo set to NOPASSWD then it does not even ask, it just
switches!

The temporary directory installerResources has access rights 0557. Other
directories are group-writable.


I view those as severe security issues:

 - the installer (actually no tool whatsoever) should switch to root
unless absolutely necessary, to prevent escalation of other security issues

 - no interactive tool should switch to root without informing the user

 - the installer must not make any directories or files writable for
anyone but the user running that tool - otherwise other users are able
to attack by inserting malicious code


I have the bad feeling that someone should perform a security audit on
MaintenanceTool and installer framework.



Konrad


___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] On how to deprecate API

[Kai Köhne]

Hi,

After seeing many different ways to deprecate API in Qt 5.15, I thought it 
might make sense to assemble some best practices (comments & extensions 
welcome):

  https://codereview.qt-project.org/c/meta/quips/+/292255

One of the main takeaways is: Please also properly deprecate in the 
documentation (including giving users a hint what to use instead!)

Another thing I'm wondering about is the use of QT_DEPRECATED_SINCE in Qt's 
.cpp files. I see the benefit of QT_DEPRECATED_SINCE in the headers, because 
these are compiled into the user code, who in turn can use 
QT_DISABLE_DEPRECATED_BEFORE. Anyhow, for Qt modules, the define is always 
hardcoded to QT_DISABLE_DEPRECATED_BEFORE=0x05 (or 0x040800 for Windows), 
so is there any point in adding checks in our .cpp files, or is that just cargo 
cult? Shouldn't we just delete code that we don't want to have in Qt 6 anymore?
 
Regards

Kai


--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Kai Köhne]

Hi,

There are now 73 results to the survey, current results are at 

https://bugreports.qt.io/secure/attachment/92413/survey_result.pdf

I tried to aggregate also the other suggestions, and ordering by absolute votes:

mySignal()  - 21 votes
Q_EMIT mySignal() - 13 votes
[[qt::emit]] mySignal() - 12 votes
qemit mySignal() - 5 votes
emit mySignal() - 3 votes
qEmit(mySignal) - 1 vote
keep the \"ugly\" q_emit but don\`t require it. - 1 vote
method call with naming convention - 1 vote
mySignal() // emit, let a comment look lik a comment - 1 vote
[[emit]] - 1 vote
emitmysignal()  - 1 vote

Thanks for participating!

Kai

> -Original Message-
> From: Development  On Behalf Of Kai
> Köhne
> Sent: Monday, February 24, 2020 4:31 PM
> To: Ville Voutilainen ; Lars Knoll
> 
> Cc: Thiago Macieira ; Qt development mailing
> list 
> Subject: Re: [Development] A modest proposal: disable lower-case keywords
> (emit, foreach, forever, signals, slots) by default
> 
> Hi,
> 
> Since this is arguably as much about taste as it is about technicalities, I
> thought it might be interesting to do a quick poll in the form of a survey:
> 
> https://www.1ka.si/a/255723
> 
> Disclaimer: Qt Project is not a democracy, so let's not pretend that whatever
> gets most clicks gets implemented in the end. Still, I'm curious ...
> 
> Kai
> 
> > -Original Message-
> > From: Development  On Behalf Of
> > Ville Voutilainen
> > Sent: Monday, February 24, 2020 2:53 PM
> > To: Lars Knoll 
> > Cc: Thiago Macieira ; Qt development
> > mailing list 
> > Subject: Re: [Development] A modest proposal: disable lower-case
> > keywords (emit, foreach, forever, signals, slots) by default
> >
> > On Mon, 24 Feb 2020 at 14:42, Lars Knoll  wrote:
> > > But we could convey the information that this is a signal you’re
> > > calling
> > *reliably* through other means. This implies that the keyword is not
> required.
> >
> > Was the keyword ever required? Seems like it's just a taste difference
> > from a
> >
> > qEmit(my_signal());
> >
> > to write
> >
> > emit my_signal();
> >
> > The first one can be namespaced, and thus its name lookup controlled.
> > It also never clashes with a member name.
> > Its worse aesthetics aside, if we'd had that since the beginning, we
> > wouldn't be talking about the current clashes with std::osyncstream.
> > ___
> > 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
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Kai Köhne]

Hi,

Since this is arguably as much about taste as it is about technicalities, I 
thought it might be interesting to do a quick poll in the form of a survey:

https://www.1ka.si/a/255723

Disclaimer: Qt Project is not a democracy, so let's not pretend that whatever 
gets most clicks gets implemented in the end. Still, I'm curious ...

Kai

> -Original Message-
> From: Development  On Behalf Of
> Ville Voutilainen
> Sent: Monday, February 24, 2020 2:53 PM
> To: Lars Knoll 
> Cc: Thiago Macieira ; Qt development mailing
> list 
> Subject: Re: [Development] A modest proposal: disable lower-case keywords
> (emit, foreach, forever, signals, slots) by default
> 
> On Mon, 24 Feb 2020 at 14:42, Lars Knoll  wrote:
> > But we could convey the information that this is a signal you’re calling
> *reliably* through other means. This implies that the keyword is not required.
> 
> Was the keyword ever required? Seems like it's just a taste difference from a
> 
> qEmit(my_signal());
> 
> to write
> 
> emit my_signal();
> 
> The first one can be namespaced, and thus its name lookup controlled.
> It also never clashes with a member name.
> Its worse aesthetics aside, if we'd had that since the beginning, we wouldn't 
> be
> talking about the current clashes with std::osyncstream.
> ___
> 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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Kai Köhne]

Hi,

Another alternative is to actually use C++ attributes for this:

  [[qt::emit]] somethingChanged();

C++ attributes are required since C++11, and since C++17 the compiler is also 
required to just ignore one's it doesn't know [1]. Because it is part of the 
core language, It is also something every C++ IDE and tool does accept (and 
could even check for) ...

Kai

[1]: In C++11, gcc and clang seem to still warn. However, there are options to 
disable this.

> -Original Message-
> From: Development  On Behalf Of Kai
> Köhne
> Sent: Thursday, February 20, 2020 2:44 PM
> To: Marc Mutz ; development@qt-project.org
> Subject: Re: [Development] A modest proposal: disable lower-case keywords
> (emit, foreach, forever, signals, slots) by default
> 
> > -Original Message-
> > From: Development  On Behalf Of
> > Marc Mutz via Development
> > Sent: Saturday, February 15, 2020 3:24 PM
> > To: development@qt-project.org
> > Subject: [Development] A modest proposal: disable lower-case keywords
> > (emit, foreach, forever, signals, slots) by default
> >
> > Hi,
> >
> > C++20 will contain new classes with emit() member functions
> > (wg21.link/P0053). While that will only pose problems for users that
> > include the new  header after (almost) any Qt header,
> > this should serve as a second shot across the bows (after namespace
> > boost::signals) that we should change something.
> >
> > To that effect, I'd like to propose that we switch the default for
> > QT_NO_KEYWORDS around.
> 
> As a counter proposal that (I hope) would get broader consensus,  I suggest to
> just do this for 'emit': QTBUG-82379 .
> 
> This keyword always seemed a bit odd to me anyway, because it has no
> semantics that's ensured by the compiler. I understand the ratio behind it, 
> and
> there's obviously tons of code that uses it. But if I have the choice between
> 
>   Q_EMIT somethingChanged();
> 
> and just
> 
>  somethingChanged();
> 
> I personally prefer the second.
> 
> My 2 cents,
> 
> Kai
> 
> ___
> 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] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Marc Mutz via Development
> Sent: Saturday, February 15, 2020 3:24 PM
> To: development@qt-project.org
> Subject: [Development] A modest proposal: disable lower-case keywords
> (emit, foreach, forever, signals, slots) by default
> 
> Hi,
> 
> C++20 will contain new classes with emit() member functions
> (wg21.link/P0053). While that will only pose problems for users that include
> the new  header after (almost) any Qt header, this should serve
> as a second shot across the bows (after namespace
> boost::signals) that we should change something.
> 
> To that effect, I'd like to propose that we switch the default for
> QT_NO_KEYWORDS around.

As a counter proposal that (I hope) would get broader consensus,  I suggest to 
just do this for 'emit': QTBUG-82379 .

This keyword always seemed a bit odd to me anyway, because it has no semantics 
that's ensured by the compiler. I understand the ratio behind it, and there's 
obviously tons of code that uses it. But if I have the choice between

  Q_EMIT somethingChanged();

and just

 somethingChanged();

I personally prefer the second.

My 2 cents,

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Changes to Qt offering

[Kai Köhne]

> Von: Development  Im Auftrag von NIkolai 
> Marchenko
> Gesendet: Montag, 27. Januar 2020 16:27
> An: Ville Voutilainen 
> Cc: Qt development mailing list 
> Betreff: Re: [Development] Changes to Qt offering
>
>>  they will be available 12 months after their commercial release 
>
> That's 12 months for cybercriminals to exploit already fixed vulnerabilities 
> in open source distros...

Well, I think the popular Linux Distributions are pretty good at backporting 
security fixes themselves. Not all Linux distributions have been settling on 
LTS versions in the first place, and all major ones have been packaging Qt 
before LTS versions were even introduced... So, while I'm not a Linux packager 
myself, I don't think this is as dramatic for them as you seem to assume.

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Nomination of Build System Maintainer(s)

[Kai Köhne]

Hi,

I'd like to nominate Jörg Bornemann and Alexandru Croitor as joint official 
maintainers of the Build System in qtbase, which is officially unmaintained [1].

Jörg has been doing a lot of work and reviews in qmake and the existing Qt 5 
build system after Ossi was leaving The Qt Company. 

Alexandru is currently organizing the work around the CMake port (Qt 6 build 
system), and also does a large fraction of the work himself. 

I believe that, together, they are the right ones to maintain the build system 
area in both Qt 5 and Qt 6.

Their individual dashboards:

Jörg: https://codereview.qt-project.org/dashboard/1000120
Alexandru: https://codereview.qt-project.org/dashboard/1004184


Regards

Kai

[1] See https://wiki.qt.io/Maintainers 

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.14 MinGW debug build doesn't add debug suffix

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Thiago Macieira
> Sent: Tuesday, January 14, 2020 4:33 PM
> To: development@qt-project.org
> Subject: Re: [Development] Qt 5.14 MinGW debug build doesn't add debug
> suffix
> 
> On Tuesday, 14 January 2020 00:02:01 PST Kai Köhne wrote:
> > -debug-and-release was completely disabled in Qt 5.14.0, but will work
> > again in Qt 5.14.1 (though still not be the default).
> 
> How will that work? Will it create debug libraries with different names
> compared to a pure debug build?

Yes, I suggest we only add a 'd' suffix if you configured with 
-debug-and-release: 
https://codereview.qt-project.org/c/qt/qtbase/+/286409/6/mkspecs/features/qt_functions.prf

> BTW, what is the situation on Apple platforms these days? I remember
> something about not having "_debug" in pure debug builds either.

It seems that _debug is still always appended on macOS.

There might be the chance to unify things (again) in the future. But for now, I 
think MinGW will keep us busy enough in 5.14 

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt 5.14 MinGW debug build doesn't add debug suffix

[Kai Köhne]

> From: Development  On Behalf Of Dmitriy 
> Purgin
> Sent: Tuesday, January 14, 2020 8:46 AM
> To: Thiago Macieira 
> Cc: Qt development mailing list 
> Subject: Re: [Development] Qt 5.14 MinGW debug build doesn't add debug suffix
>
> I've just discovered another side-effect of this change. I've integrated the 
> qdoc.exe in a custom toolchain for internal use, and it should be able to run 
> in environments > without any Qt installations. So I used to do the 
> windeployqt.exe on it, and it always worked until 5.14. Now windeployqt says 
> that the qdoc.exe is a Debug executable > (!), and it fails to deploy 
> Qt5Cored.dll for obvious reasons. It seems like windeployqt is broken as 
> well. 

Can you file a bug about this? I’m still hoping to fix all remaining issues for 
5.14.1 …
 
> I wonder what happens to debug-and-release builds now.

-debug-and-release was completely disabled in Qt 5.14.0, but will work again in 
Qt 5.14.1 (though still not be the default).

Kai

-- 
Thiago Macieira - thiago.macieira (AT) http://intel.com
  Software Architect - Intel System Software Products



___
Development mailing list
mailto: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] QtCS2019 Notes from "Fuzzing Qt" BoF session

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Oswald Buddenhagen
> Sent: Thursday, November 21, 2019 2:41 PM
> To: development@qt-project.org
> Subject: Re: [Development] QtCS2019 Notes from "Fuzzing Qt" BoF session
> 
> On Thu, Nov 21, 2019 at 12:13:55PM +, Robert Loehning wrote:
> >=== Which code needs fuzz testing the most? === Agreed criteria: Code
> >that operates on possibly untrusted data
> >
> >Proposals from the audience:
> >* Classes
> >** [https://doc.qt.io/qt-5/qcommandlineparser.html QCommandLineParser]
> >** [https://doc.qt.io/qt-5/qtranslator.html QTranslator]
> >
> how do these make any sense here?

We were just brainstorming there.

Anyhow, QCommandLineParser processes command line arguments from the outside. 
These command line arguments might come from other tools, output ... so it 
should be really robust in handling these.

QTranslator: The API is unfortunate in that the default directory were 
translations are looked up is QDir::currentPath()...

Regards

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] QtCS2019 Notes: Clang-based cpp parser for lupdate

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Joerg Bornemann
> Sent: Friday, November 22, 2019 1:25 PM
> To: Kai Pastor, DG0YT ; development@qt-project.org
> Subject: Re: [Development] QtCS2019 Notes: Clang-based cpp parser for
> lupdate
> 
> On 11/22/19 7:21 AM, Kai Pastor, DG0YT wrote:
> > Am 21.11.19 um 20:23 schrieb André Pönitz:
> >> On Thu, Nov 21, 2019 at 07:48:41PM +0100, Oswald Buddenhagen wrote:
> >>> a more radical and much simpler approach would be switching to
> >>> gettext
> >> The most prominent difference is the (usually) per-class automatic
> >> context which I always found too clever to be sensible, and that's
> >> effectively also the only reason to need a C++ parser.
> >
> > Indeed, while 'context' is a useful concept, the (implementation)
> > class name often isn't the best 'context' from a more general point of
> > view (features, human translators, screenshots). And if a class does
> > not inherit from QObject, the context already needs to be declared
> explicitly.
> >
> > Given the Qt Creator example, would it be feasible to make explicit
> > declaration of a file's context mandatory, at least for the existing
> > ("fast") parser? If not mandatory, an explicit declaration could at
> > least disable all automatic detection for the rest of the file, making
> > it possible to use modern C++ without surprises.
> >
> > Maybe this could be complemented by a lconvert feature to rename a
> > context in an existing ts-file, for those who want to move away from
> > class names as contexts.
> 
> That's certainly a possibility. With an explicit context declaration (that's 
> easy
> to detect) on file level we can use an even simpler parser/extractor that
> doesn't have to know much C++ at all.

Keep in mind that you need this context available both at runtime and 
at lupdate time. That is, the only setup how this IMO would reliably work 
is if  we make the context a part of the tr() call - effectively calling 
QCoreApplication::translate(context, string). This is already possible right 
now.

> On the topic of switching to gettext:
> 
> It would be cool to know where this was discussed before. My searches
> yielded nothing.

I remember having a meeting about that in the Trolltech office 2008, 
weren't you there? 

> It's tempting to switch to an established solution.
> Of course we must make sure that gettext is properly supported on all target
> platforms. It seems to be available via vcpkg on Windows at least.
> 
> There needs to be a migration path if we want to use gettext as the
> recommended i18n solution for Qt users (and maybe deprecate the
> lupdate/lrelease). We could provide a migration tool, based on lupdate's
> current parser, that transforms tr("foo") calls to _("foo"). Of course, that 
> gets
> more complicated due to the mentioned context differences.
> And Linguist should probably be able to edit .po files.

Well, if people want to use gettext they can already do so now. But switching 
to 
gettext is a source incompatible change, so even with 'porting' tooling I don't 
think 
we can remove lupdate  / tr() any time soon.

Regards

kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Notes from "Releasing" session in QtCon19

[Kai Köhne]

Hi,

I took the notes for the "Releasing" Session we just had at the Qt Contributor 
Summit 2019: https://wiki.qt.io/Qt_Contributor_Summit_2019_-_Releasing_Notes

High level summary:
* The Releasing Dashboard [1] in JIRA provides a good overview of upcoming 
releases, Qt Creator releases will be added there, too.
* We should list all contributors of a release in the ChangeLog (AP Jani 
Heikkinen)
* Let's encourage people to help editing ChangeLogs (gerrit in-editing) (AP 
everyone)
* Next time for release meeting (cancellations) will be (also) announced in IRC 
channel topic (AP Jani Heikkinen)

Greetings from Berlin!

Kai

[1]: https://bugreports.qt.io/secure/Dashboard.jspa?selectPageId=15911

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt Contributors' Summit 2019 - Registration open!

[Kai Köhne]

> -Original Message-
> From: Bogdan Vatra 
> Sent: Tuesday, September 24, 2019 11:14 AM
> To: development@qt-project.org
> Cc: Kai Köhne 
> Subject: Re: [Development] Qt Contributors' Summit 2019 - Registration open!
> 
> Hi,
> 
>   Considering that QtCS and QtWS are both in Berlin and both in Nov,  is there
> any reason why QtCS date was not choose immediately after QtWS (7-9)?

Hi,

I do realize that actually some people want to join both events, and having 
them 
directly in succession would have saved some travel. 
Anyhow, the venues we've considered for the Qt Contributor Summit weren't 
available around the dates of the Qt World Summit. 

Also, my experience from the one time we had the Qt Contributor Summit right 
before the Qt World Summit was rather mixed; there were timing issues (KDAB
had the training day at the 2nd day of the CS). In addition, the Qt CS was IMO 
also
overshadowed by the World Summit. That is, for people actively participating
in both the World Summit and Contributor Summit it was somewhat exhausting.

Anyhow, there will be actually a session regarding contributing to Qt at the 
World Summit:

https://www.qtworldsummit.com/2019/sessions/contributing-qt-breakfast-session/


Regards

Kai

> Cheers,
> BogDan.
> 
> În ziua de miercuri, 18 septembrie 2019, la 17:42:18 EEST, Kai Köhne a scris:
> > Hi,
> >
> > Registration to the Qt Contributors Summit 2019 (Nov 19-21th) is now
> open!
> >
> > https://www.surveymonkey.com/r/RNN7NXP
> >
> > The event is open to anyone who has contributed to Qt. It is free of
> > charge, but requires registration so that we can do some planning.
> > There's also a maximum amount of people we can accommodate, so it's
> > best to register as soon as you have made plans!
> >
> > You can find more about the event at
> >
> >   https://wiki.qt.io/Qt_Contributors_Summit_2019
> >
> > We'll continue to update the wiki, especially the program page:
> > https://wiki.qt.io/Qt_Contributors_Summit_2019_Program
> >
> > Regards
> >
> > Kai
> >
> > --
> > Kai Köhne, Director R | The Qt Company
> >
> > The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
> > Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho 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 mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt Contributors' Summit 2019 - Registration open!

[Kai Köhne]

Hi,

Registration to the Qt Contributors Summit 2019 (Nov 19-21th) is now open!

https://www.surveymonkey.com/r/RNN7NXP

The event is open to anyone who has contributed to Qt. It is free of charge, 
but requires registration so that we can do some planning. There's also a 
maximum amount of people we can accommodate, so it's best to register as soon 
as you have made plans!

You can find more about the event at

  https://wiki.qt.io/Qt_Contributors_Summit_2019

We'll continue to update the wiki, especially the program page: 
https://wiki.qt.io/Qt_Contributors_Summit_2019_Program

Regards

Kai

--
Kai Köhne, Director R | The Qt Company

The Qt Company GmbH, Erich-Thilo-Straße 10, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Save the date: Qt Contributors Summit 2019 is 19th - 21st November in Berlin

[Kai Köhne]

Hi Florian,

We'll run the Contributor Summit in Berlin Adlershof. I started to create a 
wiki page for this, expect more updates in the next days!

https://wiki.qt.io/Qt_Contributors_Summit_2019

Regards

Kai

> -Original Message-
> From: Development  On Behalf Of
> Florian Bruhin
> Sent: Monday, September 9, 2019 6:24 PM
> To: Tuukka Turunen 
> Cc: development@qt-project.org
> Subject: Re: [Development] Save the date: Qt Contributors Summit 2019 is
> 19th - 21st November in Berlin
> 
> Hey Tuukka,
> 
> On Thu, Sep 05, 2019 at 11:23:28AM +, Tuukka Turunen wrote:
> > We are working on getting the registration open in the coming weeks as
> > well as more details of the planned structure.
> 
> I don't mean to be pushy, but is there any chance you could share a more
> exact location already, if that's set?
> 
> I'd like to take care of accommodation ASAP since I plan to come to Berlin
> before Qt World Summit already and stay until Qt Contributors summit, so
> it'd be good to know where in Berlin :)
> 
> Thanks!
> 
> Florian
> 
> --
> https://www.qutebrowser.org | m...@the-compiler.org (Mail/XMPP)
>GPG: 916E B0C8 FD55 A072 | https://the-compiler.org/pubkey.asc
>  I love long mails! | https://email.is-not-s.ms/
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: QStringLiteral)

[Kai Köhne]

> Anyway, my ultimate goal is to create and distribute my Qt apps the same
> way as Qt's installation program (you can tell I really admire that
> program a lot :-)
> i.e. link *everything* statically and build myself a ~ 20 MB humongous
> .exe file (which only needs msvcrt.dll). And that kind of linking,
> Microsoft has never supported nor allowed it.

I'm pretty sure the Qt Installer / MaintenanceTool is actually built with MSVC 

Microsoft supports linking in a static version of the visual studio runtime 
library  by the /MT compiler flag. Qt will automatically do this for you if you 
configure it with -static-runtime .

Kai

From: Development  on behalf of Henry 
Skoglund 
Sent: Wednesday, August 21, 2019 9:36 PM
To: Elvis Stansvik 
Cc: Qt development mailing list 
Subject: Re: [Development] Dropping MinGW support in Qt 6 (Was: HEADS-UP: 
QStringLiteral)

Yes, I also used app-local deployment, problem is that Microsoft has not
committed 100% to allow it (as far as I know), instead they have a
seesaw approach, saying "you can temporarily use app-local deployment but.."

Anyway, my ultimate goal is to create and distribute my Qt apps the same
way as Qt's installation program (you can tell I really admire that
program a lot :-)
i.e. link *everything* statically and build myself a ~ 20 MB humongous
.exe file (which only needs msvcrt.dll). And that kind of linking,
Microsoft has never supported nor allowed it.


On 2019-08-21 21:22, Elvis Stansvik wrote:
> Den ons 21 aug. 2019 kl 20:52 skrev Henry Skoglund :
>> Please, don't drop MinGW, it's in my meaning the best compiler on Windows.
>>
>> I've switched from VS to MinGW, the #1 reason: I can distribute an .exe
>> file which is runnable directly on the user's desktop (no installation).
>> This is *verboten* when using VS, you have to send along the
>> distribution dlls (ucrtbase.dll etc.) and install them.
> Why not just ship those DLLs? I wouldn't call that "verboten"
> (forbidden), just a bit more to do for deployment.
>
> We do app-local deployment (putting the DLLs next to our application),
> which is still supported, and makes it possible for us to deliver a
> portable ZIP in addition to an installer. You don't have to go the
> route of launching the redistributables installer.
>
> To make it less inconvenient we use CMake's
> InstallRequiredSystemLibraries module along with setting
> CMAKE_INSTALL_UCRT_LIBRARIES to make sure the Universal CRT DLLs are
> also bundled.
>
> Elvis
>
>> Also, big wheels like Qt's installer program (MaintenanceTool.exe) have
>> also switched from using Visual Studio to MinGW. I believe for the same
>> reason as mine above, except MaintenanceTool.exe didn't include any VS
>> .dlls, so on early Windows 10 versions, MaintenanceTool.exe failed to
>> start, because no VS2015 runtime was installed.
>>
>> Nowadays MaintenanceTool.exe only requires the 32-bit MSVCRT.DLL to be
>> present, and tbat .dll always gonna be there (just like the VB6 runtime
>> etc.)
>>
>> This is one of the few places where Windows still shines: Qt's OOBE on
>> Windows. On that platform, you don't need any chmod +x or waiting for a
>> .dmg to unpack, just double-click on the .exe file.
>>
>> Rgrds Henry
>>
>>
>>
>> On 2019-08-21 20:35, Mathias Hasselmann wrote:
>>> Am 21.08.2019 um 19:38 schrieb Thiago Macieira:
 PPS: can we drop MinGW support in Qt 6?
>>> What alternative do you propse?
>>> ___
>>> 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

___
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

[Development] Qt PDF as a new TP module for Qt 5.14

[Kai Köhne]

Hi,

I suggest to promote Qt PDF to a Qt module. For Qt 5.14, it will be in Tech 
Preview state, and Shawn Rutledge is volunteering to be the maintainer. 
Although still staying an independent library from the user's perspective, it 
will be hosted and built in the qtwebengine.git repository. Initially only the 
desktop platforms (Windows, Linux, macOS) would be supported.

Qt PDF is so far a Qt labs module [1]. It allows Qt applications to render/view 
PDF's in QWidget based applications [2], and is built on top of PDFium. 
However, development has been stagnant, also because it is built on top of a 
rather old version of PDFium.

Why wasn't PDFium updated? PDFium got merged into Chromium a while ago, and is 
nowadays built as part of Chromium, using their build system (gn). Updating 
qtpdf.git to ship with latest PDFium would require quite some work, and keeping 
it up to date would require continuous work, too - work that nobody was willing 
to invest into so far.

But it turns out that, since Qt 5.11, we have PDFium already in our sources, 
and we're actually also building it! It's part of the Qt WebEngine libs that 
use it for PDF rendering in HTML. So technically, you can already render PDF's 
by loading them into a Qt WebEngine page. Anyhow, not everybody wants to ship a 
web browser for 'just' rendering PDF's [3] ...

So the idea is that we leverage on the existing build infrastructure for PDFium 
in qtwebengine.git, and host and build the Qt PDF libraries there. This also 
means that PDFium will be updated as part of the regular Chromium updates in 
qtwebengine.git. qtwebengine.git would furthermore get configure flags so that 
you can build just the Qt PDF libs. And, to reiterate: The Qt PDF libraries 
will _not_ depend on Qt WebEngine libs at runtime.

What do you think? Are there any objections for going forward with this for Qt 
5.14?

Regards

Kai

[1] https://github.com/qt-labs/qtpdf
[2] A Qt Quick API might come in the future
[3] Don't be fooled about the complexity of PDF though: It's quite a big spec, 
which - among other things - requires a JS engine!
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposing CMake as build tool for Qt 6

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Palaraja, Kavindra
> Sent: Thursday, June 6, 2019 3:38 PM
> To: development@qt-project.org
> Subject: Re: [Development] Proposing CMake as build tool for Qt 6
> 
> Hi,
> 
> Just curious, do you have a link to what the draft documentation for CMake
> looks like?

CMake has quite extensive documentation: https://cmake.org/cmake/help/latest/

> qmake's documentation has always been an afterthought. The documentation
> equivalent for CMake should be better than that – at the very least, it
> shouldn’t result in another https://wiki.qt.io/Undocumented_QMake and
> such.

I think this is the case  We're also gradually improving the documentation of 
CMake macros that Qt provides, see 
https://codereview.qt-project.org/q/topic:%22cmake_transition%22 (reviews 
welcome btw).

Now there will still be CMake macros & functions that are only used when 
building Qt itself (-> are internal). I don't think it makes sense yet to 
document them, because they're still in flux. But once things stabilize it 
would be IMO a good move to at least provide overview documentation.

Regards

Kai
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Qt XML and Qt Xml Patterns

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Bernhard Lindner
> Subject: Re: [Development] Qt XML and Qt Xml Patterns
> 
> > It's good that Bernhard has received an official statement.
> 
> I agree! Thank you!

Indeed, thanks for bringing this up here! We quite obviously should improve
the processes here.

> > In general, I think the Qt Company could make a little more effort to
> > communicate such decisions, educate its user community, and attract
> > new potential maintainers. Actually, communication should start before
> > a problem results in a decision. Isn't that an important aspect of community
> building?

No question about that. I can assure you though there was no ill-intend.
Let's try to do better in the future.

> Agreed as well.
> 
> 
> Assuming that Qt Xml is deprecated as well (still not sure) this is the fourth
> time a deprecated component tears major holes in my applications. Regarding
> Qt Xml and Qt Xml Patterns it surprises me a lot since I consider them 
> essential
> components. I will use the stream classes under no circumstances. This means
> in my book Qt does not support one of the most important techniques (XML)
> anymore. Hard to believe.

I'm with you on Qt XML; Uploaded 
https://codereview.qt-project.org/c/qt/qtbase/+/262779 for improving 
the documentation.

But maybe some approver wants to step up and become the official maintainer
of Qt XML?

For Qt XML Patterns, the situation is IMO a bit different. The module has
some architectural problems, and there are good alternatives out there (check
out e.g. https://xml.apache.org/xalan-c/ for XSLT).  So I think it's more honest
to our users to mark it deprecated, than to assume it's in a good state and 
should
be used for new projects.

> Obviously "no maintainer" is enough for a deprecation. 

No, there's no automatism here. We have other areas without an official 
maintainer, 
and they are not deprecated (nor do I expect them to be any time soon):

https://wiki.qt.io/Maintainers

Having no official maintainer is obviously not a very satisfying situation 
though.
 
But in the end we should consider each case individually.

My 2 cents,

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Proposal: Using Gerrit for new approver proposals?

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Florian Bruhin
> Sent: Monday, May 20, 2019 10:50 AM
> To: development@qt-project.org
> Subject: [Development] Proposal: Using Gerrit for new approver proposals?
>[...]
> What about using Gerrit to do so? I'm not sure how the repository would look
> (probably just text files with the proposal text)? Then people could +1 that
> change instead.

I wouldn't mind that. But there's also an easier way: Do hold yourself back 
with giving +1's if there's a +1 already.

Becoming an approver just needs someone nominating you + one approver or 
maintainer supporting this. I can see that people want to express their support 
for a nomination, but technically only _one_ +1 is required. 

If everybody would stick to this, the process would be just three mails 
(announcement, +1, final confirmation).

My 2 cents

Kai

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] Assistant WebKit/WebEngine support

[Kai Köhne]

> -Original Message-
> From: Development  On Behalf Of
> Subject: [Development] Assistant WebKit/WebEngine support
> 
> Hi,
>
> I am prepared to do some work on Qt Assistant, and I'd like to know how that
> will be received.

Cool, great you want to tackle this 

I'm sure Jarek (the official maintainer) will also share his thoughts, but he's 
out 
of office this week.

> [...]
> I have been looking into the plugin idea, and although it is not straight 
> forward
> I think it is doable. Some larger refactoring is needed to achieve a clean 
> border
> between Assistant and the viewer plugin interface. My goal is to eliminate 
> calls
> from the viewer plugin back into the Assistant application, which would
> otherwise require some classes to be in a common shared library. I can
> implement the QTextBrowser based viewer in a plugin that is statically linked,
> so that Assistant will work out of the box whether it is being deployed with 
> or
> without WebEngine. Plugins can be selected based on priority.

That sounds like a good approach to me.

Another abstraction you might consider is using Qt WebView as universal backend:

https://doc.qt.io/qt-5/qwebengineview.html

Qt WebView is an abstraction for showing web content, using different backends
on different platforms.  It is currently geared towards the mobile platforms, 
using
Qt WebEngine as default backend on the desktop. Anyhow, it has already an
(experimental) backend on macOS using Safari, and my hope is that we can make  
it also work with the new Chromium based Edge browser on Windows, 
see  https://bugreports.qt.io/browse/QTBUG-75747 .

Anyhow, I'm not sure the QtWebView API is actually capable enough to cater for
Qt Assistant. One obvious challenge is that you've to pass a url to the engine 
that 
it can actually resolve. This probably means either extracting the html in the
.qch files to a local directory, or even running a minimal local web server. 
There
might be even more functionality missing ... 

But Qt WebView has already a plugin infrastructure, so you can at least take
inspiration from there  

> Having the viewer back end be separated from the application with a plugin
> interface may be an advantage regardless, whether WebKit comes back or
> WebEngine is being removed from the Qt distribution in the future. At least
> users will have a possibility to replace the default viewer with whatever
> alternative is available.
> 
> Does this sound like a good idea?

I think your approach makes sense, but I'd wait for Jarek to comment first.

Also, would you mind creating a JIRA item for this ? This way it's easier to 
track...

Regards

Kai 

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

Re: [Development] [Interest] Qt World Summit 2019 - CfP

[Kai Köhne]

Hi,

The deadline for submissions indeed got extended to * 2nd of June *... which is 
already end of next week!

So feel free to still submit proposals, but hurry up 

https://www.surveymonkey.com/r/K7PMKC8

Regards

Kai

> -Original Message-
> From: Interest  On Behalf Of Giuseppe
> D'Angelo via Interest
> Sent: Thursday, May 2, 2019 11:01 AM
> To: inter...@qt-project.org
> Subject: Re: [Interest] Qt World Summit 2019 - CfP
> 
> Hi,
> 
> On 23/04/2019 11:49, Kai Köhne wrote:
> > For Berlin, we (again) have an open Call for Presentations. The deadline for
> submissions is already *3rd of May* - that is, Friday next week!
> >
> >
> > https://blog.qt.io/blog/2019/03/27/qt-world-summit-2019-call-presentat
> > ions-open/
> >
> > Check out above link for the details.
> 
> Looks like the deadline has been moved to June, 2nd (quietly, haven't seen any
> announcement, and the blog post above has been silently patched).
> 
> Cheers,
> --
> Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer
> KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53,
> http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development

[Development] Qt World Summit 2019 - CfP

[Kai Köhne]

Hi,

In case anybody missed it so far - Qt World Summit 2019 will happen on 4-6 
November in Berlin, and 28, 29 November in Tokyo:

  https://www.qt.io/qtws19/home

For Berlin, we (again) have an open Call for Presentations. The deadline for 
submissions is already *3rd of May* - that is, Friday next week!

  
https://blog.qt.io/blog/2019/03/27/qt-world-summit-2019-call-presentations-open/

Check out above link for the details.

Regards

Kai

--
Kai Koehne, Senior Manager R | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, 
HRB 144331 B

___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development