"Cherry-pick" of C++2b's std::to_underlying.
[ChangeLog][QtCore][QtGlobal] The qToUnderlying function has been
added, to convert an value of enumeration type to its underlying
value.
Change-Id: Ia46bd8e4496e55174171ac2f0799eacbcca02cf9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Not just a compile-time one (that the macros compile and don't
raise warnings).
Change-Id: I5642bf242a6c26a33730708f3c1710237fc107a2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The boostrap library is built with exceptions disabled, and its
sources include qglobal.cpp. Therefore, the file must work when built
w/o exceptions.
Amend/partially revert 282b724808 with
the necessary fixes.
Driveby, cleanup an unnecessary QT_THROW (just throw, if we do have
exceptions).
Change-Id: I370c295c21edd3d81a9fa670e60909b29d1c68aa
Pick-to: 6.1
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
The dependencies to moc, uic and rcc have already been handled by
qt_manual_moc(), qt_enable_autogen_tool() and
_qt_internal_process_resource().
This allows not building some of the debug executables in a
multi-config scenario.
Task-number: QTBUG-88414
Change-Id: I6c162721f3ddf6b4b410345ad012073abbdfd9df
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Before, building ${target}_make_apk always re-built the apk, instead of
rebuilding the apk only when inputs changed. This patch fixes that by
moving the creation code from a custom target to a custom command with
proper dependencies.
The androidtestrunner tool now does not check for the existence of an
apk anymore and always runs the make command that is supposed to build
the apk.
The ${target}_prepare_apk_dir target is not needed anymore by the Qt
build but is still used by Qt Creator's Android support. Add a
clarifying comment.
Fixes: QTBUG-93431
Change-Id: I00d65d616fef9511b03b65f879c4bc6cb92dfc30
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The documentation for QCoreApplication::exit() even refers to it as
such. Instead of refactoring the documentation to explain that it isn't,
just make it a slot and do the same for the other classes.
Complements 2e6c37fe51.
[ChangeLog][QtCore][QEventLoop] exit() is now a slot, like quit().
[ChangeLog][QtCore][QThread] exit() is now a slot, like quit().
Change-Id: Ic42004c9bf71440eb433fffd167f4a1b89bcac80
Reviewed-by: David Faure <david.faure@kdab.com>
Q_IMPORT_PLUGIN generates a global static symbol that initializes a
plugin. If this symbol is added to a static library and the library
is then linked to an executable, the linker decides that the symbol is
unused (because nothing references it) and discards it.
This means there's no point to compile the Q_IMPORT_PLUGIN containing
files into static libraries.
Change the generator expression we use for plugin propagation via
associated modules to not compile and link the plugin initialization
object file into a static library.
Pick-to: 6.1
Task-number: QTBUG-80863
Change-Id: Ide32c0124c1e313c352a72280ce32ce9fbe8fff1
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
A previous change to fix QTBUG-85431 has caused this issue by emulating
the behavior of the non-enhanced mouse event handler in a particular
case, where mouse move events that did not change position were ignored.
However, some of these events seem to be involved in the dock drag&drop
implementation. This issue is also reproduced in pre-5.15 releases,
predating the QTBUG-85431 fix, by disabling the enhanced mouse event
handler by setting the QT_QPA_DISABLE_ENHANCED_MOUSE env var. However,
the ignored events in the current issue seem to be non-client events
only, while the QTBUG-85431 issue was related to client mouse events.
So we can restrict the test added in the QTBUG-85431 fix and have both
issues fixed.
Fixes: QTBUG-92182
Pick-to: 5.15 6.0 6.1
Change-Id: I98c0c8597912c7f4fe58af375a5a560695a82746
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Since commit f5c69a5195 the examples/widgets/painting examples could
not be built standalone anymore.
Move the find_package calls out of the examples/widgets/painting/shared
subdirectory and add a .cmake file that can be included to use the
library conveniently.
Change-Id: I35cb5bd8419a67c782d109104c4a88d64477a8be
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
There's no need of converting a QFlags to int in openExternalFile's
signature; just use the flag.
Also, avoid an implicit QFlags->bool conversion by using testAnyFlag.
Change-Id: Ia2d560bce235c842745d8a6a5fb5d8ac0851fc47
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Turn some implicit conversions into calls to QFlags::testAnyFlag.
Change-Id: I755f8a1afb1ff02e823e747e021e9744d68b4f62
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Turn some implicit conversions into calls to QFlags::testAnyFlag.
In one case, move some code using QFlags operators *after* such
operators have been declared by the right macro.
Change-Id: Ib5713f028ce74d1c9054b87cc12eea5715f2bc94
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Turn a couple of implicit conversions into calls to QFlags::testAnyFlag.
Change-Id: I21a0b4c1644986a98a2d0d54ae4b95f9fdc92841
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
There's no reason to be storing `int` in the array data header and
then using it as a QFlags. Just store the QFlags.
Change-Id: I78f489550d74d15a560dacf338110d80a7ddfdd2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Turn an implicit conversion into a call to QFlags::testAnyFlag.
Change-Id: Idbd80bb6a9b5d84952b76d8d7544f617fe693b91
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Turn an implicit conversion to bool in
* a call to testAnyFlag in one case;
* a comparison against 0 in another case, for consistency with the
surrounding code.
Change-Id: I1eee42ba82c59a72430bf507ea80408c553be889
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Turn a cast into a call to QFlags::toInt(), plus a cast.
This is in preparation for a future patch that will remove the
implicit conversion. So why not casting directly? Because we don't
know if the QFlags is backed by int or uint, so using the wrong
cast won't compile; and we MUST pass unsigned because of the %x
specifier. Granted, one could've used a static_assert, but I prefer
a more flexible and idiomatic solution.
Change-Id: I32a3e0ed69b925e8d56268ec84d9e668ca540188
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
It seems that QtCore could only be compiled with exceptions enabled.
Therefore it doesn't make sense to keep conditonal code under
QT_NO_EXCEPTIONS in qglobal.cpp. qTerminate may be called whether
exceptions are enabled or not.
Pick-to: 6.1
Fixes: QTBUG-93739
Change-Id: Ie49c10f27cfa75360f018e8638603e6a1791450e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Just use the original QFlags. Drive by, use testFlag to check if
it contains a given value or not.
Change-Id: I4d5e8454df33a3f4727855d55f7587143450dda6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
* Turn some `flags & bit` statements that rely on QFlags->int->bool
implicit conversions, into some more idiomatic `return
flags.testAnyFlag(bit)`. This is in preparation for a future patch, and
to avoid inserting casts (return statements do not contextually convert
to bool).
* Remove a magic constant, replacing it by the symbolic one.
Change-Id: I62fc2b2bf6f0ab8fad121edd19cb2ea0d9e3582a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
For 32-bit systems. They're not important (to me), but might as well fix
this oversight.
Change-Id: I755911ae7d0341f49039fffd167b26617db93354
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
QFlags was lacking a named function for testing whether a QFlags object
contains _any_ of the bits set by a given enumerator/other QFlags.
Drive-by, add testFlags taking a QFlags, not just an object of the
enumeration; and simplify the implementation of testFlags to more
closely follow what its documentation says it does.
[ChangeLog][QtCore][QFlags] The testFlags, testAnyFlag and
testAnyFlags functions have been added.
Change-Id: Ie8688c8b0dd393d34d32bc7786cdcee3eba24d1c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As is the case in Qt for Python, causing:
QtCore/qcoreapplication.h: In member function I* QCoreApplication::nativeInterface() const:
QtCore/qcoreapplication.h:163:5: error: reference to TypeInfo is ambiguous
163 | QT_DECLARE_NATIVE_INTERFACE_ACCESSOR
Amends 7feeb7c34b.
Change-Id: I7d363e1d8c0a0f648d12f8040afb9d071356cbb8
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Since the correct accessibility traits for EditableText are not
available as a direct enum value, then we depend on the defaults for a
UITextField to give us this information.
Done-with: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Fixes: QTBUG-93494
Pick-to: 6.1 5.15 5.12
Change-Id: If428414aec5ce571f0f8c0ecccffdbaf1c908120
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Since you can pass a define to org.gradle.jvmargs that can have the
name=value approach, then we need to ensure that this is accounted for.
Task-number: QTBUG-88989
Pick-to: 6.1 5.15
Change-Id: I2a795bff7ce683eca521b3a987293b3320accb6a
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
A QPageSize::PageSizeId is a faithful representation of a QPageSize,
so the corresponding QPageSize ctor shouldn't be explicit.
[ChangeLog][QtGui][QPageSize] Conversion from a QPageSize::PageSizeId
is now implicit.
Pick-to: 5.15 6.0 6.1
Change-Id: I2d32da370c032949686757400cb7c28583d9d8ac
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Giuseppe D'Angelo <giuseppe.dangelo@kdab.com>
Avoid some QFlags<->int conversions; use the named conversions
instead.
Change-Id: If12c55ca362ed5c2c73182e10562a2d09e80aa49
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Move the ValidityMask / DaylightMask enumerators in the right
enumeration. This allows to use them in a type-safe way through
the StatusFlags flag type.
Also, define the flag operators for StatusFlags.
Change-Id: Icdba7c3f49f18ffb4aff9921d8012ddc3f7cbed7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
The int was used as a flag the entire time, except in one stance.
So just use the right QFlags type instead, and replace that one usage
with a call to toInt().
Change-Id: I3670e6afdc244df69189dd15b8c2c34573476e2f
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
If the condition Int(flag) != 0 is false, it means that flag == 0.
So just check i against 0, which is more in line with what testFlag
behavior is documented to do.
Change-Id: Ia75fa07eee65e67a769fda7c020bf17ada77e9a3
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
While at it, move tst_android under corelib/platform/android.
Change-Id: Icf91cd75cb5e04d03fe6a81d52fba52a485ca41f
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
The option is called QT_CREATE_VERSIONED_HARD_LINK. By default, it
is set to ON. Users can set this option to OFF to disable versioned
hard link.
Pick-to: 6.1
Fixes: QTBUG-93636
Change-Id: I0ffa1ee1c6bae1950df332fcce3152a861b33db0
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Remove a magic number from the code, by adding it (as a private value)
to the right enumeration. Use toInt() to convert to integer.
Change-Id: Id1b00dde900619684b5a3df247d46938439150ca
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Either be explicit, or just use QFlags directly.
Change-Id: I18cbea4eaa1a0a4bce7665b735e7d785f7a196b2
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Rather than forcing an implicit conversion to int, accept a QFlags
(over either one of the two enumerations) directly.
Change-Id: I56af3a85982ecb66369e4a7105d07de0d6e0c40a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The initial approach for providing public access to native
interfaces via T::nativeInteface<I>() was based on the template
not being defined, and then having explicit instantiations of
the supported types in a source file, so that the accessors
were exported and available to the user.
This worked fine for "simple" types such as QOpenGLContext
and QOffscreenSurface, but presented a problem in the context
of classes with subclasses, such as Q{Core,Gui}Application.
To ensure that a native interface for QCoreApplication was
accessible both from QCoreApplication and its subclasses,
while at the same time preventing a native interface for
QGuiApplication to be accessible for QCoreApplication, the
nativeInterface() template function had to be declared in
each subclass. Which in turn meant specializing each native
interface once for each subclass it was available in.
This quickly became tedious to manage, and the requirements
for exposing a new native interface wasn't very clear with
all these template specializations and explicit instantiations
spread around.
To improve on this situation, while also squashing a few
other birds at the same time, we change the approach to
use type erasure. The definition of T::nativeInteface<I>()
is now inline, passing on the requested interface to a per
type (T, not I) helper function, with the interface type
flattened to a std::type_info.
The type_info requested by the user is then compared to the
available types in a single per-type (T) "switch statement",
which is a lot easier to follow for someone trying to trace
the logic of how a native interface is resolved.
We can safely rely on type_info being stable between the user
application and the Qt library as a result of exporting the
type info for each native interface, by explicitly ensuring
they have a key function. This is the same mechanism that
ensures we can safely dynamic_cast these interfaces, even
across library boundaries.
The use of a free standing templated helper function instead
of a member function in the type T, is to avoid shadowing issues,
and to not pollute the class namespace of T with the helper
function.
Since we are already changing the plumbing for how a user
resolves a native interface for a type T, we take the opportunity
to add a few extra safeguards to the machinery.
First, we add a static assert in the T::nativeInteface<I>()
definition, that ensures that only compatible interfaces,
as declared by the interface themselves, are allowed.
This ensures a compile time error when an incompatible
interface is requested, which improves on the link time
errors we had prior to this patch, and also offsets the
one downside of type erasure, namely that errors are only
caught at runtime.
Secondly, each interface meant for public consumption through
T::nativeInteface<I>() is declared with a revision, which
is checked when requesting the interface. This allows us
to bump the revision when we make breaking changes to the
interface that would have otherwise been binary incompatible.
Since the user will never see this interface due to the
revision check, they will not end up calling methods that
have been removed or renamed.
One advantage of moving to a type-erased approach for the
plumbing is that we're not longer exposing the native
interface types as part of the T::nativeInteface symbols.
This means that if we ever want to rename a native interface,
the only exported symbol that the user code relies on is
the type info. Renaming is then possible by just exporting
the type info for the old interface, but leaving it empty.
Since no class in Qt implements the old native interface,
the user will just get a nullptr back, similarly to bumping
the revision of an interface.
Change-Id: Ie50d8fb536aafe2836370caacb22afbcfaf1712a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
When using native dock widgets on macOS, it will currently
fail if you try to drag on a dock widget inside QMainWindow
to make it floating. The reason is that the drag will
basically start as as drag inside one NSWindow (QMainWindow),
but continue as a drag on another NSWindow (QDockWidget).
And this is not handled well by AppKit, especially since the
NSView where the drag was started is reparented into a new
NSWindow (the floating QDockWidget) while the dragging is
ongoing. And there seems to be no practical solution to how
we can support this from the cocoa QPA plugin
This patch will therefore change the logic in QDockWidget to
simply make the dock widget floating if you drag on it, rather
than actually starting a drag (but only for the described case).
Pick-to: 6.1 5.15
Fixes: QTBUG-70137
Change-Id: Ic309ee8f419b9c14894255205867bce11dc0c414
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Set y for the EditPopupMenu from the previous correct value if select handles values are zero.
The SelectionHandle.bottom() is zero if selection handles have not yet been displayed on the screen.
Task-number: QTBUG-71900
Change-Id: I3694a8edd4f0d8f8799dbac1217a75c375038e66
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
Since we changed binding evaluation to be always eager, we notify and
evaluate all bindings as soon as any dependency changes. This includes
bindings which have been initially installed on a property, but which
were later removed.
With lazy evaluation, we would only notify those bindings and mark them
as dirty, which is unproblematic. With eager evalution, we attempt to
evaluate the binding, though. While that part is still fine, afterwards
we would attempt to write the new value into the property. However,
there is no property at that point, as the binding is not installed.
Instead of adding a check whether the propertydataptr is null, we skip
the reevaluation completely by removing the bindings observers - and
thus the cause for the binding function's reevaluation. As soon as the
binding is set, we reevaluate the function anyway, at which point we
also capture the observers again.
Task-number: QTBUG-89505
Change-Id: Ie1885ccd8be519fb96f6fde658275810b54f445a
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Already blacklisted on the other linux versions, but is failing on
SLES now in 5.15
Pick-to: 6.1 5.15
Change-Id: I267908adf94ede51e5520aa2cb806b394fb0438e
Reviewed-by: Tarja Sundqvist <tarja.sundqvist@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The m_buttons property is meant to hold the currently pressed mouse
buttons done on the contents part of a QNSView. But m_buttons can
sometimes get out of sync with AppKit (NSEvent.pressedMouseButtons).
One way this is shown to happen is if you do a mouse press on a native
child widget (that is backed by it's own QNSView), and then convert the
widget to a top-level window before the release. In that case, the
underlying QNSView will be reparented from one NSWindow to another,
which will result in the old NSWindow getting the mouseUp call instead
of the new window. The result is that we don't update m_buttons for
the reparented QNSView, which will instead be left as "pressed".
As a result of m_buttons being stuck in a faulty state, we also refuse
to send out QEvent::NonClientAreaMouseMove events to the top-level
widget. This because QNSView thinks that it's already in a dragging
state that started on the content part of the view (and not on the
strut). As a result, it can sometimes be impossible to dock a
QDockWidget back into a QMainWindow, since we basically don't send
out any frame-drag events to Qt for the new dock window.
We can reason that if you start a mouse press on the frame strut, you
cannot at the same time have an active mouse press on the view contents.
This patch will therefore remove the buttons that we know was pressed
on the frame strut from m_buttons. This will at least (be one way to)
clear the faulty pressed state, and will let us send mouse
press/drag/release (and after that, move) frame strut events to Qt.
Pick-to: 6.1 5.15
Task-number: QTBUG-70137
Change-Id: If51e1fe57d2531b659d39de85658893dae6391e3
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
