Calculate effect bounds for the updated region when drawing the effect
so that the whole affected area gets updated. The effect bounds have
already been added to the region so it doesn't need to be handled in
the drawing function.
Pick-to: 6.2 5.15
Fixes: QTBUG-96240
Change-Id: I0c317311622e6299fb1a3015541408d1d83c93de
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Instead of plumbing QWidgetWindow close events via handleCloseEvent,
we just implement closeEvent directly. This allows QWindow do save
the state of the window/widget before the close event, so that we
know whether we should trigger lastWindowClosed handling, even if
the window was deleted as a result of the close event.
This also relieves QGuiApplication and QApplication from dealing
with the close logic in their notify functions, so that these
functions can focus on the propagation of events -- not how the
event is handled.
Change-Id: I8b586b53a53b1df1d8630c1acb635c60f191bb4b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Cocoa sends QWidget the state-change notification after the window has
been resized already, at which point we cannot store the normal geometry
anymore.
Handle zoom and full screen callbacks prior to the state changing
to store the geometry in QCocoaWindow. We do not need to handle
minimized state, as the window will still reflect the original
geometry.
Return the stored value from an override of
QPlatformWindow::normalGeometry so that QWidget gets the correct values
even though the new state is already active.
Fix the tst_QWidget::normalGeometry test to make it pass on all
platforms by waiting for the window to actually have transitioned to
the new state before comparing geometries. Both macOS and Windows fully
pass; on Xcb, deminimizing a window using setWindowState does not work,
which is why the test was partially skipped (confirmed by visual
testing). Move those problematic, complex test cases to the end so
that most cases are covered on Xcb as well.
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Pick-to: 6.2
Change-Id: I518a5db9169b80e8fa25fe4fa2b50bd1ea0e6db3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Doing so results in bailing out early for a widget that hasn't been
shown yet, or otherwise resulted in creating extra and topextra,
which means the normalGeometry will not reflect the widget's geometry.
Pick-to: 6.2
Change-Id: Ieb85e9a6109ae34fe20d79e3c12f4517f827a590
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Since commit 7ba75d0 we close the QWindow in QWidget::close for native
widgets and trigger the closeEvent in QWidgetWindow. However, if the
widget's window handle is not a top level window, QWindow::close()
will not close the window, failing in this way to deliver the
closeEvent and call the close handling in QWidgetPrivate::handleClose.
To fix, call handleClose() from QWidget::close for such widgets.
Task-number: QTBUG-74606
Pick-to: 6.2
Change-Id: Ied342eced3340aaf19b5443762935b1a5fc5c27b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The signal is emitted from QGuiApplication these days.
Pick-to: 6.2
Change-Id: I7423cd4808e8df86960f225fd6e4a12a1a4f11f3
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
On macOS, when showing a window, we decide if it should be made
key and therefore active, if the app has no active modal session
or if the window's worksWhenModal returns true.
However, the window needs to be made key also when a modal window
is present, but not visible. Add this condition when checking if
the window needs to be made key.
This makes the behavior consistent with what happens when a modal
is minimized on macOS. The input focus is passed to the next window,
and the window appears active, even if it can not be interacted with.
Fixes: QTBUG-85574
Pick-to: 5.15 6.2
Change-Id: I204d4f912128f4a46840789fc2ee08e1b2716bfc
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Closing a window with a native child results in the native child's
QWidgetWindow being closed. That explicitly calls setVisible(false)
on the child, which will still have the ExplicitShowHide attribute
set from the initial (explicit) show. Even though we then reset
the ExplicitShowHide, the WState_Hidden attribute will still be
set, so Qt considers the window to have been hidden, and not show
it again when the parent becomes visible.
Add a test case.
Fixes: QTBUG-96286
Fixes: QTBUG-79012
Fixes: QTBUG-71519
Change-Id: I482e6d5236c959d82ce66798176b259a3176972c
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Remove dead code
Make logic to position test widgets more consistent across test functions
Consistent cursor positioning logic
Get rid of unnecessary event processing
Reduce calls to qWait with hard coded values
Use qWaitFor to establish asynchronous preconditions
Ignore expected warning messages
Expect-fail (instead of blacklist or skip) some tests that always fail
Ignore unpredictable events in childEvents test
Split large "render" test in multiple test functions
Task-number: QTBUG-52974
Task-number: QTBUG-26424
Change-Id: I206e114c2c1d9801e08600d3341c2738dc881f17
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
QWidget::setParent might be called to change the window flags, without
changing the parent. For those cases, we don't have to clear the focus.
Decouple the newParent state from the wasCreated flag. In most places
where newParent was tested, wasCreated was either tested previously and
can't be false anyway, or the code executed is irrelevant for widgets
that are not yet created (there can't be a paint manager). In the
remaining case, test wasCreated explicitly to maintain existing logic.
Add test for the cases where the previous code broke the focus, both
for QWidget and QDialog.
Fixes: QTBUG-93005
Pick-to: 6.2
Change-Id: I39dc179c2d348054de3927aa8b69eecef4935511
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
The Cocoa QPA plugin no longer tracks popups, but dispatches enter/leave
events when popups show and hide. So the special handling in tests and
QWidgetWindow can go away now.
Change-Id: Ib6ef00689de231996e5e57ecdd8fd0d4c861d68b
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Since macOS doesn't give us any event when a modal window opens,
we need to do so ourselves explicitly so that the current mouse
window gets a leave event when e.g. a popup opens, and an enter
event when the popup closes again. The case for modal dialogs is
partially handled by QGuiApplication already.
Note: We cannot rely on the transientParent of the opening/closing
window, as it's nullptr for QMenu windows even if the QMenu has
a widget parent.
Add a test for enter/leave events when a secondary window opens,
covering both the dialog and the popup case. For the dialog case,
we sometimes get two Enter events when the dailog closes, which
we have to tolerate for now.
To make the test pass on b2qt platforms, fix the offscreen plugin
to explicitly send enter/leave events in the same way as Cocoa
now does.
Fixes: QTBUG-78970
Pick-to: 6.2
Change-Id: If45e43e625e8362c3502c740154f6a6a8962b9e9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The test passes consistently in local test runs on macOS 10.15.
Change-Id: I6f05b27d3cbf930475a435c41db267a00b1726b0
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Move the status setting and resetting back into handleClose so that we
don't end up with it being set if handleClose is never called in response
to a close attempt. This can happen when QWindow's platform window has
already been destroyed.
Since QWindow::close handles that case gracefully and returns true,
we can safely call it multiple times.
Add test coverage to verify that we get exactly those close event
calls that we want.
Change-Id: Ica77bf17c26d923c3b79b1e5a688addbc88a6277
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Also when closed by destruction, which as of today doesn't call
QWidget::close and therefore also not QWindow::close.
Pick-to: 6.2
Change-Id: I426255e2274eae9262243c769df2264fbaa915b0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The plan for QObject::connect() (perfect) forwarders, such as
QWidget::addAction(), was to just use a variant of the Detection Idiom
to see whether QObject::connect() with the arguments as given would
compile and SFINAE out the forwarder otherwise.
It turns out that the "functor" overload of QObject::connect(), in
particular, is severly underconstrained and accepts e.g. QKeySequence
as a function object, only erroring out via a static_assert() in the
body of the function, and thus at instantiation time and not, as
needed, at overload resolution time.
At the same time, we don't really want QObject::connect() to SFINAE
out on argument mismatches between signal and slot, because the
resulting error messages would be ... unkind to users of the API. We
would like to keep the static_assert()s for easier error reporting.
Reconciling these two contradicting requirements has so far eluded
this author, so for now, to unblock progress, we explicitly black-
and, in one case, white-list possible arguments. Because QKeySequence,
in particular, is implicitly constructible from int(!), and therefore
any enum type(!), incl. Qt::ConnectionType, we need to do way too much
coding in the addAction() constraints. Hopefully, we'll be able to fix
the issue at the root cause, in QObject, before Qt 6.3 is out, but
until then, this is an ok-ish stop-gap measure.
Add thorough overload set checks (positive ones only, for now) to
tst_qwidget and tst_qmenu.
Change-Id: Ia05233df818bc82ecc924fc44c1b349af41cbbf1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Changing anything on a QWindow's QSurfaceFormat has zero and null
effects once the underlying native window has been created. Letting
QWidget update the format is wrong in this case, because we always
expect that the value returned from QWindow::format() reflects
reality.
(reality being the settings with which the underlying native resource
was created, which is typically frozen after QWindow::create(), not
the state of some QWidget attribute. There are certain exceptions to
this, such as when preparing to recreate the underlying native window,
in which case one will want to update all relevant fields of the
format based on the current values of the widget attributes, which is
exactly what QWidgetPrivate::create() implements, and that's good.)
Such a mismatch can have fatal consequences when OpenGL and friends
are involved, but this always depends heavily on the platform and
windowing system. For example, claiming that the alpha buffer size is
0 when the native window was created with 8, or vice versa, can break
OpenGL-related code (both in Qt itself and in applications), that
tries to create a QOpengGLContext configured based on what
QWindow::format() returns. If that format describes settings that are
incompatible with the actual underlying native window, we end up with
the classic Invalid pixel format, EGL_BAD_MATCH, and alike errors.
This is exactly what is happening when a QOpenGLWidget (or
QQuickWidget) is placed in a QDockWidget where one of the ancestors is
forced to native (winId() was called or WA_NativeWindow was set). When
undocking, various code paths in QWidget will try to update the opaque
flag of the widget, which in turn calls updateIsTranslucent. Now, if
this function unconditionally changes the alphaBufferSize in the
QWindow's QSurfaceFormat (even though this is completely futile to do,
it has no visible effect in practice), we get the problem described
above: rendering breaking down due to OpenGL contexts created with a
pixel format incompatible with the native window.
Prevent all this by not touching the format once the QWindow has a
QPlatformWindow. This is the right thing to do, regardless of the bug
in question: a window's (or context's or any other native resource
wrapping class's) format must describe the underlying native resource
and must never deviate, unless we are preparing to create a new native
resource underneath.
When it comes to the autotest, this changes the test added in
555661b625c40f21a6a3e4c73e928a6e8a46db20: the autotest logic is
inverted because what we should test for is that the QSurfaceFormat
stays untouched once the application makes a - futile - attribute
change on the widget.
Fixes: QTBUG-85714
Pick-to: 6.2 6.1
Change-Id: I7bf90711867e8a0fd474895625bf9530a7821fd5
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Several tests failed due to side effects of client side
decorations. We explicitly disable this when initializing
the test to make things go smoother.
In addition, the setToolTip() test tries to set the mouse
cursor position programmatically, which is not possible
on Wayland.
And finally, the qWaitForWindowActive() falls back to
qWaitForWindowExposed() on platforms where explicit window
activation is not supported. This fixes a few issues, but
in cases like focusProxy(), it means we aren't actually
waiting for the WindowActivation event. Instead of testing
for exposed twice on such platforms (Wayland), we replicate
the logic from qWaitForWindowActive() instead and rely on
automatic window activation. If it fails, we do a QSKIP, so
this shouldn't cause any flaky test failures at least.
Task-number: QTBUG-91418
Change-Id: I767c881e7cdc91f43ad357294a2c6240ab1af43c
Reviewed-by: Liang Qi <liang.qi@qt.io>
setTabOrder was not considering the case, when a child widget has
its focus proxy set to its parent widget. This happens, for example,
for the QLineEdit that is nested inside the QAbstractSpinBox.
For such cases the lastFocusChild was calculated incorrectly, and, as
a result, such child widgets were not correctly positioned in the
focus chain. This could lead to an error while backtabbing.
Here is a brief example. Suppose we have 3 widgets arranged like this:
auto spinBoxOne = new QDoubleSpinBox;
auto spinBoxTwo = new QDoubleSpinBox;
auto button = new QPushButton;
Then the default widget focus order is:
- spinBoxOne
- lineedit (from spinBoxOne)
- spinBoxTwo
- lineedit (from spinBoxTwo)
- button
Before this commit setting the explicit tab order changed the focus
order in the following way:
QWidget::setTabOrder(spinBoxOne, spinBoxTwo);
QWidget::setTabOrder(spinBoxTwo, button);
- spinBoxOne
- spinBoxTwo
- button
- lineedit (from spinBoxOne)
- lineedit (from spinBoxTwo)
In this case, backtabbing from spinBoxOne actually leads us to
lineedit (from spinBoxTwo), which refers to spinBoxTwo.
And so we're stuck in a loop.
This commit fixes the issue by handling such special case, and
preserving correct focus order.
Note: the actual unit-test in this patch uses QLineEdit instead of
QPushButton, because one can't tab to buttons on macOS by default.
However the general idea is the same.
Pick-to: 6.0 5.15
Fixes: QTBUG-81097
Change-Id: I5d16da7733a4d63f809cab28b8ca9e116b87cffa
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's unnecessary, and copying QEvents is a bad practice since it's a
polymorphic class.
Change-Id: Ieb6de106084f838c5e6c8a0643c54fd3c7f4a7a8
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Leave the normalizedPos warnings, there is no equivalent function.
Change-Id: I50c72ab24b4855e36941aafdee30cdb0e94c1684
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Use QScreen APIs instead.
Change-Id: Ie99af94fe4292223dbb165b3f5c1b74e8fe0498b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Changes the definition of invalid QRects to be more consistent.
This simplifies the logic, and makes it possible for us to fix
normalized() so dimensions don't change.
The actual API is not changed except for inverted rects.
Only one use-case for the old normalized() function existed,
and has been reimplemented as QRect::span().
Fixes: QTBUG-22934
Change-Id: I29dad2952dc6c8e84a6d931898dc7e43d66780f3
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Remove around 1000 compiler warnings about missing overrides
in our auto tests.
This significantly reduce the compiler warning noise in our auto
tests, so that one can actually better see the real problems
inbetween.
Change-Id: Id0c04dba43fcaf55d8cd2b5c6697358857c31bf9
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is a source incompatible change for widget implementors.
Leaving the old enterEvent as a virtual overload is problematic due to
shadowing. Best to make a clean cut, widget reimplementors will get a compile
time warning if they mark their override as such, or if they try to call the
parent class implementation.
Addresses ### Qt 6 comment.
[ChangeLog][QtWidgets][QWidget] The virtual enterEvent handler now receives
a QEnterEvent, which contains information about mouse position and button
states, rather than a plain QEvent.
Change-Id: I233f594fd79c0c090983b3db8532913d00132fde
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Follows the QWindow semantics, and is a replacement for creating
a QWidget with a QDesktopScreenWidget as the parent.
We can now remove much of the special handling of QDesktopWidget and
the Qt::Desktop window type, and get rid of QDesktopScreenWidget.
Add a manual test that allows local testing. Our CI environments
only have a single screen, and no multi-head display server setup
which is the primary case where QWidget::setScreen is interesting.
For the more common case of a virtual desktop, QWidget::setScreen
has no real impact (just as QWindow::setScreen doesn't).
Change-Id: Id0099e069d316741bacd8c795c396ccad37be297
Fixes: QTBUG-85483
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
A QWindow should only become Active when it's inside an
NSWindow that is Key. If the NSWindow is not key, we need
to wait for it to be so, and handle window activation
from QCocoaWindow::windowDidBecomeKey() instead. Otherwise
Qt will report a QWindow as Active when, in reality, it
is not.
Change-Id: Ib7e63b374f26af527a668c7f7d863c4168a4446d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change the functions to operate in float and add the
QPoint versions as overload calling them. This is
more in-line with the event accessors using float
and allows for removing some workarounds using a delta when
converting touch points.
Leave QPlatformWindow::map(To/From)Global() as is
for now and add helpers for float.
Change-Id: I2d46b8dbda8adff26539e358074b55073dc80b6f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Fixes regression introduced in b4981f9d4c,
due to which it was possible to back-tab into a widget even though it or
its focusProxy had a NoFocus policy.
As a drive-by, split the complicated if-statement up a bit for improved
readability.
Change-Id: Ib0ac2604076e812e340b11534c23ae8ae958d082
Fixes: QTBUG-76924
Pick-to: 5.15 5.12
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
We have seen during the Qt 5 series that QMouseEvent::source() does
not provide enough information: if it is synthesized, it could have
come from any device for which mouse events are synthesized, not only
from a touchscreen. By providing in every QInputEvent as complete
information about the actual source device as possible, we will enable
very fine-tuned behavior in the object that handles each event.
Further, we would like to support multiple keyboards, pointing devices,
and named groups of devices that are known as "seats" in Wayland.
In Qt 5, QPA plugins registered each touchscreen as it was discovered.
Now we extend this pattern to all input devices. This new requirement
can be implemented gradually; for now, if a QTWSI input event is
received wtihout a device pointer, a default "core" device will be
created on-the-fly, and a warning emitted.
In Qt 5, QTouchEvent::TouchPoint::id() was forced to be unique even when
multiple devices were in use simultaneously. Now that each event
identifies the device it came from, this hack is no longer needed.
A stub of the new QPointerEvent is added; it will be developed further
in subsequent patches.
[ChangeLog][QtGui][QInputEvent] Every QInputEvent now carries a pointer
to an instance of QInputDevice, or the subclass QPointingDevice in case
of mouse, touch and tablet events. Each platform plugin is expected to
create the device instances, register them, and provide valid pointers
with all input events. If this is not done, warnings are emitted and
default devices are created as necessary. When the device has accurate
information, it provides the opportunity to fine-tune behavior depending
on device type and capabilities: for example if a QMouseEvent is
synthesized from a touchscreen, the recipient can see which touchscreen
it came from. Each device also has a seatName to distinguish users on
multi-user windowing systems. Touchpoint IDs are no longer unique on
their own, but the combination of ID and device is.
Fixes: QTBUG-46412
Fixes: QTBUG-72167
Task-number: QTBUG-69433
Task-number: QTBUG-52430
Change-Id: I933fb2b86182efa722037b7a33e404c5daf5292a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Remove QDestopWidget public header, simplify the implementation that
maintains a Qt::Desktop type QWidget for each QScreen, and turn
QWidget's initial target screen into a QScreen pointer.
QApplication::desktop() now takes an optional QScreen pointer, and
returns a QWidget pointer, so that applications and widgets can get
access to the root widget for a specific screen without having to
resort to private APIs.
QDesktopWidgetPrivate implementations to look up a screen for an index,
widget, or point are now all inline functions that thinly wrap
QGuiApplication::screens/screenAt calls. We should consider adding those
as convenience APIs to QScreen instead.
Note that QWidget::screen is assumed to return a valid pointer; there is
code that handles the case that it returns nullptr (but also code that
trusts that it never is nullptr), so this needs to be defined, verified
with tests, and asserted. We can then simplify the code further.
Change-Id: Ifc89be65a0dce265b6729feaf54121c35137cb94
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Many of these were generated by clazy using the new qevent-accessors check.
Change-Id: Ie17af17f50fdc9f47d7859d267c14568cc350fd0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Macros and the await helper function from qfunctions_winrt(_p).h are
needed in other Qt modules which use UWP APIs on desktop windows.
Task-number: QTBUG-84434
Change-Id: Ice09c11436ad151c17bdccd2c7defadd08c13925
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Starting from Qt 5.11 QWindow::event is called after QDialog::closeEvent
which would cause a crash if "delete this" was called on closeEvent. The commit
that changed this was e0b5ff4ad5. Added
a check before QWindow::event call utilizing QPointer to prevent the
function call in case object is destroyed by a user in close event handler.
Change-Id: I64a4a0f3271714e55bf7e806177f0d8b39b67fa3
Fixes: QTBUG-84222
Pick-to: 5.15 5.12
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Rather than have a paletteChanged() signal which can be connected to for
tracking when the application palette has changed, then it is better to
use the event that is sent to all windows and the application itself.
That way it is easy for a window/widget or item that cares about the
change to the application font to catch it in the event() function.
[ChangeLog][QtGui][QGuiApplication] Deprecated paletteChanged() signal
in favor of QEvent::ApplicationPaletteChanged.
Change-Id: I95da211e30590e357007cc14d8ee266baceba7b3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This amends 23b998fa45, and the commits
3e7463411e and
947883141d. This change restores the
pre-5.13.1 behavior of setFocusProxy to not move focus away from a
previously set focus proxy.
With the previous changes, focus would move away from a proxy when a
new proxy is set, if the old proxy had focus. While there are arguments
in favor of this behavior, it is a change of behavior that shouldn't
be introduced to 20+ years old functionality in order to fix the real
bugs addressed by the initial commits.
Instead, move focus only to the new proxy when the focus widget was
the widget that gets a focus proxy.
[ChangeLog][QtWidgets][QWidget] setFocusProxy no longer moves focus
away from a previously set focus proxy, restoring pre-Qt 5.13.1
behavior.
Change-Id: Icf2ad7cba5b860014aeef91cb274c442a2ab9d42
Fixes: QTBUG-83720
Pick-to: 5.15
Reviewed-by: David Faure <david.faure@kdab.com>
Rather than have a fontChanged() signal which can be connected to for
tracking when the application font has changed, then it is better to
use the event that is sent to all windows and the application itself.
That way it is easy for a window/widget or item that cares about the
change to the application font to catch it in the event() function.
[ChangeLog][QtGui][QGuiApplication] Deprecated fontChanged() signal in
favor of QEvent::ApplicationFontChanged.
Change-Id: Iae8e832238fc85e385a52305bc04f16e597454b0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This follows up on commits 3e7463411e and
947883141d.
The changing of the pointer of QApplicationPrivate does not transfer
focus properly. It updates the pointer, but it doesn't deliver events
or update the widget hierarchy's focus chain. The result is that
multiple line edits might show a blinking cursor.
Instead, use QWidget::setFocus when the focus proxy has changed while
it had focus, and pass OtherFocusReason rather than NoFocusReason.
Add a basic test for QWidget::focusProxy, which exercises this code
path and verifies that pointers are consistent when focus changes as
a side effect of modifying the focusProxy.
Change-Id: I15a4d868bab2b590cfe4a1daa6a3c8cebc9c9ca2
Fixes: QTBUG-83720
Fixes: QTBUG-79707
Pick-to: 5.15
Reviewed-by: David Faure <david.faure@kdab.com>
Alexander Volkov
Antti Määttä
Tor Arne Vestbø
Volker Hilsheimer
Doris Verria
Marc Mutz
Laszlo Agocs
Eskil Abrahamsen Blomfeldt
Ivan Solovev
Giuseppe D'Angelo
Kirill Burtsev
Liang Qi
Allan Sandfeld Jensen
Lars Knoll
Morten Johan Sørvig
Richard Moe Gustavsen
Friedemann Kleint
Lars Schmertmann
Jarek Kobus
Shawn Rutledge
Oliver Wolff
Miika Pernu
Andy Shaw
Tor Arne Vestbø
Qt Forward Merge Bot