main.qml: StatusWindow removed, regular Window used
#19228
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
micieslak
requested review from
a team,
alexjba,
caybro and
noeliaSD
as code owners
Member
Jenkins BuildsClick to see older builds (57)
|
micieslak
force-pushed
the
chore/issue-19218
branch
2 times, most recently
from
05b64dc to
ccfeb2f
Compare
caybro
approved these changes
Nov 6, 2025
Member
caybro
left a comment
caybro
left a comment
There was a problem hiding this comment.
Great if it works everywhere :)
Worth checking if the event listener to quit on close still works as expected; or if we still need it at all
Contributor
|
i will fix the tests |
Contributor
|
i tried to fix it and the "fix" works for the tests with 1 app instance what Squish gives me in inspector is: 
any ideas? |
Contributor
|
based on Squish docs, TopLevel Window should work with Main Window type I tried to hack that locally, but sadly no luck yet |
Member
Author
|
So, summarizing the
This switch led to some behavioral changes in the app:
case Constants.appSection.community:
for (let i = this.children.length - 1; i >= 0; i--) {
var obj = this.children[i]
if (obj && obj.sectionId && obj.sectionId === appMain.rootStore.activeSectionId) {
return i
}
}
// Should never be here, correct index must be returned from the for loop above
console.error("Wrong section type:", d.activeSectionType,
"or section id: ", appMain.rootStore.activeSectionId)
return Constants.appViewStackIndex.communityHow it's possible that that change caused that butterfly effect? The other interesting observation was that after the change, sections started loading in visually more "progressive" way, a bit like web pages in ancient times. And it's the key to understanding the situation. Let's add sth like that e.g. to loader in our Loader {
id: loader
onStatusChanged: {
console.log("STATUS CHANGED ------------------------------> ", status)
}
asynchronous: true
...On On
It means that in Ok, but why, especially knowing that both The answer seems to be in the aforementioned middle-ware code, In that place, the void QQuickWindowQmlImpl::classBegin()
{
Q_D(QQuickWindowQmlImpl);
QQmlEngine* e = qmlEngine(this);
QQmlEngine::setContextForObject(contentItem(), e->rootContext());
//Give QQuickView behavior when created from QML with QQmlApplicationEngine
if (QCoreApplication::instance()->property("__qml_using_qqmlapplicationengine") == QVariant(true)) {
if (e && !e->incubationController())
e->setIncubationController(incubationController());
}
{
// The content item has CppOwnership policy (set in QQuickWindow). Ensure the presence of a JS
// wrapper so that the garbage collector can see the policy.
QV4::ExecutionEngine *v4 = e->handle();
QV4::QObjectWrapper::wrap(v4, d->contentItem);
}
}This discovery seems to be a key for explaining multiple puzzles:
Final conclusions:
|
micieslak
added a commit
that referenced
this pull request
Nov 7, 2025
All Loaders restored to default synchronous mode because with StatusWindow they all were synchronous even with asynchronous property set to true. Along with migration from StatusWindow to Window, those loaders become truly asynchronous causing various subtle issues in the app. Asynchronous behavior will be introduced step by step, with proper handling of loading state. Needed for: #19218 Related to https://bugreports.qt.io/browse/QTBUG-141829 Detailed explanation: #19228 (comment)
micieslak
force-pushed
the
chore/issue-19218
branch
from
4632223 to
df56328
Compare
micieslak
added a commit
that referenced
this pull request
Nov 12, 2025
All Loaders restored to default synchronous mode because with StatusWindow they all were synchronous even with asynchronous property set to true. Along with migration from StatusWindow to Window, those loaders become truly asynchronous causing various subtle issues in the app. Asynchronous behavior will be introduced step by step, with proper handling of loading state. Needed for: #19218 Related to https://bugreports.qt.io/browse/QTBUG-141829 Detailed explanation: #19228 (comment)
micieslak
force-pushed
the
chore/issue-19218
branch
from
df56328 to
7da3cd6
Compare
All Loaders restored to default synchronous mode because with StatusWindow they all were synchronous even with asynchronous property set to true. Along with migration from StatusWindow to Window, those loaders become truly asynchronous causing various subtle issues in the app. Asynchronous behavior will be introduced step by step, with proper handling of loading state. The only exception is StatusRoundedMedia where async behavior is assumed in existing tests. Needed for: #19218 Related to https://bugreports.qt.io/browse/QTBUG-141829 Detailed explanation: #19228 (comment)
micieslak
force-pushed
the
chore/issue-19218
branch
from
7da3cd6 to
6360f11
Compare
Contributor
|
ran full suite here just in case, it looks okay , 1 test failed but thats not related to the changes in this PR https://ci.status.im/job/status-desktop/job/e2e/job/manual/2851/allure/# |
alexjba
approved these changes
Nov 12, 2025
micieslak
added a commit
that referenced
this pull request
Nov 12, 2025
All Loaders restored to default synchronous mode because with StatusWindow they all were synchronous even with asynchronous property set to true. Along with migration from StatusWindow to Window, those loaders become truly asynchronous causing various subtle issues in the app. Asynchronous behavior will be introduced step by step, with proper handling of loading state. The only exception is StatusRoundedMedia where async behavior is assumed in existing tests. Needed for: #19218 Related to https://bugreports.qt.io/browse/QTBUG-141829 Detailed explanation: #19228 (comment)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does the PR do
StatusWindowas none of the custom functionality defined there is usedWindowasynchronous: truefor Loaders has been removed (see the comment below)This is potentially helpful to simplify SafeArea handling as custom window is problematic in some cases, e.g. https://bugreports.qt.io/browse/QTBUG-141733
Important
This PR should be tested on Windows to verify performance. Last attempt to remove
StatusWindowwas abandoned because surprisingly bad performance on Windows (but thenApplicationWindowwas used)Closes: #19218
Affected areas
main.qmlArchitecture compliance
My PR is consistent with this document: QML Architecture Guidelines