QWidget and QWindow use bits in QObjectPrivate to provide for a couple
of shortcuts -- one in qobject_cast, and another in the isWidgetType() /
isWindowType() functions in QObject. These can be optimized by simply
looking at the bits, without actually doing more expensive runtime
casts.
These bits were set on construction, but not unset on destruction. The
result was for instance that destroying a QWidget would report that the
object was still a QWidget when ~QObject was reached.
Fix this
1) by setting the bits only when QWidget / QWindow constructors start;
2) by resetting the bits once ~QWidget / ~QWindow are completed.
Technically speaking this is not 100% correct in the presence of data
members, but luckily those classes don't have any.
Amend an existing test for QWidget (whose comment said exactly the
opposite of what the test actually did) and add a test for QWindow.
Some other code was wrongly relying on isWidgetType() returning true
for destroyed QWidgets; amend it as needed.
[ChangeLog][QtCore][QObject] Using qobject_cast on partially constructed
or destroyed QWidget/QWindow instances now yields correct results.
Similarly, using the convenience isWidgetType() / isWindowType()
functions now correctly return false on such instances. Before,
qobject_cast (and the convenience functions) would erroneously report
that a given object was a QWidget (resp. QWindow) even during that
object's construction (before QObject's constructor had completed) or
destruction (after QWidget's (resp. QWindow's) destructors had been
completed). This was semantically wrong and inconsistent with other ways
of gathering runtime type information regarding such an object (e.g.
dynamic_cast, obj->metaObject()->className() and so on).
Pick-to: 6.3
Change-Id: Ic45a887951755a9d1a3b838590f1e9f2c4ae6e92
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The test waits a bit hoping that all paint events are delivered after
showing the widget so that we can count the rectangles that are getting
updated when scrolling.
Waiting for 20ms is too short unless the system is completely idle.
Based on testing on a local VM, 150ms produces reliable results.
Pick-to: 6.2 6.3
Change-Id: I7729e94eae41476be67291a2f664cff784f96c7d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
After 7369c31ca1f446e81eda1c93ba13767ffcd83efe, unaccepted touch points
were not grabbed anymore in calls to activateImplicitTouchGrab. However,
gesture recognition relies that widgets for which a gesture has been
partially recognized grab also unaccepted touch points.
Add a parameter to allow the implicit grabbing to take place also for
unaccepted event points.
Add test case that replays touch events similar to what Squish is doing,
and fails without this fix.
Pick-to: 6.2
Change-Id: Idb0b20301b1827be57a03013a59043d97c2ee7b6
Reviewed-by: Stefan Gehn <stefan.gehn@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Expose QWidgetRepaintManager's data structures so that we can write
unit tests, and verify that they are correct after moving opaque
widgets (which triggers the accelerated move code path).
Improve the compareWidget logic to not rely on screen grabbing
(which requires permissions), but instead use QPlatformBackingStore's
toImage function, which is faster and more reliable, and also doesn't
require us to show the UI we want to grab full screen in order to
avoid issues with overlapping windows etc.
Change-Id: Iff2ea419f03a390ab6baca26814fef6ff45f7470
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
On some platforms, such as X11 and Wayland with some compositors,
QMenu could be a popup window, which should be set a transient parent
to get relative position, which is requested by Wayland.
Added transientParentWindow() for QMenuPrivate like QDialogPrivate.
Fixes: QTBUG-68636
Pick-to: 6.2
Change-Id: I6d8880cb008ecf61a4c005898b38e3953379a13d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Added to QWidgetRepaintManager test case, which is the only place where
the function is used.
Includes a helper that creates a complex scene with opaque children,
which will be used in additional unit tests.
Change-Id: I0e0188dd560923a552a8967d8e992dc17cc849d6
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When you are editing in a QTextEdit and press enter to start a new line,
calling insertBlock() with no arguments tries to preserve the current
charFormat and blockFormat. That is often OK:
- if you hit enter at the end of a list item, you probably want another
item in the same list
- if you are writing code inside a code block, you're probably just
writing the next statement on the next line: stay in the same block
- margins, indents, tab positions should stay the same (but hopefully
your editor has UI to manually reset the block format to default
in case you are not continuing in the same style)
But there are some exceptions we can apply to be helpful:
- nobody ever wants to follow an <hr/> with another one (but
hopefully the application has an action to insert one manually)
- a heading is more likely to be followed by a paragraph, or perhaps
a smaller heading; another heading at the same level is unlikely.
We need to reset the char format, not only the block format, because
the large font and heavy font weight are stored there.
- when adding to a todo list, hitting enter at the end of the last task,
let's assume the next task is not yet done, so it will be unchecked
by default (else, why are you writing a todo list at all)
To achieve that, we need to customize the formats and call the
insertBlock() overload that takes them. The no-argument insertBlock()
will continue to preserve the formats, because it's an old API that is
used for much more than interactive editing.
Additionally, word processors tend to let you end a list (for example)
by hitting enter twice. In that case, you stay in the same paragraph
that you created the first time you hit enter, but now the formats are
reset to default, so that you can go on typing an ordinary paragraph,
rather than having to mouse up to the toolbar to select the paragraph
style in a combobox, or something like that. So we now do that: reset
both block and char formats after you hit enter on a blank line; but if
you then hit enter again, after the block format has been reset, then
you will get the actual blank line (empty block) inserted.
[ChangeLog][QtWidgets][QTextEdit] Hitting enter at the end of a line
with a special block format (horizontal rule, heading, checklist item)
now makes some "smart" adjustments to avoid retaining properties that
are unlikely to be continued on the next line. Hitting enter twice now
resets block and char formats to default.
Fixes: QTBUG-48815
Task-number: QTBUG-80473
Fixes: QTBUG-97459
Change-Id: I3dfdd5b4c0d9ffb4673acc861cb7b5c22291df25
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
We need to check whether the horizontal header's selection includes the
index for the row at the top, rather than for row 0, as the index we
check is based on the scrolled position of the header, so would never be
included in the top row when the view is scrolled. This is correctly
done in selectRow already.
Add a test case that simulates selection of rows and columns by clicking
on the header.
Fixes: QTBUG-98444
Pick-to: 6.2
Change-Id: I2fa1b32bf75dc96225b40145b713bf7e2ffc29dd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The first sub window added will activate itself automatically, and
isActive is set to true. Therefore the call to setActiveSubWindow to
activate the first sub window will be ignored.
When showing the mdiarea, all sub windows will be activated in the order
in which they were added, so the active window will always be the last
sub window added.
Fix this by setting isActive to false so that setActiveSubWindow
activates the first sub window when the mdiarea becomes active.
Fixes: QTBUG-92037
Pick-to: 6.2
Change-Id: Id4a793e2059803c1a4ada916fdae2d3cc02cdf06
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
We have some special handling in qt_windows.h,
use it instead of the original windows.h
Change-Id: I12fa45b09d3f2aad355573dce45861d7d28e1d77
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Don't crash if the font does not have any families set.
Pick-to: 6.2
Task-number: QTBUG-97995
Change-Id: I8dc2f2fc00309b6fff6d4a661ec6d659f30808af
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
If QFontComboBox is instantiated in the form of new and call
QFontDatabase::addApplicationFont, QFontComboBoxPrivate::_q_updateModel()
will be called when the program exits, at this time qApp will crash.
Fix this by when program exiting, QFontComboBoxPrivate don't need
call _q_updateModel().
Fixes: QTBUG-98099
Done-With: Konstantin Ritt <ritt.ks@gmail.com>
Pick-to: 5.15 6.2
Change-Id: I3df3d19c3d1971288d60f2eef386262befbf396b
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
In paintAndFlush, QWidgetRepaintManager subtracts opaque children if
the target isn't overlapped and isMoved is set to true. So in moveRect,
set isMoved to true after the blitting of movable areas, and reset it to
false if we have overlapped sibling or child regions. Otherwise, moving
so far that sourceRect is invalid (none of the original pixels are
visible after the move) we end up in a code path that sets isMoved to
true even with overlapping children or siblings, which then breaks
paintAndFlush's assumptions.
Reuse the test case written by Sergiy Korobov <tiamatenko@gmail.com> in
earlier attempts to fix this bug.
Fixes: QTBUG-26269
Pick-to: 6.2
Change-Id: If7443863f5eee79a80220cd587522122f42a21e4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
Since QMainWindow::setMenuWidget accepts a QWidget (allowing users to
implement their own menu widget), we need to use qobject_cast on the
stored widget to see if it is a QMenuBar before calling QMenuBar APIs.
This qobject_cast may return nullptr.
Pick-to: 6.2
Fixes: QTBUG-98247
Change-Id: Iff1dbd24fa7ca09098fe49c179770356c966251d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QTabBar implements wheelEvent to move the current index up or down. This
is useful for clicky mouse wheels, but a bad user experience when using
a kinetic wheel or touch pad, as every pixel movement will change the
current index.
Instead, scroll the entire tab bar when the wheel event comes from a
device that supports scroll phases, without changing the current index.
As drive-by's, fix the test introduced in aa09bea00c to
not leak memory or leave a test-specific style set on the QApplication
instance, which can break other tests.
Also, make relevant layout code in QTabBar respect the usesScrollButtons
property, const'ify local variables, and return an accepted QWheelEvent
if the event resulted in a change.
[ChangeLog][QtWidgets][QTabBar] Scrolling with a kinetic wheel or touch
pad scrolls the entire tab bar, without changing the current index.
Change-Id: I990e51466dd25c741877bbf0e197449f897a9efb
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
The slider is very touch friendly from macOS 11 on, and the knob is quite
large. Give it some extra pixels, and adjust the test accordingly.
Pick-to: 6.2
Task-number: QTBUG-98093
Change-Id: Iedf6db1081cdd4013ca29ce760aea1e0361b1123
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Check that a file name, not the full path, contains a dot.
Fixes: QTBUG-59401
Pick-to: 5.15 6.2
Change-Id: I193b2ae457a3ac6a460524dbf200786eb3461cef
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
After special processing for hover, QPushButton::mouseMoveEvent()
needs to call the base class function, like every virtual override
should, to continue processing other logic. Amends
3310e13a17
Fixes: QTBUG-97937
Pick-to: 6.0 6.2
Change-Id: Ic2e111d6c38371e0aa04423f5fb26c52717bf5fb
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Relying on QCursor::pos makes tests fragile and prevents multi-seat support.
Instead, record the mouse position in the already existing event handling,
and use that instead. Styles might use either WA_Hover or enable mouse
tracking for the widget to enable hover-effects, so we need to support both.
Fix the scenario where a newly inserted tab ends up under the mouse, which
was previously not handled correctly (only the case of removing a tab was).
Clean up the repaint management when the hovered tab changes; just call
update on the old rect, and then later update on the new rect; there's no
need to make a copy first, updates are posted and compressed.
Add a unit test that makes sure that we paint tabs that should be under the
mouse in the hovered state. Since not all styles enable hovering and/or
mouse tracking in all cases, use a style sheet for those styles that don't.
Change-Id: I7cdbb18e9e04b52651e273680fec87b50cb81e05
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Amends 17c1ebf8bf, which introduced logic
that recognizes double clicks to avoid duplicate clicked() emits. If a
slot connected to doubleClicked opens a dialog, then the release-event
will not be seen by the item view, leaving the flag incorrectly set and
preventing the next clicked signal.
Fixes: QTBUG-97853
Pick-to: 6.2 5.15
Change-Id: Iced83e8c66a763672f522265435dc52a745227e4
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Otherwise, the button state maintained by Qt when using the offscreen
plugin is not reset, breaking following tests.
Pick-to: 6.2
Task-number: QTBUG-97964
Change-Id: Ib37fd038e214863e1e316dc3d41e9d28c157b1f8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: David Skoland <david.skoland@qt.io>
QTest's simulation of mouse move events currently uses QCursor::setPos
and then processes events. This is unreliable across platforms.
This test relies on the event processing and either way has inverted
logic in the paint event; the painted region needs to at least include
the tab's rect, not the other way around. Also, the mouse move wasn't
needed here at all, and some styles don't have a different style for
pressed tabs anyway.
Pick-to: 6.2
Change-Id: Ib8f6f7be017ff87458e96ec419edcd065dd75b15
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
QTabBar caches the rects for the tabs to avoid costly recalculation of
each tab's size hint. That cache is only updated via layoutTabs if the
entire tab bar is resized or modified. However, when a style sheet is
set that calculates a different size hint for tabs that are selected,
then the tab bar also needs to be laid-out when the current tab changes.
To minimize the cost, compare the cached size for the new current tab
with its new size hint, and re-layout the tabs when they are different.
Fixes: QTBUG-6905
Fixes: QTBUG-8209
Pick-to: 6.2
Change-Id: I110444d18938c2b3446ee58e4a8c6c472b5f12c3
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Menus can be represented by a menu action, and if that menu action has
been hidden or disabled, then the submenu is not accessible from the
parent menu or menu bar to which it was added. Don't walk the menu
action chain further when checking whether the shortcut should trigger.
Note that this is unrelated to the menu being visible or not; we
obviously want to trigger shortcuts for actions that only live in a menu
that has not been shown, otherwise the shortcut would be rather
pointless.
Pick-to: 6.2
Fixes: QTBUG-25743
Change-Id: I48735e17352989bbc84a72263e4828f519b78095
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Some item views, such as QListView in icon mode, implement a selection
rectangle with which the user can "lasso" items. So far, dragging that
rectangle did not trigger auto scroll, so unless an item near the edge
was selected, the user had to stop the lassoing and scroll manually to
reach more items.
Since QAbtractItemView implements auto scrolling for drag'n'drop, we can
use that mechanism also when the selection rectangle is dragged. This
requires some modifications:
We need to make sure that scrolling the view during a drag-selection
generates mouse move events so that the selection is extended and the
rectangle is updated in subclasses.
And we need to stop using QCursor::pos to get the position of the mouse
pointer, as this makes the auto-scrolling untestable. Instead, record
the mouse position last seen during a mouseMove or dragMoveEvent in
content-coordinates (identical to pressedPosition).
As a drive-by, fix some coding-style issues in nearby code.
Done-with: Zhang Hao <zhanghao@uniontech.com>
Fixes: QTBUG-96124
Change-Id: I426f786e5842ae9f9fb04e9d34dc6d3379a6207f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
Amends 32edae5e26, which introduced a
timeout after which the restored state is discarded. If this timeout
hits during a CI run, then the test is expected to
fail.
Implement a lambda that watches for the restored state to disappear.
This happens primarily when restoring a fullscreen state, where some
desktop environments scroll in a new virtual desktop. It should not
happen for other data tags.
Change-Id: I5ff43a4e1857eca17a5d4fe2b47add1f70636e8d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
On systems that asynchronously resize the window to maximized or full
screen state, the window will become visible in its normal geometry
before it gets the final size by the windowing system. This might cause
multiple resize events, to each of which the widget's layout responds
with a call to its setGeometry implementation.
The QMainWindowLayout is special in that it will shrink dock widgets if
there is not enough space for them, but it doesn't grow them back once
there is. With the initial resize event being for a smaller size than
what was restored, the state is not restored correctly, but remains in
the state that fit into the smallest size with which setGeometry got
called.
To fix this, we have to keep the restored state around until the window
either gets a size that is large enough for it to fit, or until we can
be reasonably certain that the windowing system is done resizing the
window while transitioning it to the maximized or full screen state.
Since across the various platforms and windowing systems there is no
reliable way to know when the window reaches its final size, we have
to use a timer that we (re)start for each call to setGeometry with a
size that's not large enough. Once the timer times out, we have to
give up; then the last layout state calculated is the final state.
To calculate the size of the layout, introduce a function to the
QDockAreaLayout that returns the size required for the current sizes
of the docks. Refactor sizeHint and minimumSize (which were identical)
into a helper template that takes member-function pointers to call the
respective method from the dock area layout's content items.
Add a test case for various permutations of the scenario. The timeout
of 150ms is based on running this test case repeatedly on various
desktop platforms and X11 window managers.
Fixes: QTBUG-46620
Change-Id: I489675c2c40d3308ac8194aeb4267172b2fb38be
Reviewed-by: Albert Astals Cid <albert.astals.cid@kdab.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
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>
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>
QGridLayout::takeAt() and QLayoutItem *itemAt() only check the upper bound.
If the index < 0, these function will return invalid pointer.
Fixes: QTBUG-91261
Pick-to: 5.15 6.0 6.1
Change-Id: Idfb9fb6228b9707f817353b04974da16205a835c
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The calculation rounds early and often, which is intentional. Add
unit test to make sure we don't regress.
Fixes static analzyer report about incorrect rounding in
c903a34347776fe3b89785faa35c446d.
Address some outdated comments and documentation. The property
is read only and calculated, so don't imply that it can be changed
from its default value.
Change-Id: If2dbd9890e533dfccda3eae4cbc96db4f1246f4d
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The tst_QPushButton::sizeHint() test was leaking top level
windows and confusing the other tests, as they may end up
becoming active.
This also re-enables tst_QPushButton::setAccel() since I
cannot reproduce the failure with that, so maybe that was
related to the leaking widgets.
Task-number: QTBUG-91418
Change-Id: I33f4a12bf67f784c5d6a06b2407d067e804d766f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Liang Qi <liang.qi@qt.io>
There is something wrong with dock widget positioning on Wayland.
In the interest of getting tests running at all, we skip the
test for now, like we already do with a few others.
Task-number: QTBUG-91418
Task-number: QTBUG-91483
Change-Id: I44f5fa0e4d0a43a46ce24a61a899bfcc03787f28
Reviewed-by: Liang Qi <liang.qi@qt.io>
Wayland doesn't support explicit window activation, so the
qWaitForWindowActive() function won't actually wait for the
window to be active.
On platforms like this, we just QTRY_VERIFY() for the window
activation instead.
Task-number: QTBUG-91418
Change-Id: I5f728e6a6bcaac283c026b60e6378b9d5aaf1be5
Reviewed-by: Liang Qi <liang.qi@qt.io>
The test assumed that a window was registered as the active
one immediately when it was exposed. This created a race
condition on Wayland, where we would often get the wrong
active window when simulating the events.
Task-number: QTBUG-91418
Change-Id: Ie41fe5adb339bbb43d5ee5db400a198e479de386
Reviewed-by: Liang Qi <liang.qi@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>
This reverts commit 6269438af9, and adds a test.
This change introduced QTBUG-91735, without fixing QTBUG-86857 correctly. The
code already interprets the textAlignment values from the rule, also if no
icon is set. Adding the same, or some default textAlignment to the text flags
if there is no icon doesn't work.
Fixes: QTBUG-91735
Task-number: QTBUG-86857
Pick-to: 6.1 6.0 5.15
Change-Id: Iee07e63a40e72909275f32e1caa28b33a595f879
Reviewed-by: Oliver Eftevaag <oliver.eftevaag@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
The test assumed that dialog.move() would actually move
the dialog box to the requested location, which is an invalid
assumption on Wayland.
Since the objective of the test is not to check if move() works
this way, but to check whether the dialog box shows up in the
same location when it is re-shown, we actually fetch the pos
after showing it the first time, rather than assume this is the
same as the requested one.
Task-number: QTBUG-91418
Change-Id: Ifa21fa08429f198988f90d7ee328e4f35a4764c2
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
If we only wait until the window is shown before testing the
event delivery, we may be getting a WindowActivation event
and subsequent paint event after we start testing. This can
cause a shift in the paint events, so that we end up with an
unexpected paint event at the end.
We should wait until the window is active before we start
checking the response to updates, to be sure nothing is pending
on the queue still.
Note that you'd expect QTest::qWaitForWindowActive() to do this,
but this actually falls back to qWaitForWindowExposed() when
the platform does not have WindowActivation capability. While
there is no real link between WindowActivation capability and
waiting for a window to be active, changing the behavior of that
function would be too scary, so we just implement an explicit
wait in the functions that depend on this.
Task-number: QTBUG-91418
Change-Id: Iee40dcfa1377f543ea05042cc5a972270b346708
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
QTreeView's drawTree implementation performs lazy layouting
when calling itemDecorationAt. If animations are enabled,
this can change the list of items, and invalidate the copy
made earlier.
Don't copy the list of items, use a reference instead so that
code iterating over the items later operates on valid data.
Add an assert in the private itemHeight method, it must not
be called with an index that is out of bounds.
Fixes: QTBUG-42469
Pick-to: 6.0 6.1 5.15
Change-Id: Ifdb782881447912e00baffd1c407de10a1d8d0d4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QTBUG_89082_actionTipsHide() is very flaky if tooltips fade in, as the
mouse move might happen while the tooltip is still appearing.
Fixes: QTBUG-91532
Pick-to: 6.1 6.0 5.15
Change-Id: I55305927fcf143d99dfff28d0bc70b2e831a139a
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Use the QWindow-based overloads of QTest::mouseMove(), which do
not move the cursor position.
Amends ba13960392,
3f3d5e6716.
Task-number: QTBUG-89082
Pick-to: 6.0 6.1 5.15
Change-Id: I2cc62e4d1f24e4baebafd0d76fbf0fbdb6f588c7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The test has been observed to fail with:
FAIL! : tst_QDoubleSpinBox::setReadOnly() 'QTest::qWaitForWindowActive(&spin)' returned FALSE. ()
/Users/qt/work/qt/qtbase/tests/auto/widgets/widgets/qdoublespinbox/tst_qdoublespinbox.cpp(863) : failure location
Remove the widget member and use a widget instantiated on the stack instead.
Add a check for top level widget leaks in cleanup() and fix leaking task224497_fltMax()
by instantiating the widget on the stack.
Pick-to: 6.1
Change-Id: Idbbb5d859c0df2d9b9f49fb9f69ef6bb7d1ee150
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Move the cursor out of the way to prevent it from interfering.
Amends 3f3d5e6716.
Task-number: QTBUG-89082
Pick-to: 5.15
Pick-to: 6.0
Change-Id: I0efbe2b5618a04e92839083a1bd3383e05d6ff93
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Extend and rename the pixmap() crash test to also verify
that a non-null pixmap is returned.
Change-Id: Ia972c4f705724cfa1394521a2dfd87451d9c5d64
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Applications on macOS are automatically activated (put into the foreground),
when launched from the Finder, or via 'open' on the command line. But when
launched from the terminal, e.g. foo.app/Contents/MacOS/foo, the application
will launch in the background (inactive).
In Qt we override this behavior, activating the app even when launched from
the terminal, as a convenience, as long as the application is a GUI application.
Unfortunately this means that when tst_qapplication launches a subprocess that
is a GUI app, it will steal activation from tst_qapplication, which in turn
will break tests that later try to activate a window and check that the window
is then active. The window will not be active until the application is active.
We can work around it by preventing Qt from activating the application, but
ideally we'd find a better solution to this, as we don't want to sprinkle
overrides all over our tests.
Fixes: QTBUG-90699
Pick-to: 6.1 6.0 5.15
Change-Id: If53a86548002b739df0c0a7153d6244924a4a205
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
The text of QPlainTextEdit might change when it is invisible, so an
adjustment of scroll bars is needed when the QPlainTextEdit showing
up, otherwise the range of scroll bars might be incorrect.
Fixes: QTBUG-77937
Pick-to: 5.15 6.0 6.1
Change-Id: I45c686c7e09ca7b2944c36122e9157de0ec4f0e0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
With the updated QEMU and toolchain, these tests now pass.
Change-Id: Icb74562a0e6422cd4564f63db991aa431e0e3119
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
The test was flaky in recent test runs on X11. Debugging
showed that the global position of the synthesized mouse
events was not correct due to the window not being mapped
properly. Use QTest::qWaitForWindowActive() instead of
QTest::qWaitForWindowExposed() to ensure that.
Task-number: QTBUG-90016
Pick-to: 5.15
Pick-to: 6.0
Change-Id: Ie1bc4157e6d0e807d8530f70dcbd27b5e2fc813c
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Mouse wheel/touchpad scroll signals sent to the tab bar trigger
cycling through the tabs. In applications where the tab bar is
close to "mouse click hotspots", the cursor may accidentally be
left over the tab bar instead of the main content of the window.
When the user wants to scroll up/down the main conten, the
scroll signals are thus sent to the tab bar and instead of
scrolling, the focus switches to another tab. This is
confusing to the user, because not only does the application
not carry out the desired action (scrolling through the main
content), it jumps to a different tab. Two common examples of
applications affected by this nuisance are Konsole and any kind
of browser (file browser or web browser), where the address bar
is right below the tab bar. Moreover, on macOS, scroll events
do not have an effect on the tab bar widget of the native UI.
Currently, the code makes use of preprocessor directives to
achieve consistent behavior on macOS (`#ifndef Q_OS_MAC`). This
patch implements the check of a StyleHint in order to determine
if scroll events on the tabbar should have an effect. This
approach is more consistent with Qt coding style than
OS-dependent preprocessor directives and, in addition, makes
the behavior configurable according to the user's preferences.
[ChangeLog][QtWidgets][QStyle] Added
SH_TabBar_AllowWheelScrolling as a style hint to enable/disable
cycling through tabs using the scroll wheel. This defaults to
true in all styles except the macOS one so there is no change in
existing behavior.
Change-Id: I99eeb5a1aab03cbc574fac7187d85a8a2d60cf34
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
A resize event delivered after closing the platform window
was causing the stored frame margins to be cleared.
Bail out of QWidgetWindow::updateMargins() if the
platform window is null.
Pick-to: 5.15
Fixes: QTBUG-79147
Change-Id: Iebbc90c3cccafa209cd720baedf45affb3f3c2b8
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When setting the application's focus widget we search for the next
child widget that can hold the focus and call its setFocus() method,
which also updates focus widgets of all its parent wigets.
In case if the focus widget is the active window itself, we only set it
as the application's focus widget, but we don't update the focus widget
of the active window itself. Because of this the focusWidget() method
always results nullptr for the active window. This prevents from setting
the focus back to active window after the focus has changed (for example
after a context menu is closed, as in the bugreport).
Transfer the focus to active window by calling the setFocus() method, as
it is done in case of transferring the focus to any other widget.
Pick-to: 6.0 5.15
Fixes: QTBUG-85846
Change-Id: I91ebf182fd5bb7d451a1186e2f3e38c8d48acc4e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
In this case, the previous action's tip is still displayed
when the cursor moves from one action with tip to another action
without tip.
Fixes: QTBUG-89082
Pick-to: 5.15
Pick-to: 6.0
Change-Id: I0a00595dc3d716725678487be9cbb363c4d3b392
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If a default font was not registered for the widget's class, it returns the default font of its nearest registered superclass.
Fixes: QTBUG-89910
Pick-to: 5.15 6.0
Change-Id: I6e6b2c6a0044462f84db9f76a03be0c6cfaaae8e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@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>
Those serve no purpose anymore, now that the .pro files are gone.
Task-number: QTBUG-88742
Change-Id: I39943327b8c9871785b58e9973e4e7602371793e
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
The color should be used across the board, so the PlaceholderText color
should also be respecting the one passed for Text and so on.
Fixes: QTBUG-89815
Pick-to: 6.0 5.15
Change-Id: I2accb3db35488f95a1c8ebacf2316a08ee416fac
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QTextDocument and the text editor classes suggest to override
their loadResource() methods to provide data associated with
a text document. This approach has the following drawbacks:
- it requires subclassing
- there is no way to set a global resource provider
- QLabel is missing virtual loadResource() method and
it can't be added without breaking ABI
QUrlResourceProvider is designed to solve these issues.
One should create a derived class that implements
QUrlResourceProvider::resource(). The objects of the derived
class then can be set for any text document.
The default resource provider can be set with
QUrlResourceProvider::setDefaultProvider().
This change also adds QLabel::setResourceProvider(),
which doesn't break ABI.
[ChangeLog][QtGui][Text] Introduced QUrlResourceProvider that allows to
load resources for HTML. It is intended to replace the use of
QTextDocument::loadResource().
Change-Id: Iaf19b229f522a73508f20715257450fe58f68daf
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
The Android tests were marked insignificant for some days, due to an
emulator issue, these tests slipped during that time. Exclude them now
to bring Android tests.
Task-number: QTBUG-89402
Pick-to: 6.0
Change-Id: I96d0f87b36975b7e2c83956b04b6569a03a781a9
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Remove the qmake project files for most of Qt.
Leave the qmake project files for examples, because we still test those
in the CI to ensure qmake does not regress.
Also leave the qmake project files for utils and other minor parts that
lack CMake project files.
Task-number: QTBUG-88742
Change-Id: I6cdf059e6204816f617f9624f3ea9822703f73cc
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
Fix indentation in tst_qlockfile and remove QtTest include in
tst_qcheckbox.
Change-Id: Idf630c6337859dbcc8f644010b941bfe55bb0633
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QAbstractItemView::selectionCommand() returned the wrong SelectionFlags
when no event is given since c4366ff018.
Therefore re-add the call to QGuiApplication::keyboardModifiers() when
no event is given and add a unittest for them so it's not removed again.
Fixes: QTBUG-89711
Change-Id: I107357df08c4ff1b1a14d49523401c5e7b428f56
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Complete search and replace of QtTest and QtTest/QtTest with QTest, as
QtTest includes the whole module. Replace all such instances with
correct header includes. See Jira task for more discussion.
Fixes: QTBUG-88831
Change-Id: I981cfae18a1cabcabcabee376016b086d9d01f44
Pick-to: 6.0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Avoid possible memory leaks by creating the checkbox on the stack, adopt
coding style.
Change-Id: I25f8b9048c8318d2897fd942492254a036c3a706
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Apparently some library definitions went overboard, link them directly.
Pick-to: 6.0
Change-Id: I009737f7e3edff5619241b700a627dc4e25e6018
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Historic QDateTime behavior when being asked to create a
QDateTime in the DST gap was to interpret the given date
as if it was in the time before that gap, mapping it to a point
in time after the gap. This has changed with
a04411119e .
Since then, the given date is interpreted as if it was in the
time after the gap, thus being mapped to a point in time
before the gap.
This patch restores the historic behavior.
This was not caught by Coin because machines ran in timezone
"Atlantic/Reykjavik" which does not have DST since 1967.
This patch changes tests to always run in "Europe/Oslo".
Driveby: Test function "findSpring" did some operations in
local time, even though being asked to work in a specific
time zone. Fixed that.
Fixes: QTBUG-86960
Fixes: QTBUG-89208
Pick-to: 6.0 5.15
Change-Id: Iecce5898bf9711a10e7dfc0a25e4bbeaed1c8ade
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QTableViewPrivate::heightHintForIndex()/widthHintForIndex() did not
honor spans and therefore returned too big values.
Fixes: QTBUG-89116
Change-Id: I52948902b7eaaa27c092ed39da68950c3840e8e4
Pick-to: 5.15
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
tst_QLineEdit::QTBUG13520_textNotVisible checks that text is visible
if a QLineEdit is set to Qt::AlignRight. To do that, it writes
some text into a line edit and checks afterwards that the first
character is in the left half of the window. This fails if the window
is larger than twice the length of the text used and thus might fail
in multiple situations where Qt is not in full control over the size
of the windows created, as is the case with tiling window managers.
This patch changes the test to not check for the first character in
the left half of the window, but instead check for the first character
be approximately at the expected position.
Pick-to: 6.0
Change-Id: I18f6de356ea20f4744f3a58cd2b1d76f6a9545a4
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
The hash and equality operators used need to be consistent with
each other. Unfortunately, QPMI::operator==() is not suitable to do
this. So specialize qHashEquals() for QPMI.
Fixes: QTBUG-88966
Change-Id: If5f19a722ae9fc4e78e93537e7ea15726f148768
Reviewed-by: Jarek Kobus <jaroslaw.kobus@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 83e95956ed58e88b11e2cc3cb61c5beacb7985db)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QHeaderView sorting may be triggered when the user performs
some mouse interactions that should really not result in sorting.
Generally speaking, this happens when the user:
* presses on a non-movable section (A)
* moves on another section (B)
* releases on that section
resulting in B becoming sorted / flipping sorting.
(Non-movable is required, otherwise dragging would cause section moving,
not sorting.)
To make the matter worse, QHeaderView doesn't check that the release
happens within its geometry. This makes sense when moving sections: one
is able to drag a section horizontally/vertically even if the mouse
leaves the QHeaderView.
But when not moving sections, this means that one can
* press on section (A),
* move the mouse anywhere vertically (for a horizontal bar, mut.mut
for a vertical) above or below another section (B), that is,
outside QHeaderView's geometry
* release the mouse
and cause B to be sorted.
Fix it by
1) remembering which one was the section that the user originally
clicked on; that's the only one that can possibly become sorted
(if we're not moving and other conditions hold). No other variable
seemed to remember this.
2) on release, check that it happens within that section's geometry.
If so, sort.
Pick-to: 6.0 5.15
Change-Id: Icfb67662221efbde019711f933781ee1e7d9ac43
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This patch disables four failing unit tests when executed with the
offscreen backend.
Change-Id: Ie67341b886984e6de19cd8dd8a8a237a620a1b7a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
If one clicks on a QHeaderView's section, the header view will
sort the view by the respective column/row. By clicking multiple
times, one is able to toggle the sorting between ascending
and descending. Something that is NOT possible to do however is to
un-sort the view -- that is, to restore the model's original
sorting. This must be done via code, by asking the header or the
view to sort by section -1.
This commit adds new property to QHeaderView to make it possible
to unsort models. Basically, the sort indicator becomes a tri-state:
sort ascending, sort descending, unsort (sort by column -1).
[ChangeLog][QtWidgets][QHeaderView] Added the sortIndicatorClearable
property. Setting this property allows the user to clear the sort
indicator on a section, resetting the model to its default ordering.
Change-Id: Ibf4e280b2086b75ccd64d619ea4d70816dc3529f
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: David Faure <david.faure@kdab.com>
One test in tst_qfiledialog2 only succeeded if the directory "~/foo"
did not exist. This patch changes the path used to "~/Vugiu1co"
which has hopefully a much lower probability of existing.
The string "Vugiu1co" is taken from a call to "pwgen".
Pick-to: 6.0
Change-Id: Ia82b07902a91eb908a74aa90cdbdf4761d432d9a
Reviewed-by: Karsten Heimrich <karsten.heimrich@qt.io>
When we are using the offscreen plugin, there might or might not
be a working system tray icon. This patch disables the unit test in
that case as we do not know what to expect.
Change-Id: I34fded516300cc9aab1eb67644dcef8631ecfdf1
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
By depending on setFamilies() then we can be sure that font names with
spaces, commas, quotes and so on are correctly handled without being
misinterpreted. For now it will split on the comma when a string
containing one is passed to setFamily. But from Qt 6.2 this will be
removed to preserve the family string as a convenience function.
[ChangeLog][QtGui][QFont] Indicated that setFamilies/families is
preferred over setFamily/family to ensure that font family names are
preserved when spaces, commas and so on are used in the name.
Change-Id: Id3c1a4e827756a4c928fed461a4aafa5a0f06633
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Tests can run faster now, but we still expect calculations based on
the timestamp (such as QEventPoint::velocity()) to be correct.
Change-Id: Ie962604c9ebd139384dcd89a157de66b4b773cc9
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Android packages the test instead of qapplication folder, thus the
BLACKLIST file for Android tests needs to be in "test" folder
instead.
Task-number: QTBUG-87666
Task-number: QTBUG-87025
Change-Id: I065072fa8a030cf9d15e057869e74a8c736c80ab
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These tests are failing with "java.lang.UnsatisfiedLinkError: dlopen
failed: invalid ELF file" at the start, excluding them now to enable
Android testing until they're fixed later.
Task-number: QTBUG-87671
Task-number: QTBUG-87025
Change-Id: Ida7d7158fccdc31df1f9689f77fde832964d732f
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
These look like leftovers (API flaws).
Construction of QFileInfo from QString (or similar) should be not
implicit, as QFileInfo construction is expensive (might hit the file
system), and this may have users overlook APIs (for instance build a
QFileInfo out of QDirIterator::next(), instead of using ::fileInfo();
using QDir::entryList instead of entryInfoList; etc.).
Leave an opt-out mechanism to ease porting.
Fix a handful of usages around qtbase, with at least a couple of them
likely to be actual "sloppy" code.
[ChangeLog][Potentially Source-Incompatible Changes][QFileInfo] Most
QFileInfo constructors are now explicit. The
QT_IMPLICIT_QFILEINFO_CONSTRUCTION macro is provided to keep old code
working.
Change-Id: Ic580e6316e67edbc840aa0c60d98c7aaabaf1af6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QChar should not be convertible from any integral type except from
char16_t, short and possibly char (since it's a direct superset).
David provided the perfect example:
if (str == 123) { ~~~ }
compiles, with 123 implicitly converted to QChar (str == "123"
was meant instead). But similarly one can construct other
scenarios where QString(123) gets accidentally used (instead of
QString::number(123)), like QString s; s += 123;.
Add a macro to revert to the implicit constructors, for backwards
compatibility.
The breaks are mostly in tests that "abuse" of integers (arithmetic,
etc.). Maybe it's time for user-defined literals for QChar/QString,
but that is left for another commit.
[ChangeLog][Potentially Source-Incompatible Changes][QChar] QChar
constructors from integral types are now by default explicit.
It is recommended to use explicit conversions, QLatin1Char,
QChar::fromUcs4 instead of implicit conversions. The old behavior
can be restored by defining the QT_IMPLICIT_QCHAR_CONSTRUCTION
macro.
Change-Id: I6175f6ab9bcf1956f6f97ab0c9d9d5aaf777296d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
The test function only runs on X11, and this might help with the
asynchronous nature of the client/server architecture, also for
drag'n'drop.
Change-Id: I38db9104e304e57c36f84932d13f8dfae7452883
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
QLatin1String::arg (and QStringView::arg) only support string-like
arguments, and QLatin1String("%1").arg(123) does *not* produce
the string "123" -- 123 gets routed through the QChar(int) constructor
instead. Fix by using QString.
Change-Id: I96371a15e1af957ef8133e30e79eb3e22b3e9d32
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QStyle::styleHint returns int, and that int was simply used to
build a QChar representing the "password mask" character.
Enforce that it actually fits and then do an explicit cast.
(In general, of course, this is an API flaw; styleHint should
somehow return a QString for this use case).
Change-Id: Ifb6181b229b91cc84859cb9b9d57e21d6748c31a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: David Faure <david.faure@kdab.com>
We want to re-enable Android tests in QTQAINFRA-3867. However,
many tests are failing already preventing that from happening.
QTBUG-87025 is currently keeping track (links) to all of those
failing tests.
The current proposal is to hide those failing tests, and enable
Android test running in COIN for other tests. After, that try
to fix them one by one, and at the same time we can make sure
no more failing tests go unnoticed.
Task-number: QTBUG-87025
Change-Id: Ic1fe9fdd167cbcfd99efce9a09c69c344a36bbe4
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This makes it feature comparable with QAction, and makes it possible
to use as a backend for QAction, and fixes a few missing alternative
keybindings in qtwidgets.
Change-Id: Iaefc630b96c4743fc5ef429dc841870ddd99fc64
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
All QFontDatabase APIs are static, use them accordingly.
Task-number: QTBUG-88114
Change-Id: I0e4a7508646037e6e2812611262eed8b6d7ad3de
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Let the new created embedded QLineEdit use the palette from QCombobox,
when calling [setEditable(true)]
Fixes: QTBUG-81533
Pick-to: 5.15
Change-Id: Ia406dd8122a348e185f0e94d027646b95eeaa76e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
CMake builds are special and need to know the path to the source dir.
This is handled automatically by QTEST_MAIN, but tst_qapplication
doesn't use QTEST_MAIN. Thus we need to call
QTEST_SET_MAIN_SOURCE_PATH manually.
Task-number: QTBUG-87137
Change-Id: Ib2c461f0da0a3d9a2f571f37476b750a606065f7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
[ChangeLog][QtCore][QLocale] Deprecated several Language and Country
aliases, ready for removal in Qt 6.0, in favor of their newer names.
Task-number: QTBUG-84669
Pick-to: 5.15 5.15.2
Change-Id: Iebaa0a5a77bfa12f7014de53fab4a25b5f1cc92c
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Testing the mouseMoveCount before XFAIL'ing before then testing the
mouseRelaseCount was anyway wrong.
Change-Id: I666f143ff15088562fc63f833f5785f870de6f26
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When converting the year as an integer via the locale then it can add
in group separators which would not be desired here. Therefore it should
be converted via the QDate approach to get the right output for the year.
Fixes: QTBUG-86307
Fixes: QTBUG-85966
Pick-to: 5.15
Change-Id: I092bd1e5f69e544843fd5f28c96b94c9066490c5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's been obsolete for a long time already. Make sure
the compiler now warns about it and remove all remaining
uses in qtbase.
Change-Id: I0ff80311184dba52d2ba5f4e2fabe0d47fdc59d7
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
on Ubuntu 20.04
There is some issue with the glib event dispatcher.
Task-number: QTBUG-87728
Pick-to: 5.15
Change-Id: I4d64206898dd2c8356d5fc51a68c2e5759b38aac
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@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>
Index of the last visible tab was not updated, if a new tab was inserted
after the current tab and before the last tab.
When the new tab is inserted before the last visible tab, the index of
the last tab increments by one.
When the new tab is inserted after the last visible tab, then the newly
inserted tab becomes the last visible.
Fixes: QTBUG-86898
Change-Id: I2f4b7f705261ec35a5aa7b883ecdddba25f007b7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Extract checkPositions helper function to re-use in the new test.
Task-number: QTBUG-86898
Change-Id: I5c8241b5701cd8c8c3e21607c385217d4b75e728
Reviewed-by: Jordi Pujol Foyo <jordi@vikingsoftware.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Silence the warning, and test event delivery in addition.
Change-Id: I59c49a2ac70ecd32429116b76643700a7ad5ce3e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
If a model only allows MoveAction, then calls in the view/widget subclasses'
dropEvent implementation to set the event's drop action to CopyAction
will fail. QAbstractItemView will then remove the item when QDrag::exec
returns.
Instead of abusing the event actions for this, store explicitly that the
dropEvent implementation already moved the item. If the flag is set,
don't remove the item.
In QListView, which uses moveRow to move items in the dropEvent handler,
handle the case that the model might not implement moveRows. In that
case, or when dropping an item onto another item (to overwrite data),
fall back to the default implementation of QAbstractItemView. Sadly, it
is impossible to know whether a model doesn't implement moveRows, or
whether the move failed for other reasons, so this requires a bit of
extra special case handling. QListView in IconMode is particularly odd
in that it moves the item in the view, but not in the model.
This follows up on fd894fd68e and fixes
additional issues discovered during debugging. Extend the existing unit
test; since drag'n'drop runs a modal, native event loop on most systems,
it still only runs on the Xcb platform.
Change-Id: I6c5377e2b097c8080001afe904d6d3e4aed33df4
Pick-to: 5.15
Fixes: QTBUG-87057
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
tst_QApplication::sendEventsOnProcessEvents() and
tst_QItemDelegate::editorKeyPress()
There is some issue with the glib event dispatcher.
Task-number: QTBUG-87137
Pick-to: 5.15
Change-Id: I79a983192edef3c3560a4296cc9dea2dfc2ee1b0
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@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>
Also correct two comments which lied about the year being tested.
Change-Id: I5be491a2b2c1e0c3b49d6ff9a8de852e17321cff
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
This time based on grepping to also include documentation, tests and
examples previously missed by the automatic tool.
Change-Id: Ied1703f4bcc470fbc275f759ed5b7c588a5c4e9f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
In tst_QDateTimeEdit::dateEditCorrectSectionSize(), only the final
displayed date was tested; many of the tests checked day of week (by
name), which might well match despite actually selecting a different
date than the one intended. So test the date is as expected, too.
In the process, tidy up the code, give values more informative names,
turn a trivial static function into a lambda.
Change-Id: I0491159e9ee2f3cfdcf8a194c723be92c190c2a8
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Fix remaining places that still exercised it.
Task-number: QTBUG-85700
Change-Id: I84562f53439197141343831c0b9f88983689e6bf
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@qt.io>
QAbstractItemModel::canFetchMore and fetchMore implementations might only
add a few rows to the model each time they are called. The item views don't
generally expect that, and don't call fetchMore repeatedly, even if there
would be room in the itemview for more data. This problem cannot be
generally solved for all item views, as it would require in repeated expensive
laying out of items.
For nested indexes in a treeview however, we can try to fetch enough child
rows to populate the screen when the item is laid out by repeatedly
calling canFetchMore and fetchMore. To calculate how many items have space,
apply the same heuristics as in the scrollContentsBy implementation to
guess the number of items that can fit into the viewport.
Created test case for the fix.
Done-with: Doris Verria <doris.verria@qt.io>
Fixes: QTBUG-85366
Pick-to: 5.15
Change-Id: I54f95552993873dd4cba80b0f70f4db9d98ddc1d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Use a QScopeGuard to fix its restoration of left-to-right mode after completion.
Change-Id: I5ac1e44629e72d993f2d5ba6586b86508d57cdaf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Andreas Buhr <andreas.buhr@qt.io>
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Change lots of code to avoid the deprecated operator+() or implicit
casts to int.
Change-Id: I0c343cd5b28603afdf1214eefb85e928313345e2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If it does not add item,the currentText should return empty string
Fixes: QTBUG-86580
Pick-to: 5.15
Change-Id: I54c3a8b7ececfb1e62bcd7ac592feccaff3f8b48
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Current implementation of QLineEdit uses the "edited" bit-field flag to
prevent unnecessary emissions of editingFinished() when a line edit
loses focus but its contents have not changed since the last time the
signal was emitted; however, this flag is only cleared when the signal
is fired due to focus loss and not when the Return/Enter key is pressed.
This causes an unexpected double emission of the signal when focus is
lost following a press of the Return/Enter key if the line edit's text
was not further altered between the two actions.
This change includes the Return/Enter press as a trigger for clearing
the "edited" flag to make editingFinished()'s behavior more consistent
and expected. Prevents slots in user code from triggering twice in
situations where the line edit's current contents have already been
handled, but still allows the end-user to force an emission of the
signal via Return/Enter.
The effect of the "edited" flag on the signals behavior has also been
noted in the signal description as it was previously omitted.
[ChangeLog][QtWidgets][QLineEdit][Behavior Change] Pressing the
Return/Enter key in a QLineEdit will now also prevent editingFinished()
from firing due to focus loss if the contents of the line edit have not
changed since the last time the signal was emitted.
See - https://forum.qt.io/topic/116902/
Change-Id: I11aadd45341337b7852da8cf5802c7c9efdd614d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Modify special case locations to use the new API as well.
Clean up some stale .prev files that are not needed anymore.
Clean up some project files that are not used anymore.
Task-number: QTBUG-86815
Change-Id: I9947da921f98686023c6bb053dfcc101851276b5
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Clean up the state of the projects,
before changing the internal CMake API function names.
Task-number: QTBUG-86815
Change-Id: I90f1b21b8ae4439a4a293872c3bb728dab44a50d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
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>
Current implementation of QProgressDialog always calls
QCoreApplication::processEvents() when the user calls
QProgressDialog::setValue() if the PD is modal. For most cases this is
fine, but when using a Qt::WindowModal PD with setValue() connected to
a signal in another thread using Qt::QueuedConnection a reentrancy
issue is present if setValue() is triggered too frequently as the
execution of its previous call may not have finished. If this happens
too many times in a row a stack overflow will occur.
Current documentation notes this potential issue but offers no way it
avoid it while still using QProgressDialog (user must implement a
custom dialog) without resorting to using Qt::BlockingQueuedConnection,
which unnecessarily reduces performance.
Introduces the boolean reentrancy guard "processingEvents" that is
checked before calling QCoreApplication::processEvents() in a modal
PD when setValue() is used. It is set before the first call to
processEvents() and cleared after that call returns. This ensures that
only one invocation of processEvents() is possible from within
setValue() at a time, and thereby minimizes iterations of the main event
loop and eliminates the aforementioned stack overflow condition.
See - https://forum.qt.io/topic/118292/
Fixes: QTBUG-10561
Pick-to: 5.15
Change-Id: Ifa9b91cbb66881981356954ead0906bdc91fab60
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
The reason for this bug is that after the TextItem loses focus,
the focusItem in QGraphicsScene is already empty.
When QGraphicsScene responds to the inputMethodEvent event again,
since focusItem is already empty,focusItem will no longer deliver events.
Fixes:QTBUG-85088
Pick-to:5.15
Change-Id: I329054333c2adec133d35318761612aca3afcf0d
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QToolButton::initStyleOption is const. Apply some DRY while at it.
Change-Id: If29a52e828bbc2aa58df2852c4c434545acfef3e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Adjust to changes to QIcon::pixmap, QMetaType::type, and
QAbstractItemView::itemDelegate.
Change-Id: I9eb0331ef899131afc86c33f27feeee76331ffc8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Change the rounding of negative half values to match standard C++
round, this will also allow future optimizations.
Change-Id: I8f8c71bed1f05891e82ea787c6bc284297de9c5c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Amends f9940b15f7, which
amended 6e1d70ae12.
The bevel of the button is not defined by the contentsRect, but by the
borderRect that the stylesheet style calculates.
Change-Id: I9a0d5bf29a06ce2270014f0d144e33cc3a1a7473
Pick-to: 5.15
Fixes: QTBUG-86587
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
As per ### Qt6 comment. Also rename the LibraryLocation enum
to LibraryPath.
Change-Id: I556025a19c5bcdf2ff52598eaba32269522d4128
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This change shouldn't matter much to widgets, since style names
there are case insensitive. But for controls style names are
case sensitive, and in that case, "macOS" looks more correct.
Change-Id: Ia1d442bce465692ff58fecba1cc68ecbb2e52549
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
It flaky fails for both normal and reverse cases.
Pick-to: 5.15
Task-number: QTBUG-41341
Change-Id: If6ecd6dc58f131bb67d46a5d508f59b6bb0fd962
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Because we removed public setters from QTouchEvent and QEventPoint in
4e400369c0 and now it's proposed to give
QEventPoint a d-pointer again, the implementation of QTouchEventSequence
needs to start using QMutableEventPoint: being a friend will no longer
be enough, because the member variables won't be accessible in the future.
But because we have separate test libs for Gui and Widgets, it needs to
be further refactored into two classes.
Change-Id: I0bfc0978fc4187348ac872e1330d95259d557b69
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Following the introduction of QKeyCombination, reduce the number
of warnings raised by the test. Drive-by, remove some pointless
math like Qt::SHIFT+0, which does not make any sense and would
actually fail to compile (shortly).
Refactoring the test to fully use QKeyCombination (instead of
ints) is left as a future exercise; some QKeyCombination->int
warnings are still around.
Change-Id: If825bc4c369986623447927bb11493c4f58b544f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Instead of QCoreApplication::quit() directly calling exit(0), which would
leave QGuiApplication and client code out of the loop, we now send the
Quit event, and let it pass through event delivery, before finally ending
up in QCoreApplication::event(), where we call exit(0).
This has the advantage that QGuiApplication can ensure all windows are
closed before quitting, and if any of those windows ignore the close
event the quit will be aborted. This aligns the behavior of synthetic
quits via QCoreApplication::quit() with spontaneous quits from the
platform via QGuiApplicationPrivate::processApplicationTermination.
Clients who wish to exit the application without any event delivery or
potential user interaction can call the lower level exit() function
directly.
[ChangeLog][QtGui] Application termination via qApp->quit() will now
deliver Quit events to the application, which in turn will result in
application windows being closed as part of the application quit,
with an option to cancel the application quit by ignoring the close
event. Clients who explicitly want to exit the application without
any user interaction should call QCoreApplication::exit() explicitly.
Task-number: QTBUG-45262
Task-number: QTBUG-33235
Task-number: QTBUG-72013
Task-number: QTBUG-59782
Change-Id: Id4b3907e329b9ecfd936fe9a5f8a70cb66b76bb7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
