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>
QAbstractScrollAreaPrivate::layoutChildren() positions the viewport, but
did not take the overshoot from scrolling with a scroller into account.
If the scroll area was resized during a scroll, then this resulted in the
roll back overcompensating for the overshoot, placing the viewport outside
the visible area.
Fix this by taking the overshoot into account when positioning the
viewport.
Add a test case. We have to use QWindow-based mouse event simulation, as
the QWidget based move events use QCursor::setPos, which doesn't reliably
go through the gesture framework.
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Done-with: Zhang Hao <zhanghao@uniontech.com>
Fixes: QTBUG-94769
Pick-to: 5.15 6.2
Change-Id: Idf650c91e5a9cffa996e23e743939243b1d4fcc0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The test passes, the functionality is implemented in QCocoaWindow.
Task-number: QTBUG-8857
Pick-to: 6.2
Change-Id: I2f4b3a39cec1aaaf4351753b590f35e280503461
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
- when there is no intersection between the current selection and the
spans collection, get ranges for all cells, just as if no span exists
- when there is an intersection between the current selection and the
spans collection, get separate ranges for each cell (as before)
This fixes the regular case of selecting multiple non-spanned cells
after some cells are merged (get a single range for all cells instead of
separate range for each cell). However, when selecting together a group
of spanned and non-spanned cells, you still get a separate range for
each cell. But this is normal behavior in similar applications; for
example in LibreOffice, you cannot select and merge spanned and
non-spanned cells: an error dialog tells you that it's not allowed.
Done-with: Christos Kokkinidis
Pick-to: 6.2
Fixes: QTBUG-255
Change-Id: Ic38f9a064a1f499825e7f750668013fc2dc564ba
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Add operators as hidden friends, add test case to make sure that
basic value-type operations are possible with this type.
Task-number: QTBUG-255
Change-Id: I7fbf453aa16084c0b2a0079487cacb4e092ff664
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The skip-reason only cites Qt/X11. Convert the #ifdef into a platform
name check instead. The test also fails with the offscreen plugin, so
skip it for that as well.
Pick-to: 6.2
Change-Id: I49607b89f4b32359e81e1d9aadff2c3e03035c53
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QDialog overrides setVisible to set focus on the default push button, or
(if there is no such button), make the first autoDefault push button the
default button. QDialog also explicitly sends a FocusIn event to the
focus widget in the dialog.
All this should not be done if the dialog does not become active after
getting shown, which will be prevented if the WA_ShowWithoutActivating
attribute is set.
Add a test case.
Fixes: QTBUG-8857
Pick-to: 6.2
Change-Id: If47021a4721a280ba45e95b43d0424cdacd9b4ea
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
For a widget that implements height-for-width, the vertical scrollbar
becoming visible might be just enough to make the scrollbar unnecessary.
In that situation, the scrollbar flips on and off continuously.
To avoid that situation, make the width of the widget smaller until the
height fits without scrollbar, up to the point where we have space for
the scrollbar anyway.
The calcuation here is assumed to be cheap, but depends on the
heightForWidth implementation in the widget. Running the while-loop a
few dozen times should have no performance impact during resizing
and laying out the scroll area contents.
Add a test that confirms that within a brief period of time we only get
the one hide-event we expect.
Done-with: Zou Ya <zouya@uniontech.com>
Fixes: QTBUG-92958
Pick-to: 6.2 5.15
Change-Id: I0faeb5f9b1a226aada958c18333d9c2ac8203dd1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When setCurrentIndex is called by removeTab, the old current index
might no longer be valid. Only update the lastTab value of the new
current tab if the old current index is still valid.
As a drive-by, use the validIndex helper function.
Fixes: QTBUG-94352
Pick-to: 6.2
Change-Id: I945e2093a90a1fccbba86d32b1113f83fedd41de
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
On a mobile device, selecting text in a line edit brings up the text
action popup for select/copy/cut. In a spinbox where the user changes the
value using the buttons, this can be very irritating, without providing
any usability - the user is unlikely to start typing, at least not
without first transferring focus into the lineedit first to bring up the
keyboard.
This style hint allows styles to override the default behavior of
QAbstractSpinBox. Implement the customization for the Android style, and
add a test case for QSpinBox.
[ChangeLog][QtWidgets][QStyle] A new style hint, SH_SpinBox_SelectOnStep,
specifies whether pressing the up/down buttons or keys in a spinbox will
automatically select the text.
Fixes: QTBUG-93366
Change-Id: If06365a7c62087a2213145e13119f56544ac33b5
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
Item views can open an editor widget on the first key press, and need to
take special care not to break input methods. The initial key press
starts compositing by the system input method, which is then interrupted
by the focus transfer to the editor.
To solve this problem, the widget needs to keep focus while the initial
composition is ongoing, and only transfer focus to the editor once the
composition is either accepted or cancelled by the user. Add a state flag
that is set during this initial preedit phase.
During this initial composition, the item view will receive all input
method events, and needs to forward these to the open, but not yet focused
editor for the user to get the correct visual feedback during the preedit
phase. The item view also needs to report to input method queries on
behalf of the editor to make sure that the IM UI is correctly positioned
without covering the user input.
Implement a test that simulates the sequences through synthesized
QInputMethodEvents; we can't simulate the entire system input stack.
Fixes: QTBUG-54848
Change-Id: Ief3fe349f9d7542949032905c7f9ca2beb197611
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
At the current state, Qt::WA_StaticContents is not respected on any
platform, and optimizations for opaque widgets is not implemented on
Cocoa.
Task-number: QTBUG-73117
Change-Id: I48b7b0c4436da5a609fdbe51bb1c9789a2a059bd
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
Showing, hiding, and showing a window can result in the Xcb QPA plugin
warning about
qt.qpa.xcb: internal error: void QXcbWindow::setNetWmStateOnUnmappedWindow()
called on mapped window
The point of the test is to verify that we get a paint event on a window
that is shown again after having been hidden, not to verify that async
windowing systems can handle a show/hide/show sequence. So wait for the
window being exposed before we hide it.
Pick-to: 6.2 5.15
Change-Id: If91a9926613645e78e332dacff34bd57e4034b6f
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>
It is no longer handled separately from Android.
This effectively reverts commit 6d50f746fe
Change-Id: Ic2d75b8c5a09895810913311ab2fe3355d4d2983
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
By going via QWidget::close() we ensure that if there's a QWidgetWindow
backing the dialog (which is almost always the case), we will plumb down
to QWindow::close(), resulting in QEvent::Close events to the QWindow.
Since we don't want QDialog subclasses to receive a call to a closeEvent
override that they didn't receive before (and which they might interpret
as rejection or cancellation), install a temporary event filter that
eats the QCloseEvent resulting from the call to close().
Task-number: QTBUG-53286
Change-Id: Ie8f6f0cb3160acfd5865dc74f0a7b6d87f838724
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>
The test was failing because it didn't account for the platform behavior.
Task-number: QTBUG-30040
Pick-to: 6.2
Change-Id: I7c523c06f0bfa459c1532cee721718bebc1858c4
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The system behavior is to not show these kinds of dialogs as modal,
and we've documented that for QMessageBox.
However, calling show() instead of exec() is not enough, as the
default constructor of QMessageBox will set the modality of the
widget to application-modal. We need to explicitly override this.
[ChangLog][macOS] QMessageBox::about(Qt) now shows dialog non-modal,
as documented.
Pick-to: 6.2
Change-Id: I6bb59efb81feb23122276a9eede71b2f20c9d7c6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This reapplies the fix from 1ecf2212fa,
using QApplication::translateRawTouchEvent to dispatch the touch event
received by the QGraphicsProxyWidget to the relevant child widgets
under each touch point.
In addition, limit the implicit grabbing of each touch point before
sending the event to those cases where we have to: touch pads, and
if the target widget comes from a closest-widget matching. And don't
call the QTouchEvent override of QEvent::setAccepted() on QTouchEvent
instances in QGraphicsView classes, as this will override each event
point's acceptance state.
This way, we can identify which touch points have been accepted after
event delivery, any only implicitly grab those points that were.
Otherwise, touch points not accepted by a proxied widget hierarchy
will still be part of an accepted event, and be grabbed by the
viewport of the QGraphicsView. This would then lead to infinite
recursion when the QGraphicsProxyWidget passes the TouchUpdate event
on to each touch point's grabber.
Re-activate the test case, and extend it with more combinations.
Refactor touch-event recording to make it easier to test multi-touch
scenarios.
Task-number: QTBUG-45737
Fixes: QTBUG-67819
Pick-to: 6.2
Change-Id: Id5611f4feecb43b9367d9c2c71ad863b117efbcb
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Counting repaints is unreliable on macOS.
Pick-to: 6.2
Change-Id: Ifa1cf516a2cab94540bea005354d8311a2651d64
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
QDialog today only hides itself during reject and accept, it doesn't
close itself properly. This is problematic, as it doesn't close the
QWindow.
However, fixing this behavior must not result in duplicate calls to
virtual function, or additional calls to virtual functions (such as
closeEvent) without explicitly flagging the change in the changelog.
Add more tests to document existing behavior so that we can identify
such changes and verify the desired side effects.
Pick-to: 6.2
Change-Id: I1f30701cd766eb3c7957751b51e8579d4542dd16
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When showing a messagebox that has already been show we don't want to
keep around the clicked button of the previous invocation.
Pick-to: 6.2
Change-Id: Ib6f6293d40ab338c550ea344094db871ccf45c46
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We want to close the window, end full screen mode on macOS, and free
platform resources. This is all done by QWindow::close. QWindow::close
closes the platform window, triggering a closeEvent to QWidgetWindow,
which then calls QWidgetPrivate::close_helper.
This way, closing a window via QWidget::close, QWindow::close, or
interactively by the user are all equivalent.
The QCloseEvent generated by the widget needs to be spontaneous for
window-system generated events (i.e. the user clicked the close button),
and non-spontaneous if the window closes because of a call to
QWindow::close. To keep track of whether the event originated in an
explicit call to QWindow::close, add a boolean to the QWindowPrivate.
Add a test case that verifies that the window resources is destroyed,
and that events are delivered as they should.
Done-with: Morten Johan Sørvig <morten.sorvig@qt.io>
Fixes: QTBUG-46701
Pick-to: 6.2
Change-Id: Iacb6a2c8d5e880b16b0c8f0c9257ed94bed36f5b
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
After the last row is moved, 0 will be returned when obtaining
row and column data. At this time, QListView::doitemslayout will
not call d->doitemslayout, so the QBspTree data structure will
not be cleaned up, leaving a stale tree structure behind. This
will trigger an assert during paintEvent handling if QListView is
set to IconMode
In QListView::ListMode the test for a valid model index doesn't
use an assert.
Call QListViewPrivate::clear explicitly if the column count is 0
so that the QBspTree and other data structures are cleared.
Add a test case that simulates this scenario by implementing a
model that returns a 0 column count for an index after the model
structure was changed through a move of rows.
Done-with: Volker Hilsheimer
Fixes: QTBUG-95463
Pick-to: 5.15 6.1 6.2
Change-Id: I36419be5459b8ced930c619f538482ea1db4ad03
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Replace the “size() / devicePixelRatio()” pattern with
a call to deviceIndependentSize().
Change-Id: I9d9359e80b9e6643e7395028cd43e3261d449ae7
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This reverts commit 1ecf2212fa.
The fix is not correct after all. TouchBegin goes to the correct
widget with the fix, but following TouchUpdate and TouchEnd events
now go to the viewport, as QApplication::translateRawTouchEvent always
gives precedence to the widget that Qt recorded to be the touch
grabber, which is the viewport. This results in infinite recursion,
as the proxy widget trying to send the touch events to the embedded
widget (expecting that translateRawTouchEvent will split it up) ends
up sending the events back to the viewport.
Leave the added test case as QEXPECT_FAIL, reactivate the (never run,
hence unnoticed) test that the fix broke.
Pick-to: 6.2 6.1
Task-number: QTBUG-45737
Task-number: QTBUG-67819
Change-Id: I4810affb3cd066743ae94ab7beb2f0c06b60d211
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The test case was previously disabled, so tests were added to the
QGraphicsView test instead. With the QGraphicsProxyWidget test active
again, move the test cases where they belong.
Amends 1ecf2212fa,
01aeb5f7e4, and
06235d36ae
Pick-to: 6.2
Change-Id: I208b8a418653cf0640c2e7c9f716fa69538ad7e9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
They were de-facto disabled in the qmake build system, and didn't make
it into the cmake build system either. The dependency to the fusion
style is not a build-time dependency since the test uses the
QStyleFactory to create the style, and if that fails, tests can be
skipped at runtime.
As a consequence of not being executed in CI for a long time, many
tests failed. Also, many tests were commented out or skipped as
broken, ambivalent, or nonsensical. Remove that dead code. The
QGraphicsWidget::initialShow test doesn't test anything that initialShow2
doesn't test, but makes incorrect assumptions, so remove it and rename
initialShow2 to initialShow.
Failing tests frequently left QWidget objects undeleted, causing all
subsequent tests to fails as well. Fix that with std::unique_ptr.
Some tests are still unstable and fail on some platforms, handle that
using QEXPECT_FAIL. The forwardTouchEvent test fails due to a bug
in Qt introduced recently. Skipping it for now.
Pick-to: 6.2
Change-Id: I405122ea9d4d150bd1d505d40b83fe39604de0f9
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Just sending the event to the embedded widget is not enough, we
have to perform hit-testing for the different touch points, and
send the event to the child widget under the point. Fortunately,
QApplicationPrivate::translateRawTouchEvent provides the logic
that generates multiple events for groups of touch points.
Since that helper always sent events spontaneously, add an
optional parameter to allow sending of non-spontaneous events.
Add a test case that simulates touch events to different widget
configurations inside a QGraphicsProxyWidget.
Fixes: QTBUG-67819
Task-number: QTBUG-45737
Pick-to: 6.2 6.1 5.15
Change-Id: Iffd5c84c64ee2ceadc7e31863675fdf227582c81
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The nested widget might be a QGraphicsView as well (documented to be
supported), and QGraphicsScene maintains it's own activation status by
counting Window(De)Activate events. We need to make sure that the
embedded widget is informed about its activation status so that deeper
nested children can receive focus.
Forward WindowActivate/Deactivate events to the nested widget, which
will pass it on to all its children. Add test case, which without this
fix fails when verifying the inner scene's isActive state, or later
when testing that focusInEvent is delivered to the embedded widget.
Fixes: QTBUG-94091
Pick-to: 5.15 6.1 6.2
Change-Id: I4e0ecef50685ed081d15c7f76b6c1a4a40ed2682
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When forcing software scrolling through QScroller::scrollTo,
it will start from (0, 0). QGraphicsViewPrivate::canStartScrollingAt
should consider the locationof points, not just the flags of item.
Fixes: QTBUG-70255
Pick-to: 5.15 6.1 6.2
Change-Id: Iebdd5568baa3bdb41c705204dadb2895cfe9c0e2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
ImAbsolutePosition was added in f8dbed1226,
based on requirements on Android, but without an implementation for
QLineEdit. It would seem sensible to fall back to the cursor position
in this case, as QLineEdit doesn't support multiple blocks.
Pick-to: 6.2
Change-Id: Iff1255270ceef069f03ce457df633d7b675f1a28
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Remove SRCDIR defines from tests that don't use them. There is a
standard define called QT_TESTCASE_SOURCEDIR that is available to all
tests and serves the same purpose.
Pick-to: 6.2
Change-Id: I2aa237739c011495e31641cca525dc0eeef3c870
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
In order to fix QTBUG-95552 properly we have to add APIs to
QGraphicsSceneWheelEvent that informs QGraphicsProxyWidget about
whether the event is a high-precision event where Qt grabs the
wheel.
If it is, then the wheel grabber will be the QGraphicsView's viewport,
and any wheel event sent to any widget will be grabbed by it. This
results in infinite recoursion, partly fixed in change
I78400ceae8da7a4e22a988c06ed58f99f1a979f4.
The proper fix is to re-grab the wheel by the embedded widget
if it (or any of its children) accepts the ScrollBegin event (and if
not, return the grab to the QGraphicsView).
This fixes the scenarios that failed in the test case, so now scrolling
through nested widgets and scrolling in nested widgets works as the
user would expect.
Fixes: QTBUG-95552
Pick-to: 6.2
Change-Id: I3e1f31cbff999c70f8c63c034f77cd2ae567d7e3
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
For high-precision wheel scrolling sequences, the widget that gets
the first (typically ScrollBegin) event grabs the wheel. Qt directs
all future wheel events within the same sequence (i.e. until ScrollEnd)
to that widget.
QGraphicsView passes wheel events through to the item under the mouse,
and QGraphicsProxyWidget implements wheelEvent to forward a synthesized
QWheelEvent to the embedded widget. Since QGraphicsView's viewport has
already grabbed the wheel, any forwarded event would end up back in
QGraphicsView, resulting in infinite recursion (if the assert doesn't
fail first in debug builds).
The correct fix requires that QGraphicsProxyWidget knows that this is
a high-precision wheel event, allowing it to adjust the wheel grabber
temporarily to the embedded widget. However, QGraphicsSceneWheelEvent
doesn't provide this information.
To fix the infinite recursion, mark the generated event as synthesized
by Qt (but still send it spontaneously to enable propagarion within
the proxy widget hierarchy). In QApplication's notification routine,
interpret such events then to override the wheel grabber.
Add a test case for the various scenarios. This 6.1 compatible fix
does not pass all situations. A follow up commit that introduces the
missing APIs to QGraphicsSceneWheelEvent then fixes those as well.
Task-number: QTBUG-95552
Pick-to: 6.1 6.2
Change-Id: I78400ceae8da7a4e22a988c06ed58f99f1a979f4
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Changing the screen orientation will cause the menu position to be
displayed incorrectly. When the screen is rotated, the geometry of
the application changes. We can refer to the handling of the menu
on Android or IOS. Close the popup window when the screen
orientation changes.
Fixes: QTBUG-95607
Pick-to: 6.2
Change-Id: I55e1cd6a8b89e375c6714a9163dfb1902d52f101
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Replace custom SRCDIR define with QT_TESTCASE_SOURCEDIR. The latter is
automatically available to all tests to use and serves the same purpose
but is not terminated by a slash.
Change-Id: I62896d0fd84ac63ac1b74a459ec1646c6bde0a46
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The Qt style sheet reference claimed that Length properties can be
specified in 'em' or 'ex' units, but that was never implemented.
Add the missing implementation. Since the sizes depend on the size of
the font of the current element, we cannot convert the units in the CSS
parser, but have to do so in the QRenderRule constructor, where we can
make a decision about which font to use if the style sheet itself doesn't
specify a font. Fall back to the widget font if possible; otherwise it
will be the application default font.
The implementation translates em into QFontMetrics.height, identical to
what is already done in the QCssParser. This is in line with the CSS
specification, but contradicts our previous documentation which stated
that 'em' means "width of M". Fix the documentation.
Fixes: QTBUG-8096
Pick-to: 6.2
Change-Id: I145e2504ae3b19101a0d0dd63653466b6c2cec1d
Done-with: Cristian Maureira-Fredes <Cristian.Maureira-Fredes@qt.io>
Reviewed-by: Cristian Maureira-Fredes <cristian.maureira-fredes@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Unlike an acceptable effect in QTableView + QTreeView
setAdjustPolicy(QAbstractScrollArea::AdjustToContents)
unfortunately didn't work for QListViews (and QListWidget).
This patch corrects QListViews AdjustToContents
behavior.
[ChangeLog][QtWidgets][QListView] A more correct implementation
of QListView::viewportSizeHint has been made. That
implies that setting the sizeAdjustPolicy to AdjustToContent
on QListView and QListWidget will now cause the view to
size after the contents and avoid scrollbars.
Pick-to: 6.2
Task-number: QTBUG-58749
Change-Id: I1675115f2348e2fcf0b2c39b451ef337e10eb872
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The QtTest best practices documentations recommends using output
mechanisms such as qDebug() and qWarning() for diagnostic messages,
and this is also what most of our own tests do.
The QWARN() macro and corresponding internal QTest::qWarn() function
was added when QtTest was first implemented, but was likely meant as
an internal implementation detail, like its cousin QTestLog::info(),
which does not have any corresponding macro.
This theory is backed by our own QtTest self-test (tst_silent)
describing the output from QWARN() as "an internal testlib warning".
The only difference between QWARN() and qWarning(), besides the much
richer feature set of the latter, is that qWarning() will not pass
on file and line number information in release mode, but QWARN() will.
This is an acceptable loss of functionality, considering that the user
can override this behavior by defining QT_MESSAGELOGCONTEXT.
[ChangeLog][QtTest] QWARN() has been deprecated in favor of qWarning()
Pick-to: 6.2
Change-Id: I5a2431ce48c47392244560dd520953b9fc735c85
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
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>
QAbstractButton::setChecked is not virtual, so QToolButton cannot
override to synchronize the default action's checked state. This resulted
in button and default action not being in sync when the checked state
of the button was changed programmatically, while changing the checked
state on the action kept the button in sync.
Connect to the button's own toggled signal instead to keep the state of
the default action in sync. Make it a unique connection to allow multiple
calls to setDefaultAction, which are used by QToolButton to keep the
button updated if properties of the default action change.
Add a test that confirms that button and action are synchronized both
ways, and that we only get single signal emissions when changing either
programmatically.
Fixes: QTBUG-95255
Pick-to: 6.2 6.1
Change-Id: I0e027faf1da763ef1878e46e85bfa70073c8bf82
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
layoutAboutToBeChanged must be called before
persistentIndexList as the user might create persistent indexes
as a response to the signal
Fixes: QTBUG-93466
Pick-to: 6.2 5.15
Change-Id: I73c24501f536ef9b6092c3374821497f0a8f0de4
Reviewed-by: David Faure <david.faure@kdab.com>
Declaration::lengthValue only supported 'px' sizes, but one can transform
any 'pt' value into 'px' by multiplying with 1.33.
Notes: this ignores display DPI, and instead follows the W3C definition
of 'pt' and 'px' as absolute lengths [1].
[1] https://www.w3.org/TR/css3-values/#absolute-lengths
1pt = 1/72th of 1 inch
1px = 1/96th of 1 inch
so the conversion is px = pt * (72/96).
Add unit test that verifies this using QPushButton's icon-sizes property,
also with changed font in preparation of adding support for 'em' and 'ex'
units in a follow up commit.
Task-number: QTBUG-8096
Pick-to: 6.2
Done-with: Cristian Maureira-Fredes <Cristian.Maureira-Fredes@qt.io>
Change-Id: I58782e7ad0e2ff9d89ed695f8a23b1e584cfed64
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
For SingleSelection, removing the selected item will select the nearest
item and, if autoScroll is enabled, ensures that the newly selected
item is visible in the viewport. This may result in scrolling.
For Multi- or ExtendedSelection, this should not happen, as having no
selection is perfectly fine in those modes.
However, QListView still tried to scroll to the current item in response
to the currentIndexChanged signal. Since the currentIndex is at this
point already hidden, the rectangle for it became invalid, and the
attempt to scroll resulted in a one-pixel up-movement of the viewport
(since the invalid rectangle has width == height == -1).
Fix this by not scrolling if the rect for the index is invalid. Note that
the index is still valid at this point, so we can't shortcut the call
stack earlier. Add test that exercises the different combinations of
ViewMode and SelectionMode, and demonstrates the one-pixel
movement without the fix.
Fixes: QTBUG-94788
Pick-to: 6.2 6.1 5.15
Change-Id: I1f36973eadb46e8c9b8b8068bc76ee09e9f490dd
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
They're now in QWidget itself. Remove them from the API, but not the
ABI.
The QToolBar case is straight-forward. QMenu is a bit more complicated:
Since QT_CONFIG(shortcut) builds changed the signature of an existing
function instead of adding/removing an overload, we have to deal with
two cases: In a QT_CONFIG(shortcut) build, these overloads that take a
trailing QKeySequence parameter have been deprecated and therefore
cannot be removed. In a !QT_CONFIG(shortcut) build, the same functions
are 1:1 copies of QWidget functions and can be removed (from the API).
[ChangeLog][QtWidgets][QMenu/QToolBar] The addAction() functions have
been moved down into QWidget.
Change-Id: I49997b3440c137a1d4e3858d1d27d34a191e1eed
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QTableView stored the current row/column selection start in an own
variable instead using currentSelectionStartIndex. This leads to an
inconsistent behavior when the selection is done with a click on the
header and then in a cell (and the other way round)
Fixes: QTBUG-92561
Change-Id: I4c8bda3a938de451b6eff2819141e86a6870fbef
Pick-to: 6.1 6.2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Amends c0b3c06a7d.
The QCompleter used by QFileDialog uses starts-with matching of
the path parts, for all parts of the path. It uses the EditRole of the
underlying model for the data to match.
The path parts used for a path on Windows are "C:", "Users", "etc...",
and then finally whatever input has been typed so far. If we try to
match that against a starts-with rule against "Local Disk (C:)", then it
will fail and the completer will never have anything to show.
So, for the EditRole, return just the volume drive letter as we did before
c0b3c06a7d, not the volume name. Neither
can be edited anyway. This happens to then match the native file dialog
behavior, which doesn't complete "L" to "Local Disk (C:)" if the Computer
contents (ie. volumes) are shown.
Augment the QCompleter test case to cover that scenario (it already has
everything set up for this particular combination, even though we are
actually testing QFileSystemModel returning the correct data).
Fixes: QTBUG-94799
Task-number: QTBUG-78043
Pick-to: 5.15 6.2 6.1
Change-Id: I14844d91601e9b16dc07cff2ca48713acb7cdd09
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
After dc794f7622, side widgets only got
space if they were not fading out, but the logic was not correctly
accounting for side widgets that never fade, such as buttons added via
QLineEdit::addAction.
Fix this to give visible widgets space, unless they are fading out. That
was the intent of the original change. Rename the variable to make its
purpose clearer, and reset it at the end of the fade-out animation.
Add a much-needed test that relies on private APIs to verify that the
effective margins are calculated correctly.
Fixes: QTBUG-94824
Pick-to: 6.2 6.1 5.15
Change-Id: If2ee6be52be9e4f9be1e91f72f27681ce27def6d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In the unit tests, two times a validator was used without a parent,
which led to memory leaks. This patch changes this: The
validators are initialized with the widget they are meant for
as parent. This fixes the memory leaks.
Pick-to: 6.2
Change-Id: I480c0c5104cbe60159fad49df28cbb6240e7ce68
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Ievgenii Meshcheriakov <ievgenii.meshcheriakov@qt.io>
If a child widget that is affected by the parent's style sheet is
polished (because it's been shown explicitly, for instance by a layout),
then it must be repolished when the parent's style sheet changes, even
if the parent itself has not been polished yet.
Since the style sheet is set on the parent widget, we must repolish the
parent (which will repolish the entire widget tree), not just the
individual children and grand children.
Fixes: QTBUG-76945
Task-number: QTBUG-39427
Task-number: QTBUG-18958
Change-Id: I7bca9ee1badc07202fa05dc97f440f4ca6c9517d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
This should reduce the amount of fall-out from DST complications.
Also document the assumptions of QDateTimeParser's two fromString()
methods (and fix the punctuation on the QDateTime parameter).
Adjusted some tests to match.
Since only QDateTime-returning methods will show the difference, and
it's at least somewhat odd to be using those on QDateEdit or
QTimeEdit, this should have little impact on API users.
[ChangeLog][QtCore][Behavior Change] QDateEdit and QTimeEdit now
operate in UTC, to avoid spurious complications arising from time-zone
transitions (e.g. DST) causing the implicit other half to combine with
the part being edited to make an invalid result. Returns from their
dateTime() and other methods returning QDateTime (max/min) shall thus
be in UTC where previously they were in local time. QDateTimeEdit
continues using local time. The default can be over-ridden by
setTimeSpec(), as ever.
Change-Id: I44fece004c12342fe536bbe3048217d236fd97b2
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QDTP's absoluteMax(), setDigit() and getDigit() simply treated
day-of-week as synonym for day-of-month.
Consequently, QDTE::stepBy() did the same.
This meant that wrapping happened at the month boundary, so would jump
within the week if it wrapped around, otherwise the up/down arrow
would "jam" at a particular day of the week when further steps would
leave the month. Instead, when wrapping, wrap round the week while
still moving the day-of-month to match, jumping back or forward a week
to stay within the month on hitting a month boundary; otherwise, stop
backwards stepping on hitting the locale-specific day of the week, or
forward stepping when the step would be to or past this first day.
Fixed various bugs found in the course of testing this.
[ChangeLog][QtWidgets][QDateTimeEdit] Corrected handling of weekdays.
Previously, changes to the week-day were simply changes to the day of
the month. Weekday fields are now handled as such: changes to them do
change the day of the month, but a change that would step past the end
(or start) of the month is adjusted to the relevant day of the nearest
week within the month. When wrapping is disabled, the locale-specific
first and last days of the week are the bounds. Formats which specify
day of week but not day of month will now preserve day of week when
changing month or year, selecting the nearest day of month that
matches.
Change-Id: I7868b000fea7a4bc17a1b5687c44bcd56d42ae90
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
... even though the documentation states that the action takes
ownership of the widget.
Change-Id: Ie5520fbda295a5a2774ff8b82165070e9d49e310
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Edward Welbourne <edward.welbourne@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
555661b625: 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>
When calling `setStyleSheet` with property `qproperty-styleSheet`,
`QStyleSheetStyle::polish` will call`QStyleSheetStyle::setProperties`, and then`QStyleSheetStyle::setProperties` goes on to call `setProperty`.Because there is property `qproperty-styleSheet`, it will update stylesheet by calling QStyleSheetStyle::polish`.
This causes the recursive call to crash.
Fixes: QTBUG-94448
Pick-to: 5.15 6.2
Change-Id: I79c51192a939b0b62e5b1d0dcc90d38f79e28222
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
This test failed when checking for a pre-condition of the tested scenario,
so skip the test if that condition isn't met, as the test won't test
anything.
Amends b1fdcc8c0f.
Pick-to: 6.2 6.1 5.15
Task-number: QTBUG-64543
Change-Id: I135cd5b45efcae111305b9be338eb5429d3b97d5
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
A mouse press that transfers focus from an open editor back to the view
will close the editor. To prevent that the corresponding release then
opens the same editor again we need to know that the closeEditor call
was caused by the mouse press. Since Qt first generates the focusOut
event, and then delivers the mouse press, we have to start a zero-timer
to check whether we are in the same event delivery process. If so, ignore
the corresponding release.
Add test case that simulates that chain of events.
Fixes: QTBUG-20456
Pick-to: 6.2 6.1
Change-Id: I28fa32bfbc776db207c594c329961f575ae58ea9
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
When the listview setWordWrap is true and ScrollBarPolicy is
ScrollBarAsNeeded, if QStyle::PM_ScrollView_ScrollBarOverlap
returns true, the text displayed an empty line.
Fix this by not reserving the width of the vertical scrollbar
if the flow is TopToBottom and the vertical scrollbar, and QStyle
returns true for PM_ScrollView_ScrollBarOverlap. Amends
aeef92c3c3
Pick-to: 6.1 6.2
Fixes: QTBUG-94248
Done-with: Volker Hilsheimer <volker.hilsheimer@qt.io>
Change-Id: I4d47c7e86bbb86474cb1a99bb26d8b67f0e8a7e2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When pressing an index in order to start a flick gesture, QAIV sets
the current index. When QScroller changes state to Dragging, then
QAIV restores the current index to what it was before the press, as
the user is clearly scrolling the view. With autoScroll enabled, this
will produce an ugly jump if the old current index is no longer in
the viewport.
To prevent this, disable autoScroll before restoring the currentIndex.
Fixes: QTBUG-64543
Pick-to: 6.2 6.1 5.15
Change-Id: I3e0a18a6a179d80b9d810fce5aa658f0cfff9a29
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When finding the index we need to scroll to, use the one where both start
and end of the tab rect are outside the currently visible section.
Otherwise we wouldn't scroll when the left-most index ends outside the
visible section.
Add test, which requires that the scroll buttons have object names.
Fixes: QTBUG-70498
Pick-to: 6.2 6.1 5.15
Change-Id: Id153c77dd5fca146612375e0ff39bd1f3e0536b1
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Since 0f1008a593, views record if they
moved the item in the model, and prevent the deletion of the source item
in QAbstractItemView by setting the dropEventMoved private data member.
However, QListView in icon mode is special: it doesn't rearrange the
model, it repositions the icons in the view. While the dropEventMoved
logic was applied to the drag event filter to prevent deletion, the
variable was never set in the filterDropEvent handler. The drop event got
ignored, breaking rearranging of icons.
Fix this by setting the dropEventMoved member in filterDropEvent.
Fixes: QTBUG-94226
Pick-to: 5.15 6.1
Change-Id: I963f5db0f81bcd0d25eef05d9a265be00a5871f6
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
In MultiSelection mode, items are by default toggled on press, which
follows the example of standard Windows controls. However, when dragging
is enabled, then the press might be the beginning of a drag'n'drop
operation, and deselecting the item on press breaks the selection and user
experience.
Don't toggle the selection for presses on an already selected item that
might get dragged; instead, wait for the release event.
Extend the test case slightly to cover the special case. Dragging a
selection in a drag-enabled and MultiSelection item view wasn't possible
before either.
Fixes: QTBUG-59888
Change-Id: Ibd3e95a71ea63dd1e9bc3c8a723eafa9a1c21afa
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
In ExtendedSelection mode, a Ctrl+Press might be both the start of
a selection toggle, or the start of a Ctrl+Drag operation.
If we already toggle on the press, then it's impossible to drag the
existing selection while the Control key is pressed. Ignore Ctrl+Press
events and let the corresponding release event toggle the selection.
Adjust the relevant test cases accordingly. The QItemDelegate test
case used a click+control event incorrectly, such an event doesn't
change the clicked state and should not be eaten, and now it does
change the selection, so fix the test.
Task-number: QTBUG-59888
Change-Id: Ia76126e31c28bc97d3e93e54965bdb1d0b8ac6a4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Covers all selection modes and various combinations of mouse press, click,
drag, with or without modifiers.
Task-number: QTBUG-59888
Change-Id: Ib8ddc319a89649338d55fbc47e5a7ccfed338af9
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
After d6551fe125 it was no longer possible to start a drag with a
double click (where the first click selects an item, and the second
press+move starts the drag). Resetting the pressedItem variable to block
the emission of the clicked() signal had this unwanted side effect.
Instead, use an explicit boolean to store that the next release event
will be the result of a double click, so that the clicked() signal is not
emitted again (preventing the double-emission was the purpose of change
d6551fe125).
Task-number: QTBUG-77771
Fixes: QTBUG-94087
Pick-to: 6.1 5.15
Change-Id: I082c5169d89eb980dcd7985ef3d302b6ff060fb9
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Olivier BARTHELEMY <perso.olivier.barthelemy@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Test would previously have leaked on failure.
While checking for other uses of delete-after-checks, simplify one
place that tested deleting a calendar widget lead to recreation.
Pick-to: 5.15 6.1
Change-Id: I9524902a02dd42793bcf71113c6799dc925ac4a0
Reviewed-by: Mitch Curtis <mitch.curtis@qt.io>
When the PageDown is pressed, the current's rect cannot be
used to match the item, because we don't know the size of
the rect. Move the rect by the height of the viewport, and
then move the rect upwards until it matches the
button <= viewport's bottom of the item
Fixes: QTBUG-92583
Pick-to: 6.1
Change-Id: I210edc0e8b942984f3fc20e7752c6e1315152ea1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When changing the style of the combobox, the change will not propagate
to the internal container widget, so the changeEvent handler won't be
called. This is correct (as per QWidget::setStyle documentation).
QComboBoxPrivateContainer asks the combobox style for relevant settings,
such as the frame style, which is then used for sizing and positioning.
If the combobox's and container's settings become inconsistent, then the
combobox popup will not get the correct size and/or position.
Move some of the style-dependent changes into a separate function and
call it when the QComboBox::changeEvent handles the style change so that
both widgets have a consistent set of settings.
Add a test case that verifies that the style is asked for the relevant
setting when the style changes.
Note: QComboBox does a lot of style-dependent setup work in different
places, which is quite messy and complex. Trying to consolidate that
further breaks tests though, so this change is doing the minimum
necessary to fix the reported issue.
Pick-to: 6.1 5.15
Fixes: QTBUG-92488
Change-Id: Ia957d504b2d800add26fc0565be727b5c08a5358
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
child->widget() returns null if the layout item is not a widget.
Thus, calling removeWidget(nullptr) will remove all non-widget items
such as layouts or strechers.
Change-Id: I772c1158d0f7e8e2850b6e571b0405a2896f09b8
Pick-to: 6.0 6.1 5.15
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
When the listview setWordWrap is true and ScrollBarPolicy is
ScrollBarAsNeeded, if the text needs a newline display and the
vbar is not shown, the width of the item was subtracted from
the width of the scrollbar.
In most cases, the listview needs to reserve the size of the scrollbar.
But if the flow is TopToBottom and the vertical scrollbar is not
visible, the width of the vertical scrollbar cannot be reserved.
Fixes: QTBUG-92366
Pick-to: 5.15 6.0 6.1
Change-Id: I73cce691099a253d409019dbb3fe9a16e1830bb1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If a tab has a font assigned to it through a style sheet, then take the
font size into account when calculating the contents rectangle.
Add a test, which hardcodes the windows style to avoid flaky behavior
when e.g. macOS lays tabs out in the center.
Fixes: QTBUG-92988
Pick-to: 6.1
Change-Id: Ifb0ac97db7647cc25367972737be8878e50f6040
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When trying to find the original window title, check for another
maximized sub window and use its title. Protect the calls to
setWindowTitle to prevent the original title from being cleared.
Pick-to: 6.1 5.15
Fixes: QTBUG-92240
Change-Id: I55175382ab261b4cf8b5528304adaaec4fbe2c31
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Those tests don't fail anymore and show in CI as BPASS, so we
can safely, hopefully, unblock them
Task-number: QTBUG-87429
Fixes: QTBUG-68974
Fixes: QTBUG-69166
Fixes: QTBUG-87403
Fixes: QTBUG-87411
Fixes: QTBUG-69083
Fixes: QTBUG-69084
Fixes: QTBUG-87426
Pick-to: 6.1
Change-Id: I831b955116c0f465319b9c5fc726dd98804d1c00
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
For items that are children of other items, removeRows calls
beginRemoveRows directly and then once again inside takeChild()
The signal blocker that dates back to the monolitic import from Nokia
prevents the model from emitting extra signals
but the persistent indexes are corrupted nonetheless.
Fixes: QTBUG-90030
Pick-to: 6.1 6.0 5.15
Change-Id: I5bc4b2598bf13247683b113faeec22471f1f04a4
Reviewed-by: David Faure <david.faure@kdab.com>
Those overloads have been documented as obsolete, but never been deprecated.
Add the deprecation macros to trigger warnings as of Qt 6.2.
The overloads taking a single StandardButton should not be deprecated until
Qt 7, as otherwise porting from old to new API will require an unnecessary
cast to StandardButtons for calls with only a single enum value.
The unit test explicitly tests the deprecated members, so disable warnings
there.
Fixes: QTBUG-92483
Change-Id: I283ddce4681eafda2378607f999946e56bbb777e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
contentsMargins is a Q_PROPERTY on a QLayout. Qt 6.1 introduced
QLayout::unsetContentsMargins() to reset the contents margins to the
"default" ones (that the user can't know); that's the textbook
description of a RESET function for the property.
Add some tests also for unsetContentsMargins.
[ChangeLog][QtWidgets][QLayout] The unsetContentsMargins() function now
acts as the RESET function for the contentsMargins property.
Change-Id: I463d88363c11f4a15ad3d6af71401d8698de1d41
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Setting a cancel button on QProgressDialog more than once caused the layout
to be invalid. The layout was only applied when the dialog resizes or the
style changes, but not when a new cancel button is set.
The solution is to update the layout() before showing the dialog when adopting
new child widgets.
Fixes: QTBUG-19983
Pick-to: 6.0 6.1
Change-Id: Id8fb1ac56e94a9bd97d4559a2e8d4835856fd7d0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The use of "Country" is misleading as some entries in the enumeration
are not countries (eg, HongKong), for all that most are. The Unicode
Consortium's Common Locale Data Repository (CLDR, from which QLocale's
data is taken) calls these territories, so introduce territory-based
names and prepare to deprecate the country-based ones in due course.
[ChangeLog][QtCore][QLocale] QLocale now has Territory as an alias for
its Country enumeration, and associated territory-based names to match
its country-named methods, to better match the usage in relevant
standards. The country-based names shall in due course be deprecated
in favor of the territory-based names.
Fixes: QTBUG-91686
Change-Id: Ia1ae1ad7323867016186fb775c9600cd5113aa42
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
In case of a read-only text editing widget it was imposibble to copy text
from it. In QtWidgets you could not even see the selection handless.
Text selection in QtWidgets module was filtered depending on readOnly
property of the widget. Additionally, in InputMethod the read-only state
was translated into disabled.
Patch also makes the edit menu to be aware of the read-only status of
the control - the menu items are different for rw and ro controls.
Task-number: QTBUG-91417
Change-Id: Ic7b27f78678eeaa87a38607af787f254db1383b8
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
376e3bd8ec added the new class for Qt 6.1,
but during header review we concluded that using a class introduces
complexity wrt instance ownership and API design that can be avoided by
using a std::function instead.
The functionality is tied to QTextDocument, so the type definition and
the default provider API is added there.
Since std::function is not trivially copyable, the atomicity of the
previous implementation is not maintained, and concurrent modifications
of and access to the global default provider from multiple threads is
not allowed. The relevant use case can be supported by implementing a
resource provider that is thread safe.
Task-number: QTBUG-90211
Fixes: QTBUG-92208
Pick-to: 6.1
Change-Id: I39215c5e51c7bd27f1dd29e1d9d908aecf754fb7
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
While the class name is now a bit more than a mouthful, it's purpose
is very narrowly tied to QTextDocument, so don't use a very generic
name for it. That resources are provided based on a URL is to some
degree an implementation detail, and URLs are resource locators so
we don't need that in the class name.
Address code review comment for 6.1. Add documentation and links to
existing APIs with a similar purpose.
Task-number: QTBUG-90211
Task-number: QTBUG-92208
Pick-to: 6.1
Change-Id: I4f09057cc2f53a5595513c1c9422e6ccaad6ca13
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
