Clean up the state of the projects,
before changing the internal CMake API function names.
Task-number: QTBUG-86815
Change-Id: I90f1b21b8ae4439a4a293872c3bb728dab44a50d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
It is lossy, so should be requested explicitly, using a dedicated
fromPixmap factory function.
Deprecate the constructor and assignment operator, and make the
constructor explicit.
[ChangeLog][QtGui][QBitmap] Implicitly constructing and assigning
to a QBitmap from a QPixmap has been deprecated, and the respective
constructor has been made explicit. Use the fromPixmap factory
function instead.
Change-Id: I68ce85b26c901415137b664a1db687021d48bae0
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Undeclared identifier ssize_t etc. Just use int. Not like we can have
more than a handful of physical devices anyway.
Change-Id: Ie1fb7ab9794a7d39e84db864c2be6dbdd5d97f50
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
Fix our API, so that QStringList and QList<QString> are the
same thing.
This required a bit of refactoring in QList and moving the
indexOf(), lastIndexOf() and contains() method into
QListSpecialMethods. In addition, we need to ensure that
the QStringList(const QString&) constructor is still available
for compatibility with Qt 5.
Once those two are done, all methods in QStringList can be moved
into QListSpecialMethods<QString>.
Change-Id: Ib8afbf5b6d9df4d0d47051252233506f62335fa3
Reviewed-by: Andrei Golubev <andrei.golubev@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
As per ### Qt6 comment. Also rename the LibraryLocation enum
to LibraryPath.
Change-Id: I556025a19c5bcdf2ff52598eaba32269522d4128
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Merging QAbstractPrintDialog with QPrintDialog, as proposed in the
removed comment, seems to have little value, given that the platform
specific implementations rely on the current abstraction.
Adjust examples and tests; with the QAbstractPrintDialog test now
testing the QPrintDialog::options API, the corresponding test function
can be removed from the QPrinter test.
Change-Id: Ia8906627898332e8590ea9b27e3d71dfcc6e8d71
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The qdoc-file that contains the example documentation was
left behind when the OpenGL code moved from QtGui
to QtOpenGL. This causes all the snippet commands to fail.
Task-number: QTBUG-74409
Change-Id: I86a753d4fc832965e76a085062882e6c720becd2
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Address a ### Qt6 comment from change
283008e123, and start using
QStyledItemDelegate in more places, so those get proper
look and feel.
Change-Id: I39767ba99b7942faada1fba0ac241deb35563b63
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Christian Ehrlicher <ch.ehrlicher@gmx.de>
Instead of QCoreApplication::quit() directly calling exit(0), which would
leave QGuiApplication and client code out of the loop, we now send the
Quit event, and let it pass through event delivery, before finally ending
up in QCoreApplication::event(), where we call exit(0).
This has the advantage that QGuiApplication can ensure all windows are
closed before quitting, and if any of those windows ignore the close
event the quit will be aborted. This aligns the behavior of synthetic
quits via QCoreApplication::quit() with spontaneous quits from the
platform via QGuiApplicationPrivate::processApplicationTermination.
Clients who wish to exit the application without any event delivery or
potential user interaction can call the lower level exit() function
directly.
[ChangeLog][QtGui] Application termination via qApp->quit() will now
deliver Quit events to the application, which in turn will result in
application windows being closed as part of the application quit,
with an option to cancel the application quit by ignoring the close
event. Clients who explicitly want to exit the application without
any user interaction should call QCoreApplication::exit() explicitly.
Task-number: QTBUG-45262
Task-number: QTBUG-33235
Task-number: QTBUG-72013
Task-number: QTBUG-59782
Change-Id: Id4b3907e329b9ecfd936fe9a5f8a70cb66b76bb7
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Adjusting the QPrinter test case - some use cases no longer exist, or are
already tested in QPageSize and QPageLayout tests.
Adjust examples and manual tests.
Change-Id: I01cbc65f3d8031aea2dac86dd942126ba708b111
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
C++20 via P1120 is deprecating arithmetic operations between
unrelated enumeration types, and GCC 10 is already complaining.
Hence, these operations might become illegal in C++23 or C++26 at
the latest.
A case of this that affects Qt is in key combinations: a
QKeySequence can be constructed by summing / ORing modifiers and a
key, for instance:
Qt::CTRL + Qt::Key_A
Qt::SHIFT | Qt::CTRL | Qt::Key_G (recommended, see below)
The problem is that the modifiers and the key belong to different
enumerations (and there's 2 enumerations for the modifier, and one
for the key).
To solve this: add a dedicated class to represent a combination of
keys, and operators between those enumerations to build instances
of this class.
I would've simply defined operator|, but again docs and pre-existing
code use operator+ as well, so added both to at least tackle simple
cases (modifier + key).
Multiple modifiers create a problem: operator+ between them yields
int, not the corresponding flags type (because operator+ is not
overloaded for this use case):
Qt::CTRL + Qt::SHIFT + Qt::Key_A
\__________________/ /
int /
\______________/
int
Not only this loses track of the datatypes involved, but it would
also then "add" the key (with NO warnings, now its int + enum, so
it's not mixing enums!) and yielding int again.
I don't want to special-case this; the point of the class is
that int is the wrong datatype. Everything works just fine when
using operator| instead:
Qt::CTRL | Qt::SHIFT | Qt::Key_A
\__________________/ /
Qt::Modifiers /
\______________/
QKeyCombination
So I'm defining operator+ so that the simple cases still work,
but also deprecating it.
Port some code around Qt to the new class. In certain cases,
it's a huge win for clarity. In some others, I've just added
the necessary casts to make it still compile without warnings,
without attempting refactorings.
[ChangeLog][QtCore][QKeyCombination] New class to represent
a combination of a key and zero or more modifiers, to be used
when defining shortcuts or similar.
[ChangeLog][Potentially Source-Incompatible Changes] A keyboard
modifier (such as Qt::CTRL, Qt::AltModifier, etc.) should be
combined with a key (such as Qt::Key_A, Qt::Key_F1, etc.) by using
operator|, not operator+. The result is now an object of type
QKeyCombination, that stores the key and the modifiers.
Change-Id: I657a3a328232f059023fff69c5031ee31cc91dd6
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
With the Qt6 compatibility break, it can finally be removed.
Closing windows (which might quit the application with
quitOnLastWindowClosed() true, the default) acted contrary to the
documentation of the commitDataRequest() signal, which could have
been a hint.
This removes the workaround API from the fix for QTBUG-49667 and
also removes the problematic feature that it worked around.
Change-Id: I672be58864ef062df7fb7f2a81658b92c4feedd2
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
This attribute is now on by default.
Change-Id: I7c9d2e3445d204d3450758673048d514bc9c850c
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
viewOptions returned a QStyleOptionViewItem object. Such a method
can never support newer versions of the option structure.
Most styleable QWidget classes provide a virtual method
initStyleOption that initializes the option object passed in as a
pointer, e.g QFrame, QAbstractSpinBox, or QComboBox.
Follow that API convention, but name it initViewItemOption, as the
QStyleOptionViewItem struct contains information about the item as
well as the widget itelf.
This is a source incompatible change that will go unnoticed unless
existing subclasses mark their overrides as 'override', or call
the removed QAbstractItemView::viewOption virtual function.
[ChangeLog][QtWidgets][QAbstractItemView] The virtual viewOptions
method that previously returned a QStyleOptionViewItem object has
been renamed to initViewItemOption, and initializes a
QStyleOptionViewItem object that's passed in through a pointer.
Change-Id: Ie058702aed42d77274fa3c4abb43ba302e57e348
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
Change the name/key of the style to 'macos'. Besides the
name 'macintosh' being archaic, we also need this
change to avoid creating 'macintosh' style folders
in QtQuickControls, now that we plan to use QPlatformTheme
also there to resolve the style.
[ChangeLog][Widgets][QStyle] The 'macintosh' style
has been renamed to 'macos'.
Change-Id: I14b8a8b4dbd369e7a7d16b94e4ad27e501e7e8d0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
And remove one of the type id to name mapping that still
existed in QMetaType. QMetaTypeInterface can provide that,
so there's no need to have a second copy of the data.
qMetaTypeTypeInternal() can still map all the names of all
builtin types to ids. That functionality is for now still
required by moc and can't be removed yet.
Change-Id: Ib4f8e9c71e1e7d99d52da9e44477c9a1f1805e57
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
And remove the old manual registration code for those operators.
Add some special handling for long/ulong, as these types could be
streamed as a QVariant so far, but are not directly streamable
through QDataStream.
[ChangeLog][QtCore][QMetaType] The QMetaType::registerStreamOperators()
and QMetaType::registerDebugStreamOperator() methods have been
removed. The streaming operators for a type are now automatically
registered together with the type registration. This implies that the
operators should be visible wherever the type is visible and being used.
[ChangeLog][Behavior Incompatible Changes] Because the QDataStream and
QDebug serialization operators are automatically registered with
QMetaType, the declarations of those functions must be present at any
point where the type is used with QMetaType and QVariant.
Change-Id: I4a0732651b20319af4a8397ff90b848ca4580d99
Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
While trying to implement instructions for building examples with
qmake in the CI, an issue has surfaced.
When building examples with CMake with -DBUILD_EXAMPLES=ON in the CI,
the examples are built in-source, aka source dir == build dir.
This means that the header files generated by qdbusxml2cpp will be
placed in the qtbase source dir.
The instructions that try to build examples with qmake build the
examples in a separate build dir after building the examples with CMake.
Unfortunately the qtbase/examples/dbus/remotecontrolledcar/car example
includes the generated DBus adaptor header via a statement like
#include "car_adaptor.h"
and the compiler prefers to pick up the header file from the example
source dir (the one generated by CMake), rather than the one generated
by qmake in the example build dir.
Because CMake's DBus integration uses different flags than qmake's
DBus integration, the generated header file code is not compatible
with the qmake generated cpp file, and the example fails to link when
building with qmake, because it can't find an appropriate constructor
symbol.
In an ideal world, we wouldn't do in-source builds with the CMake
build, but that leads to other issues which I currently don't recall.
To circumvent the issue, adapt the CMake DBus qt6_add_dbus_adaptor
function to allow not passing the problematic '-l' flag by making it
optional. This shouldn't break existing code, but allows us to
generate a compatible header that will be used by qmake and succeed in
linking the example.
Task-number: QTBUG-85986
Change-Id: I06759f79aeb66bb32da7f158f55dd4734c4a9887
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Export some private functions from QUtf8 to resolve
undefined symbols in Qt5Compat after moving QStringRef.
Task-number: QTBUG-84437
Change-Id: I9046dcb14ed520d8868a511d79da6e721e26f72b
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
This gives some source incompatibilities, most of them can be
handled by using auto instead of QStringRef explicitly.
[ChangeLog][Important API changes] QXmlStream now uses QStringView
insteead of QStringRef in it's API. Using auto forvariables returning
a QStringRef in Qt 5 should lead to code that can be used against both
Qt versions.
Fixes: QTBUG-84317
Change-Id: I6df3a9507276f5d16d044a6bdbe0e4810cf99440
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Move the QIODevice::OpenMode enum into a base class, so that
we can remove the full QIODevice (and thus QObject) dependency
from qdatastream.h and qtextstream.h.
This is required so that we can include QDataStream in qmetatype.h
without getting circular dependencies.
As a nice side effect, QDataStream and QTextStream can now inherit
QIODeviceBase and provide the OpenMode enum directly in their
class scope.
Change-Id: Ifa68b7b1d8d95687ed032f6c9206f92e63bfacdf
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Add metaType()/setMetaType() methods to be used instead
of the type() methods taking a QVariant::Type.
Change-Id: Ieaba35b73f8061cd83288dd6b50d58322db3c7ed
Reviewed-by: Maurice Kalinowski <maurice.kalinowski@qt.io>
Only widgets is required here, so drop the dependency on QT_BUILD_PARTS
and just depend on widgets.
Pick-to: 5.15
Change-Id: Idaae547b69ffd91681900b33c73e4a341011c30c
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
... and QMultiMap as std::multimap.
Just use the implementation from the STL; we can't really claim that
our code is much better than STL's, or does things any differently
(de facto they're both red-black trees).
Decouple QMultiMap from QMap, by making it NOT inherit from
QMap any longer. This completes the deprecation started in 5.15:
QMap now does not store duplicated keys any more.
Something to establish is where to put the
QExplictlySharedDataPointer replcement that is in there as an
ad-hoc solution. There's a number of patches in-flight by Marc
that try to introduce the same (or very similar) functionality.
Miscellanea changes to the Q(Multi)Map code itself:
* consistently use size_type instead of int;
* pass iterators by value;
* drop QT_STRICT_ITERATORS;
* iterators implictly convert to const_iterators, and APIs
take const_iterators;
* iterators are just bidirectional and not random access;
* added noexcept where it makes sense;
* "inline" dropped (churn);
* qMapLessThanKey dropped (undocumented, 0 hits in Qt, 1 hit in KDE);
* operator== on Q(Multi)Map requires operator== on the key type
(we're checking for equality, not equivalence!).
Very few breakages occur in qtbase.
[ChangeLog][Potentially Source-Incompatible Changes] QMap does not
support multiple equivalent keys any more. Any related functionality
has been removed from QMap, following the deprecation that happened
in Qt 5.15. Use QMultiMap for this use case.
[ChangeLog][Potentially Source-Incompatible Changes] QMap and
QMultiMap iterators random-access API have been removed. Note that
the iterators have always been just bidirectional; moving
an iterator by N positions can still be achieved using std::next
or std::advance, at the same cost as before (O(N)).
[ChangeLog][Potentially Source-Incompatible Changes] QMultiMap does
not inherit from QMap any more. Amongst other things, this means
that iterators on a QMultiMap now belong to the QMultiMap class
(and not to the QMap class); new Java iterators have been added.
Change-Id: I5a0fe9b020f92c21b37065a1defff783b5d2b7a9
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
QEasingCurve has a richer variety of curves and curveShape was already
implemented by changing the easingCurve property.
[ChangeLog][QtCore][QTimeLine] Deprecated QTimeLine's curveShape
property in favor of the easingCurve property.
Pick-to: 5.15
Change-Id: I7261c0f24d7e02bc94624f0b74d699df62de1a52
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: hjk <hjk@qt.io>
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
The example is meant to show an item delegate with a line edit with
QRegularExpression-based validation depending on type.
Unfortunately, this does not work since QSettings mostly
return QString types.
Fix it to a partially working state by
- Making the expressions match from beginning to end which
was overlooked in the QRegExp->QRegularExpression change.
- Use QCheckBox, QSpinBox for bool/int since it is silly
to have a user edit a bool value by typing 'true'/'false'.
- Move the expressions out to a separate struct to be
able to do some guessing of the type when reading
the QSettings, implement for bool and int.
- Use a fancy Unicode checkmark for displaying bools.
- Fix the garbled display of QByteArray with binary data
by displaying them with hex characters and setting them
read-only.
Change-Id: Iba22dfafc3b813b3fd3d2915ef5210d661049382
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
This is required to remove the ; from the macro with Qt 6.
Task-number: QTBUG-82978
Change-Id: I3f0b6717956ca8fa486bed9817b89dfa19f5e0e1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The change creates a slight source incompatibility. The main
things to take care of are
* code using printf statements on list.size(). Using qsizetype in
printf statements will always require a cast to work on both 32
and 64 bit.
* A few places where overloads now get ambiguous. One example is
QRandomGenerator::bounded() that has overloads for int, uint and
double, but not int64.
* Streaming list.size() to a QDataStream will change the format
depending on the architecture.
[ChangeLog][QtCore][QList] QList now uses qsizetype to index into
elements.
Change-Id: Iaff562a4d072b97f458417b670f95971bd47cbc6
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The API is available by including qopenglcontext.h as usual,
but scoped in the QPlatformInterface namespace. The namespace
exposes platform specific type-safe interfaces that provide:
a) Factory functions for adopting native contexts, e.g.
QCocoaGLContext::fromNative(nsContext, shareContext);
b) Access to underlying native handles, e.g.
openGLContext->platformInterface<QCocoaGLContext>->nativeContext()
c) Platform specific functionality, e.g.
static QWGLContext::openGLModuleHandle()
openGLContext->platformInterface<QEGLContext>->doSomething();
The platform interfaces live close to the classes they extend,
removing the need for complex indirection and plumbing, and
avoids kitchen-sink modules and APIs such as the extras modules,
QPlatformFunctions, or QPlatformNativeInterface.
In the case of QOpenGLContext these platform APIs are backed
by the platform plugin, so dynamic_cast is used to ensure the
platform plugin supports the requested interface, but this is
and implementation detail. The interface APIs are agnostic
to where the implementation lives, while still being available
to the user as part of the APIs they extend/augment.
The documentation will be restored when the dust settles.
Task-number: QTBUG-80233
Change-Id: Iac612403383991c4b24064332542a6e4bcbb3293
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
* Assume UTF-8 on all Unix like systems
* Export some functions to be able to compile QTextCodec once
moved to Qt5Compat.
Task-number: QTBUG-75665
Change-Id: I52ec47a848bc0ba72e9c7689668b1bcc5d736c29
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
There is no reason for keep using our macro now that we have C++17.
The macro itself is left in for the moment being, as well as its
detection logic, because it's needed for C code (not everything
supports C11 yet). A few more cleanups will arrive in the next few
patches.
Note that this is a mere search/replace; some places were using
double braces to work around the presence of commas in a macro, no
attempt has been done to fix those.
tst_qglobal had just some minor changes to keep testing the macro.
Change-Id: I1c1c397d9f3e63db3338842bf350c9069ea57639
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
And not +. Guess what, this was "accidentally" working around
a number of bugs, most importantly QTBUG-75172 (which is caused by
QTBUG-74639 and probably others).
Change-Id: If13810d9408f2be7b87f0d259737bff8cacc6f7b
Pick-to: 5.15
Reviewed-by: Samuel Gaist <samuel.gaist@idiap.ch>
Reviewed-by: David Faure <david.faure@kdab.com>
We have seen during the Qt 5 series that QMouseEvent::source() does
not provide enough information: if it is synthesized, it could have
come from any device for which mouse events are synthesized, not only
from a touchscreen. By providing in every QInputEvent as complete
information about the actual source device as possible, we will enable
very fine-tuned behavior in the object that handles each event.
Further, we would like to support multiple keyboards, pointing devices,
and named groups of devices that are known as "seats" in Wayland.
In Qt 5, QPA plugins registered each touchscreen as it was discovered.
Now we extend this pattern to all input devices. This new requirement
can be implemented gradually; for now, if a QTWSI input event is
received wtihout a device pointer, a default "core" device will be
created on-the-fly, and a warning emitted.
In Qt 5, QTouchEvent::TouchPoint::id() was forced to be unique even when
multiple devices were in use simultaneously. Now that each event
identifies the device it came from, this hack is no longer needed.
A stub of the new QPointerEvent is added; it will be developed further
in subsequent patches.
[ChangeLog][QtGui][QInputEvent] Every QInputEvent now carries a pointer
to an instance of QInputDevice, or the subclass QPointingDevice in case
of mouse, touch and tablet events. Each platform plugin is expected to
create the device instances, register them, and provide valid pointers
with all input events. If this is not done, warnings are emitted and
default devices are created as necessary. When the device has accurate
information, it provides the opportunity to fine-tune behavior depending
on device type and capabilities: for example if a QMouseEvent is
synthesized from a touchscreen, the recipient can see which touchscreen
it came from. Each device also has a seatName to distinguish users on
multi-user windowing systems. Touchpoint IDs are no longer unique on
their own, but the combination of ID and device is.
Fixes: QTBUG-46412
Fixes: QTBUG-72167
Task-number: QTBUG-69433
Task-number: QTBUG-52430
Change-Id: I933fb2b86182efa722037b7a33e404c5daf5292a
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
