This allows to have system tray support on the fly on Wayland at least
where only QDBusTrayIcon is possible and no need to fallback to
QSystemTrayIconSys
Fixes: QTBUG-114439
Task-number: QTBUG-94871
Pick-to: 6.7 6.5
Change-Id: Ic927cde585ef02f9b9ef03f3b6338f35072bef70
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
When Marc introduced them way back in 2012 in commit
c856e37c5f ("Logging: mark qt_assert()/
qt_assert_x()/qFatal() as nothrow"), he said:
> QT_TERMINATE_ON_EXCEPTION, which expands to something like
> try { expr; } catch(...) { std::terminate(); }
> if the compiler doesn't support Q_DECL_NOEXCEPT
Well, all compilers now support noexcept, so we always had the plain do
{ } while (0) expansion instead.
Change-Id: If3345151ddf84c43a4f1fffd17d27dbc0f100ec7
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
It's just memrchr()... which unfortunately is a GNU extension (picked by
FreeBSD and OpenBSD too), so we need to provide a fallback
implementation for other OSes and bootstrap mode.
By creating a new overload instead of doing the inlining trick, this
gets inlined in QtCore uses as well and has a simpler #ifdef'ery. We
still reach the C library function indirectly, but that's going to be
minimal (and unavoidable) overhead, more than offset by the gain in
accessing an optimized memrchr().
Change-Id: If05cb740b64f42eba21efffd17d0b681bcfe9cf3
Reviewed-by: Ahmad Samir <a.samirh78@gmail.com>
If QT_CONFIG(mimetype) isn't set, this class was silently creating
invalid output. If no mimetype is specified by the user and the type
cannot be deduced then omit the content-type header.
Change-Id: Iff15462b94fa1e992369df26f74b2bd64d523f31
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The overload taking a Qt::TimeSpec is deprecated; we need to use
the one taking a QTimeZone instead. However I can't just use
QTimeZone because this is inline code in qdatetime.h, and QTimeZone
is only forward declared there. Moving the definition in qtimezone.h is
possible (like it's done for zoned_time), but that is a source break
(requires a new inclusion from users) and also weird (this function
doesn't deal with timezones, why do we need to include qtimezone.h?).
Instead, just add another overload of fromStdTimePoint that takes
precisely sys_time<milliseconds>. As such, it can be always available
even in C++17, and implemented out-of-line.
Even if this is a new symbol, the new commit policy allows the
backport. I also don't think this qualifies as a new feature;
it's a cleanup that we forgot to do (if we had a C++20-enabled
configuration in the CI when we also did the fromMSecsSinceEpoch
deprecation, we would've caught this).
Pick-to: 6.7 6.5
Change-Id: Ica77da291be4bcda2ffc7c164316a2977974c386
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Test this gesture with both mouse and touch.
Change-Id: I0285e7a17302361893c4b7ed0faf97c4f342814e
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
QMenu doesn't handle touch events, but depends on mouse synthesis.
QGuiApplicationPrivate::processTouchEvent() calls
QWindow::forwardToPopup(), which sends it to the popup window, which
sends it to QMenu. The inherited QWidget::event() calls
QEvent::ignore(). It's important for forwardToPopup() to return nullptr
when the event is not handled, so that processTouchEvent() goes on to
create the synth-mouse event and send it to processMouseEvent(), which
calls forwardToPopup() again, which QMenu::mouseMoveEvent() handles.
And we also follow the usual pattern that when an event is duplicated
for delivery (as a synthetic event, or just to remap it), the accepted
state of the original event must be updated to reflect whether or not
the cloned event was accepted.
QTabletEvents are handled similarly.
Amends e4ef0f03e6
Change-Id: I0c6c03452a5b952161c9898d84d2c17afa52fc95
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
We use them heavily in Qt's Android code, so can be very certain that
they work as advertised. In order to properly document the respective
QJniObject and QJniEnvironment APIs and to move them out of
Technology Preview, we need to have those helpers documented as
well.
Change-Id: Ifd02cbdde892d7db721204eaf6f18ad59c53e8fd
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
When our Metal layer changes its bounds or contents scale, for
example as a result of a window resize, or moving a window between
screens of different device-pixel-ratios, the layer will be marked
as needing display.
The changes to the layer will then make their way to the screen
as part of committing the root level CATransaction, managed by
the macOS display cycle, which synchronizes the presentation of
the bounds or scale changes to the screen's vertical sync.
By default, presenting a Metal drawable to a Metal layer ignores
any ongoing transactions, so the drawable ends up on the screen
as fast as possible. The downside to this is that the drawable
size or scale may be based on the yet-to-be presented bounds or
scale changes of the layer, as these happen when the display
cycle commits its transaction.
To ensure that the layer properties and content changes in lock
step we can enable the presentsWithTransaction property on the
Metal layer. We do so selectively when the layer is asked to
display, which happens during the display cycle, but not for
update requests (via our display-link).
This would normally be enough to ensure smooth and glitch free
resizing, as long as everything happens on the main thread.
Unfortunately, the [MTLCommandBuffer presentDrawable:] API we
use to present a Metal drawable when rendering in response to
update requests is actually scheduling the presentation on a
secondary thread com.Metal.CompletionQueueDispatch queue. The
result of this is that the presentation on the secondary thread
might race against a presentation on the main thread initiated
from the display-cycle, presenting too early, or overwriting
the layer's content with stale content.
To fix this we use [MTLCommandBuffer addScheduledHandler:]
explicitly instead, which lets us control what happens during
the presentation on the secondary thread. We then add a lock
to the layer that we lock as soon as the layer needs display,
and use this lock to skip presentations that should not step
on the toes of the display-cycle presentation. Once the display
cycle ends we unlock the lock.
The lock is a read-write lock, to ensure we prioritize the main
thread's display-cycle over any other presentations in case of
contention. We also defer update requests if we detect that the
lock is held, as there is no point in rendering a frame if we
are likely not going to present it. Doing this also prevents
the update-requests from starving the main thread from getting
its drawables.
The final case we have to account for is where the display
of the layer during the display-cycle is implemented by asking
another thread to do the rendering, as is the case with the
Qt Quick threaded render loop. In this case the main thread
is blocked while it waits for the render thread to complete
drawing and presenting a frame. But the actual presentation
of the Metal drawable still has to happen on the Main thread
for it to be part of the display-cycle's transaction.
To ensure the latter, we move the presentation of the drawable
to a block, that we schedule to be run on the main thread. Once
displayLayer is done with the expose event it processes the
deferred presentation, on the main thread.
Finally, to mitigate Qt Quick's threaded renderer running
animators without any coordination with the main thread, and
thereby starving it from drawables, we expose the inLiveResize
property on QNativeInterface::Private::QCocoaWindow, so that
the threaded render loop can step back during live resizing
and drive animators via the main thread's update request.
The QT_MTL_NO_TRANSACTION environment variable has been
kept, as an opt-out in case the new machinery breaks somehow.
It will disable the locked Metal layer, and all code paths
that depend on it.
[ChangeLog][macOS] Metal layers are now presented with
transactions during the display-cycle, which should fix
issues with the layer's content being out of sync with
the layer bounds or scale. If this causes issues, set the
QT_MTL_NO_TRANSACTION environment variable to opt out.
Fixes: QTBUG-107198
Fixes: QTBUG-114351
Change-Id: I765e11051c3a4d44b60ff10e787589feec8917a0
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
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 backwards compatibility reasons, font files have multiple different
ways to specify vertical metrics (ascent, descent, etc.).
For OpenType, the main two are the usWin* and sTypo* metrics in the OS/2
font table. The usWin* metrics are typically used as the clipping bounds
of the font (so no character will ever draw outside these bounds). The
sTypo* metrics thus make it possible to specify a different set of
metrics for use in text layouts which is smaller than the clipping
bounds (or bigger), so that you can have fonts where some characters
overlap with preceding or subsequent lines.
However, GDI (and thus many applications) use usWin* also for line
spacing, which lead to the sTypo* metrics being untrustworthy in some
fonts and later to the introduction of the USE_TYPO_METRICS in the OS/2
table version 4. The idea of this flag is to tell the font system that
the sTypo* metrics can be trusted and should be preferred over the usWin*
metrics.
But the OpenType specification states that sTypo* metrics should *always*
be preferred and modern font systems such as FreeType and DirectWrite
will respect this. This in turn has lead to fonts where the
USE_TYPO_METRICS flag is untrustworthy instead, i.e. the sTypo* metrics
are preferable, but the USE_TYPO_METRICS has accidentally not been set.
Qt trusts the USE_TYPO_METRICS flag and uses the usWin* metrics whenever
this is unset. Since QFontMetricsF::height() (ascent+descent) in this
case includes the line gap metric, a lot of components have been written
to use it for size without adding any margins over the text. So changing
the default now would break a large amount of components, including the
ones in our own Windows style.
Most fonts should work correctly, by setting the USE_TYPO_METRICS flag
if the typo metrics are intended to be used. For those that do not, we
introduce a PreferTypoLineMetrics style strategy.
[ChangeLog][QtGui][Fonts] Added QFont::PreferTypoLineMetrics for using
the recommended line spacing metrics of the font, even if the font has
not explicitly set its USE_TYPO_METRICS flag.
Fixes: QTBUG-125585
Change-Id: Ib2f7df404fe719186d78733bda26da712f1ab85a
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@qt.io>
Types signatures have to start with either "[L" (array of class)
or "L" (just class), and end with ";". Only "[" (array of primitive
type) makes no sense, esp since we also require a terminating
";".
Change-Id: Iea9ce992c31a34639016c967f813ebf9343c6978
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Move it to the private implementation to be later used as a template
when switching to QAnyStringView.
Change-Id: If9977711757677546cfc058602ada9f54b978509
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
... to be in sync with QObject naming.
This amends b4c63b89df.
Change-Id: I25301f65aa880205d8c0cfd6f4bfa9fdba34a01c
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
QIcon::addPixmap() creates an icon engine when not yet available. During
the initialization, the filename of the image is already passed to the
icon engine and some (e.g. svg icon engine) already loads it. Afterwards
the image is loaded again with addFile(). Avoid this by checking if the
ctor of the icon engine already loaded the file and don't call addFile()
afterwards in this case.
Fixes: QTBUG-8151
Change-Id: I9289f17e5d703c08a82ce51ce8bded70feb6f82d
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Remove a redundant nullptr check found by CodeChecker.
Change-Id: I03327475e1df8de27459457fc8fc2c66592889ab
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Due to QTBUG-125371 we currently record Qt6 as a third party
dependency for many qt packages.
Until that is fixed, we should not record the provided targets of the
Qt6 package, because it causes issues during SBOM generation.
Amends 58eefbd0b6
Task-number: QTBUG-125371
Change-Id: I35d548996c3820aaa7a1175b3a1f34c23ec2290f
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Also write gray, CMYK and mAB RGB color space profiles.
Fixes: QTBUG-125302
Change-Id: Id3b3b64537b9c08f1d40b8243c228ad111d08289
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
DBusConnection is forward declared as a class, and after
c9e62c2444 we include a header that
forward declares it as a struct. This triggers a warning, and also
indicates that we have an ODR violation.
Rename the offending type in Qt.
Fixes: QTBUG-125623
Change-Id: I13ffdceec82b86910a60083aebc2afc47f9f3a4e
Reviewed-by: Tim Blechmann <tim@klingt.org>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Robert Löhning <robert.loehning@qt.io>
It seems like all subclasses of QAccessibleEvent need to be registered
here, otherwise tests explode.
Change-Id: I924961f351bda1f50e2c73d54abe4b51162dc82a
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The CMake variable QT_ANDROID_GENERATE_JAVA_QML_COMPONENTS
will add "is_generate_java_qml_components" property to the
android-deployment-settings.json file to be read by
androiddeployqt, that enables/disables QtQmlComponent Java
code generation of QML components.
Task-number: QTBUG-124846
Change-Id: I5b3dc009aaa18beaa533296ce489e09c09d864e0
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Rami Potinkara <rami.potinkara@qt.io>
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
The QtQmlComponent class is a public Java API in Qt Declarative.
ADQt extracts QML dom info using qmldom tool, and creates concrete
classes, extending QtQmlComponent, by implementing abstract methods
of it, based on target lib, QML modules & QML components.
Additionally, it iterates properties and signals of each component
and adds get/set/connect methods with appropriate arg/return value
types, to each component. Java class generation will be invoked if
generate-java-qml-components is true in the deployment settings
file.
The generated classes will be in the same package name as the target.
If the leaf part of the package has the same name as the target,
a new .java file will be created for each module, else Java code
for all modules will be generated under a root level static class
with the same name as the target name in a single .java file with
the same name as the target name.
The first letter of target name & module names get caplitalized
to match Java naming convension.
Task-number: QTBUG-124846
Change-Id: I1f94e059a6573991c991bccc32838a211f3ee456
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
The QOpenGLBuffers used by QOpenGL2PaintEngineEx are tied to a specific
share group on creation, via QOpenGLSharedResourceGuard.
If QOpenGL2PaintEngineEx is later used with a recreated QOpenGLContext,
that happens to live at the same address as the previous one, we will
fail to detect that the context has changed by using a naked pointer
comparison (ABA problem).
If the share group of the new context is different, this will cause
problems down the line in QOpenGLBuffers::bind(). This scenario has
been observed on Android, where the context created in
QOpenGLWidgetPrivate::initialize() ends up with the same address,
but then adopts a new share context from RHI, because the widget has
been moved to a different top level window.
To remedy this, we store the QOpenGL2PaintEngineEx's cached context
via a QPointer, so that we pick up the B state of ABA (null), and
correctly throw away the old buffers in QOpenGL2PaintEngineEx::begin.
Pick-to: 6.7
Change-Id: I5c221a37fd95f846d96e72509bba54f3d10fee3a
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
The test data is provided as float, so we must obey [conv.fpint]/1 when
converting from float to integer types. There are values in the rows
that are outside of the range of short and shorter integers, so just
check the range.
Fixes: QTBUG-125889
Pick-to: 6.7
Change-Id: If3345151ddf84c43a4f1fffd17d405ee0cd00d44
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The test passes locally, and if individual functions should fail, then
skip those.
Change-Id: Ib9123bacaff2a83c2bc378b37201fd1d75dfdb45
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
We don't need the bodyName member, because it's the same as
originalBodyName, just encoded, and we can delay the encoding to
build() time.
This is not worse than the old code, since we anyway toString() the
QAnyStringView unconditionally.
So we don't need to visit the QASV and implement RFC2232 encoding for
all three view types, we can just use the QString version, after
toString().
This not only has the advantage of less code and not storing duplicate
data, but we now also encode u8"ä.txt" the same as "ä.txt"_L1 and
u"ä.txt", ie. using latin1, as required by Postel's Law, and not as
UTF-8, as the old code did.
Change-Id: If82a33a1cd09b859b3a4450a60083b1d3aedf7bc
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Constructing and composing a QHttpMultipart contains some aspects that
are possible candidates for automating, such as setting the headers
manually for each included part. As a reference, when issuing a default
multipart with CURL, one does not need to manually set the headers.
Add the class QFormDataPartBuilder to simplify the construction of
QHttpPart objects.
Add the class QFormDataBuilder to simplify the construction of
QHttpMultiPart objects.
[ChangeLog][QtNetwork][QFormDataBuilder] New class to help constructing
multipart/form-data QHttpMultiParts.
Fixes: QTBUG-114647
Change-Id: Ie035dabc01a9818d65a67c239807b50001fd984a
Reviewed-by: Marc Mutz <marc.mutz@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>
Provide the new comparesEqual() helper function as an implementation of
(in)equality operators.
Use QT_DECLARE_EQUALITY_OPERATORS_HELPER macro instead of
Q_DECLARE_EQUALITY_COMPARABLE for the comparison between QPointer<T>
and QPointer<X> to avoid creating the reversed version of the
operators in C++17 mode.
Use new \compares command in the documentation to describe the
comparison operators provided by QPointer.
Task-number: QTBUG-120306
Change-Id: Iff24d3ef5c790de7f06ab825f853e06186fa1471
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
The CLDR's "IANA" IDs may (for the sake of stability) date back to
before IANA's own naming has been updated. As a result, the "IANA" IDs
we were using were in some cases out of date. CLDR does provide a
mapping from its stable IDs to all aliases and the current IANA name
for each (which I shall soon be needing in other work), so use that to
map the CLDR IDs to contemporary IANA ones.
Revise the documentation of CldrAccess.readWindowsTimeZones() to take
this into account, pass it the alias mapping from the table, use that
to map IDs internally and, in passing, rename a variable. Update
cldr2qtimezone.py to match the new CldrAccess methods and regenerate
the data.
Change-Id: I23d8a7d048d76392099d125376b544a41faf7eb3
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mate Barany <mate.barany@qt.io>
This makes it possible for the stdCompatibility() test to cope with
the backend (based on the Windows Registry, which disagrees with MS's
ICU-based std::chrono::tzdb) successfully constructing a zone, by
finding a known alias, instead of failing because it doesn't know the
name. It may also be useful to client code when dealing with legacy
names.
Amended some existing tests to only expect what they now should and
added some tests specific to aliasMatches(). Also added some
explanative comments where it isn't needed.
Task-number: QTBUG-115158
Change-Id: I095bdbead78df339e29b29518d5010ef905fa8b2
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Follow-up to commit 69555b364d, using
QTimeZone::isTimeZoneIdAvailable() instead of trying to construct an
ad-hoc test for known unknonwn zone IDs.
Reopens: QTBUG-102187
Fixes: QTBUG-102187
Change-Id: I36ff4f1dfbc4035d73df5b8fd68376c1bc9641e1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since 6.5, you can declare the Q_OBJECT macro in any class section, not
only in private. The docs are updated accordingly. The Q_OBJECT macro
specifies a private section on its own, thus making private all the
members declared after the macro. This is an important behavior change,
so the note about it was rewritten for clarity & moved a little bit up.
Fixes: QTBUG-125776
Pick-to: 6.5 6.6 6.7
Change-Id: Ifba063af7cf7fe7258b6183da5a4599784171052
Reviewed-by: Nicholas Bennett <nicholas.bennett@qt.io>
Same change as previously done for QCryptographicHash; same rationale
applies.
[ChangeLog][QtCore][QMessageAuthenticationCode] Added hashInto()
methods, see QCryptographicHash for more information.
Fixes: QTBUG-125431
Change-Id: I88a15479b020b39ff0669a9615793886289c83f7
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Also rename the subdirs in the hiddenDirs_hiddenFiles test dir,
normalDirectory/normalDirectory/ is a bit confusing.
Make the test more deterministic by comparing lists of files/dirs
instead of just counts.
Change-Id: I12fdb5428bbef8382d4ee591792d167abcd216cf
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
So far, the keys of icon engine plugins were only interpreted as the
suffix of icon files, loaded via QIcon(filename). However, an icon
engine could provide a lot more flexibility if it could implement an
entire theme.
Match the list of keys a plugin can register itself with also against
the current theme name. If a matching plugin is found, use that plugin
to create the icon engine. Store the factory from the plugin to avoid
costly lookups for each icon.
Extend the QIcon test case by adding a custom plugin that supports two
themes. Since the plugin and icon engine creation infrastructure
doesn't communicate which theme the plugin was created for, use
QIcon::themeName to record the current theme when the engine gets
created.
[ChangeLog][QtGui][QIconEnginePlugin] The keys registered by an
QIconEnginePlugin implementation are now also matched against the
current theme (system or user theme), allowing engine providers
to implement entire themes through a plugin.
Change-Id: I8a5e30ff8b5bb7c78b5204e82760e4328671e4c1
Reviewed-by: Axel Spoerl <axel.spoerl@qt.io>
Pointers have these.
We also have qt_ptr_hash for raw pointers, so add an ADL overload for
that, too.
Don't provide a member-swap, since raw pointers don't have that.
Change-Id: I1517588d2ff1aa5caf06ad5861ff09d5e7652183
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Pointers are.
The default-constructor is = default'ed, meaning it has the same
semantics as the raw pointer it replaces:
totally_ordered_wrapper<int*> p; // partially-formed (uninit'ed)
totally_ordered_wrapper<int*> p{}; // well-formed (nullptr)
totally_ordered_wrapper<int*> a[1024]; // doesn't write 8KiB of NULs
Change-Id: I0d2e906bc5ec45d95b03a3af451167fec84439fd
Reviewed-by: Rym Bouabid <rym.bouabid@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Copying pointers is noexept.
Adding unconditional noexcept doesn't limit us to switch to
conditional noexcept going forward, because any P for which
copy-construction isn't noexcept is currently excluded by the
static_assert(is_pointer).
Change-Id: I475e6294515a4c76bb31974cd6fd458fb0c0d42e
Reviewed-by: Rym Bouabid <rym.bouabid@qt.io>
Reviewed-by: Ivan Solovev <ivan.solovev@qt.io>
Makes sense to collect the stuff in a similarly-named header.
Change-Id: Ic4190932a32fa06f1219473583327424dd2a8c11
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It's a helper to pass along option arguments that are set by
cmake_parse_arguments, from the current scope to another function
call.
It avoids a lot
if(arg_FOO) set(options FOO ${arg_FOO})
boilerplate.
It is somewhat the opposite of _qt_internal_remove_args.
The options that the function takes are prefixed with FORWARD_
to avoid possible naming conflicts with the actual options that should
be forwarded.
Change-Id: I54fd22b884d8af8379f2f735eb911a3bc66d3416
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
Ilya Fedin
Thiago Macieira
Marc Mutz
Giuseppe D'Angelo
Shawn Rutledge
Volker Hilsheimer
Tor Arne Vestbø
Eskil Abrahamsen Blomfeldt
Christian Ehrlicher
Ahmad Samir
Alexandru Croitor
Allan Sandfeld Jensen
Lars Schmertmann
Aleix Pol
Soheil Armin
Mate Barany
Eirik Aavitsland
Rym Bouabid
Edward Welbourne
Tatiana Borisova
Alexei Cazacov