There is no need to run the catch-all DPR update if
the window is not visible.
Pick-to: 6.6
Fixes: QTBUG-117762
Change-Id: Ib4e235fed4b21e5aa2ecafa960ab0900e2b68295
Reviewed-by: David Edmundson <davidedmundson@kde.org>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In rare situation, base size could be (-1,-1) or (-2,-2) for high
dpi, it will be converted into huge positive numbers.
https://tronche.com/gui/x/icccm/sec-4.html
If a base size is not provided, the minimum size is to be used
in its place and vice versa.
Pick-to: 6.6 6.5 6.2 5.15
Task-number: QTBUG-117702
Change-Id: I900ed82f2291fb454d7e34a0dee27459d0a57240
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Add missing include of global module header.
Drop unneeded global namespace qualifier for constant in
our namespace.
Amends 6017695bfa
Change-Id: I04633030af13df3c3359fc09b08b4a5f031013a9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Using this trick we force CMake xcode generator to give the more
specific project name when configuring standalone tests.
Change-Id: Ic679003c574c0407bdc8df9eecf3762db214fd50
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Method is trying to infer the signature from the types of the
arguments, but since the argument for the view is a plain jobject
this signature is wrong, method is not found and the view is never
inserted.
Change-Id: I3cbf9bccbcb1e5526f843213ba0f66e5bd1e7107
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When a QWindow is parented into another window, either via its constructor,
or via setParent(), we also update the QObject parent of the window. This
in turn sends ChildAdded and ChildRemoved events to the new and old parent
of the window, as well as ParentAboutToChange and ParentChange to the window
itself.
But at the point when these events are sent, the QWindow parent relationship
has not been fully established. We have not updated d->parentWindow, nor
have we propagated the parent relationship to the platform window.
This is problematic because clients can not use these events to react to
window parent changes synchronously. For example. trying to raise a child
window when added to a parent is not going to work, because at that point
the child window isn't a native child of the parent.
Instead of re-using the QObject events for QWindow, like QWidget does,
by delaying the events or sending them manually at a point when the
window parent relationship has been fully formed, we opt to add new
dedicated events.
Change-Id: I019c14eba444861f537e4f68ab3a82297f843cf7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This is somewhat of a corner case, where there is a single sub-window,
setViewMode(TabbedView) is called before addSubWindow(), and the latter
is called before show(). The sub-window would be active, i.e.
subwindow->d_func()->isActive is true and QMdiArea::aboutToActivate() is
emitted, but QMA::emitSubWindowActivated() is never called for that
sub-window, resulting in that sub-window shown as
unmaximized/with-a-title-bar instead of as maximized/tabbed as is
expected in TabbedView.
Pick-to: 6.6 6.5
Fixes: QTBUG-114188
Change-Id: Ia7b2cfd07c51867707866a1f99f70129bbdc0e3e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
endDrag(false) meant to end a drag with a dock location change.
endDrag(true) meant to abort a drag without a dock location change.
Replace this with a meaningful enumeration.
Define a dummy enum for builds w/o QDockWidget.
Task-number: QTBUG-118578
Task-number: QTBUG-118579
Pick-to: 6.6 6.5
Change-Id: I786f4210f5a3ee67ffcf0dc9285f77a480148569
Reviewed-by: David Faure <david.faure@kdab.com>
QGuiApplicationPrivate::processMouseEvent() requires the following
conditions to be met in order to trigger a double click event:
1. The same button should be pressed (kept in mousePressButton member)
2. The time between two press events should not exceed doubleClickInterval
3. Movement between presses shouldn't be bigger than doubleClickDistance
Unfortunately, when we are processing *synthesized* mouse events (from
touch), in order to check criterion 2) we cannot rely on
QPointingDevicePrivate::pointById(0)->eventPoint.pressTimestamp();
because this was already updated in QGuiApplication::processTouchEvent(),
so it does not any longer reflect the *previous* press timestamp, but
the current one.
Therefore we could not reliably calculate the time between the previous
press and the current press (in fact, it never exceeded the
doubleClickInterval condition)
I suspect this occurs with all touchscreens, but at least it was
reproduced with e.g. a NVIDIA Terra / Thinkvision touch screen on
Windows 11 and Dell Express SVC touch screen on Windows 11.
=> Since QGuiApplication is a singleton, add a static local variable to
remember the time stamp of the last processed press event.
Autotesting has been modelled in PS7. However, QTest::touchEvent is
unable to synthesize hardware specific detection latency and stray
touch events, which actually reproduce the issue.
=> Not adding an autotest.
Fixes: QTBUG-112479
Fixes: QTBUG-119032
Fixes: QTBUG-100688
Pick-to: 6.6 6.5
Change-Id: Idc97fb9d49ed334f56d702d420451fc062e9b5a9
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QList::QList(InputIterator, InputIterator)` is
not in sync with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" command.
Task-number: QTBUG-118080
Change-Id: I576a3b71ba39cec0d51f08f7db9771401e1fa340
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for `QScopedArrayPointer::QScopedArrayPointer(D*)` is
not in sync with the intended target template declaration.
Hence, add the missing information to the relevant "\fn" command.
Task-number: QTBUG-118080
Change-Id: Icf4178989952bbc7dac9a0e8b7cfd031eed3a9d2
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
Some of the documented callables in "qsharedpointer.cpp" are not in sync
with the template declaration of their intended target.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: Iadac55e944aa425205b9d1cd8b4189ffacb4a089
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
When QDoc parses a project, it parses the source code to extract the
user-provided documentation and perform sanity checkings based on the
code itself on it.
When QDoc parses an "\fn" command as part of this process, it tries to
understand, based on its intermediate representation built on the
information extracted from the code-base, which "documentable element"
the "\fn" refers to.
When QDoc performs this "matching" process, it takes into consideration
only a certain amount of information.
For example, no checking is performed over the template declaration of a
callable.
Due to some upcoming documentation, where two callables are
indistinguishable to the current process, as they differ only in their
template declaration, QDoc will start to take into consideration the
template declaration of a callable when matching.
This implies that an "\fn" command should now provide information
parity, with regards to template declaration for callables, with the
code-base so that QDoc can perform the match correctly.
The documentation for
`QModelRoleDataSpan::QModelRoleDataSpan(Container&)` is not in sync with
the intended target template declaration.
Hence, add the missing information to the relevant "\fn" commands.
Task-number: QTBUG-118080
Change-Id: I08c7adf901fac81bb1c115a5017908cba4656bea
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Release and RelWithDebInfo builds always default to passing
--release to androiddeployqt. There is an opt-in variable
(QT_ANDROID_DEPLOY_RELEASE), presumably for Debug builds,
but there is no opt-out for non-Debug builds. Instead,
there is a hack for autotests.
In addition to tests, there are situations during development
where we want to deploy a release build, but do not have or
want to set up the release signing infrastructure. Having a
variable to opt-out is then very useful.
Change-Id: I6c6b9aaccad7d9d4f86745f3ed7d3c475b383ad3
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
More logical than throwing it in the main rhi backend object.
In addition, holding on to the generated data from the last
setShaderResources() per command buffer has great value if/when
more granular resource updating is introduced at some point.
Change-Id: I26887423cf66b27995ec92ae9965d99a40267066
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kristoffer Skau <kristoffer.skau@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
CBV and SRV descriptor ranges default to
DATA_STATIC_WHILE_SET_AT_EXECUTE with RS 1.1.
Due to how constant buffers (that back
Dynamic+UniformBuffer QRhiBuffers) are implemented,
DATA_STATIC is more appropriate, leaving more optimization
opportunities. The buffer contents will not change once
setShaderResources() is called (which is what issues
the SetGraphicsRootConstantBufferView()). In fact
the buffer contents should not be changing anymore during
the whole render pass recording (begin..endPass).
Change-Id: I5901a6d9608fb7c61f04f9d6a3a9acebce37a673
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Nothing is relying on the binding list being sorted based on the
binding number. In many ways the D3D12 backend is very similar
to the OpenGL one: the srb merely holds some flags derived from
the binding list and that's it really, no native resources or
other content are owned directly by the binding set objects.
Change-Id: I35d652c9738308bff691095e43aea9706031dd90
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Because it is.
Amends 405244fe30.
Pick-to: 6.6 6.5
Change-Id: Icc7bb1a000e89b63254ca5c306325d01603eb1d4
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Going through the UIImage.CGImage flattens the image to monochrome.
Change-Id: If74c33badb4e94253b3bf21b6d69bb9f521d6bff
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This fixes an infinite loop reported by a user who had both the
definition of text/javascript from shared-mime-info 2.3 and the
definition of text/javascript from shared-mime-info 2.4 installed at the
same time. In 2.3, text/javascript is a subtype of
application/ecmascript, but in 2.4 application/ecmascript is a subtype
of text/javascript. Having both at the same time resulted in circular
inheritance.
https://gitlab.freedesktop.org/xdg/shared-mime-info/-/merge_requests/258#note_2167707
[ChangeLog][QtCore][QMimeDatabase] Added code to detect and break
circular inheritance loops in the MIME data, which were causing infinite
loops
Pick-to: 6.6 6.5
Change-Id: Ic207b1593a49c7bb88e4fd810d8f88aa630087ce
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: David Faure <david.faure@kdab.com>
If manual test target is created using the standard Qt API but not
qt_internal_add_manual_test command, we need initialize autotools
for these targets. Add the generic functionality that ensures that
autotools are inialized for all manual tests.
Pick-to: 6.5 6.6
Change-Id: Ic048760390174d1be2f01096d70e84458f1c870f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
So far, there was custom handling for exposing the selection
of tab bars on Windows via UIA, s. QWindowsUiaSelectionProvider.
Implement QAccessibleSelectionInterface for QAccessibleTabBar,
so selection is exposed via the platform a11y bridge on all
platforms.
(This makes the custom handling for tab bars
in QWindowsUiaSelectionProvider obsolete for qtbase's own classes,
but there are 4 more uses of the QAccessible::PageTabList role in
qtdeclarative that might need a closer look before dropping
the custom handling from QWindowsUiaSelectionProvider.)
For consistency, also set the selectable/selected state for
the tab buttons (that are the selectable children of the
tab bar).
Sample use via AT-SPI on Linux using Accerciser to interact
on the a11y level (check the current selection, then select
the second tab):
1) run the qtabbar example (tests/manual/qtabbar)
2) start Accerciser
3) select the tab bar in Accerciser's tree view of the
a11y hierarchy
4) query for currently selected item, switch selection
from "Tab 0" to "Tab 1" by using the following commands
in Accerciser's IPython console:
In [10]: sel = acc.querySelection()
In [11]: sel.nSelectedChildren
Out[11]: 1
In [12]: sel.getSelectedChild(0)
Out[12]: <Atspi.Accessible object at 0x7fe01ce8a240 (AtspiAccessible at 0x43928c0)>
In [13]: sel.getSelectedChild(0).name
Out[13]: 'Tab 0'
In [14]: sel.selectChild(1)
Out[14]: True
In [15]: sel.getSelectedChild(0).name
Out[15]: 'Tab 1'
Equivalent on Windows using NVDA's Python console:
1) start NVDA
2) run the qtabbar example (tests/manual/qtabbar)
3) click on the first tab ("Tab 0") in the tab bar
4) press Numpad_insert+control+z to start the NVDA Python console and
capture snapshot variables
5) query and use the interfaces using NVDA's Python console:
>>> import UIAHandler
>>> tabbar = focus.parent
>>> selectionpattern2 = tabbar.UIAElement.GetCurrentPattern(10034).QueryInterface(UIAHandler.IUIAutomationSelectionPattern2)
>>> selectionpattern2.CurrentFirstSelectedItem.CurrentName
'Tab 0'
>>> selectionpattern2.CurrentLastSelectedItem.CurrentName
'Tab 0'
>>> selectionpattern2.CurrentItemCount
1
>>> selectionitempattern = tabbar.children[1].UIAElement.GetCurrentPattern(10010).QueryInterface(UIAHandler.IUIAutomationSelectionItemPattern)
>>> selectionitempattern.Select()
0
>>> selectionpattern2.CurrentFirstSelectedItem.CurrentName
'Tab 1'
Fixes: QTBUG-104602
Change-Id: I49b05bb84852c86a2b8669d7843fe173caf28e18
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
If the attribute does not follow the required
"name:value" syntax, ignore it, rather than crashing
if it doesn't contain any colon.
Same issue as spotted by Jan Arve Sæther during the review
of a QTBUG-118106 related change that would have introduced
the same issue in UIA code.
Pick-to: 6.6 6.5
Change-Id: Id391502ed7aec7f09ef2826a456f2e4737af045e
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
It follows f9e4402ffe.
Fixes: QTBUG-105395
Pick-to: 6.6 6.5
Change-Id: I399c448517b7dbdc28ba33f75ae43102836a8998
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Use std::array<QPoint, 5> instead a dynamic QPolygon since there is no
dynamic allocation needed here.
Change-Id: Iaa6fce9e0e769f2a5dd47de083208457b430f3c3
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Use std::array<QPoint, 5> instead a dynamic QPolygon since there is no
dynamic allocation needed here.
Change-Id: Ica31d22a7b0d44efb901e230f14a00e2ce0a2c0a
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Get the rotation value from the Core Graphics API, and map it to the
Qt::ScreenOrientation values.
Change-Id: I9bc9f37f34e00affee15e6ce0eace70d853eab0c
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Amending c6fe64b17c, which (thankfully)
didn't make the 6.6 feature-freeze cut.
Change-Id: I6c206020af3ba752422cc9f1adaebd7bbbd96024
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This means checks have to be rewritten using endsWith().
It mainly affects the QSizePolicy handling whose values originate from
different sources, including numbers. To address this, refactor the
code to deal with unqualified enum value names and introduce a helper
function that fully qualifies the enumeration when writing out.
Pick-to: 6.6 6.5
Task-number: PYSIDE-2492
Task-number: PYSIDE-1735
Task-number: QTBUG-118473
Change-Id: Iccbb884777aa9c696fbf48f9d7329353ef945b0f
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Tell the compiler that next() and isDone() cannot throw, so it doesn't
need to create exception handling code. This might yield more faithful
benchmark results for micro-benchmarks.
As a drive-by, mark isDone() as const, too.
Change-Id: Ifac3d9ee2f4df524e780fd07423e26bb5e87dab3
Reviewed-by: Jason McDonald <macadder1@gmail.com>
Reviewed-by: Isak Fyksen <isak.fyksen@qt.io>
Follow-up change from enabling DPI awareness, which
caused some style elements (for instance check boxes)
to be rendered incorrectly on non-primary displays,
when there is a difference in DPI between displays.
Use two approaches to get system metrics and themes:
* Use forDpi() API variants and query at 96 DPI for style
metrics, that are in device independent pixels. These are
metrics which are used for layout calculations.
* Get theme metrics at the target display DPI, and scale
to device independent pixels when needed. This is used
for OpenThemeData(), since this theme is used for drawing
as well and needs to be in device pixels.
One approach is not used any more:
* Get metrics for the main display, and scale by the ratio
between the main and target display.
Change the theme cache to cache themes per window handle (HWND).
This is required since OpenThemeData() returns theme data for
a specific DPI, which means we can no longer use a shared
cache.
Clear the cache on theme change, DPI change, and when
the window is destroyed. This handles cache invalidation
when the window is moved to a different screen, and also
when the DPI for a screen is changed.
Move the cache implementation to QWindowsStyleSupport
in QtGui, where it can be accessed by both the style and
windows platform plugins.
Task-number: QTBUG-110681
Change-Id: I5a4ff3a3753762bad8a51d08e51e8013bc7816a1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
the QtDisplayManager listener uses m_layout but it can be called
before m_layout is actually initialized, so set the listener after
the layout has been initialized.
Task-number: QTBUG-118077
Fixes: QTBUG-119007
Fixes: QTBUG-119134
Change-Id: Icebc350f09210c12dbd011f86ce88a90b6f27d12
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
The item_list of a QDockAreaLayoutInfo has abstraction methods for
reading the item list. Adding to and removing from the item list is
done directly, by using the QList api.
Implement an abstraction, that takes a QWidget *.
The argument may either be a QDockWidgetGroupWindow or a QDockWidget.
Task-number: QTBUG-118578
Task-number: QTBUG-118579
Pick-to: 6.6 6.5
Change-Id: Ib2ccd7557a21a43b68f184fe4575018f2a97004b
Reviewed-by: David Faure <david.faure@kdab.com>
When dock widget (1) starts to hover over another floating dock
widget (2), the latter animates a rubber band, to indicate to the user
that it is ready to accept a drop.
The creation of a QRubberBand moves (2) one position up in the Z order.
The consequence is a visual glitch: While
- the mouse cursor dragging (1) is still outside (2) and
- the visual rectangle of (1) starts overlapping (2)
(1) hides behind (2).
As soon as the mouse cursor enters (2), (1) suddenly comes on top and
(2) hides behind (1).
=> raise() 1 as soon as it starts hovering. That brings it on top of
the Z order, which is expected behavior.
Pick-to: 6.6 6.5
Change-Id: I1140fc6ff109c7a713e7e2617072698467375585
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
