The accessibility implementations require the type to be fully
defined anyway in order to call type-specific APIs, so there's no
need to use inherits(). Use qobject_cast instead.
Pick-to: 6.7
Change-Id: I5c013be57f48272a748451f4888911fe6aa6574e
Reviewed-by: Pavel Dubsky <pavel.dubsky@qt.io>
Reviewed-by: Santhosh Kumar <santhosh.kumar.selvaraj@qt.io>
Qt already runs on Vision Pro as "Designed for iPad", using Qt
for iOS. This change enables building Qt for visionOS directly,
which opens the door to visionOS specific APIs and use-cases
such as volumes and immersive spaces.
The platform removes some APIs we depend on, notably UIScreen,
so some code paths have been disabled or mocked to get something
up and running.
As our current window management approach on UIKit platforms
depends on UIWindow and UIScreen there is currently no way to
bring up QWindows. This will improve once we refactor our
window management to use window scenes.
To configure for visionOS, pass -platform macx-visionos-clang,
and optionally add -sdk xrsimulator to build for the simulator.
Change-Id: I4eda55fc3fd06e12d30a188928487cf68940ee07
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Added in 1bd755465e
We already access oldtlw and oldtlw->d_func() in other places,
and the source of oldtlw is a call to QWidget::window(),
which returns the widget itself if it doesn't have a parent.
This should also fix a CodeChecker issue where it thinks
that the other unchecked accesses to oldtlw are suspicious.
Add assert just in case, so we catch it explicitly if for
some reason this assumption doesn't hold in the future.
Pick-to: 6.7 6.5
Change-Id: Iefa9b2df6b25a993afe87e4ee90fe9d2075ebbd0
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Having already caught some bugs in real code because of unchecked calls
to QFile::open, this commit marks QFile::open (and open() in other
file-I/O classes) as [[nodiscard]].
Since it's going to raise warnings, the plan is to keep the existing
behavior up to and including the next LTS. Then the warnings will switch
on by default. All of this is protected by system of macros to opt-in or
opt-out the behavioral change at any time.
A possible counter-argument for doing this is that QFile::open is also
used for opening files in the the resource system, and that opening
"cannot fail". It clearly can, if the resource is moved away or renamed;
code should at a minimum use a Q_ASSERT in debug builds. Another
counter-argument is the opening of file handles or descriptors; but
again, that opening may fail in case the handle has been closed or if
the flags are incompatible.
---
Why not marking *every* open() override? Because some are not meant to
be called directly -- for instance sockets are supposed to be open via
calls to `connectToHost` or similar.
One notable exception is QIODevice::open() itself. Although rarely
called directly by user code (which just calls open() on a specific
subclass, which likely has an override), it may be called:
1) By code that just takes a `QIODevice *` and does something with it.
That code is arguably more rare than code using QFile directly.
Still, being "generic" code, they have an extra responsibility when
making sure to handle a possible opening failure.
2) By QIODevice subclasses, which are even more rare. However, they
usually ignore the return from QIODevice::open() as it's
unconditionally true. (QIODevice::open() doesn't use the protected
virtual pattern.)
I'll try and tackle QIODevice in a future commit.
[ChangeLog][QtCore][QFileDevice] The open() functions of file-related
I/O classes (such as QFile, QSaveFile, QTemporaryFile) can now be marked
with the "nodiscard" attribute, in order to prevent a category of bugs
where the return value of open() is not checked and the file is then
used. In order to avoid warnings in existing code, the marking can be
opted in or out, by defining QT_USE_NODISCARD_FILE_OPEN or the
QT_NO_USE_NODISCARD_FILE_OPEN macros. By default, Qt will automatically
enable nodiscard on these functions starting from Qt 6.10.
Change-Id: Ied940e1c0a37344f5200b2c51b05cd1afcb2557d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The threee enumerations
- PM_DialogButtonsSeparator
- PM_DialogButtonsButtonWidth
- PM_DialogButtonsButtonHeight
Are not documented since Qt3 times and also not used anywhere. Therefore
deprecated them and remove the logic to handle them.
Change-Id: Ia59fe15482e744123e7fbf04b8d44661afb58b5c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When a slot is connected to the modelReset signal before the model is
set on the view, then such a slot might try to resize the columns or
rows to fit the contents before the view had a chance to perform layout
work.
In that case, the while-loop that calculated the size hint of a rows
(or column) by checking the size hint of each cell might not exit, as
cached information about visual indexes would be invalid.
To prevent this, don't loop over the cells if the actual last row/column
of the model (after the reset) is less than the first (cached) visible
row/column. Also, make sure we increase the counter for number of
rows/columns processed with each iteration.
Add a test (that loops infinitely without the fix, resulting in the
test being killed by the framework), and make the 'actual' variables
constant for clarity.
Fixes: QTBUG-124301
Pick-to: 6.7
Change-Id: I0adb2f1e8a1e78760ef7c19e9686c9572eca8be6
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
A click on the corner widget should select all items, not reset the
selection. This was accidentally added with
3e144bdc74.
Pick-to: 6.7
Fixes: QTBUG-124267
Change-Id: Ie20b7cf0ff730214dca80116ad888f42c2b7a670
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
It will return the minimumSize of the underlying QWindow.
The container can then be put inside QLayouts without risking to be
shrunk to a smaller size than the QWindow::minimumSize.
Whenever the QWindow::minimumWidth or QWindow::minimumHeight changes, we call QWindowContainer::updateGeometry(), which will make the layout re-query QWindowContainer::minimumSizeHint() again.
Task-number: QTBUG-121798
Change-Id: Ib7ece7d9d75f2e4964ca9042d8d8b95ce3b17739
Reviewed-by: Doris Verria <doris.verria@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
In commit 9da8d67b3b a recreation of the
ComboBox Container was introduced, since QWindows11Style depends on
WA_TranslucentBackground flag, whereas the other styles don't set this
flag. This leads to the destruction of user supplied views we don't own.
Fixes: QTBUG-124191
Pick-to: 6.7
Change-Id: I4a693f612ddc299696b9de0d87c94d88c04d9b39
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QCommonStyle sets the font for a selected header section to bold.
This overrides the font weight a calling style might already have set,
e.g. when a style sheet is applied to explicitly set a weight for a
checked header section:
QHeaderView::section:checked {
font-size: 20px
font-weight: normal
}
Since setting the weight on a font sets the respective resolve-mask
bit, we can avoid overwriting a weight that is already set explicitly.
Add baseline test coverage using a QTableWidget.
Fixes: QTBUG-122180
Pick-to: 6.7 6.5
Change-Id: I8c6279ad2fd8c5718ebea26e27c64ae823625748
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
If QToolButton::mouseReleaseEvent triggers its deletion then it
will crash when dereferencing its d pointer.
qabstractbutton.cpp already uses QPointer guards in many places but
qtoolbutton.cpp was missing this one.
While deleteLater() is still our recommendation, we shouldn't crash.
It's not always obvious what led to the button's destruction,
as the chain of indirections can be long.
Change-Id: I4a33447fa4e90953370277eb57a161398ded9a9c
Pick-to: 6.7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
QLayout::widgetEvent() returned early, when the layout was disabled.
That suppressed ChildRemoved events and lead to a crash, when the
layout was enabled again.
Don't return early on ChildRemoved events.
Add an autotest in tst_layout::removeWidget().
Fixes: QTBUG-124151
Pick-to: 6.7 6.5 6.2
Change-Id: Ib0a0bb73978d9fc2c9777d300cf38a8c4496b702
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Chris René Lerner <chris.lerner@qt.io>
Currently the drawing of CE_ItemViewItem is propagated to QWindowsStyle,
which leads to ignoring alternating rows in ItemViews. Propagating the
drawing to baseStyle honors the set base style.
Fixes: QTBUG-123632
Pick-to: 6.7 6.6 6.5
Change-Id: I656ee1c44029abf7233551303d469d38b6c848e3
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Use string views in QFontDialog, QColorDialog and QCommonStyle
Change-Id: I22f4b4694e2d18b784aaa85aebff8d92b8f0b871
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
QtQuick also uses "lcFocus" as a category name, which
causes link errors in static builds when both QWidget
and QtQuick are linked in one executable.
Making it static is also a good solution, but here
adding a "Widget" prefix seems more consistent.
Change-Id: I0a6a02750bd347f62b67544b4044789612f0fa4d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When a QWidget with an associated RHI swapchain (via its QWindow) is
moved to a different top level window, that top level window has its
own backing store, and QBackingStoreRhiSupport, which doesn't know
anything about the fact that the window already has an associated
swap chain in the original top level window's QBackingStoreRhiSupport.
As having multiple swap chains for the same window is not supported
on all RHI backends (Vulkan and DX in particular), we need to throw
away the swap chain when detecting that the window is moved to a new
top level.
We do this by hooking into the existing WindowAboutToChangeInternal
event delivery to renderToTexture children, which now delivers the
event both to renderToTexture QWidget children as well as QWindows
in the hierarchy. The condition of when to deliver the event has
been updated to reflect whether the top level uses RHI for flushing,
instead of only including renderToTexture children, as the former
also includes setting QT_WIDGETS_RHI=1 explicitly.
The event is then caught by QBackingStoreRhiSupportWindowWatcher,
and handled the same way as for SurfaceAboutToBeDestroyed.
Renaming qSendWindowChangeToTextureChildrenRecursively would make
sense at this point, but to make cherry-picks easier we keep the
current name for now.
Fixes: QTBUG-120276
Pick-to: 6.7 6.5
Change-Id: Ic4c60e89be985f12a84e9f893c299e602b70851a
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
The focus chain in widgets is implemented as a double-linked list,
using QWidgetPrivate::focus_next and focus_prev as pointers to the
next/previous widget in the focus chain.
These pointers are manipulated directly at many places, which is error
prone and difficult to read.
Build an abstraction layer and remove direct usage of focus_next and
focus_prev. Provide functions to insert and remove widgets to/from the
focus chain.
Add a test function to tst_QWidget.
Task-number: QTBUG-121478
Change-Id: Ide6379c0197137e420352a2976912f2de8a8b338
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
As part of eacd58d4e7, a mechanism was
added to prevent posting redundant UpdateRequest events to the top
level widget, managed by QWidgetRepaintManager. The mechanism relied
on a boolean that was set when posting an update request event, and
reset when processing the event for the top level widget, as part
of QWidgetRepaintManager::sync().
However, for paint-on-screen widgets, we don't post an update request
to the top level, we post it to the paint-on-screen widget directly.
And when processing that event, we don't paint the widget though the
normal QWidgetRepaintManager machinery, but instead call the paint
event via QWidgetPrivate::paintOnScreen().
As a result, an update() on a paint-on-screen widget would result
in never receiving updates for non-paint-on-screen widgets, as
we assumed there was no reason to send further update requests.
We could fix this by clearing the updateRequestSent flag as part
of the paintOnScreen() code path, but that's incorrect as the flag
represents whether the top level QWidgetRepaintManager needs an
update request event or not, and would lead to missed updates
to normal widgets until the paint-on-screen widget finishes its
update.
Instead, we only set updateRequestSent if we're posting update
requests for non-paint-on-screen widgets, which in practice
means the top level widget.
The paint on screen logic in QWidgetRepaintManager::markDirty
still takes care of rate-limiting the update requests to the
paint-on-screen widget, by comparing the dirty area of the
widget.
There is definite room for improvement here, especially in the
direction of handling update requests via QWindow::requestUpdate
instead of manually posted events, but for now this will have to
do.
Fixes: QTBUG-80167
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: Ib5685de7ca2fd7cd7883a25bb7bc0255ea242d30
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
8cd7a3d472 remembered the current screen
in QMenuPrivate::popupScreen. This QPointer member is not reset, after
QMenu:exec(), which makes a re-used menu remember the wrong screen, if
its next usage happens on another screen.
Reset the member variable at the end of QMenuPrivate::exec().
This amends 8cd7a3d472.
Fixes: QTBUG-118434
Pick-to: 6.7 6.6 6.5
Change-Id: I7457ca72166346f01cf71b2706ebc20ecd71173c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Coverity complains that QToolBarAreaLayout's
addToolBarBreak(QInternal::DockPosition) could access
QToolBarAreaLayout::docks out of bounds if passed
QInternal::DockCount.
That is correct, but a valid pos seems to be a precondition for this
function, judging from its sister functions, e.g.
addToolBar(DockPosition, .) or insertItem(DockPosition, .), which also
don't validate `pos`. All in-module callers of addToolBarBreak() only
pass valid positions, and use validateToolBarArea() to ensure that. So
it seems that Coverity doesn't grok the pass-by-in/out -parameter used
by that function. That, or it doesn't track back far enough.
Before attempting more drastic measures, first try rewriting the
function to return-by-value instead, and see what Coverity has to say
afterwards.
As a drive-by, make validateToolBarArea() constexpr.
Pick-to: 6.7 6.6 6.5 6.2 5.15
Coverity-Id: 444141
Coverity-Id: 444135
Change-Id: I5fcc664c3cea608429036cad75c37f5c38059733
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
A QMenuBar may span multiple screens. Its menus will
then open on the screen which the bottom middle of
the action rect is at, and will snap to that screen's
geometry if needed.
However it can happen that the bottomLeft() of the action
rect is on a different screen from the selected popup
screen, in which case mapping this point to global
coordinates can give incorrect coordinates if the screens
have different scale factors.
The x value will be corrected by the screen snapping
if needed. Use the y from the screen test point, which
will be correct for the selected screen.
Task-number: QTBUG-73231
Change-Id: If9a39f6b832a64f2f701868f2be0d3a6468fe553
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
On macOS, entries that do not match the filter are shown in the
directory listing.
Do not accept the dialog when these entries are double-clicked
(activated).
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-120768
Change-Id: If8ff6c56f1d21861b4e30051c212c9497042ed0f
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Focus abstraction in QWidgetPrivate makes direct access to
QWidget::focus_next and focus_prev an antipattern.
Remove usage.
Task-number: QTBUG-121478
Change-Id: I741e6875e686a9cfb4e6a113e7575c911a38e80c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Focus abstraction in QWidgetPrivate makes direct access to
QWidget::focus_next and focus_prev an antipattern.
Remove usage.
Task-number: QTBUG-121478
Change-Id: Iaab97024c20b97a0d9850dce43816a432d4bc7a1
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Palette and font changes made by a style sheet are propagated to
existing widgets and their children at change time.
Palette and font changes made by setPalette() and setFont() are
inherited by all existing and future children of the widget to which the
call was made.
Clarify this in the documentation.
Fixes: QTBUG-122588
Pick-to: 6.7 6.6 6.5 6.2 5.15
Change-Id: Ic40d96fc1e5e4507f84a33138303b7193948d3fe
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Allows to use it without Qt Widgets or Qt Graphics Views.
Since anyone having imported this through Qt Widget will also be
linking Qt Gui this should be compatible.
qt_halfScaled is also unexported for lack of known users.
Change-Id: I39406dfd4839ed46f8cbfd4651577ab6ece9932c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
When a QWidget was reparented, we would take care to reparent its
backing QWidgetWindow as well, into the nearest QWindow of the
new QWidget parent.
However we would only do this for the reparented widget itself,
and not any of its child widgets. In the case where the widget
has native children with their own QWindows, the widget itself
may not (yet) be native, e.g. if it hasn't been shown yet, or
if the user has set Qt::WA_DontCreateNativeAncestors.
In these scenarios, we would be left with dangling QWindows,
still hanging off their original QWindow parents, which
would eventually lead to crashes.
We now reparent both the QWindow of the reparented widget (as
long as it's not about to be destroyed), and any QQWindow
children we can reach. For each child hierarchy we can stop
once we reach a QWindow, as the QWindow children of that
window will follow along once we reparent the QWindow.
QWindowContainer widgets don't usually have their own
windowHandle(), but still manage a QWindow inside their
parent widget hierarchy. These will not be reparented
during QWidgetPrivate::setParent_sys(), but instead
do their own reparenting later in QWidget::setParent
via QWindowContainer::parentWasChanged(). The only
exception to this is when the top level is about to
be destroyed, in which case we let the window container
know during QWidgetPrivate::setParent_sys().
Finally, although there should not be any leftover
QWindows in the reparented widget once we have done
the QWidgetWindow and QWindowContainer reparenting,
we still do a pass over any remaining QWindows and
reparent those too, since the original code included
this as a possibility.
We could make further improvements in this areas, such
as moving the QWindowContainer::parentWasChanged() call,
but the goal was to keep this change as minimal as possible
so we can back-port it.
Fixes: QTBUG-122747
Pick-to: 6.7.0 6.7 6.6 6.5
Change-Id: I4d1217fce4c3c48cf5f7bfbe9d561ab408ceebb2
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
If the dialog is closed by pressing a button, the button will be
reflected via clickedButton(), and the result() will reflect either
the QMessageBox::StandardButton value, or an opaque value for custom
buttons.
Depending on the role if the buttons, the accepted or rejected
signals are emitted.
If the user called accept() or rejecct() on a dialog that had
already been closed by a button, we would as a result of
1f70c073d4 emit a signal based
on the original button that was clicked, instead of respecting
the newly triggered function.
It's a questionable use-case, as the clickedButton() is still
the original button e.g., but we should still avoid regressing
this, so we now emit the signals based on the newly stored
result code instead of using the clicked button as the source
of truth.
To allow this we had to change the opaque result() value for
custom buttons to stay out of the QDialog::DialogCode enum,
but this should be fine as the documentation explicitly says
that this is an opaque value.
Fixes: QTBUG-118226
Pick-to: 6.7 6.6 6.5
Change-Id: Ia2966cecc6694efce66493c401854402658332b4
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
QMessageBox::setTextFormat can set the text format for its text label,
but the informative label will still use its default text format. This
change allow the setTextFormat also apply to the informative label, thus
user can use their preferred format like Markdown in the informative label.
Task-number: QTBUG-122712
Change-Id: I6f7487b29712ca07cee27171453312ff1707eea3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
In the \fn commands for a limited number of methods in the
documentation for Testlib and Widgets, `= 0` is passed as default
argument instead of `= Qt::KeyboardModifiers()`. Until QDoc with Clang
17, inclusive, QDoc generated the correct signature. However, with
Clang 18, QDoc outputs `= 0` in the documentation. While strictly
speaking still correct, this change impacts the documentation
negatively in terms of readability.
Dropping the default argument from the \fn command ensures that QDoc
generates the right signature with both Clang 17 and Clang 18.
Task-number: QTBUG-123130
Pick-to: 6.7
Change-Id: I94ccec2f2c9a02241095fb5b18feb74aa55f97e1
Reviewed-by: Andreas Eliasson <andreas.eliasson@qt.io>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Dockwidget title accelerators doesn't work in dock widgets, so don't
show them.
This amends cc67b25579.
Fixes: QTBUG-86407
Pick-to: 6.7 6.6
Change-Id: I83fb2da1304d1e2b5eedfc127e5db3d322756d06
Reviewed-by: Sune Vuorela <sune@vuorela.dk>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
When the styled check indicator is smaller than the one from the base
style, then the clip region was to small and the check indicator from
the base style was also drawn. Therefore add both check rects to the
clipRegion.
Pick-to: 6.7 6.6 6.5
Task-number: QTBUG-102820
Fixes: QTBUG-122821
Fixes: QTBUG-122825
Change-Id: I1b5b8d70d66475bbfa4a40652dc3fdd4cc670c32
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Destroying the QComboxBox will, once it reaches the QWidget destructor,
close all popups, including the QComboBoxPrivateContainer, which emits
signals on behalf of the QComboBox, that is now gone.
Regression after d8e1100548.
The old-syle signal-slot syntax had the advantage of not delivering
signals to slots in derived classes after that derived class's
destructor had finished running (because we called via the virtual
qt_metacall). The new syntax made no checks, so a conversion from the
old to the new syntax may introduce crashes or other data corruptions
at runtime if the destructor had completed.
See 0e72a846d3.
We also need a QPointer for the QComboBoxPrivateContainer, as the
container may be deleted from outside QComboBox, as seen in the
tst_QGraphicsProxyWidget::bypassGraphicsProxyWidget() test, where
the QGraphicsProxyWidget proxies the QComboBoxPrivateContainer.
Pick-to: 6.7 6.6 6.5
Change-Id: I7590cc2821c73a6762f281504aa62f0c2b472252
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
On hidpi screens, the painted edges of the rubberband can extend
beyond the selection rect because of scaling. Extend the area to be
updated by 2x frame width, when the rubberband changes.
Fixes: QTBUG-113432
Pick-to: 6.7 6.6 6.5
Change-Id: Ie7aec1fefdc3fbf71c63952b693f462697adf849
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
The toplevelChanged signal notifies about changes of the floating
property.
Add it in property declaration.
Change-Id: I06be59a24e2732030be26d87ce38f6ce58bdebbc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
A QDialogButtonBox with the first accept button becoming default, didn't
explicitly set focus on such a button in a QDialog.
d44413d526 implemented this missing
functionality. It set focus to the automatic default button, unless the
QDialog had a focusWidget() set.
That has caused a regression, in cases where
- the QDialog has a QWidget child with a Qt::StrongFocus policy, and
- the QDialog is not yet visible, so focusWidget() returns nullptr.
Amend d44413d526ec12ed83acd7343c2005782178c7ad:
Implement a helper in QWidgetPrivate, that returns true, if a child
with a given focus policy is found.
Do not set focus to a QDialogButtonBox's automatic default button, when
- not located inside a QDialog, or
- a focusWidget() exists, or
- the dialog has QWidget child with Qt::StrongFocus, that is not a
child of the QDialogButtonBox.
Add an autotest function.
Pick-to: 6.7 6.6 6.5
Fixes: QTBUG-121514
Fixes: QTBUG-120049
Change-Id: I3c65ae36b56657f9af4a3a4b42f9b66e8bc5c534
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
During QMenuPrivate::popup() and QMenuBarPrivate::popupAction(),
QMenuPrivate::popupGeometry() is called from updateActionRects() with
screen = 0 several times (from sizeHint() and various event handlers
triggered), which causes it to return the primary screen geometry
always.
To fix this for the non-QGraphicsView case, use the screen of
the menu when it is visible or the screen stored in a newly introduced
popupScreen member variable, which is set from a few places
in QMenuPrivate::popup().
Fixes: QTBUG-118434
Pick-to: 6.7 6.6 6.5
Change-Id: I6b18593d313719d628b0856004197ac59f46c270
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
The existing widget machinery works through mouse positions. In order to
correctly update state when a drag moves outside of a window it needs
to see a move outside of the window. When the platform drag leaves the
window a move to the outside of the window is now faked to not keep the
layout in the hovered state of the last move event.
Fixes: QTBUG-122944
Pick-to: 6.7 6.6
Change-Id: I348f5281a200b78e6be4f11b3c25339d052783a5
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Regression after 9e78256579.
Apparently the string based connection syntax is more lenient,
as with PMF-style connects, we (correctly) get:
ASSERT failure in QWindowContainer: "Called object is not of the
correct type (class destructor may have already run)"
when the QWidget destructor closes the QWindow and we get a
synchronous callback from the platform that we've lost the
focus window.
Pick-to: 6.7
Change-Id: I8f25b3b050e11913ec0f0941eaf831c88b4249f9
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
975c0bdf73 has disabled usage of a resizer
on Windows. This has caused a regression, when a dock widget was
rendered frameless.
Use a resizer in that case.
Fixes: QTBUG-120694
Task-number: QTBUG-102196
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: I9fbcb1a8b1d8869995093bc1da7524ec81e9f02d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
For accessing the RHI managed by the widget compositing machinery.
Pick-to: 6.7 6.6 6.5
Change-Id: Ia3c1227cc2d9cfebe95611cad3dbcd7aa6f6f8c7
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
In contrast to nativeParentWidget(), we return the closest widget with a
QWindow, even if this window has not been created yet.
Pick-to: 6.7 6.6 6.5
Change-Id: Icac46297a6052a7a5698d752d4aa871bd5c2bdd8
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
It was added for Android in a4f50269f8,
for the case of QSurface::RasterGLSurface, but since 6.4 we no longer
use QSurface::RasterGLSurface for composition. And the Android usage
was removed in 2020ce5fd2.
Pick-to: 6.7 6.6 6.5
Change-Id: I8dafe959c54e09b3a974253e15d184365141d559
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Replace if/else snake, made more complex by handling of QT_NO_*
configurations. Move the unconditional cases to the top, which also
fixes the handling of ShortcutOverride and ToolTip events when Qt was
built with QT_NO_CONTEXTMENU.
Pick-to: 6.7
Change-Id: I1e2cc2c39e3cef9fe29a71e48595756cff0d2949
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Volker Hilsheimer
Tor Arne Vestbø
Giuseppe D'Angelo
Christian Ehrlicher
Axel Spoerl
Jan Arve Sæther
Wladimir Leuschner
Sergio Martins
Anton Kudryavtsev
Zhao Yuhang
Marc Mutz
Morten Sørvig
Venugopal Shivashankar
Keith Kyzivat
Kai Uwe Broulik
Wang Zichong
Paul Wicking
Eirik Aavitsland
Friedemann Kleint
David Redondo
Ahmad Samir