[qt/qt/qtbase]: Summary of bulk changes made
KDE Git Services - Bulk Change <[email protected]>
| Newsgroups | gmane.comp.kde.cvs |
|---|---|
| Message-ID | <[email protected]> |
Git repository change summary for qt/qt/qtbase
Pushed by mirror-service into branch 'dev'.
Changed from 5a9af3dbfa4efffeba7ef82816b391884ce35382 to d94973f5b8b73a876cbab9234aa0f9f20afeb05d
Acknowledgement was received that this change introduces only existing code that has been pushed to another public open source repository.
This change contains the following new commits:
Git commit 158c43050596d7e48f192449d155628c64fcc070 by Zbigniew Chyla on 20/07/2026 at 15:35..
ohos: prefer QNapi Object::eval() over call()
Object::eval() and Object::call() are almost functionally identical:
both resolve a JS member function from an expression and invoke it, and
both support nested calls inside that expression. For example, the
eval() expression
"@ohos.abilityAccessCtrl.createAtManager().checkAccessToken(*)"
is equivalent to the call() method name
"@ohos.abilityAccessCtrl.createAtManager().checkAccessToken"
The only difference is that call() spells the outermost invocation
without trailing brackets and takes its arguments from a separate
parameter, whereas eval() expresses that call in the expression itself.
Keeping two overlapping APIs adds no value and only invites inconsistent
call styles across the code. Standardize on eval(), the more flexible
and more widely used of the two. A bracket-less invocation, should it
ever be needed, remains available through the underlying Napi::* APIs.
Convert the call() uses that remain in qtbase. We plan to remove the
call() member once uses in other modules are gone as well.
Pick-to: 6.12
Task-number: QTBUG-148367
Change-Id: I0131bb9e955111a4acf342742095877cadc7a078
Reviewed-by: Dawid Śliwa <[email protected]>
Reviewed-by: SanthoshKumar Selvaraj <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/158c43050596d7e48f192449d155628c64fcc070
Git commit d94973f5b8b73a876cbab9234aa0f9f20afeb05d by Ulf Hermann on 20/07/2026 at 21:41..
Add QPropertyBindingPrivate::bindingFunctionVTable() accessor
Expose the binding function vtable so that code creating a binding from
a named functor can recover that functor from a type-erased
QUntypedPropertyBinding by matching the vtable against the functor type.
We need this in order to identify translation bindings by compilation
unit when dynamically updating objects during QML preview.
Pick-to: 6.12
Task-number: QTBUG-146122
Change-Id: I5de612bbf04404f297f6ab5da5235ca2bdc81f8a
Reviewed-by: Fabian Kosmale <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/d94973f5b8b73a876cbab9234aa0f9f20afeb05d