[Development] Infinite loop in QML ShaderEffect polish()
Hi all! I've recently bumped into an issue on AuroraOS (a fork of SailfishOS), where as soon as an application window gets created, the output gets filled with logs similar to these, and the application gets stuck: [W] unknown:230 - qrc:/Sailfish/Silica/private/TabBar.qml:230:5: QML OpacityRampEffect: possible QQuickItem::polish() loop [W] unknown:230 - qrc:/Sailfish/Silica/private/TabBar.qml:230:5: QML OpacityRampEffect: OpacityRampEffect called polish() inside updatePolish() of OpacityRampEffect OpacityRampEffect is a ShaderEffect, and, in fact, while debugging I've reproduced the same issue with a pure QtQuick ShaderEffect. The warnings appear even if the ShaderEffect is unused (that is, no source is connected to it): it looks like instantiating it is enough to get the application stuck. The "live" and "recursive" properties have no effect on this. The way I've fixed it (apparently, with no ill side effects) is this: == --- a/src/quick/items/qquickgenericshadereffect.cpp +++ b/src/quick/items/qquickgenericshadereffect.cpp @@ -332,7 +332,7 @@ void QQuickGenericShaderEffect::maybeUpdateShaders() // scenegraph ready. Schedule the polish to try again later. In case #2 // the backend probably does not have shadereffect support so there is // nothing to do for us here. -if (!m_item->window() || !m_item->window()->isSceneGraphInitialized()) +if (!m_item->window()) m_item->polish(); } } == That is, removing the check on isSceneGraphInitialized() and only queue a polish if the window has not been set yet. I noticed that the same logic is followed on the OpenGL implementation (QQuickOpenGLShaderEffect), but the whole logic behind this is not clear to me, so that's why I'm writing here. It indeed looks unlikely that this is a bug, otherwise it would have broken a lot of other setups as well. Could there be something wrong in our QPA plugin (which is for the 99% the same as https://github.com/mer-hybris/qt5-qpa-hwcomposer-plugin)? We are also using a scenegraph plugin, but I verified that even with it being removed, the issue presents itself. For the record, this is on Qt 5.15. Ciao, Alberto -- http://www.mardy.it - Geek in un lingua international -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] [Announce] Qt Creator 10 Beta released
2023-02-16
Thread
List for announcements regarding Qt releases and development via Announce via Development
We are happy to announce the release of Qt Creator 10 Beta! https://www.qt.io/blog/qt-creator-10-beta-released -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-Straße 10 D-12489 Berlin eike.zil...@qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B ___ Announce mailing list annou...@qt-project.org https://lists.qt-project.org/listinfo/announce -- 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 (15 February 2023 08:50) replied:
>>> 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"
>>> }
Edward Welbourne (Wednesday, February 15, 2023 10:45 AM) objected:
>> 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.
and, overlapping with my follow-up correcting that,
Kai Köhne (15 February 2023 17:10) replied:
> 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
It seems we read the same standard at about the same time, arriving at
the same conclusion ;^>
> 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 think we can live with ignoring a warning from linters that aren't
part of our tool-chain ;^>
I've updated my reviews to the "Comment" version.
That just leaves us with the open question of whether to, instead,
switch to some other way of storing the data - preferably one that
supports multi-line strings - with Ulf currently championing QML and
Thiago YAML.
Eddy.
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] QUIP 18: License specification in Qt's modules
On 2/15/23 14:46, Jörg Bornemann via Development wrote: we're proposing a new QUIP: License specification in Qt's modules Please review https://codereview.qt-project.org/c/meta/quips/+/436096 And because QUIP 3 suggests that the initial text is also sent to the mailing list - here's the document attached. Cheers, JoergQUIP: 18 Title: License specification in Qt's modules Author: Lucie Gerard, Jörg Bornemann Status: Active Type: Informational Created: 2022-09-26 Post-History: https://lists.qt-project.org/pipermail/development/2023-February/043648.html Overview This QUIP specifies the licenses that are used in different parts of a typical Qt module repository and also provides helpful guidance about how to express which license source code is under. Note that repositories may deviate from this guideline. Check with the authors and copyright holders of the repository in question. Much of this document overlaps with the "Permitted Licenses in the Qt Free Edition" section of the KDE Software License Agreement [4]_. Please keep this document in sync with the KDE Software License Agreement. License header format = The license header follows the SPDX standard [0]_. There is a Copyright line and a license expression line:: Copyright (C) 2023 The Qt Company Ltd. SPDX-License-Identifier: The copyright line for code written by contributors outside the Qt Company can include that person's name (or legal entity they represent) in the Copyright header. Multiple copyright lines are possible. The `` must be a valid expression, according to the SPDX standard as defined in [1]_. The license identifiers used in a license expression are either from the list of known licenses [2]_ or prefixed with `LicenseRef-`. The license files are placed into a `LICENSES` directory below the Qt module repository's root. The license files are named after the SPDX license identifier followed by ``.txt`` [3]_. Parts of a Qt module repository === This sections defines the different parts of a Qt module repository. Module and plugin implementation Source files that belong to the implementation of Qt modules and plugins. The usual locations for module source code are the subdirectories ``src`` and ``plugins``. Examples Source files that belong to the implementation of Qt examples. The usual locations for examples is the ``examples`` subdirectory. Tests - Source files that belong to the implementation of Qt tests. The usual location is the ``tests`` subdirectory. Tools - Source files that belong to the implementation of Qt tools. The usual location is the ``tools`` subdirectory. Documentation - All ``.qdoc``, ``.qdocinc`` and ``.qdocconf`` files that are needed to generate the documentation. The usual locations for such files are ``doc`` directories all over the Qt module repository's directory tree. Documentation snippets -- Any source code that appears in the documentation. The usual locations are ``doc/snippets`` directories throughout the Qt module repository's directory tree. Build System Files -- All files that contribute to Qt's build system. That includes the following file name patterns: - ``CMakeLists.txt`` - ``*.cmake`` - ``*.pro`` - ``*.pri`` - ``*.prf`` License identifiers per repository part === Different parts of a Qt module repository are licensed differently. The following table lists the SPDX license expressions that should be used and where. ++--+ | Qt repository part | SPDX License Expression | ++==+ | Module and plugin | ``LicenseRef-Qt-Commercial OR LGPL-3.0-only``| | implementation | ``OR GPL-2.0-only OR GPL-3.0-only`` | | (Qt Essentials)| | ++--+ | Module and plugin | | ``LicenseRef-Qt-Commercial OR GPL-3.0-only`` | | implementation | || | (Qt Add-ons) | | *alternatively:* | || | ``LicenseRef-Qt-Commercial OR LGPL-3.0-only`` | || ``OR GPL-2.0-only OR GPL-3.0-only``| ++--+ | Examples | ``LicenseRef-Qt-Commercial OR BSD-3-Clause`` | ++--+ | Documentation | ``LicenseRef-Qt-Commercial`` | || ``OR GFDL-1.3-no-invariants-only``
