If widget A starts at y=0 and widget B starts at y=19, when the mouse
moves from y=15 to y=18.6667, the code was doing childAt(p) with a
rounded QPoint y=19 and finding B, but then the relative coord for B
was set to -0.33333 so B wasn't under the mouse and didn't get an enter
event (and since it's now the "last receiver", it doesn't get one later
either when y is bigger).
Add QWidget::childAt(QPointF) to fix this.
Fixes: QTBUG-128391
Change-Id: I76d4b711a8297648780bdd079eb67405ab12be14
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 40bde8a572bd8ed039d3f5a5ab99b281de7410bd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As a result of c956eb8edd we are now
reparenting QWindows managed by QWidgets when the widget itself or
any of its parent widgets are reparented. When reparenting a child
widget from being a child to a top level, or top level to child, we
need to know the new top level state to determine if the QWindow
should have a QWindow parent or not. As the window flags of the
widget are in flux during the reparenting, we were using the new
window flags of the reparented widget to determine this.
However, for QWidget children of the widget that's being reparented
we can't use the window flags of the reparented widget. We must use
the flags of the child itself. These flags are not in flux, so we
can use QWidget::windowFlags() directly.
Failing to propagate the child widget window flags was causing us to
lose the transient parent relationship to its parent QWindow for
popup windows.
Fixes: QTBUG-127641
Fixes: QTBUG-125149
Task-number: QTBUG-122747
Pick-to: 6.7 6.5
Change-Id: I6dbc5ff5ad019b0f9188516ff3d645e860a9627b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Volodymyr Zibarov <gogan419@gmail.com>
(cherry picked from commit 6c036012b5f2304a05af29f29daa7582603f79ae)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As part of 5ba0982b28 we started calling
QWidgetPrivate::setVisible instead of QWidget::setVisible when showing
children, to avoid setting ExplicitShowHide.
Unfortunately some widget subclasses wrongly override setVisible to do
initialization, which resulted in these widgets not running their init
code. The documentation clearly specifies to use showEvent or Polish
for this use case, but to avoid a regression we temporarily set a flag
that prevents QWidget::setVisible from setting the ExplicitShowHide
attribute.
We can not rely on simply unsetting ExplicitShowHide after our call
to QWidget::setVisible, as the call might recurse into logic that
checks ExplicitShowHide and wrongly determines that the show is
explicit.
Fixes: QTBUG-126721
Fixes: QTBUG-126218
Pick-to: 6.7
Change-Id: Ibf88340b68cb4fcb20ce3d8ec5b76de0fd2d2551
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit fc4c6fb5f6bd6bd63b13f1f8b5b7a7289a5fd230)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When the top level window that a QWindowContainer is in is about to
be destroyed the QWindowContainer must reparent the contained window
into a dummy window, as otherwise the destruction of the top level
will bring down the contained window as well.
We were notifying the window container about this situation when
the window container was moved from being a top level itself, to
being a child widget, but did not have any logic for other ways
the window container could lose its parent QWindow.
An example of this was when RHI-needs would result in recreating
the top revel with a different RHI backend.
We now have a last minute call to toplevelAboutToBeDestroyed in
QWidgetPrivate::deleteTLSysExtra().
Fixes: QTBUG-126303
Pick-to: 6.7 6.5
Change-Id: I5b14e156956ae76a8f53cac31904eaadee9e791f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 006cbf658ea1f5986bbe1baafa7c146780320661)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When invoking setWindowFlags with a QStyleSheet and QProxyStyle set, a
repolish is recursivly done creating a second QStyleSheetStyle in
QWidgetPrivate::inheritStyle due to not cleared WA_SetStyle window flag.
This leads to a use-after-free in the then following recursive call to
QStyle::polish. This patch uses the previously create QStyleSheetStyle
in the case that there is already a QStyleSheetStyle for the proxy.
Fixes: QTBUG-125513
Pick-to: 6.7
Change-Id: I841bf68143e893d74ab7373b7a3d3d4ee2bce514
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 26af5d1854336907d6d7fd6aa1ad060f6d38ce1c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The RHI support and compositor in QPlatformBackingStore were
tied to the surface format of the top level window owning
the backing store.
This meant that inserting an RHI-enabled widget (QRhiWidget,
QOpenGLWidget, QQuickWidget, QWebEngineView) into the widget
hierarchy required recreating the top level window with a
matching surface format that could support the RHI composition.
It also meant that we could not have two RHI enabled widgets
with different surface format requirements (Metal and OpenGL
for example) in the same top level widget hierarchy.
The recreation of the window had various visual side effects,
such as temporarily switching out of full screen state, or the
widget rendering a frame of black, as well as more serious
problems such as not correctly restoring the window geometry.
In addition, if client code had pulled out the winId() of the
window, and did not invalidate these references on window
destruction via QEvent::WinIdChange or QEvent::PlatformSurface,
the client would reference stale window handles. Although
this is a programming error (QWidget::winId() specifically
mentions this requirement), we should avoid recreation if
we can.
We were already supporting flushing the backingstore to
individual native child widgets, but always did so via a
single RHI managed by the platform backingstore. By
expanding QPlatformBackingStore to keep one set of RHI
support and compositor per surface format, we can refine
the logic in QWidget and QWidgetRepaintManager to not
require recreating the top level. Native child widgets
are then flushed independently, including any RHI textures
and raster content that overlaps with the widget.
We still assume that a single RHI support and compositor
can be be used for multiple windows, as long as those
windows have the same surface format. In the future, if
needed, we can refine this to use one set per surface
format e.g.
Fixes: QTBUG-119221
Fixes: QTBUG-121181
Fixes: QTBUG-120096
Task-number: QTBUG-115652
Task-number: QTBUG-108344
Task-number: QTBUG-113557
Task-number: QTBUG-119309
Change-Id: I2635ed3d20c2fb76eab3b8130007dd656a0b93e5
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
For compatibility reasons, QPaintDevice needs to query subclasses for
device metrics as int values. To report fractional DPR values, they
have been multiplied with a large constant and divided back
afterwards. However, the loss of accuracy introduced by this, though
tiny, could still lead to rounding errors and painting artefacts when
the values where multiplied up for large coordinates.
Avoid this issue by adding a metric query that transports the full
floating point value encoded as two ints.
[ChangeLog][QtGui] Added new QPaintDevice metrics for querying
fractional device pixel ratios with high precision. Custom paintdevice
classes that support fractional DPRs are recommended to implement
support for these queries in metric(). Others can ignore them.
Fixes: QTBUG-124342
Change-Id: Ia6fa46e68e9fe981bdcbafb41daf080b4d1fb6d7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Focus abstraction in 58d5d4b7c2 was
supposed to be behavior-neutral. QWidgetPrivate::reparentFocusChildren
used QObject::findChildren() to find children inside and outside the
current focus chain. If the re-parented widget had only direct children
and the focus chain was equal to creation-order, the result was
identical to previous behavior.
When the re-parented widget had grandchildren, the behavior differred.
While not being detected by existing tests, it caused a regression.
Re-implement the previous logic: Iterate through the focus chain,
instead of relying on QObject::findChildren() returning a complete and
well-ordered list.
Modify tst_QWidget::focusChainOnReparent() in order to cover the
regression.
This amends 58d5d4b7c2.
Fixes: QTBUG-125257
Change-Id: Iff4f1d0d9b6117c50c8980dfb6eebfc6f6d4a710
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When no explicit accessible name is set for a window,
QAccessibleWidget::text uses the window title instead for a
non-minimized window.
Send a QAccessible::NameChanged event when changing the
window title results in a change of the accessible name,
to ensure that the AT-SPI cache on Linux gets updated.
Extend tst_QAccessibility::mainWindowTest() to cover the scenario as well.
Note: The entire test function is skipped on platforms not supporting
window activation, e.g. Wayland.
Fixes: QTBUG-124192
Change-Id: I0fa7f683fb5969d6ba9878f6a506c4f192069799
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
As an optimization when calculating the safe area margins for child
widgets we look at the parent hierarchy, and if we find a widget that
is in a layout, and that layout respects the widget's contents rect,
we assume the safe area margins are accounted for already.
But this relies on the widget the layout is operating on to not opt out
of the safe area margins affecting the contents rect. If it does, the
layout can't help us, and we need to fall back to computing the child
widget's safe area margins.
Task-number: QTBUG-125345
Change-Id: I2e2f7d292d2b2c3ecd2e2e95316c4d72b92db5d6
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Rendering a widget to a paintdevice via QWidget::render() did not pass
the LayoutDirection mode of the widget to the paintdevice which lead to
wrong rendering of text.
This is especially visible with the windows 11 style which does not draw
some widgets directly on the screen but through a QGraphicsEffect on a
QImage.
Pick-to: 6.7 6.5 6.2
Fixes: QTBUG-124931
Change-Id: If2cfa326d2ca45c42e203a4ae91fd857afa5c69c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
QWidgetPrivate::isFocusChainConsistent() iterates over
QApplication::allWidgets() to identify and log inconsistencies.
In applications with many widgets, this has a major performance
impact.
Disable the check and return true, unless the logging category
qt.widgets.focus is enabled.
Adapt tst_QWidget::focusAbstraction() to enable the logging category.
This amends 58d5d4b7c2.
Fixes: QTBUG-124666
Change-Id: Ia487b381ab45b052638b189bf56acaf4353b1a37
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
As it is, when a QWindowContainer's embedded window gains focus, the
container doesn't report having focus and QApplication::focusWidget()
will be nullptr. This is because when the embedded window gets focus,
the container will clearFocus() on the old focus widget. To be able
to set focus to the next focus widget (eg: as a result of a key tab
event sent to the container's parent window), the container checks
if its embedded window is already focused, and if so, forwards focus
to its nextInFocusChain(). That is why it keeps track of the (old)
focusWindow.
The problem with the current behavior is that if we want to make focus
navigation via key tabbing work and return focus *from within the
window* back to the normal widget focus chain, the encapsulating widget
needs to remember its focusWidget(), in this case the window container,
in order to be able to set focus to the next/PrevInFocusChain().
That is why we now set the focus to the window container whenever its
contained window gains focus. This means that
QApplication::focusWidget() will be the window container if the contained
window has focus. In this way, we don't have to call clearFocus() on the
old focus widget, or keep track of focus windows, because calling
setFocus() on the container will handle that.
It is worth noting and probably documenting the following caveats:
- even though the window container will be the
qApp's focusWidget(), it won't directly handle keyboard events, but the
contained window will
- we won't be able to respect the window container's focusPolicy in this
case, since the contained window will be activated from interactions
inside it, no matter the container's focusPolicy
[ChangeLog][QtWidgets][QWindowContainer] The window container will
become focused if the contained window becomes focused. This
implies that the QApplication::focusWidget() will be the window
container if the contained window is the focus window.
Task-number: QTBUG-121789
Change-Id: I1050afc59780f7189a0d8e8c95bff27f96f38dbc
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Qt already runs on Vision Pro as "Designed for iPad", using Qt
for iOS. This change enables building Qt for visionOS directly,
which opens the door to visionOS specific APIs and use-cases
such as volumes and immersive spaces.
The platform removes some APIs we depend on, notably UIScreen,
so some code paths have been disabled or mocked to get something
up and running.
As our current window management approach on UIKit platforms
depends on UIWindow and UIScreen there is currently no way to
bring up QWindows. This will improve once we refactor our
window management to use window scenes.
To configure for visionOS, pass -platform macx-visionos-clang,
and optionally add -sdk xrsimulator to build for the simulator.
Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Added in 1bd755465e
We already access oldtlw and oldtlw->d_func() in other places,
and the source of oldtlw is a call to QWidget::window(),
which returns the widget itself if it doesn't have a parent.
This should also fix a CodeChecker issue where it thinks
that the other unchecked accesses to oldtlw are suspicious.
Add assert just in case, so we catch it explicitly if for
some reason this assumption doesn't hold in the future.
Pick-to: 6.7 6.5
Change-Id: Iefa9b2df6b25a993afe87e4ee90fe9d2075ebbd0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QtQuick also uses "lcFocus" as a category name, which
causes link errors in static builds when both QWidget
and QtQuick are linked in one executable.
Making it static is also a good solution, but here
adding a "Widget" prefix seems more consistent.
Change-Id: I0a6a02750bd347f62b67544b4044789612f0fa4d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When a QWidget with an associated RHI swapchain (via its QWindow) is
moved to a different top level window, that top level window has its
own backing store, and QBackingStoreRhiSupport, which doesn't know
anything about the fact that the window already has an associated
swap chain in the original top level window's QBackingStoreRhiSupport.
As having multiple swap chains for the same window is not supported
on all RHI backends (Vulkan and DX in particular), we need to throw
away the swap chain when detecting that the window is moved to a new
top level.
We do this by hooking into the existing WindowAboutToChangeInternal
event delivery to renderToTexture children, which now delivers the
event both to renderToTexture QWidget children as well as QWindows
in the hierarchy. The condition of when to deliver the event has
been updated to reflect whether the top level uses RHI for flushing,
instead of only including renderToTexture children, as the former
also includes setting QT_WIDGETS_RHI=1 explicitly.
The event is then caught by QBackingStoreRhiSupportWindowWatcher,
and handled the same way as for SurfaceAboutToBeDestroyed.
Renaming qSendWindowChangeToTextureChildrenRecursively would make
sense at this point, but to make cherry-picks easier we keep the
current name for now.
Fixes: QTBUG-120276
Pick-to: 6.7 6.5
Change-Id: Ic4c60e89be985f12a84e9f893c299e602b70851a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The focus chain in widgets is implemented as a double-linked list,
using QWidgetPrivate::focus_next and focus_prev as pointers to the
next/previous widget in the focus chain.
These pointers are manipulated directly at many places, which is error
prone and difficult to read.
Build an abstraction layer and remove direct usage of focus_next and
focus_prev. Provide functions to insert and remove widgets to/from the
focus chain.
Add a test function to tst_QWidget.
Task-number: QTBUG-121478
Change-Id: Ide6379c0197137e420352a2976912f2de8a8b338
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When a QWidget was reparented, we would take care to reparent its
backing QWidgetWindow as well, into the nearest QWindow of the
new QWidget parent.
However we would only do this for the reparented widget itself,
and not any of its child widgets. In the case where the widget
has native children with their own QWindows, the widget itself
may not (yet) be native, e.g. if it hasn't been shown yet, or
if the user has set Qt::WA_DontCreateNativeAncestors.
In these scenarios, we would be left with dangling QWindows,
still hanging off their original QWindow parents, which
would eventually lead to crashes.
We now reparent both the QWindow of the reparented widget (as
long as it's not about to be destroyed), and any QQWindow
children we can reach. For each child hierarchy we can stop
once we reach a QWindow, as the QWindow children of that
window will follow along once we reparent the QWindow.
QWindowContainer widgets don't usually have their own
windowHandle(), but still manage a QWindow inside their
parent widget hierarchy. These will not be reparented
during QWidgetPrivate::setParent_sys(), but instead
do their own reparenting later in QWidget::setParent
via QWindowContainer::parentWasChanged(). The only
exception to this is when the top level is about to
be destroyed, in which case we let the window container
know during QWidgetPrivate::setParent_sys().
Finally, although there should not be any leftover
QWindows in the reparented widget once we have done
the QWidgetWindow and QWindowContainer reparenting,
we still do a pass over any remaining QWindows and
reparent those too, since the original code included
this as a possibility.
We could make further improvements in this areas, such
as moving the QWindowContainer::parentWasChanged() call,
but the goal was to keep this change as minimal as possible
so we can back-port it.
Fixes: QTBUG-122747
Pick-to: 6.7.0 6.7 6.6 6.5
Change-Id: I4d1217fce4c3c48cf5f7bfbe9d561ab408ceebb2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
A QDialogButtonBox with the first accept button becoming default, didn't
explicitly set focus on such a button in a QDialog.
d44413d526 implemented this missing
functionality. It set focus to the automatic default button, unless the
QDialog had a focusWidget() set.
That has caused a regression, in cases where
- the QDialog has a QWidget child with a Qt::StrongFocus policy, and
- the QDialog is not yet visible, so focusWidget() returns nullptr.
Amend d44413d526ec12ed83acd7343c2005782178c7ad:
Implement a helper in QWidgetPrivate, that returns true, if a child
with a given focus policy is found.
Do not set focus to a QDialogButtonBox's automatic default button, when
- not located inside a QDialog, or
- a focusWidget() exists, or
- the dialog has QWidget child with Qt::StrongFocus, that is not a
child of the QDialogButtonBox.
Add an autotest function.
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-121514
Fixes: QTBUG-120049
Change-Id: I3c65ae36b56657f9af4a3a4b42f9b66e8bc5c534
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
For accessing the RHI managed by the widget compositing machinery.
Pick-to: 6.7 6.6 6.5
Change-Id: Ia3c1227cc2d9cfebe95611cad3dbcd7aa6f6f8c7
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
In contrast to nativeParentWidget(), we return the closest widget with a
QWindow, even if this window has not been created yet.
Pick-to: 6.7 6.6 6.5
Change-Id: Icac46297a6052a7a5698d752d4aa871bd5c2bdd8
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When destroying a widget via QWidget::destroy(), we clear WA_WState_Created,
and then delete the QWidgetWindow, which in turn hides the widget. But
QWidgetPrivate::setVisible(false) skips hide_helper() if the widget has
not been created, which leaves out important events such as the hide
event, and even more important, fails to clear WA_WState_Visible. As
a result, the widget is left visible (and mapped), even if it has been
destroyed.
This is normally not a big issue for the main use of destroy(), namely
destructing the widget, but for cases where destroy() and create() is
used to recreate the widget this is important.
We now unconditionally call hide_helper() if the widget is not already
hidden. As a result, the widget will correctly be visible=false after a
destroy(). This in turn means we need to re-apply the visible state after
recreating the widget when we detect a mismatch in RHI configuration.
Due to our meddling of the Hidden and ExplicitShowHide attributes in
QWidgetWindow private, a QWidet::show() will not have any effect after
being destroy(). This is okey for now, as destroy() is internal to
a widget, and we make sure to either update WA_WState_Visible and
WA_WState_Hidden (in QWidgetPrivate::setParent_sys), or use the
QWidgetPrivate::setVisible() code path directly, which doesn't
have that issue. The root problem will be fixed in a follow up.
Pick-to: 6.7
Change-Id: I77cb88d75e57f0d9a31741161fb14d618a653291
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When we recreate a top level QWidget due to the RHI config not matching,
we need to re-apply the window state, as the state is lost on destroy().
But we should do this on the QWidget we are recreating, not on its
closest QWindow. These are usually the same, so it didn't matter in
practice for most cases (besides the more convoluted way of getting
to the QWidget's window).
But if the top level widget does not have a winId yet, the call to find
the closest QWindow via QWidgetPrivate::windowHandle() will traverse from
the top level widget to its transient parent widget, via nativeParentWidget,
which is strange and likely a bug.
As a result of that, we would store the window state of the transient
parent widget, and then, once we had created() the new top level, we
would apply the window state to the top level, which now had a winId.
We can simplify all of this by just storing and applying the window
state on the widget we are re-creating. There's no need to go via
the closest QWindow for this. We do however need to set the window
state on the widget's window, as going via QWidget will just bail
out since the window state hasn't changed.
Amends c88211d1e4
Fixes: QTBUG-119795
Pick-to: 6.7 6.6 6.5
Change-Id: I0ad6e7bbac5f29d095cc643e9a7094784e9a2122
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The call site may pass in a null-widget, so guard for that.
Pick-to: 6.7
Change-Id: I631cb2fc105bad69faf3daaeac4b893457d27cc1
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
As a result of using QWidget::setVisible to show the child widgets we
would end up also setting ExplicitShowHide. This is not in line with
the intent of ExplicitShowHide, which is to flag a widget as explicitly
shown/hidden by the developer, which in turn prevents Qt Widgets from
toggling WState_Hidden when the widget is reparented.
By using QWidgetPrivate::setVisible instead, we can show the child
without setting ExplicitShowHide.
As side effect of this is that we no longer reset WA_WState_Hidden
from QWidgetWindowPrivate::setVisible(). This is an issue when the
setVisible call comes as a result of destroying the QWidgetWindow,
as that is an implicit hide, and should not result in the widget
having WA_WState_Hidden. QWidget handles this case in hideChildren
by not calling QWidgetPrivate::setVisible -- instead doing its own
reset of WA_WState_Visible. We don't want to untangle this just yet,
so as a workaround we detect that the widget is already !isVisible(),
thanks to hideChildren having hidden it, and then skip the call
to QWidgetPrivate::setVisible that results from QWindow::destroy().
Task-number: QTBUG-121398
Pick-to: 6.7
Change-Id: Ib5b4d9c84f0569124c5f3ca2169cabff18934e2d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
To aid readability.
Task-number: QTBUG-121398
Pick-to: 6.7
Change-Id: I3cb231584c2b7aee72e9f01c669fed1e01fbe475
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
We were assuming that QWidget was in full control of QWidgetWindow
destruction, via deleteTLSysExtra(), and that we could limit any
cleanups to that function.
But in some situations QWidgetWindow is destructed from other code paths,
in which case we were left with dangling pointers to the QWidgetWindow
in both QTLWExtra, as well as the backingstore.
This can happen if there's a child widget hierarchy where there is not
a 1:1 mapping between QWidgets and QWindows, for example if the window
attribute WA_DontCreateNativeAncestors has been set. In this situation
our normal recursion into children in QWidget::destroy() stops at the
first widget without a window handle. When we then delete the top level
QWindow, the QWindow destructor will delete any child QWindows, which
includes our leaf QWidgetWindow.
We should probably fix up QWidget::destroy to continue looking for
children, even if we don't destroy the current child. But independently
of that we should make sure the QWidgetWindow cleans up when it's being
deleted, regardless of how it ended up there.
There's further room to clean up the deleteTLSysExtra() function and
friends, but that's been left for a later time.
Fixes: QTBUG-120509
Pick-to: 6.7 6.6 6.6.2 6.5
Change-Id: Ib691df164d7c9c83cb464c0a6bf3bc2116e8ca43
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Make sure to pass the widget to QStyle::pixelMetric() as some styles
might use this (e.g. the new windows styles) to determine the correct
pixel metric.
Pick-to: 6.7 6.6 6.5 6.2
Task-number: QTBUG-1857
Change-Id: I5c32f5af8b284749732b610e56b4e3d8c8ed1946
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
The Qt::WindowState enum is documented to specify the current state of
top-level windows, and does not make sense for child windows. It's up to
the client code to ensure any sizing of child windows/widgets, e.g. via
layouts.
Many of our QPA backends bail out on QPlatformWindow::setWindowState()
for a child window. Ideally we would do this at a higher level, in
QWindow, but that's a bigger task, and the semantics of what happens
when a window is moved from being top level to child or back are not
fully clear.
As a first step, we ensure that the default window state when showing
the window via show() is Qt::WindowNoState.
Unfortunately, the QPlatformIntegration::defaultWindowState() API only
takes into account the window flags, which sadly do not have a way to
reflect whether the window is a child window or not (Qt::SubWindow is
not a child window, see QTBUG-115729).
We don't want to pass a QWindow to this API, as it would mean QWidget
would need to create a window when requesting the default window state.
Instead we hard-code the opt-out for child windows/widgets.
[ChangeLog][Gui/Widgets] Child windows and widgets are now always shown
in their normal state by show().
Pick-to: 6.7
Change-Id: Ie8caf2df2d854194b9985c9427a9eac1312aba65
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The logic was needed for the old QMacCocoaViewContainer, which was a
QWidget, that set Qt::ForeignWindow, and hence Qt::Window, on its
windowHandle().
The modern way of embedding a foreign window into a widget hierarchy
is via QWindow::fromWinId() and QWidget::createWindowContainer(),
which manages the foreign window as a child QWindow of the window
container's window handle, instead of replacing or modifying the
window container's own window handle.
The opposite case is a QWidget embedded into a foreign/non-widget
window hierarchy. Ideally, in this case, we should return false for
isWindow(), as the function is documented to only return true for
"if the widget is an independent window", and "a window is a widget
that isn't visually the child of any other widget and that usually
has a frame and a window title". This notion is used in many places,
including in QApplication::topLevelWidgets(), which in turn affects
the quit logic of QApplication to prevent quitting the application
as long as the child/embedded widget is visible.
Unfortunately, embedding the widget as a non-Qt::Window is not an
option at this point, as we have a lot of code paths that assume
isWindow() || parentWidget(), and these code paths break down in
flames when we end up dereferencing the (non existing) parent
widget.
As a result of removing the logic, we can now embed a QWidget into
a non-widget window hierarchy as a Qt::Window, without the removed
logic resetting the widget back to a Qt::Widget on create(), which
would send us into into the broken code paths described above.
Removing this logic should not cause issues for child widgets backed
by a native window, as those are created with Qt::Widget window flags,
not Qt::Window, so we never relied on the removed logic to sanitize
those window flags.
Task-number: QTBUG-119652
Change-Id: Id6b8e5c67bf8f83af8c2f1594806f3419303b1a1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The active window of QApplication overlaps largely with the focus window
of QGuiApplication. As a first step towards potentially removing the
active_window member, make it private so we control access to it.
Task-number: QTBUG-119287
Change-Id: I95785fea3ba4444db64063f4e4d3d3004465ef64
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Upcoming changes to QDoc require accurate definition for
template arguments in \fn commands.
Task-number: QTBUG-118080
Change-Id: I3a193ca69a911ee2f62e7663aaf4c032a35ee5dd
Reviewed-by: Luca Di Sera <luca.disera@qt.io>
Restore the WindowState, when a Window has to be recreated due to
changed SurfaceType.
Fixes: QTBUG-118194
Pick-to: 6.6 6.5
Change-Id: I40ba552cda9dfc8ab543611595c068f80b8fa1d6
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Reviewing and improving the docs for QWidget is part of the objectives
for the 2023 Q4 OKRs.
Most of the work in this patch is fixing grammatical errors and typos.
It is tempting to move much, if not all, of the Detailed Description content from the QWidget class reference page (qwidget.cpp) into its own overview/explanation page, which would be more in line with the diátaxis framework. But I think that should be a different patch.
Fixes: QTBUG-117758
Pick-to: 6.6 6.5 6.2 5.15
Change-Id: Ibb3f367c4677f7e6615bc0cd39d0ffe921862cb9
Reviewed-by: Safiyyah Moosa <safiyyah.moosa@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Another one in the series of problems around having texture-based and
regular widgets in hierarchies where some widgets are native and some
are not.
Pick-to: 6.6 6.5
Fixes: QTBUG-115652
Task-number: QTBUG-108344
Task-number: QTBUG-113557
Change-Id: I34306503cb17ccb915b90168ec3f39e209f668e5
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Found in API-review.
Pick-to: 6.6
Change-Id: I261aa450d25288e7a3e8caa033ce5000e5dd77f2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
The Android QPA implementation requires a 1:1 link between a platform
window and a platform backing store, to correctly flush a backing
store to the screen. QAndroidPlatformBackingStore has a bool member
m_backingStoreSet, to remember if this link exists. It defaults to
false and is set to true, when setBackingStore() is called in the
constructor. It falsely remains true, when a platform window is
deleted, e.g. because a QWindow has been hidden. When the QWindow is
shown again, a new Android platform window is created. With
m_backingStoreSet still being true, this new platform window will
never be associated with a backing store. As a consequence, it will
never be displayed on the screen.
The 1:1 relationship of an Android platform window and an Android
backing store is neither ideal, nor in line with other QPA layers
(e.g. XCB). Changing the Android QPA implementation is complex and a
short term fix is necessary.
This patch removes the member m_backingStoreSet. Instead of it,
QAndroidPlatformBackingStore::flush() directly checks, if the platform
window corresponding to the QWindow argument is associated to a backing
store. If that is not the case, setBackingStore() is called.
QTBUG-97482 has been fixed with another approach, which this patch
reverts.
The following commits are effectively reverted by this patch:
9a39ad8dfbf91588923ba4ca9e8065dbb072eb28959a8b3967
Fixes: QTBUG-97482
Pick-to: 6.6 6.5 6.2
Change-Id: Ic4344f8df2e954c057dd2705340f11dfd2d4c6fe
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
QWidget re-uses an existing backing store. Platform windows depend on
being associated to a backing store, in case they become toplevel
windows. If a platform window gets deleted and re-created each time it
is shown or hidden, it has to be manually associated to the re-used
backing store.
This patch partly reverts fbf0aeea7d3b38ced7a16fcd5c3e2e9b45536292.
It removes Android specific code from QWidgetPrivate::create(), which
has been added to suppress re-using backing stores in the absence of
the new API.
Fixes: QTBUG-97482
Pick-to: 6.6
Change-Id: Iaa1b7652efa120ec1955914c0383e8ccd8a41429
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
QWidget re-uses backing stores created in QWidgetPrivate::create().
The Android platform plugin creates a new platform window, when a
widget becomes a toplevel window. When it is hidden, the platform
window is deleted. The link between QAndroidPlatformWindow and its
backing store is made in the constructor of
QAndroidPlatformBackingstore. When a new QAndroidPlatformWindow is
constructed and the backing store is re-used, there is no more link
between platform window and platform backing store.
This has lead to screen assets not being painted, when shown more than
once.
This patch forces QWidgetPrivate::create() to construct a new backing
store on Android. This way, toplevel windows always have a backing
store associated with it. It adds an assertion to
QAndroidPlatformScreen::addWindow(). That will make e.g.
tst_QWidget::visible() crash without the fix.
Fixes: QTBUG-97482
Pick-to: 6.6 6.5 6.2
Change-Id: Ib1b172068b03549df161ab93ac24a273221d5423
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Correct the typo inherts to inherits in QWidget::backgroundRole() docs,
as it is incorrect english.
Fixes: QTBUG-115160
Change-Id: I03892753d6ec7d81c1f818fd9caa279ca11cc3ec
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QWidgetPrivate::focusObject() always returns nullptr. That has lead to
mismatches between QGuiApplication::focusObject() and
QApplication::focusWidget(), when a widget got focus by the window
system (e.g. mouse click).
This patch implements QWidgetPrivate::focusObject.
It returns the current widget, if it doesn't have a focus proxy.
If it has a focus proxy, it resolves the proxy chain and returns the
deepest focus proxy.
(Note: It does not return QWidget::focusWidget(), because the focus
widget might not yet have been set, when the method is called).
Fixes: QTBUG-92464
Fixes: QTBUG-108522
Pick-to: 6.6 6.5 6.2
Done-With: Liang Qi <liang.qi@qt.io>
Change-Id: Icf01e8ac4fc5f722fbf8e0ca5a562617ae9ae8f2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
The Qt Widgets Application example was moved to manual tests,
and no longer contains the snippet identifiers. Fix \snippet
and \quotefile commands to quote similar code snippets from
other examples or snippet files.
Fix also the following documentation warnings:
* No such parameter 'parsingMode' in QUrl::fromEncoded()
* Missing image: rsslisting.cpp
Pick-to: 6.6 6.5
Change-Id: Ibc989e83abc49837db08628facaf8e5f72b2f123
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
David Faure
Tor Arne Vestbø
Wladimir Leuschner
Eirik Aavitsland
Axel Spoerl
Michael Weghorn
Christian Ehrlicher
Doris Verria
Zhao Yuhang
Topi Reinio
Andreas Eliasson
Liang Qi
Laszlo Agocs
Keith Kyzivat