-
User Story
-
Resolution: Fixed
-
P2: Important
-
6.7
-
Re-opening, reasons
- https://codereview.qt-project.org/c/qt/qtdeclarative/+/644210 is for dev and not merged, should that now go in to dev/6.11? If so we need to move this to 6.11 not to keep in 6.10
- I'm fine to let it go to dev/6.11 if we did not get exception for FF, if customer later requires this we can pick it then?
Re-opening, reasons https://codereview.qt-project.org/c/qt/qtdeclarative/+/644210 is for dev and not merged, should that now go in to dev/6.11? If so we need to move this to 6.11 not to keep in 6.10 I'm fine to let it go to dev/6.11 if we did not get exception for FF, if customer later requires this we can pick it then?
-
Android
-
2c6be851a (dev), 62cf01a10 (dev), 7d7d68a6c (6.10), 8998fa8b7 (6.10)
Why?
Cause
- Example use case: if tire-pressure change in all four wheels at the moment now each one need to be split to separated emits. After the change you would get this all once.
Customer
- ?
- Technically: more common use case than singleton also harder to work-around than singleton
Cruft
- No customer had wanted this since Qt 6.7, why would need it now?
What?
Definition
- Receive root object QML emits with multiple arguments by introducing a new signal management mechanism
- Find the best way to pass multiple parameters to the user
- We already have QtSignalListener as a functional interface
Demarcation
- This is not complex data model
QTBUG-124803and not for arrays? - This can handle only data up to 1MB - otherwise TransactionTooLargeException
Dependencies
- Previous work
QTBUG-124486 - FF (end of May 2025) dependent 6.10 for the new API
- blocks
-
QTBUG-137025 Early QML signals can be missed
-
- Closed
-
-
QTBUG-130768
QtSignalListener API CI tests
-
- Closed
-
- depends on
-
QTBUG-136061
Upgrade Java version used to compile Qt for Android
-
- Withdrawn
-
- mentioned in
-
Page Loading...