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>
clang's fallthrough detection is a little stricter than gcc.
Pick-to: 6.7
Change-Id: If1052275f035a8e8a496cc5a40a21137d18712e3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The QFrame::frameRect property is implemented in terms of the QWidget's
contentsMargins, and when the QFrame is resized it recalculates the new
frame rect by reading the contents rect and then setting the widget's
content margins based on the new value.
This conflicts with the implicit inclusion of safe area margins in the
widget's contents rect, as those implicit margins are then persisted as
user-set contents margins. If the safe area margins later change (to 0),
the frame will still reflect the old safe area margins.
We may find a way to untangle this for QFrame, but in the meantime let's
set Qt::WA_ContentsMarginsRespectsSafeArea to false. This avoids the
issue above, and also informs child widgets of the QFrame that they
themselves need to potentially take the safe area margins into account.
Disabling Qt::WA_ContentsMarginsRespectsSafeArea in this manner should
not cause any major behavior changes, as a QFrame is typically part of
a parent widget that does respect the contents margins, and so the frame
will not need to apply any margins of its own once the layout settles
down.
Task-number: QTBUG-125345
Pick-to: 6.7
Change-Id: I936ff5ec9056d05676560cc7659ba31105fdc224
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Focus abstraction in 58d5d4b7c2 was
supposed to be behavior-neutral. QWidgetPrivate::reparentFocusChildren
used QObject::findChildren() to find children inside and outside the
current focus chain. If the re-parented widget had only direct children
and the focus chain was equal to creation-order, the result was
identical to previous behavior.
When the re-parented widget had grandchildren, the behavior differred.
While not being detected by existing tests, it caused a regression.
Re-implement the previous logic: Iterate through the focus chain,
instead of relying on QObject::findChildren() returning a complete and
well-ordered list.
Modify tst_QWidget::focusChainOnReparent() in order to cover the
regression.
This amends 58d5d4b7c2.
Fixes: QTBUG-125257
Change-Id: Iff4f1d0d9b6117c50c8980dfb6eebfc6f6d4a710
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When no explicit accessible name is set for a window,
QAccessibleWidget::text uses the window title instead for a
non-minimized window.
Send a QAccessible::NameChanged event when changing the
window title results in a change of the accessible name,
to ensure that the AT-SPI cache on Linux gets updated.
Extend tst_QAccessibility::mainWindowTest() to cover the scenario as well.
Note: The entire test function is skipped on platforms not supporting
window activation, e.g. Wayland.
Fixes: QTBUG-124192
Change-Id: I0fa7f683fb5969d6ba9878f6a506c4f192069799
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Some standard button icons do not have the correct quadratic extent
which leads to rendering artifacts. Even though the real fix might be to
actually let QIcon::actualSize() return the correct pixmap size instead
the size given by the construction of the QIcon via QIcon::addFile()
this fix does not hurt anyone.
Pick-to: 6.7 6.5
Fixes: QTBUG-73655
Change-Id: I43edb38b0146e7d0a698f7a6239da5dbfbc65aa4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Use QFlatMap for standardButtonMap and hiddenButtons - these two
container normally don't hold more than 5 elements so QFlatMap suits
much better.
Change-Id: I70f1a0471ec3cb118120805973bab28568d48317
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
As an optimization when calculating the safe area margins for child
widgets we look at the parent hierarchy, and if we find a widget that
is in a layout, and that layout respects the widget's contents rect,
we assume the safe area margins are accounted for already.
But this relies on the widget the layout is operating on to not opt out
of the safe area margins affecting the contents rect. If it does, the
layout can't help us, and we need to fall back to computing the child
widget's safe area margins.
Task-number: QTBUG-125345
Change-Id: I2e2f7d292d2b2c3ecd2e2e95316c4d72b92db5d6
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Use new term in examples, code comments, error messages and and mime types.
Task-number: QTBUG-122253
Change-Id: I355452d6eb02a7a0ffbb20acf82ddb8ebbfa4837
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Add Qt::ContextMenuTrigger enum used with
QStyleHints::setContextMenuTrigger() to override default platform
behavior when to trigger context menu event.
The default is to show context menu on mouse press on
UNIX systems and on mouse release on Windows.
Give developer a possibility to override platform default behavior
to make cross platform application that behaves the same way on all
platforms
Task-number: QTBUG-93486
Change-Id: Ic832d3d8a7c355a8adb46868fff9cfd19988cf3c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Rendering a widget to a paintdevice via QWidget::render() did not pass
the LayoutDirection mode of the widget to the paintdevice which lead to
wrong rendering of text.
This is especially visible with the windows 11 style which does not draw
some widgets directly on the screen but through a QGraphicsEffect on a
QImage.
Pick-to: 6.7 6.5 6.2
Fixes: QTBUG-124931
Change-Id: If2cfa326d2ca45c42e203a4ae91fd857afa5c69c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Wladimir Leuschner <wladimir.leuschner@qt.io>
This commit introduces a new `qt_add_ui` CMake API to be used instead
of AUTOUIC, due to several hard-to-fix bugs it has.
* Resolves the issue where Ninja required two passes to correctly build
`.ui` files.
* Avoids build folder leakage, in contrast to `AUTOUIC`
* Prevents unnecessary recompilation of unchanged source files when a
`.ui` file is modified with Ninja.
* Since `qt_add_ui` does not scan source files, it provides a faster
build than `AUTOUIC`.
These changes aim to streamline the build process and improve
efficiency when working with `.ui` files.
This addresses the following issues:
https://gitlab.kitware.com/cmake/cmake/-/issues/16776https://gitlab.kitware.com/cmake/cmake/-/issues/25436https://gitlab.kitware.com/cmake/cmake/-/issues/25195
Task-number: QTBUG-110369
Fixes: QTBUG-114563
Change-Id: I34cd3df70542becf6e08502f0cbcd1c11eeeadd6
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The focusReason is also important when setting focus to the target, so
ammend 8c44064f62 and add this parameter
to the virtual method.
Change-Id: Id7800a366cbc1ce2ac26b3fec1e47ec9267a57bb
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The overload carrying the new state as an integer is deprecated, but
still documented, so we need to document the parameter as well. Bring
the full documentation back to silence the warning.
Amends 5a96d13bb5.
Pick-to: 6.7
Change-Id: I5253e68e4ad7b42fc552feb958cc0ac40d685609
Reviewed-by: Safiyyah Moosa <safiyyah.moosa@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Set object names for actions created by createStandardContextMenu() to
be able to access them from the outside. Use the same naming schema as
by QWidgetTextControl::createStandardContextMenu() (used by QTextEdit
and others).
Pick-to: 6.7 6.5
Fixes: QTBUG-112721
Change-Id: Id92f1ba13e7f7e8b1d531678895902374114d167
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It's trivially copyable and fits into a (128-bit) register.
Delete one spurious line from a \internal doc in the process.
Task-number: QTBUG-122619
Change-Id: I55bd39f176f58e0dcd0ecc86e88bd29d449c7fd7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
It seems this was neglected in 5.14, when the methods were added.
The calendar setting is also not a Q_PROPERTY; and hadn't been tested
until recently.
This follows up on commit 2dee006216
Pick-to: 6.7 6.5
Task-number: QTBUG-115200
Change-Id: I9625bf54d05a55a40867847bd58130be90e78271
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
QFusionStyle::iconFromTheme is not a reimplementation of a
virtual function, so document it as internal instead of \reimp.
Change-Id: I676de4aa68c41af8982e55d8bcf24a7cdc202c7c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
When setting new buttons with setStandardButtons(), the old ones are
deleted by iterating over d->standardButtonHash. But this hash is
modified when a button is destroyed and therefore sometimes not all
buttons were deleted.
This amends df735d794f.
Fixes: QTBUG-123939
Pick-to: 6.7 6.5
Change-Id: I867086855cfde88a7b22a5579662f250b9db0042
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Rework the painting code to not use floating point numbers and make sure
the tip of the arrow is painted with one or two points (depending on the
size is odd or even) so the arrow is always symmetric. Therefore also no
anti-aliasing is needed. Sadly the dpr scaling and also
QPainter::drawPolygon() screw things up a little bit with such small
sizes, therefore do the dpr handling by ourself to get nice results.
Pick-to: 6.7
Fixes: QTBUG-124554
Task-number: QTBUG-114539
Change-Id: I8ab8c2ce3ceb90af5d7c3a0dfeec7f7445e92a4d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There are two cases in which we let the style polish a palette:
- after merging the system palette and the style's standard palette
- or when a widget-class specific palette gets set
A style needs to know which colors of the palette it can safely
overwrite with style-specific preferences. For that to work, we
need to reset the resolve mask of the synthesized palette (first
case) to 0 before polishing. Palettes set explicitly by application
code will then have resolve bits set, and the polishing can
respect those colors and not overwrite them.
Simplify the polish() implementation then to check whether the
respective color's resolve bit is set, and only overwrite it with
the style's preferred color if the bit is clear. Move that logic
into a macro for simplification.
This amends b733d31f27 and makes
sure that colors that are set by the application explicitly don't
get overridden by the style.
Task-number: QTBUG-124490
Task-number: QTBUG-124286
Change-Id: I69e1e3da93f661ebdafee0b62adbb3d411322443
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
QMainWindow:.tabifiedDockWidgets() was refactored in Qt 6.6.3, because
it returned wrong values. It now loops from 0 to
QMainWindowTabBar::count() and uses QMainWindowTabBar::dockAt(), to
get the dock widget pointer for an index.
When a dock widget is removed from a floating tab, event processing is
necessary for the item_list and QMainWindowTabBar::count() to get in
sync. This case was overlooked in the refactoring. It can lead to
dockAt() being called with an out-of-bounds index, which it asserted.
The assertion triggered, when QMainWindow::removeDockWidget() and
QMainWindow::tabifiedDockWidgets() were called right after each other,
without processing events inbetween.
QMainWindowTabBar::dockWidgets() doesn't add nullptr to the list, it
returns.
Therefore, return nullptr, when dockAt() is called out-of-bounds.
Add test functionality in
tst_QDockWidget::updateTabBarOnVisibilityChanged().
Fixes: QTBUG-124262
Pick-to: 6.7 6.5
Change-Id: If66084b9f00b4e39f7a620da68df67c735029cf1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When the widget the completer is attached to was hidden,
the popup stayed open. It would "hang around" with no
corresponding UI being around anymore, which is weird.
Fixes: QTBUG-124861
Pick-to: 6.7
Change-Id: If9cb04e693c2663ef9da14164611f26becafc4b4
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QWindows11Style inherits from QWindowsVistaStyle for which StyleSheet
theming is deactivated. QWindows11Style draws most elements with
QPainter and should therefore be able to use overrides by StyleSheets.
This patch checks, whether QWindows11Style is used and enables the
theming by declaring it not to be a QPixmap based style. Further drawing
routines for QComboBox, QPushButton and QLineEdit are now drawing always
the base background and when they are hovered a alpha mask is used to
overdraw the elemens to create a highlight effect.
Fixes: QTBUG-124286
Pick-to: 6.7 6.7.1
Change-Id: I65436493bc2b1572c0d9423a066caea3ba9e1459
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
When a window gains focus, the focus will be set to the focusWidget,
if one exists, in the case of QWidgetWindow, and to the window's
contentItem's subFocusItem, in the case of QQuickWindow.
However, we want to be able to customize this as we may want to set
the focus item/widget to the first, last, prev, or next, depending
for example, on the reason the window got focus. Eg.: on a TabKey
we want to focus the next focus object, on a BackTabKey the previous
one, and so on.
To be able to do this, add a virtual method in QWindowPrivate that sets focus to the specified item, and override for QWidgetWindowPrivate.
Task-number: QTBUG-121789
Done-with: axel.spoerl@qt.io
Change-Id: Ib5e17d6ff52c2323a4013c80bf411e92b4c8ce9b
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
QWidgetPrivate::isFocusChainConsistent() iterates over
QApplication::allWidgets() to identify and log inconsistencies.
In applications with many widgets, this has a major performance
impact.
Disable the check and return true, unless the logging category
qt.widgets.focus is enabled.
Adapt tst_QWidget::focusAbstraction() to enable the logging category.
This amends 58d5d4b7c2.
Fixes: QTBUG-124666
Change-Id: Ia487b381ab45b052638b189bf56acaf4353b1a37
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
This reverts commit 74e8f673b8.
Reason for revert: the change as is makes the rendering of arrows in the
styles unpleasantly blurry.
Pick-to: 6.7
Change-Id: I59ccd7373631a550276465caffb7d3074ff5893c
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The method isn't used and not even defined.
Change-Id: If442806e8d4b7e5ac8f83bc783163c02bbabf47f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Tor Arne Vestbø
Christian Ehrlicher
Liang Qi
Even Oscar Andersen
Ingo Klöcker
Santhosh Kumar
Albert Astals Cid
Sami Varanka
Volker Hilsheimer
Alexey Edelev
Axel Spoerl
Wladimir Leuschner
Shawn Rutledge
Eirik Aavitsland
Tim Blechmann
Michael Weghorn
Kai Köhne
Volodymyr Zibarov
Orkun Tokdemir
Doris Verria
Edward Welbourne
Eike Ziller
Friedemann Kleint