The interval in QTimer is a QProperty of type int, which means it's
limited to the number of milliseconds that would fit in an int (~24
days), this could cause overflow if a user constructs a QTimer with an
interval > INT_MAX milliseconds. And it can't be easily changed to use
qint64/std::chrono::nanoseconds:
- changing the getters to return qint64 means user code would have
narrowing conversions
- the bindable QProperty interval can't be changed to qint64 during
Qt6's lifetime without the risk of breaking user code
- adding a new bindable QProperty that is qint64/nanoseconds is an
option, but it has the complication of what to do with the int
interval; set it when setInterval(milliseconds) is used by using
saturation arithmetic? and what about notifying observers of the
changed interval?
Thus the idea of creating a new stop-gap class, QChronoTimer, as a
cleaner solution. Both classes use QTimerPrivate.
During the lifetime of Qt6, QTimer's interval range is about 24 days,
whereas QChronoTimer's interval range is about 292 years
(duration_cast<years>nanoseconds::max()).
Currently the plan is to fold QChronotTimer back into QTimer in Qt7.
Mark all QPropertyS in the new class as FINAL since they aren't
intended to be overridden; this offers a performance boost for QML[1].
[1] https://lists.qt-project.org/pipermail/development/2024-February/044977.html
[ChangeLog][QtCore] Added QChronoTimer, which uses a
std::chrono::nanoseconds intervals, as a replacement for QTimer.
Fixes: QTBUG-113544
Change-Id: I71697f4a8b35452c6b5604b1322ee7f0b4453f04
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Ultimately this is the best way to keep the log history of the code.
Change-Id: I3413deffdb093a3239d65b6ca939e744224e722a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We already had the machinery to copy one buffer to another, so this
machinery has been generalized a bit, so we can use it to preserve
the static content during buffer resize.
As explained in the comments, we need to do the buffer copies during
buffer creation, instead of relying on our back buffer finalization,
as we are not guaranteed that we can always copy the static content
from the front buffer.
Pick-to: 6.7
Change-Id: Ia9b3ac6ec982949990d172b0b14f35b13bbae92a
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
This was a feature in Qt 4, but the only platform that carried it over
to Qt 5 was Windows, in ab76593f18, and
that's still the situation.
As a first step in possibly implementing this on more platforms, lets
replace the hard-coded check in QWidgetRepaintManager::hasStaticContents
with a proper QPlatformIntegration capability check in the only call site.
Pick-to: 6.7
Change-Id: I2067109f45116cd8c62facf7224cd748f19e845b
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
The plumbing from QBackingStore::resize to the platform backing store
was missing a high-DPI conversion for the backing store's static
contents, which is also expressed in the QtGui coordinate system.
Pick-to: 6.7 6.6 6.5 6.2
Change-Id: Ifaac916cbf184b9386aa5feca1577a53bf2906ed
Reviewed-by: Axel Spoerl <axel.spoerl@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>
All we need are the APIENTRY and WINGDIAPI macros, as those are used
in the gl.h header. Define those locally for the time we need them.
Use a QT_APIENTRY macro instead of hijacking APIENTRY for when we
declare OpenGL functions with the stdcall calling convention.
A few build fixes needed in tests that used Windows types without
explicitly including windows.h first, or that (incorrectly) included
one of the sub-headers of windows.h (like winuser.h).
[ChangeLog][Potentially Source-Incompatible Changes][OpenGL]
On Windows, the public qopengl.h header no longer includes windows.h.
Pick-to: 6.7
Fixes: QTBUG-120687
Change-Id: I3770ac8eaeee5bcf4e7234e5a2539935a8aa5a7d
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
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>
This change is required when running in real hw with eglfs backend. It passed on CI because CI used "offscreen" backend and eglfs is not tested on CI at the moment.
Task-number: QTBUG-115777
Change-Id: I4bbfbedcbe21c5c2041be9bdb8ae370156bb6200
Reviewed-by: Laszlo Agocs <laszlo.agocs@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>
It's used to build different variations of the unittest,
linking against QtCore-only/QtGui, with/without GLib, that's four
individual tests.
Change-Id: Iaf0f37041dbb148134631f86be99feaa881a8ce8
Reviewed-by: Alexandru Croitor <alexandru.croitor@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>
Although not explicitly documented, this is the behavior in practice
on XCB and Windows, and we rely on this behavior in our implementation
of QApplication::widgetAt(), where we punch a temporary hole in the
widget using a mask if it has Qt::WA_TransparentForMouseEvents set.
Pick-to: 6.5 6.6
Fixes: QTBUG-41696
Task-number: QTBUG-119092
Change-Id: Ie7abc31b6930ee6b56fcdf391befc625c1ddf502
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Under some circumstances (e.g. setDesktopSettingsAware(false) on
windows) it may happen that the call to platformTheme::palette() returns
a nullptr which is not checked before dereferencing the pointer.
Therefore add a check for this to avoid a crash.
Fixes: QTBUG-111527
Change-Id: I6443d5d1a9b813f499d8f65b4fee55b0b8299b16
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
All these TUs relied on transitive includes of qpointer.h, maybe to a
large extent via qevent.h, though, given that qevent.h is more or less
the only public QtBase header that includes qpointer.h, something else
seems to be at play here.
Said qevent.h actually needs QPointer in-name-only, so a forward
declaration would suffice. Prepare for qevent.h dropping the include.
The algorithm I used was:
If the TU mentions 'passiveGrabbers', the name of the QEvent function
that returns QPointers, and the TU doesn't have qpointer.h included
explicitly, include it. That may produce False Positives, but better
safe than sorry. Otherwise, in src/, add an include to all source and
header files which mention QPointer. Exception: if foo.h of a foo.cpp
already includes it, don't include again.
Task-number: QTBUG-117670
Change-Id: I3321cccdb41ce0ba6d8a709cea92427aba398254
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
After d9bb8c0a17 we call inputDirection()
on the platform input context to initialize the direction at startup.
The test can't assume there are no other callers to the functions
in the QPlatformInputContext layer.
Change-Id: Ic1cecd608b2759e703a17838fcf24b4ff53ad07e
Reviewed-by: Liang Qi <liang.qi@qt.io>
We were already doing this for a key combination without modifiers,
but now we do the same for e.g. Control+Unknown. This matches the
behavior we have for QKeySequencePrivate::decodeString(), where
we return Qt::Key_Unknown if we can't resolve the key, even if
we have resolved some valid modifiers, e.g. "Meta+Trolls" as in
the tst_QKeySequence::parseString() test.
Change-Id: I238e29276e6ce356ae60c67585739587fa388f07
Reviewed-by: Liang Qi <liang.qi@qt.io>
A Qt::ApplicationShortcut shortcut is not tied to a specific window.
We do however document that the shortcut "is active when one of the
applications windows are active", which seems like a strange limitation,
but for now we honor it in our test as well by making another window
active.
Change-Id: I235230ff69df29ee43d356d3efaeedb20071faf3
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There's no need for the manual sendKeyEvent, as QTest already
has the ability to send synthetic clicks, and we don't need
a colored window to test shortcut activation.
Pick-to: 6.6
Change-Id: I8409888664e2316bec4ea64f21dbb8b6915091f4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The bindable property tests were not using the QTestPrivate helpers, so
add a new test which uses them.
The new tests revealed a binding loop for the interval property.
Fix it in a usual way by explicitly removing the binding and using
{set}ValueBypassingBindings() in the setter.
Task-number: QTBUG-116346
Pick-to: 6.6 6.5
Change-Id: If94f57938da449a68e3527aead5ebd55ba410adb
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The density of Q_FOREACH uses in this and some other modules is still
extremely high, too high for anyone to tackle in a short amount of
time. Even if they're not concentrated in just a few TUs, we need to
make progress on a global QT_NO_FOREACH default, so grab the nettle
and stick to our strategy:
Mark the whole of Qt with QT_NO_FOREACH, to prevent new uses from
creeping in, and whitelist the affected TUs by #undef'ing
QT_NO_FOREACH locally, at the top of each file. For TUs that are part
of a larger executable, this requires these files to be compiled
separately, so add them to NO_PCH_SOURCES (which implies
NO_UNITY_BUILD_SOURCES, too).
In tst_qglobal.cpp and tst_qcollections.cpp change the comment on the
#undef QT_NO_FOREACH to indicate that these actually test the macro.
Task-number: QTBUG-115839
Change-Id: Iecc444eb7d43d7e4d037f6e155abe0e14a00a5d6
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Accent color role has been renamed according to name rule of other
color roles in QPalette.
Fixes: QTBUG-116107
Pick-to: 6.6
Change-Id: I70ac98a1e97afbdc7ea5f8d79f808c307e170712
Reviewed-by: Mitch Curtis <mitch.curtis@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>
Different mime types are widely used on mobile devices. For example all
text copied from gmail is copied as text/html type.
After 2937cf91c7 commit there is a
regression that makes it impossible to paste any text different than
"text/plain".
To fix it, any "text/*" mime type should be treat as it contains a text
(not only "text/plain"). That will allow to paste different text mime
types.
During this work also tst_qclipboard testset was turned on for Android
and new test (getTextFromHTMLMimeType) was added.
Pick-to: 6.6 6.5 6.2
Fixes: QTBUG-113461
Change-Id: I3ef9476b8facdc3b61f144bd55222898390127c9
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@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>
QDeferredDeleteEvent has the loopLevel field, which is a sum of
scope and loop levels found at posting. In sendPostedEvents however,
it is impossible to only use this information to find delete events
posted before the outermost loop (which should be handled by any loop)
based solely on this information, as the scope level essentialy removes
the information on loop level.
Break the loopLevel in two, storing both loop and scope levels in
QDeferredDeleteEvent, so that we can check whether an event was posted
before the outermost event loop (for which we need to compare only the
loop level).
QDeferredDeleteEvent was also made private as it should - it is an
implementation detail that wasn't hidden properly.
Change-Id: I0a607a0bd3a2deb5024acad67f740dbf4338574c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Mikołaj Boc <Mikolaj.Boc@qt.io>
The desktop file name should not contain ".desktop" suffix, but some
applications still specify it anyway because of the ambiguity in the
documentation that was fixed in
0c5135a9df.
This change makes setDesktopFileName remove ".desktop" suffix so
desktopFileName always returns a desktop file name with correct format
and its users don't need to chop ".desktop".
Pick-to: 6.5
Change-Id: If5abccaf3bf976449cada8891fff887870e45b5f
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Ahmad Samir
Tor Arne Vestbø
Tasuku Suzuki
Lucie Gérard
Liang Qi
Volker Hilsheimer
Doris Verria
Christian Ehrlicher
Marcin Zdunek
Marc Mutz
Ivan Solovev
Santhosh Kumar
Thiago Macieira
Assam Boudjelthia
Bartlomiej Moskal
Alexandru Croitor
Inho Lee
Mikolaj Boc
Vlad Zahorodnii