QButtonGroup::addButton() automatically assigns a negative id when no id
is given. This logic did not work out when a button with a positive id
was added beforehand.
Add a check to make sure to always return an auto-assigned negative id.
Pick-to: 6.7 6.5
Fixes: QTBUG-129398
Change-Id: Ieadfa44c4b145184a5473713591f4c111a5dafa4
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 772d374ce715de9caaae4f026594d49f6da28dec)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If you right-click to open a context menu, followed by another
click to close it again, without moving the mouse, it can
happen that the menu item under the mouse will trigger.
This is especially prone to happen if Qt has a large scale
factor and the number of menu items is high, since then the
menu has to move a bit up to make room for as menu items as
possible on the screen.
This patch will reuse the already existing hasMouseMoved()
function to avoid triggering a menu item if the mouse hasn't
moved. This will make sure that the user won't trigger a menu
item by accident when instead trying to close it.
Fixes: QTBUG-128359
Pick-to: 6.7 6.5 6.2
Change-Id: Ie4d73ee2031d1159dd6c003124869004b4928d18
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
(cherry picked from commit dc1d3abd7e852829b9bc81c1ba9565f40147402d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
on Ubuntu 24.04 GNOME Wayland
There is a bug in GNOME 46.0 on Ubuntu 24.04 Wayland when showing
a maximized or fullscreen window.
Task-number: QTBUG-129361
Change-Id: I5291439dd9e1ba78cf403a0272ecbd8c83d2f94f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 649794fddf9c1d1c96b271de3b29b3b67593dff6)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This depends on 9eb06a2848 .
This follows bc7821764b4d50fbb4e0ca1b84f85980ce15eeb0 and
5709baea2c261f77f955ab76c074a39c9c3993aa.
There are lots of work to remove QApplicationPrivate::setActiveWindow()
in test code, see also QTBUG-121488. We need to adapt them for Wayland.
Task-number: QTBUG-125446
Task-number: QTBUG-121488
Change-Id: I093568c1d89de31c3893d3c7b139f1db33579633
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit f42979cf6937c78c412fcfa25ec011fb66b48132)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
* tst_QListView::styleOptionViewItem()
* tst_QTreeView::styleOptionViewItem()
There is a bug in GNOME 46.0 on Ubuntu 24.04 Wayland when showing
a maximized or fullscreen window.
Task-number: QTBUG-127920
Change-Id: I4136a97441870a769814a483c0f91aeacd830651
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 5d71f4680df30674b8615b9b9a6b418f0a1c0864)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QTest mouse emulation doesn't support drag & drop on wayland.
This is why all tests fail, where dock widgets are undocked by mouse.
Move skipping in the qCreateFloatingTabs macro, where possible.
Remove skipping where possible.
Fixes: QTBUG-129362
Change-Id: Ic71529f34b8bc39864c9eccadc2aff7b6d426ca8
Reviewed-by: Liang Qi <liang.qi@qt.io>
(cherry picked from commit 597f4bd4734e8a165929bc163ac910f44ba7a1e7)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The helper function shows the main window and uses the
QApplicationPrivate::setActiveWindow() antipattern afterwards.
Use qWaitForWindowExposed() instead.
Task-number: QTBUG-129362
Change-Id: I915c5f8221e4e289950e917ad9c4fc2a7f5b9987
Reviewed-by: Liang Qi <liang.qi@qt.io>
(cherry picked from commit 899c89c8d71d90b30c21b688cfe6b62868ad1ee9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QWindowPrivate::forwardToPopup() sends key events with
QCoreApplication::sendEvent(), which sets QEvent::m_spont to false.
That makes key and pointer events sent to popups appear synthetic,
while they are sponaneous if sent to other widgets.
The method has been newly implemented in the course of moving
popup handling from QApplication to QGuiApplication.
Make current behavior consistent to the behavior prior to
e4ef0f03e6.
Since events are always spontaneous, use
QCoreApplication::sendSpontaneousEvent() instead.
Add a test function to tst_QComboBox to Verify, that key events
- are sent directly to the popup
- not seen by the window
- appear as spontaneous.
This amends e4ef0f03e6.
Fixes: QTBUG-129258
Pick-to: 6.8.0
Change-Id: Iff61b98b290f6483948007b5f12b19393759d9db
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 3fbae61ea245291cb4c34e9126562c307741a600)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We use pathconf in some of our tests to determine if the file system
on Darwin is case sensitive. But pathconf returns -1 if the case
sensitivity can't be determined, with errno set to ENOTSUP.
The convention in this case is to treat the file system as not being
case sensitive (as reported by NSURLVolumeSupportsCaseSensitiveNamesKey
and VOL_CAP_FMT_CASE_SENSITIVE in equivalent APIs), so we need to check
explicitly for a return value of 1.
Change-Id: I1107e849babd8813da3b148c92494e8e35a32d36
Reviewed-by: Liang Qi <liang.qi@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit bd3aabf38454087a96a17ff0130d7f5c2b2b39a9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Setting the opacity on an NSWindow does not result in a paint event.
Change-Id: I6d2780191ba97082f7ca80e2aa1094ccf796fb75
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 3d1ec9ee94bac4222637bc9791ffc4d051c08fbd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The test requires Qt::TabFocusAllControls, so Qt::TabFocusTextControls
and/or Qt::TabFocusListControls, which is the default on macOS, is not
sufficient.
Change-Id: Iaf84c7ba67b978b942f396911048716417c38c03
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 283cfe0b80f83833a549d79e2787f5b936d90236)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The test requires Qt::TabFocusAllControls, so Qt::TabFocusTextControls
and/or Qt::TabFocusListControls, which is the default on macOS, is not
sufficient.
Change-Id: Ideb673f570125c0d73c67a408f3d144f29052ace
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 0a1c5d6e7de13afdb76161a6655d1024df03f454)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
tst_QWidget::render_windowOpacity
- Fails constantly, therefore QEXPECT_FAIL better than blacklist
tst_QWidget::enterLeaveOnWindowShowHide(dialog)
- Known flaky, but doesn't need blacklist as it passes when
rerun is used, no need for actions.
Task-number: QTBUG-128371
Task-number: QTBUG-128372
Task-number: QTQAINFRA-6396
Change-Id: I806419996fedea22628eecf311e977c74066d748
Reviewed-by: Tero Heikkinen <tero.heikkinen@qt.io>
Reviewed-by: Dimitrios Apostolou <jimis@qt.io>
(cherry picked from commit 975b4c078036427d2bf7026f1ba50ad095d83172)
Reviewed-by: Tony Sarajärvi <tony.sarajarvi@qt.io>
The test is using QCursor::setPos(), which also fails locally, unless
the user explicitly gives the test permission to control the mouse.
Change-Id: I6c85c8fd194e178d5df92b7b4cf9c222f8b5a066
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 47b9251de1d722674fd08fe907dff09a0f8ae353)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This depends on 9eb06a2848 .
Done-with: Inho Lee <inho.lee@qt.io>
Task-number: QTBUG-107157
Pick-to: 6.7
Change-Id: I9f4521c27ebc847596a94eed0c9116d71905def2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit bc7821764b4d50fbb4e0ca1b84f85980ce15eeb0)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
- As explained in
https://blogs.kde.org/2009/03/26/how-crash-almost-every-qtkde-application-and-how-fix-it-0
creating dialogs on the stack is a bad idea, if the
application or the dialog's parent window can be closed
by means other than user interaction (such as a timer or
an IPC call). Since we cannot know whether Qt is used to
build such an application, we must assume it is, create
the dialog on the heap, and monitor its lifetime with a
QPointer.
Long time ago instead of using manual resource management,
QAutoPointer was added to fix the crash problem for QInputDialog.
The same fix now is being applied for the rest of QDialog classes:
QColorDialog, QFileDialog, QFontDialog.
Documentation warnings about deleting the parent are not actual anymore. Deleted.
Pick-to: 6.5
Task-number: QTBUG-54693
Change-Id: Ib7cc0575ea25f392a295538e21de9015dc49ebe4
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
(cherry picked from commit 81d55f772892445686862e49d0a6092668f8c725)
Implemented the virtual method moveRows to allow row movement.
Used it for the case of sorted insertion.
Heavily based on QListModel::moveRows and its unittest.
[ChangeLog][QtWidgets][QTableWidget] Implemented moveRows in model.
When sorting is enabled, setItem() now moves the row to its
sorted position, emitting rowsMoved rather than layoutChanged.
Task-number: QTBUG-69807
Change-Id: I62a150cca4e5b7d982f2359a6d8c248494528cac
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
(cherry picked from commit f951c11586081efea108ea5b6a7028c672e12c2a)
When QFileDialog::HideNameFilterDetails is set, the combobox does not
show the complete filter but only the filter name. Therefore we can't
use the value from QComboBox::currentText() when returning the current
selectedNameFilter()
Fixes: QTBUG-127924
Change-Id: I8feb894e5336f2899b42d798558a3c9380669938
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 92e650832d425944037ad6ad3c1d46667f62f454)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The way QMainWindow handles dock widget separators is a bit evil. They
are real QWidgets, added as direct children of the QMainWindow, but
painting and mouse interaction is handled by a hook into the QMainWindow
events, via QMainWindowLayoutSeparatorHelper::windowEvent(), which
is called at the start of QMainWindow::event().
For reasons unknown, we also raise() these separator widgets, which
means they are always at the top of the child window stack of the main
window. This is problematic for the situation when a QToolBar has an
expanded overflow-menu, which is also raised(), but where we end up
raising the separators on top of the toolbar again. As a result the
toolbar gets leave events when we hover one of the separators, even
if the toolbar menu is overlaid the dock area, resulting in the menu
closing.
We don't see this visually, as the separators are drawn via the hook
mentioned above, which happens before QMainWindow draws any of its
child widgets, like the toolbar.
Fixing this requires us to selectively place the separators below
any expanded toolbar each time we raise a separator, so that we
respect the request of the toolbar to be on top, while still
ensuring that the separators are above any of the dock widgets.
Unfortunately the QMainWindowLayoutSeparatorHelper hook also
processes mouse move and click events, resulting in the cursor
changing shape when hovering the separator, even if the toolbar
menu is over it.
To fix this we amend the logic of finding a separator widget
based on the mouse event position to also querying the QWidget
childAt() function, and if we are over a tool bar, we bail out
instead of looking for a separator on that position in the dock
area layout.
As the special separator logic in QMainWindow is conditioned on
the style returning 1 for QStyle::PM_DockWidgetSeparatorExtent
the test checks for this, and skips if another style is in use.
So far only the macOS style is affected by this. See the original
change in fba33a6bbc09bb278df75829d8d705863d40a6a3.
Fixes: QTBUG-124733
Pick-to: 6.5 6.2
Change-Id: Ifc741336bd9725ef0fea9f0474e27b7481f3a183
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 3d99f90b50ab22ef5ab4433c57f9ee584a0a7cae)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The test function renders a pixmap into a widget that is never shown.
It checks for a crash, without failing or passing.
tst_QWidget::render_graphicsEffect() tests the same code path.
Remove the unneeded test function.
Change-Id: I1b64e0466c5a133deec28d0f74ef5acd9858e1ea
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit dfdcb90ffdec0c3a4f7c1c5c59dfba5c04b8c521)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When setting the current index through the related model's
QItemSelectionModel::setCurrentIndex(), the selection can also change.
However, attempting to shift-select after doing so would produce
an unexpected selection, because the internal variable that keeps
track of the start index of the current selection would still have
its old value.
This change moves where said variable is set: instead of doing that
in QAbstractItemView::setCurrentIndex(), it is now done inside the
currentChanged() slot instead. This slot will get called both when
the selection is modified through the QAbstractItemView class itself,
as well as when it's modified from the outside (e.g. from the model).
Pick-to: 6.7 6.5 6.2
Fixes: QTBUG-127381
Change-Id: I6d38320e656aa5a102ce079604590672c88ecad1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit fb2d64bc57aadf5bf140c72cf7eb2a5f391b7d55)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Initially the function was used as a helper function for QWidget,
implemented in da55a1b041. But with
e0bb9e81ab we started overriding it
e.g. QDialog. This "worked" because QDialog itself would call the
private helper, but left a footgun when called via a plain QWidget
pointer, as we did in 5ba0982b28.
That specific instance of the problem was solved by the change in
fc4c6fb5f6bd6bd63b13f1f8b5b7a7289a5fd230, but the trap still exists.
To ensure we can use the function in a polymorphic context in the
future we make it virtual.
Task-number: QTBUG-127806
Change-Id: Ic0810c5439b1e696cfbf199e701f41217acc5742
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 1a0f056f318417ba5e54c8110257b75cf5537acb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
on Ubuntu 24.04 GNOME Wayland.
There is a bug in GNOME 46.0 on Ubuntu 24.04 Wayland when showing
a maximized or fullscreen window.
Task-number: QTBUG-127920
Change-Id: I15e1f6b9bbf27d92cd106318ac44c33fdabfa3a0
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit f31bce32cdb50eb02bffc690e3ba7cc6b986915e)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
6c036012b5f2304a05af29f29daa7582603f79ae added a case branch to a
switch before the break of the previous case.
Amend the commit and add the missing break.
Task-number: QTBUG-127641
Task-number: QTBUG-125149
Task-number: QTBUG-122747
Pick-to: 6.7 6.5
Change-Id: I3f2b3e07db463b72fa99af493f40cbc1a783f1ed
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 1d409c0854d664bafc2a35b33cb73129a51c947a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As a result of c956eb8edd we are now
reparenting QWindows managed by QWidgets when the widget itself or
any of its parent widgets are reparented. When reparenting a child
widget from being a child to a top level, or top level to child, we
need to know the new top level state to determine if the QWindow
should have a QWindow parent or not. As the window flags of the
widget are in flux during the reparenting, we were using the new
window flags of the reparented widget to determine this.
However, for QWidget children of the widget that's being reparented
we can't use the window flags of the reparented widget. We must use
the flags of the child itself. These flags are not in flux, so we
can use QWidget::windowFlags() directly.
Failing to propagate the child widget window flags was causing us to
lose the transient parent relationship to its parent QWindow for
popup windows.
Fixes: QTBUG-127641
Fixes: QTBUG-125149
Task-number: QTBUG-122747
Pick-to: 6.7 6.5
Change-Id: I6dbc5ff5ad019b0f9188516ff3d645e860a9627b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Volodymyr Zibarov <gogan419@gmail.com>
(cherry picked from commit 6c036012b5f2304a05af29f29daa7582603f79ae)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
styleOptionViewItem() sometimes fails due to a very small widget size
even when using showMaximized(). This might be due to a mis-configured
vm scrren size or similar. To make sure that all 4 rows are properly
painted set the minimum width to a reasonable value and also resize the
sections appropriately.
Pick-to: 6.7 6.5
Fixes: QTBUG-126494
Change-Id: I9956d3119be1ba9e0fb33e4e7b30f40b01b017a5
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit f7662366b120c1cacd43a2c2ae36b03f578d7478)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This amends 91079e64d8 .
It needs to have a QGuiApplication object before the check.
Task-number: QTBUG-123172
Change-Id: I51929431e69e4584c46e2dc08ca9c33b48b900c6
Reviewed-by: Inho Lee <inho.lee@qt.io>
(cherry picked from commit e743931294d9d9c4e5a27d2644fd1cd354ce56cb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
QTest::qWaitForWindowActive() isn't supported on Wayland, however in
these tests what's required is a specific widget having keyboard focus.
Pick-to: 6.7
Change-Id: Ib47431351f60f4ee31d67563ce1892dc2e8149eb
Reviewed-by: Liang Qi <liang.qi@qt.io>
(cherry picked from commit 3d3faa128508b6eb5fd656330cf3be0097844abb)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This reverts commit 99c8ffb9f2. It fixed
QTBUG-104201, which in essence pointed out a state mismatch between
widgets and platform windows on Linux (X11 and wayland). Mismatches
occurred in the margins between calls to QWidget and async screen
rendering: While the widget layer reported the expected size, the
platform layer did so only after the rendering thread had finished.
As mentioned in the comments of QTBUG-104201, the state mismatch is
predictable, temporary and consistent.
By bridging the time gab, an async operation was made to look
synchronous. That gave more comfort to application developers. By
oversight, it broke code that relied on the platform window state
reflecting physical rendering. This has caused QTBUG-126479 as a
regression.
Both purposes can't be served at the same time: The platform window
state either reflects rendering, or the expected state. It's therefore
justified to revert.
Reason for revert: <Causes QTBUG-126479>
Pick-to: 6.7 6.5
Fixes: QTBUG-126479
Task-number: QTBUG-104201
Change-Id: I22380a6a463822a1cb4be90a44d2775954c7ca82
Reviewed-by: Liang Qi <liang.qi@qt.io>
(cherry picked from commit 7d7be38d95eb82ef3e0be5250440072d8b5bc4b2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When the top level window that a QWindowContainer is in is about to
be destroyed the QWindowContainer must reparent the contained window
into a dummy window, as otherwise the destruction of the top level
will bring down the contained window as well.
We were notifying the window container about this situation when
the window container was moved from being a top level itself, to
being a child widget, but did not have any logic for other ways
the window container could lose its parent QWindow.
An example of this was when RHI-needs would result in recreating
the top revel with a different RHI backend.
We now have a last minute call to toplevelAboutToBeDestroyed in
QWidgetPrivate::deleteTLSysExtra().
Fixes: QTBUG-126303
Pick-to: 6.7 6.5
Change-Id: I5b14e156956ae76a8f53cac31904eaadee9e791f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 006cbf658ea1f5986bbe1baafa7c146780320661)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
If a span is selected, we used to assume that rows and columns might be
moved, and made a selection with a range for each cell in the span. This
resulted in very large selection models.
We already had optimized the case that we didn't have any moved rows or
columns, skipping the mapping for the respective (or, usually, both)
directions and just making a single range. Apply that same optimization
for the case where a span exists and intersects with the selection area.
Avoid code duplication by only updating the top/left/bottom/right values
depending on the configuration of the table, and then create the
selection based on those.
Adapt the test case; we now get a single range, even when a span is
present, and the range includes all cells included in the span. Add a
debug streaming operator in the test case, as there is none implemented
in QTableWidgetSelectionRange, to ease debugging. That operator can
become a hidden friend of QTableWidgetSelectionRange in a follow-up
commit.
Pick-to: 6.7 6.5
Fixes: QTBUG-119076
Change-Id: If699463944ca2abaed8f93a2cd3ea30f33b79145
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 57d209c4fdea4766f24479a1f20c2975d34a1a0f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The test checks if paths in /etc and /home are properly completed.
/etc and /home do not exist on VxWorks.
Use /tmp instead.
Pick-to: 6.7
Task-number: QTBUG-115777
Change-Id: I6203fabb003a9a81eb4cdb666a972f47a53f06d6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit 843f8fb043a0812ab01f0a378be1a821f2e1534d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When QGuiApplicationPrivate::processTouchEvent() sees that the
touch event was not handled, and calls processMouseEvent(), the latter
uses the QEventPoint with pointId 0 regardless of the original
touchpoint ID. Now it updates the persistent QEventPoint from the
original touchpoint so that a double-click event will not be ruled out
because of the timestamp delta or position delta (movement since press)
being too large.
Fixes: QTBUG-125993
Pick-to: 6.7 6.5
Change-Id: I8e9b007818107ac2329454e0ccfb2ac9e506b617
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 2a0b907f11b9c0ad46322ba06482861423246d93)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>