If a window is positioned with setFramePosition, we reflect that to
the platform window via QPlatformWindow::setGeometry(), but with the
QWindowPrivate::positionPolicy set to WindowFrameInclusive. On the
platform side the position policy is read from QWindowPrivate to
determine how to interpret the incoming geometry.
When the resulting geometry is applied to the native window,
it's reflected through QPlatformWindow::geometry() and reported
back via QWSI::handleGeometryChange() as client geometry, ie.
without the frame margins.
If the platform layer later interprets this geometry in
combination with the window's positionPolicy, it will incorrectly
position the frame top left at the point of the client geometry's
top left.
It would make sense to reset the window's positionPolicy at
the point of QGuiApplicationPrivate::processGeometryChangeEvent,
but doing so might break situations where there's another in
flight geometry request.
What we can do as a first step is reset the positionPolicy when
the platform window is destroyed. This ensures that the next
time the platform window is created it will be placed at the
same position, even if the initial position was requested via
the setFramePosition() API.
Change-Id: Ic555f19884ccd68c46421d0fe666717170ba7638
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 11a09a9bd0a7e899a918b078a94c6c3b82240dee)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
The framePositioning test was split out from the positioning test, but
without the existing skips. Turns out we do need the same skips, so
add them.
Change-Id: Ib5d1cdf474a3a88a154c7cdc8df346668c8053d6
Reviewed-by: Tinja Paavoseppä <tinja.paavoseppa@qt.io>
(cherry picked from commit 6f46f85899b425729d595af6461c6dbe3f4f7e1c)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
This amends 31ec108dd08d6381a15e49b6fbec9337705c3b2a .
framePositioning() was split from positioning(), which was skipped
before.
Pick-to: 6.7 6.5
Change-Id: I23dcfbe6012bb44c9b7c343b963e7338ddd16f28
Reviewed-by: David Edmundson <davidedmundson@kde.org>
(cherry picked from commit e2165f0198ec09c5c0faa6bdb3dbec3b9ca482ab)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
We no longer support fake fullscreen mode on macOS, and haven't for
a long time.
Pick-to: 6.7 6.5
Change-Id: Ic2eb6065239c4e5be5ab2011a6da50272c77460a
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
(cherry picked from commit 4079ecfb9b3dc794212a81154e18145256741cfd)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
When the QCocoaWindow is created it picks up the QWindow geometry,
and applies that to the NSWindow it creates. But since we haven't
created an NSWindow yet for the first step, our logic to adjust the
window geometry when the positionPolicy is WindowFrameInclusive is
a noop. As a result the NSWindow gets a client geometry corresponding
to what the user requested as the frame geometry.
To fix this we hook into [QNSWindow setContentView:], where we apply
QWindow properties to the NSWindow after creation.
The tst_QWindow::positioning test has been split out into a separate
framePositioning test.
Pick-to: 6.7 6.5
Change-Id: I85fe6ad10aee8346202de3d55d6b2cd89915c5df
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
(cherry picked from commit 31ec108dd08d6381a15e49b6fbec9337705c3b2a)
Reviewed-by: Qt Cherry-pick Bot <cherrypick_bot@qt-project.org>
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>
We rely on setParent for parenting top level windows into our desktop
manager view, so we can't condition the call on having a parent window,
like we do on other platforms.
This was a regression from 988039729f.
Fixes: QTBUG-125142
Pick-to: 6.7
Change-Id: I2884d77db09cba5371ccd77eabda7ce38c0292de
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
We used to set a private _q_foreignWinId property on QWindow when
creating foreign windows, and this was the mechanism which we then
passed the foreign winId to the platform plugin.
With c585802e94 this was removed,
since we now were passing the winId through via explicit QPA
APIs, and since 0c6911e5cd removed
the ability to explicitly destroy() a foreign window.
But when closing a QWindow, we destroy both the window itself,
and all its children, including foreign windows. In this case
we still want to support recreating the foreign window, for
example when the parent window is shown again. To enable this
we restore the _q_foreignWinId private property, but keep
the limitation of not being able to explicitly destroy a
foreign window.
Pick-to: 6.7 6.5
Fixes: QTBUG-124160
Change-Id: Ia885ba9f043e64fb21eedd2b4c344679726f1b5c
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
According to QUIP-18 [1], all tests file should be
LicenseRef-Qt-Commercial OR GPL-3.0-only
[1]: https://contribute.qt-project.org/quips/18
Pick-to: 6.7
Task-number: QTBUG-121787
Change-Id: I9657df5d660820e56c96d511ea49d321c54682e8
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Remove the following CIs from BLACKLIST files as they are no longer
used:
- msvc-2015
- msvc-2017
- windows-7sp1
- opensuse-42.3
- ubuntu 16.04/18.04/20.04
- rhel 6.6/7.4/7.6
- redhatenterpriselinuxworkstation-6.6
Change-Id: Ief9550e3455a1ed211d978933262c8d5557b0fec
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
It's flakey, so let's unbreak the build while we investigate further.
Pick-to: 6.6
Change-Id: I9f7559803dd3ebc80946e5e5c5d31292101cd36f
Reviewed-by: Liang Qi <liang.qi@qt.io>
We only care about no longer being a child of the old parent window,
not what the system does when we reparent to nullptr.
Pick-to: 6.6
Change-Id: Ibd670432f0fd2595195d3951014a570dfdb7a998
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
When a QWindow is parented into another window, either via its constructor,
or via setParent(), we also update the QObject parent of the window. This
in turn sends ChildAdded and ChildRemoved events to the new and old parent
of the window, as well as ParentAboutToChange and ParentChange to the window
itself.
But at the point when these events are sent, the QWindow parent relationship
has not been fully established. We have not updated d->parentWindow, nor
have we propagated the parent relationship to the platform window.
This is problematic because clients can not use these events to react to
window parent changes synchronously. For example. trying to raise a child
window when added to a parent is not going to work, because at that point
the child window isn't a native child of the parent.
Instead of re-using the QObject events for QWindow, like QWidget does,
by delaying the events or sending them manually at a point when the
window parent relationship has been fully formed, we opt to add new
dedicated events.
Change-Id: I019c14eba444861f537e4f68ab3a82297f843cf7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
A foreign window used to embed a Qt window into it should not end up
with changes to its own parent, as its only job is to give the embedded
Qt window a parent handle.
Pick-to: 6.6
Change-Id: If1bc89658fedf449d266bc0cc750c90b6a841a68
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
We are using eglfs in VxWorks which make 3 few testcases fail, because eglfs windows are fullscreen by default.
This is the same solution as in qt5 in tag 5.12.6 from commit with hash 39027ef076c.
[...] EGLFS forces the first top-level window - either a QWidget or a QQuickView - to become fullscreen. [...]
from: https://doc.qt.io/qt-6/embedded-linux.html
Change-Id: I3ab3208b3c7c1b2e27d879bac1ee0679f48109e2
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Use the arguments to call the parent class implementation.
Pick-to: 6.5 6.6
Change-Id: I602a66447fb8681b3ec9ef8e2e281828612d178c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
A foreign window embedded into a Qt hierarchy must also support
being removed from that window hierarchy.
Pick-to: 6.6
Change-Id: Id4d08079ff19d67a8989937bc72602e8bd14b31b
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
In be268ae197 we made QCocoaWindow::setVisible
idempotent by checking if NSView.hidden needed update.
This failed to take into account the case when a window is moved from
being a child window to a top level, where the window is still visible
and the NSView's hidden state doesn't change, but we need to order in
the NSWindow that we're now managing.
We now check NSWindow.visible as well, if we're a top level window.
Pick-to: 6.5 6.6
Change-Id: I94434d6ebfe2c9ece6eac7f83f17ead250ccc07a
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
When a child window is made visible without its parent having been
created yet, we defer creating and making the child visible until
the parent is created.
But if a child window is explicitly created, we create the parent
first. And creating the parent will in turn apply visibility to
all children that had their visibility deferred. Which includes
creating the child.
This results in child -> parent -> child creation recursion,
which means that when we return from creating the parent window
we already have a platform window for our child, and should
bail out.
Pick-to: 6.6 6.5
Change-Id: I11dc4864b57f031de2cca70b79cdfc057d4fbd0d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We've known for a long time that this is producing worse code with GCC
because of how we implemented in Q_ASSUME_IMPL(). So bite the bullet and
actually deprecate the macro, replacing all extant Q_ASSUME() with
Q_ASSERT().
The replacement is in C++23. Backporting the support onto Q_ASSUME_IMPL
was previously rejected by reviewers.
[ChangeLog][Deprecation Notice] The Q_ASSUME() macro is deprecated. This
macro has different side-effects depending on the compiler used (GCC
compared to Clang and MSVC), and there are certain conditions under
which GCC is known to produce worse code than if the macro was absent.
To give a hint to the compiler for optimizations, use the C++23
[[assume]] attribute.
Change-Id: I80612a7d275c41f1baf0fffd177a3a4ad819fb2d
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
To avoid having to take high-DPI scaling into account for geometry
calculations/comparisons.
Pick-to: 6.6
Change-Id: I941b74781264455b70520df8d1e6e91592e00310
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Those tests often fail on Android 13 on RHEL 8.6 and 8.8. This patch
skips them to unblock CI while the underlying reasons are investigated
and fixed.
Task-number: QTQAINFRA-5606
Change-Id: If088d69c2160470ef50b2e74cd9b9399451c526d
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Add the boilerplate standalone test prelude to each test, so that they
can be opened with an IDE without the qt-cmake-standalone-test script,
but directly with qt-cmake or cmake.
Boilerplate was added using the following scripts:
https://git.qt.io/alcroito/cmake_refactor
Manual adjustments were made where the code was inserted in the wrong
location.
Task-number: QTBUG-93020
Change-Id: I2ef59684cf297a0222a136ce7b5630037294d000
Reviewed-by: Amir Masoud Abdol <amir.abdol@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This test fails too frequently on Android and RHEL to leave in as
significant. The bug report is already closed after timeouts were
extended, so perhaps we just have to accept the status quo. No
point in keeping tickets open for tests that we can't get stable on
some platforms.
Pick-to: 6.5
Task-number: QTBUG-102239
Change-Id: I54b8ae821e93b3e1f24acd67a2e84ef405388667
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Equivalent to the test added to the QWidget test case, but since QtWidgets
code contains logic to both synthesize and compress/filter enter/leave
events, we can only verify that the QWindow does get the events.
The test is very flaky on Windows, so blacklisting it right away.
Change-Id: Ic1da9439f60f619a76a3653a23fef8e9ebc0e75d
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
We sometimes use Objective-C++ code in files with a .cpp extension,
to avoid the churn of adding a foo_mac.mm file. Instead of manually
telling the compiler to build these files in Objective-C++ mode, we
use CMake's intended mechanism, which means genex constructs such as
$<$<COMPILE_LANGUAGE:OBJCXX> will work for these files as well.
Pick-to: 6.5 6.2
Change-Id: If295c3f34f6bee9f4d9f877f519c9c7770665fee
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
A foreign window can be used both for embedding a Qt window into a
native window hierarchy, or for embedding a native window into a Qt
window hierarchy. In the former case, we should not modify the foreign
window in any way. Since the platform does not know anything about the
intended use case at the time of the foreign window creation, it should
avoid modifying the foreign window in any way, and should instead pick
up the foreign window state and reflect that through QWindow.
Pick-to: 6.5
Change-Id: Id2e39d101277ecebd656d615cea3e7f734a4b0a6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Upon programmatic window state changes, windowStateChange was fired
once in QWindow::setWindowStates and once when the visual state had
been changed by the window interface.
This patch adds if guards to ensure that the singal is fired only once.
It adds a corresponding autotest to tst_QWindow.
tst_QWidget::resizePropagation() is adapted to no longer expect double
signal emission.
Fixes: QTBUG-102478
Pick-to: 6.4 6.2
Change-Id: If093c0a883d76d8a676e4fab90db6b0676452267
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This is a semantic patch using ClangTidyTransformator as in
qtbase/df9d882d41b741fef7c5beeddb0abe9d904443d8, but extended to
handle typedefs and accesses through pointers, too:
const std::string o = "object";
auto hasTypeIgnoringPointer = [](auto type) { return anyOf(hasType(type), hasType(pointsTo(type))); };
auto derivedFromAnyOfClasses = [&](ArrayRef<StringRef> classes) {
auto exprOfDeclaredType = [&](auto decl) {
return expr(hasTypeIgnoringPointer(hasUnqualifiedDesugaredType(recordType(hasDeclaration(decl))))).bind(o);
};
return exprOfDeclaredType(cxxRecordDecl(isSameOrDerivedFrom(hasAnyName(classes))));
};
auto renameMethod = [&] (ArrayRef<StringRef> classes,
StringRef from, StringRef to) {
return makeRule(cxxMemberCallExpr(on(derivedFromAnyOfClasses(classes)),
callee(cxxMethodDecl(hasName(from), parameterCountIs(0)))),
changeTo(cat(access(o, cat(to)), "()")),
cat("use '", to, "' instead of '", from, "'"));
};
renameMethod(<classes>, "count", "size");
renameMethod(<classes>, "length", "size");
except that the on() matcher has been replaced by one that doesn't
ignoreParens().
a.k.a qt-port-to-std-compatible-api V5 with config Scope: 'Container'.
Added two NOLINTNEXTLINEs in tst_qbitarray and tst_qcontiguouscache,
to avoid porting calls that explicitly test count().
Change-Id: Icfb8808c2ff4a30187e9935a51cad26987451c22
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
In Qt 6, after changes such as 121fddcf5a,
we go through the QPA layer to close widget windows properly. Closing
and hiding of windows is now done in when we receive and handle the
window system's CloseEvent.
Such an event to a modally blocked window should be blocked, so that
users can't close a modally blocked window. However, if the event is the
result of a call to QWindow::close, then it should not be blocked.
Luckily, we know that the event is the result of such a call, so let
such events through. This restores compatibility with Qt 5, where it was
possible to first open a new dialog, and then close the previous dialog.
Add a test case.
Fixes: QTBUG-107188
Pick-to: 6.4 6.2
Change-Id: Id812c1fc36aa0e1a10dfb8d3a16a11d387289b05
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
We've been requiring C++17 since Qt 6.0, and our qAsConst use finally
starts to bother us (QTBUG-99313), so time to port away from it
now.
Since qAsConst has exactly the same semantics as std::as_const (down
to rvalue treatment, constexpr'ness and noexcept'ness), there's really
nothing more to it than a global search-and-replace, with manual
unstaging of the actual definition and documentation in dist/,
src/corelib/doc/ and src/corelib/global/.
Task-number: QTBUG-99313
Change-Id: I4c7114444a325ad4e62d0fcbfd347d2bbfb21541
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
On Wayland there is a special case when decorations are enabled,
where we post an initial update request to ensure widgets are
redrawn after the buffer is recreated (see
af7b60ade5c4be81cbc58eb18307c017d5594071 in qtwayland). To
make sure the test behaves the same on Wayland as on other
platforms, we disable client-side decorations when running
these tests.
The flag is primarily required for the requestUpdate() test
at the moment, but it is only queried once per application
run, so it has to be set before any tests are run.
Pick-to: 6.4
Fixes: QTBUG-100889
Change-Id: Ica6d744083ecae4a3722b6d04b956e7615f0dfe5
Reviewed-by: Inho Lee <inho.lee@qt.io>
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
The client does not know its global window position on Wayland,
so testing for this will not work.
Pick-to: 6.4
Fixes: QTBUG-100888
Change-Id: Ibdfc84f1b33d25223dbd740603ce4783c21afc70
Reviewed-by: Inho Lee <inho.lee@qt.io>
The intialSize bug has been fixed in Qt Wayland Client, and thus
this test will now start XPASSing.
Pick-to: 6.4
Task-number: QTBUG-66818
Change-Id: I4b9cb8bd9306a67f04295eb23f09574dad0e97f7
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
CMakeLists.txt and .cmake files of significant size
(more than 2 lines according to our check in tst_license.pl)
now have the copyright and license header.
Existing copyright statements remain intact
Task-number: QTBUG-88621
Change-Id: I3b98cdc55ead806ec81ce09af9271f9b95af97fa
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
The cause is that the first EXPOSE event comes with the window not
having focus yet. See QTBUG-105177.
Also remove processEvents() as events are always processed when doing
qWaitFor...().
Task-number: QTBUG-105177
Change-Id: I2260d1885388bbf7091c423bc9b4c16e2ed0090f
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Previously the failure was been ignored because of the very generic
"linux" entry in the BLACKLIST file
Task-number: QTBUG-105201
Change-Id: I6914fe350f78266fc18541eb8fcd881f5a4ac511
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Liang Qi
Tor Arne Vestbø
Shawn Rutledge
Lucie Gérard
Christian Ehrlicher
Marcin Zdunek
Thiago Macieira
Assam Boudjelthia
Alexandru Croitor
Inho Lee
Volker Hilsheimer
Friedemann Kleint
Axel Spoerl
Marc Mutz
Eskil Abrahamsen Blomfeldt
Dimitrios Apostolou