If widget A starts at y=0 and widget B starts at y=19, when the mouse
moves from y=15 to y=18.6667, the code was doing childAt(p) with a
rounded QPoint y=19 and finding B, but then the relative coord for B
was set to -0.33333 so B wasn't under the mouse and didn't get an enter
event (and since it's now the "last receiver", it doesn't get one later
either when y is bigger).
Add QWidget::childAt(QPointF) to fix this.
Fixes: QTBUG-128391
Change-Id: I76d4b711a8297648780bdd079eb67405ab12be14
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 40bde8a572bd8ed039d3f5a5ab99b281de7410bd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The fusion style was the only style which checked for an undocumented
property '_q_isComboBoxPopupItem' to determine if a CE_MenuItem should
ignore the drawing of a checkmark. Remove it to be in sync with all
other styles.
Task-number: QTBUG-127536
Change-Id: I6f0af2219a2da1d8d1920cb95c233fb3e32a21ab
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit a3568a19eaba98697854db50af5546c09464ca73)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The combobox dropdown items are drawn as CE_MenuItem elements. Those
elements may have a checkmarks but not when we draw them within a
QComboMenuDelegate. Therefore add the same check as for fusion style to
avoid drawing a checkmark in a QComboBox dropdown menu.
Fixes: QTBUG-127536
Change-Id: Ib22046b018fdf36eb26518899d2427d40b0110b8
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit c2d56961394cea799b0caa241c3517ed88aa6c66)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This is only available when calling setDragDropOverwriteMode(false)
so this makes no difference in most applications (see implementation
of QAbstractItemView::position).
QTableWidget::dropEvent() was assuming we were dropping onto items
without checking that this was the case, this is fixed here,
and QTableView::dropEvent() is added to handle moving rows,
with very similar code to QListView::dropEvent().
Task-number: QTBUG-13873
Task-number: QTBUG-101475
Change-Id: I96e75da2c0abf6f568edba461735905dee5cb84f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 8e63cf282cb248ddd7fbc908766091659b3a0b22)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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)
The QDoc command `\tableofcontents` was rendered useless by a change
more than a decade ago. Remove the use of `\tableofcontents` as it
serves no purpose, and ensure that the surrounding context still makes
sense for the reader, by removing preceding text that refers to a
non-existing table of contents, such as `Contents:`.
Task-number: QTBUG-128173
Change-Id: Ibb5a6af0e80f70fa487cdf6a7e38009a9ef60cbf
Reviewed-by: Safiyyah Moosa <safiyyah.moosa@qt.io>
Reviewed-by: Venugopal Shivashankar <Venugopal.Shivashankar@qt.io>
(cherry picked from commit cd8244131e2d6fe2c2453ae40213e7f12bff893d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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 static min and max moments of QDateTimeParser are local times.
Now that baseDate() needs to check whether the start of the two-year
century falls between these, and parsing of simply a date or simply a
time (not a date-time) uses UTC, to comparisons involve mapping the
local time to UTC, with the usual associated expense. Do that
expensive operation once on creation of the min and max local times,
so that it'll be cached for use by the comparisons.
This shall also help with other comparisons to max and min, so is of
use even before the introduction of baseDate(), for all that that
change brought the issue to light.
Thanks to Jøger Hansegård for analysis of the profiler data that
revealed the root cause of a significant slow-down.
Pick-to: 6.7 6.5
Fixes: QTBUG-124465
Change-Id: I539c8ae782717635fb722c4573d85bc63073958a
Reviewed-by: Jøger Hansegård <joger.hansegard@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
(cherry picked from commit b6a11a4ee5319366f14c11c7cf3a4f1dbf33cfd5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Remove all \since 4.x comments in widgets/dialogs - this is no longer
of interest.
Change-Id: I4835be8c16363b13615ffc921454e2b5ade295eb
Reviewed-by: Safiyyah Moosa <safiyyah.moosa@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit b5bb8897d0809bae4e414c74420440255fc5b08d)
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>
When the list view of a QCompleter is visible, it receives mouse events.
A mouse press event outside the completer hid it.
If a virtual keyboard was active, it did not receive mouse press/release
events in case the completer's list view was active.
Add a helper to QGuiApplicationPrivate, that detects a virtual keyboard
under a mouse event position, and forwards the event if needed.
Adapt QCompleter::eventFilter() to use the helper.
If a virtual keyboard one exists and a mouse press event occurs inside
it, don't hide the completer and forward the event.
Add handling of mouse release events, and also forward them to the
virtual keyboard, using the helper.
Add logging.
Fixes: QTBUG-126752
Pick-to: 6.7 6.5 6.2
Change-Id: I613523a9c83b319810397770c43b2eb4ae01c31a
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 93ce8f13fc8042eac976a3c911af7d7664e8d5dc)
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
The redundancy in the conditional judgment exists
because QApplicationPrivate::keypadNavigationEnabled()
appears in both conditional branches. Specifically, the
conditional expression can be simplified because
!A || (A && B) is equivalent to !A || B.
Change-Id: I071e349ea4f67a03f89136e2156eb5918a65214f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 792373595d9d9d45f5c43e6a9e3f90c1b7ad54d8)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This leads to an assert in QConcatenateTablesProxyModel::index()
for instance.
Change-Id: Icd0ae1497705484b021067034c0d8f39049c04ed
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 1ba3277b4c79b80788e2d600840876856ec6933d)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A Toplevel QWidget can hold a pointer to the screen where it will
eventually show contents, before a QWidgetWindow is created which then
takes precedence.
The screen member of QWindows is always kept up-to-date when a screen is
removed, but not the contents of a toplevel window. If a widget has
setScreen called but is never shown, it has potentially dangling pointer
which can cause issues in the future.
Pick-to: 6.7 6.5
Change-Id: Ia7c80549e8b3c90a75cdde745487e87ecddaca63
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit d67acf94afffde6a71498be6e30447f3acf7558e)
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>
The high-dpi painting for the buttons in the QMdiSubWindow was broken
for the windowsvista style because an invalid widget was passed to the
paint routines. This lead to a wrong calculation of the devicePixelRatio
and in the end very blurry icons.
Pick-to: 6.7
Fixes: QTBUG-127288
Change-Id: I0f604ddb4faf66a6e850a1504582076f22418fcd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
(cherry picked from commit 8b261a2ad7884f8fe7a93a678c9fce5052e42c98)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Pass the correct arrow rect to the draw arrow function. This amends
0ef5d5dba3e23224c372be9c9f1144c8a73b6a49
Task-number: QTBUG-127104
Change-Id: I78392fb112a0dbf9ac4e034a4dbdc91077b59d24
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
(cherry picked from commit 161015d29f9af500d9c3899f9a6aea26f9ca1827)
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>
qt_add_ui failed for CMake 3.16 and the Ninja generator on Linux,
because it generated empty commands like
... && "" && "" && "" && ""
for targets that don't have AUTOUIC set.
Adjust the generator expressions for those commands to generate the
"cmake -E true" command instead of the empty string.
Change-Id: I03c9eb2e8f14685bccadf4eb74f309bcf152c01b
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit e98517564fa0a87ff030deb1cb05ec51aa231294)
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>
* Remove links to `qt_add_ui` in the qt_add_ui documentation
* Add links for `qt_wrap_ui` and `AUTOUIC`
Task-number: QTBUG-126463
Change-Id: I73c8e406407e3f71bba40e1c41473a17a7f45222
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 2e8d7c552df4ac0987d7756ed4de9f35bb4735cc)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This partially reverts commit 8bd532b1e.
Replacing the std::optional's with real objects led to unwanted
extra allocations, some even in the destructor.
Change-Id: Ib9f949b7d93352c9027ec8a162741d7830e9ec72
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 6f62f25daffafab750f84aec2b90e129e14c2cd9)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Adding or removing close/maximize/minimize buttons to an already
existing QMdiSubWindow is only visible after the window is repainted.
This patch repaints the QMdiSubWindow at the end of setWindowFlags.
Fixes: QTBUG-125778
Pick-to: 6.7
Change-Id: Ibdf136621bf70337a2af29dfcfd10b60dde11e15
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 6520ed0f2567c5a8fd680dccbff59c5ef8fc89c2)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
As part of 5ba0982b28 we started calling
QWidgetPrivate::setVisible instead of QWidget::setVisible when showing
children, to avoid setting ExplicitShowHide.
Unfortunately some widget subclasses wrongly override setVisible to do
initialization, which resulted in these widgets not running their init
code. The documentation clearly specifies to use showEvent or Polish
for this use case, but to avoid a regression we temporarily set a flag
that prevents QWidget::setVisible from setting the ExplicitShowHide
attribute.
We can not rely on simply unsetting ExplicitShowHide after our call
to QWidget::setVisible, as the call might recurse into logic that
checks ExplicitShowHide and wrongly determines that the show is
explicit.
Fixes: QTBUG-126721
Fixes: QTBUG-126218
Pick-to: 6.7
Change-Id: Ibf88340b68cb4fcb20ce3d8ec5b76de0fd2d2551
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit fc4c6fb5f6bd6bd63b13f1f8b5b7a7289a5fd230)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The progress bar drawing only works correct when the topLeft corner is
at 0/0 therefore we have to translate the painter to fix the drawing in
such a case.
Pick-to: 6.7
Task-number: QTBUG-126426
Change-Id: I51086dab65cc0d4a360ee539e59e3f3f4af2a375
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 369b5a3194f69072a961283c4d5e19395e0d8b06)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This reverts commit 10c3dd87d3.
QtWidgets depends on the old QApplication::topLevelAt() behavior too
much, especially for the single top level window case. It's not easy
to be decoupled in this way.
Task-number: QTBUG-113404
Task-number: QTBUG-125878
Task-number: QTBUG-126313
Pick-to: 6.7 6.5
Change-Id: Ica9753bfc85f54ef24ff3db12ea954b06b50b1f0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 04b8b61ce56d552c1240a8f5e3f089edc7b56f52)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The call to destroy() happened in QWindow destructor, after
̃QWidgetWindow destructor had run. This is to late since destroy calls
setVisible which ends up in QWidgetWindowPrivate which accesses
QWidgetWindow.
Calling destroy from ̃the QWidgetWindow destructor makes sure the object
is still alive when setVisible is called.
Tested manually by running the documentviewer demo as
given in the bug
Fixes: QTBUG-126456
Pick-to: 6.7 6.5
Change-Id: I2ca0384c453d59c5ffb9f3588d592701bebf3aa8
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
(cherry picked from commit 9b99361698219a73ce1b54fe56497560e02b2229)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A list view should always expose a table with a single column to
accessibility tools even if the underlying model has multiple columns.
Several functions need to be changed so that they only consider the
model column that was set on the list view.
For a list view logicalIndex() must only consider indexes for the
model column. For valid indexes the logical index is simply the row
because list views have neither row headers nor column headers.
The column count for list views is always 1 (unless the model has no
columns). The child count needs to use the column count of the
accessible table instead of the column count of the underlying model.
child(), cellAt(), selectedCellCount(), and selectedCells() get
separate implementation for list views.
Fixes: QTBUG-33786
Pick-to: 6.7 6.6
Change-Id: I18c604efa2014267bb6e3b68e403e436bdcbc4ce
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit cd00ce4bea6f0386048bd267495433cffe83ab12)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
No need for std::optional<> here - simply use QPixmap/QPicture::isNull()
instead. Also use non-static member initialization instead
initialization list and cleanup the needed includes.
Change-Id: I255e9e068cff1e66fbaf35be51be64228e48ffac
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 8bd532b1e54e220c81cd742fabaa236b1e7679c4)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
Simplify the code - member cachedimage is not really needed as QPixmap
has a scaled() function by itself.
Change-Id: I89cc237ef611f8516588e8b2e7b4056845bc6c69
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit cf0c9de6ed6a4edd6e8e21734e975d2554caa74f)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The tree view widget draws a border for both the decoration area and
the text that accompanies the first column whenever any background
color is set to the row. The background color set for the row
shouldn't affect the border of the decoration area.
This patch fixes that issue by handling the background draw for the
decoration area separately by drawing the background for the
decoration area without considering the configured borders.
Fixes: QTBUG-122778
Pick-to: 6.7
Change-Id: I308998a29d16c910a5370633e5bff18418c96a44
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 3ca615d9735f7ddb8e2ae5c13e5effd419a56300)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
idx.data(role) is much nicer to read than idx.model()->data(idx, role)
As a drive-by, mark some QVariants const.
Change-Id: I00c0a5ac311a03095050b2542a5c396a6c1c2c6a
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
(cherry picked from commit 319cca2e2b8679bc553e8ebf97505f0625ee1c94)
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>
Makes the follow up patch clean to review.
Pick-to: 6.7 6.5
Task-number: QTBUG-119076
Change-Id: I38c2b02876af93ce668ade7bce97b32a9ec2cef0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 71d0ea7d042d61e8d42e9cf2700c439d4337345b)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The behavior that argument was enabling is the default one now.
Task-number: QTBUG-90492
Change-Id: I11711d4c794f0b22169abb595b8ffad2eeb1300d
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
(cherry picked from commit 1ef3bd05eb45d53cdcf92b933603b995283b3432)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
A floating tab is a QDockWidgetGroupWindow, containing a
QMainWindowTabBar, with each tab representing a dock widget.
Users can unplug dock widgets from the floating tab, by dragging
the respective tab of the tab bar. Such a drag triggers an internal
move of the tab at first. When a tab is dragged outside the tab
bar, the dock widget is unplugged and becomes floating. It is
supposed to be placed with its title bar under the mouse cursor,
so the drag can seemlessly continue and move the newly unplugged
dock widget.
To position the dock widget's title bar under the mouse cursor,
QTabBarPrivate::dragStartPosition was deducted from the mouse move
event's global position.
QTabBarPrivate::dragStartPosition holds the the position of the tab
at the time when the drag had started. It is used, to restore its
position, when a move is aborted. Using this point to calculate an
unplug position is wrong. It results in random positions, away from the
mouse cursor, especially if the tab has been dragged over a longer
distance.
Implement a helper function, that positions the dockwidget with its
title bar under a given position.
Use QDockWdget::titleBarWidget()->rect.center(), if it has a title bar
widget.
Otherwise, use QApplication::startDragDistance() as an offset on the
short side and the middle of the long side as coordinates.
The behavior can't be autotested, because
- mouse move emulation doesn't follow a line.
- drag and drop can't be tested on Windows platforms
The dockwidgets manual test (former dockwidgets example) can be used
for verification.
Fixes: QTBUG-126084
Pick-to: 6.7 6.5 6.2
Change-Id: I276cb6ade3944921d747bf5e73b7b6fe402d10c5
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 37861df8e5a41f0f654e15776c631da95ba26c03)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The static QMessageBox APIs taking button texts instead of standard
buttons promises that the return value is 0, 1, or 2. After the change
in b30121041c the return value of exec
for custom buttons was changed (as the documentation says its an opaque
value), which unfortunately affected the deprecated functions.
To fix this, we use the index of the clicked button in the custom
button list, to restore the previous behavior of the deprecated
APIs.
Fixes: QTBUG-125858
Pick-to: 6.7
Change-Id: I96d39e42b64e2b55eab07e2f15df71b94cfe3e6d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
(cherry picked from commit a428c6933565ee8368367534cf306ccc6957f5a5)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
(cherry picked from commit 5b151ea2d23dc3834180d3ec6495ac5d99cae550)
When invoking setWindowFlags with a QStyleSheet and QProxyStyle set, a
repolish is recursivly done creating a second QStyleSheetStyle in
QWidgetPrivate::inheritStyle due to not cleared WA_SetStyle window flag.
This leads to a use-after-free in the then following recursive call to
QStyle::polish. This patch uses the previously create QStyleSheetStyle
in the case that there is already a QStyleSheetStyle for the proxy.
Fixes: QTBUG-125513
Pick-to: 6.7
Change-Id: I841bf68143e893d74ab7373b7a3d3d4ee2bce514
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
(cherry picked from commit 26af5d1854336907d6d7fd6aa1ad060f6d38ce1c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The RHI support and compositor in QPlatformBackingStore were
tied to the surface format of the top level window owning
the backing store.
This meant that inserting an RHI-enabled widget (QRhiWidget,
QOpenGLWidget, QQuickWidget, QWebEngineView) into the widget
hierarchy required recreating the top level window with a
matching surface format that could support the RHI composition.
It also meant that we could not have two RHI enabled widgets
with different surface format requirements (Metal and OpenGL
for example) in the same top level widget hierarchy.
The recreation of the window had various visual side effects,
such as temporarily switching out of full screen state, or the
widget rendering a frame of black, as well as more serious
problems such as not correctly restoring the window geometry.
In addition, if client code had pulled out the winId() of the
window, and did not invalidate these references on window
destruction via QEvent::WinIdChange or QEvent::PlatformSurface,
the client would reference stale window handles. Although
this is a programming error (QWidget::winId() specifically
mentions this requirement), we should avoid recreation if
we can.
We were already supporting flushing the backingstore to
individual native child widgets, but always did so via a
single RHI managed by the platform backingstore. By
expanding QPlatformBackingStore to keep one set of RHI
support and compositor per surface format, we can refine
the logic in QWidget and QWidgetRepaintManager to not
require recreating the top level. Native child widgets
are then flushed independently, including any RHI textures
and raster content that overlaps with the widget.
We still assume that a single RHI support and compositor
can be be used for multiple windows, as long as those
windows have the same surface format. In the future, if
needed, we can refine this to use one set per surface
format e.g.
Fixes: QTBUG-119221
Fixes: QTBUG-121181
Fixes: QTBUG-120096
Task-number: QTBUG-115652
Task-number: QTBUG-108344
Task-number: QTBUG-113557
Task-number: QTBUG-119309
Change-Id: I2635ed3d20c2fb76eab3b8130007dd656a0b93e5
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
We need to be able to have true popup windows in Qt Quick and Controls,
including handling the press-drag-release sequence to select one entry
from a menu or combobox. After the mouse press, a new window is created.
On some platforms (such as xcb), the new window gets window system grabs
of both keyboard and mouse (QApplicationPrivate::openPopup() calls
grabForPopup() and it actually works); while on others, the pre-existing
window continues to get the whole sequence of mouse events until the
release. In the latter case, Qt needs to forward events from the
original window to the popup. Until now, the list of popups was
QApplicationPrivate::popupWidgets.
Now we track the open popups as a list of QWindows rather than QWidgets,
in QGuiApplicationPrivate::popup_list, and add a set of static functions
to manage that list. Functions such as QApplication::activePopupWidget()
QApplicationPrivate::openPopup() and closePopup() are rewritten to make
requests to QGuiApplicationPrivate.
276943c8b7 made
QGuiApplicationPrivate::closeAllPopups() virtual. That is now reverted,
because we're putting QGuiApplication in charge of popup management
and trying to minimize widget-specific behavior. So far,
QApplicationPrivate::closePopup() is still overridden to take care
of focus changes.
So far, QtGui does not take care of closing popups when the user
clicks outside: the active popup window gets those events, and needs
to close itself if the click occurs outside. An attempt to move this
logic raised some issues with legacy widget test cases.
Using a touchscreen to press on QMenuBar and open a QMenu, drag to
a menu item and release, is temporarily broken for now. The plan is
to fix it in a subsequent patch.
Task-number: QTBUG-68080
Task-number: QTBUG-69777
Change-Id: I02b5034987b5ee8909917d305f414c8b0db9c7f5
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
For compatibility reasons, QPaintDevice needs to query subclasses for
device metrics as int values. To report fractional DPR values, they
have been multiplied with a large constant and divided back
afterwards. However, the loss of accuracy introduced by this, though
tiny, could still lead to rounding errors and painting artefacts when
the values where multiplied up for large coordinates.
Avoid this issue by adding a metric query that transports the full
floating point value encoded as two ints.
[ChangeLog][QtGui] Added new QPaintDevice metrics for querying
fractional device pixel ratios with high precision. Custom paintdevice
classes that support fractional DPRs are recommended to implement
support for these queries in metric(). Others can ignore them.
Fixes: QTBUG-124342
Change-Id: Ia6fa46e68e9fe981bdcbafb41daf080b4d1fb6d7
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The implementation for QTreeViewPrivate::intersectedRect() calculated
the view rect for every single index which is not needed:
- when the row is spanned, the first item spans the complete viewport
- the x-position of an index in the same column but different row is
the same so no need to re-calculate the boundaries again (similar to
the implementation in QTableView)
This reduces the visualRect() call count from n*m to n+m
Task-number: QTBUG-124173
Change-Id: I651b2ff9b6d4e68a82f32b3f5c3c0e746f88ce5e
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
setFloating() called on the 2nd last dock widget in a floating tab
didn't cause reparenting to the main window. The dock widget remained
parented to a QDockWidgetGroupWindow, while no longer being part of
floating tabs. The QDockWidgetGroupWindow would therefore have only
one tab, which is an inconsistent state and causes crashes.
Factor out the implementation of setFloating() to a new
QDockWidgetPrivate::setFloating(). Reparent to the main window, if
the dock widget is part of floating tabs.
Add test functionality in tst_QDockWidget::setFloating().
Turn createFloatingTabs() into a macro, in order to QSKIP() in the test
function's scope.
Fixes: QTBUG-122394
Pick-to: 6.7 6.5
Change-Id: I3719785f310b131446cdea908f09b7195c992b3e
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
David Faure
Christian Ehrlicher
Paul Wicking
Edward Welbourne
Tor Arne Vestbø
Axel Spoerl
Tian Shilin
David Edmundson
Kaloyan Chehlarski
Orkun Tokdemir
Joerg Bornemann
hjk
Vladimir Belyavsky
Wladimir Leuschner
Liang Qi
Even Oscar Andersen
Ingo Klöcker
Santhosh Kumar
Albert Astals Cid
Sami Varanka
Volker Hilsheimer
Alexey Edelev
Shawn Rutledge
Eirik Aavitsland