[qt/qt/qtbase]: Summary of bulk changes made

Git repository change summary for qt/qt/qtbase
Pushed by mirror-service into branch 'dev'.
Changed from f3f9e621212688fc6e580c5a4b39b9c7b87603ee to 6eed7d2814205cbc4127a7f544be9cb509cd04ba
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 6bf077c757c1733a4eb3f17889531b31789bfd71 by Seokha Ko on 18/07/2026 at 14:15..
ohos: Register a Mouse device and use it for mouse and wheel events

QOhosPlatformIntegration::getAvailableDeviceTypes() only registered
TouchScreen and TouchPad devices, never Mouse. Event constructors in
QWindowSystemInterface default to
QPointingDevice::primaryPointingDevice(), which falls back to the
TouchPad device when no Mouse device is registered.

QOhosInputMethodEventHandler::onMouseWheelEvent() called
handleWheelEvent() without an explicit device, even though it already
distinguishes UI_INPUT_EVENT_TOOL_TYPE_MOUSE from
UI_INPUT_EVENT_TOOL_TYPE_TOUCHPAD to compute the delta. Wheel events
from a real mouse therefore always carried a TouchPad-typed device, so
QtQuick's WheelHandler ignored them, since its default acceptedDevices
is Mouse only.

Detect a mouse source among the reported OHOS input devices and
register a Mouse QPointingDevice for it. Pick the Mouse or TouchPad
device to attach to a wheel event based on its tool type.

Registering a Mouse device changes what
QPointingDevice::primaryPointingDevice() returns process-wide, which
would silently affect any other event path in the plugin that omits
an explicit device. QOhosInputMethodEventHandler::handleMouseEvent()
was such a path: ArkUI reports mouse move/press/release uniformly for
both a physical mouse and touchpad-driven pointer movement, and it was
relying on that same implicit fallback.

Extend QArkUi::getPointingDeviceType() to also recognize
UI_INPUT_EVENT_SOURCE_TYPE_MOUSE, and thread the resulting device type
through NativeNodeMouseEvent and QOhosMouseEvent so handleMouseEvent()
can look up and attach the matching device explicitly, the same way
onMouseWheelEvent() already does. This keeps touchpad-driven mouse
move/click events classified as TouchPad, as before, and removes the
last implicit use of primaryPointingDevice() for pointer events in
this plugin.

onNonClientAreaMouseEvents() builds its QOhosMouseEvent from
Input_MouseEvent, which has no source-type query (unlike
ArkUI_UIInputEvent), so it left the new deviceType field to its
QOhosMouseEvent::Mouse default. Set it to TouchPad explicitly instead:
guessing Mouse there could make getPointingDeviceOrCreate() register a
phantom Mouse device on a machine that has none, which would then make
primaryPointingDevice() prefer it process-wide; guessing TouchPad
cannot have that effect, since TouchPad is already its fallback.

createPointingDevice() hardcoded systemId to 1 for every device it
creates. getAvailableDeviceTypes() can report several device types at
once (e.g. a laptop with both a touchscreen and a touchpad), so
multiple devices could already end up sharing systemId 1 before this
change; adding a Mouse device made that a three-way collision.
QInputDevice::systemId() is documented to be unique per device when
nonzero, and QInputDevice::operator==() compares only systemId, so
colliding IDs make unrelated devices compare as equal. Reuse the
DeviceType flag value as the systemId, since it is already guaranteed
to be distinct per type handled here. Also factor the register+release
boilerplate shared by both branches of createPointingDevice() into a
small helper.

If querying the device list fails, getAvailableDeviceTypes() falls
back to an empty set and every device ends up being created lazily on
first use instead. Note that consequence in the existing error log,
since the later per-device warnings from getPointingDeviceOrCreate()
don't otherwise reference this earlier failure.

Fixes: QTBUG-147931
Pick-to: 6.12
Change-Id: I0b38163bf4e04af74692c9267e5ef942fbdc41f4
Reviewed-by: SanthoshKumar Selvaraj <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/6bf077c757c1733a4eb3f17889531b31789bfd71

Git commit 5b70af0968e737c568bd21e2ff73fc6c73c4519a by Shane Liu on 18/07/2026 at 14:15..
ohos: report the user-set printer alias as the print device name

HarmonyOS lets the user rename a printer in the system settings. The
new name is not reflected in Print_PrinterInfo.printerName; instead it
is stored in the "printerAlias" key (since API 24) of the detailInfo
JSON object.
https://developer.huawei.com/consumer/en/doc/harmonyos-references/capi-oh-print-print-printerinfo

Override QPlatformPrintDevice::name() to query the printer info and
return the alias when one is set, falling back to the native printer
name otherwise. The info is queried live on each call instead of
caching m_name at construction, so a rename done while the application
is running is picked up.

With this, QPrinterInfo::description() reports the same user-visible
printer name that the system print UI shows.

Pick-to: 6.12
Task-number: QTBUG-148267
Change-Id: I1a1028c6643039a949878aac4eaa50c3c92b4663
Reviewed-by: Joerg Bornemann <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/5b70af0968e737c568bd21e2ff73fc6c73c4519a

Git commit 32759f676fbb9a01e2cca15b45eee7ebec6b9a43 by Dawid Śliwa on 18/07/2026 at 14:50..
ohos: make QOhosSettings a lazy singleton

QOhosSettings is owned by QOhosPlatformIntegration, created only in
initialize(), and reached through instance(), which stays null until
the plugin factory returns, so any settings access between
integration construction and initialize() dereferences null. The
integration constructor announces screens synchronously, and on a
private branch where availableGeometry() consults the PC-mode
setting this crashes every application at startup on phones and
tablets.

Make QOhosSettings a lazily created singleton and drop the
settings() accessor, so the settings can be reached at any point of
the plugin lifecycle. The PC-mode cache stays tied to the
integration - installSettingsCache() is called in its constructor
and the returned handle uninstalls the cache before the JS thread
goes away. Without the cache the value is read live.

Fixes: QTBUG-147940
Pick-to: 6.12
Change-Id: I353338e3dc79dc966a988d1adc093aeb3e908ccc
Reviewed-by: SanthoshKumar Selvaraj <[email protected]>
Reviewed-by: Zbigniew Chyla <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/32759f676fbb9a01e2cca15b45eee7ebec6b9a43

Git commit d423c8e47d77acb897e1cdb939b2576a1dd5906c by Alexandru Croitor on 18/07/2026 at 16:03..
CMake: Fix cmake_automoc_parser regression with foo.moc files

A previous change fixed cmake_automoc_parser algorithm step 1a, which
never did anything due to a missing slash in the path.

This caused a regression when a source file that #include's its own
<base>.moc file lives next to a <base>.h that also declares a
Q_OBJECT. This removed the header's moc_<base>.cpp and its json file
from the output list, even though it should stay there.

Now that the tool more closely mirrors CMake's AUTOMOC behavior in
algorithm step 1b, all of step 1a is removed to fix the issue.

Adjust the algorithm description comment to make it more clear what is
happening.

Add more tests to cover the regressed case.

Amends 590cd59119745544a70f3a60ee9f00a9a46bd76d

Pick-to: 6.12
Fixes: QTBUG-148343
Task-number: QTBUG-147924
Change-Id: Ie1f76090727d9a6391f6abf600baeb2c0be923ab
Reviewed-by: Joerg Bornemann <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/d423c8e47d77acb897e1cdb939b2576a1dd5906c

Git commit f911db5747f1b7db26cf4e5e1f294bebc960a9d9 by Simo Fält on 18/07/2026 at 16:07..
CI: Collect individual Harmony OS test results

Pick-to: 6.12
Change-Id: I88350d3fa70868119d25635725f11540af64142d
Reviewed-by: Matti Paaso <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/f911db5747f1b7db26cf4e5e1f294bebc960a9d9

Git commit 6eed7d2814205cbc4127a7f544be9cb509cd04ba by Doris Verria on 18/07/2026 at 16:50..
Fix docs for QToolbar's isMovable property default value

The docs stated that by default this property is set to true. However,
that is not exactly precise as this property is by default set to
whatever the current style's styleHint() returns for
QStyle::SH_ToolBar_Movable. That just happens to return true for most
styles. Fix docs to mark this distinction.

Pick-to: 6.12
Change-Id: I158f3d4006f0aaa9423fef1ad3de2a1a2e8bd587
Reviewed-by: Axel Spoerl <[email protected]>
https://invent.kde.org/qt/qt/qtbase/-/commit/6eed7d2814205cbc4127a7f544be9cb509cd04ba