Required for porting away from QLatin1Char/QLatin1String in scope of
QTBUG-98434.
As a drive-by, fix qsizetype -> int narrowing conversion warnings for
the touched lines.
Change-Id: I03477e645a94948cac3e3e2abca52aa4e3e2efff
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Required for porting away from QLatin1Char/QLatin1String in scope of
QTBUG-98434.
Change-Id: Ia186ed178239796bdf19db5b35a36ea606baf937
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Describe enum usage in QDockWidget::isAreaAllowed() as well as meaning
of enum members.
Pick-to: 6.3 6.2 5.15
Change-Id: Ib88509feb001be27c11fd167c9009da50ce1b851
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Check DockWidgetArea permissions of QDockWidgetGroupWindows with single
dock widget. Obtain a dock widget's tab position from a dock widget
group window if it can't be established otherwise. Remove hardcoded
assumption that a dock widget is in the left dock. Both cases have lead
to inconsistent entries and dangling pointers in
QDockAreaLayoutInfo::item_list.
Remove warning: QMainWindowLayout::tabPosition called with out-of-bounds
value '0', which becomes obsolete by the fix.
Create a QDockWidgetGroup window prepered to become a floating tab,
whenever a dock widget is being hovered over. Store it in item_list so
it can be found and deleted when required.
No longer call e->ignore() after propagating close events to the first
dock widget and thus preventing others from receiving the event.
Add logging category qt.widgets.dockwidgets
Update dock widget autotest with tests to check the fixes mentioned:
plugging, unplugging, hiding, showing, closing and deleting.
Blackist closeAndDelete, floatingTabs test on macos, QEMU, arm, android
due to flaky isFloating() response after a dock widget has been closed
or plugged.
QSKIP dockPermissions and floatingTabs test on Windows due to mouse
simulation malfunction.
QSKIP hideAndShow test on Linux in case of xcb error (QTBUG-82059)
Fixes: QTBUG-99136
Pick-to: 6.3 6.2
Change-Id: Ibd353e0acc9831a0d67c9f682429ab46b94bdbb0
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
There should be no need for CMake to add rpaths pointing to
directories outside of the build tree to the installed libraries.
All relevant install rpaths are handled by qt_apply_rpaths().
Change-Id: If554b1e3c790c2bb04a34e8b0524aab3febf5afc
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
There were a few things that were not ported correctly.
Make sure to disable rpath manipulation if the rpath feature is
disabled.
Fix if(IS_ABSOLUTE) conditions to actually take values.
Don't embed bogus relative rpaths if the platform does not support
it. QNX is such a platform, it does not support $ORIGIN (at least from
my scouring of QNX documentation and manual testing via QEMU).
Handle the extra rpath case where they are relative, but the platform
does not support relative rpaths, by transforming them into absolute
ones.
Amends 67ee92f4d8
Change-Id: I04168633ec51b3cc5d580b738a7dc280fe6e0d2d
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Previously if
-extprefix /tmp/sysroot (CMAKE_STAGING_PREFIX)
-developer-build (FEATURE_developer_build)
were specified, but
-prefix (CMAKE_INSTALL_PREFIX)
was not,
the build system would set the CMAKE_INSTALL_PREFIX to the
qtbase build dir.
Then, if targeting desktop, this would be considered a non-prefix
build (ninja install would refuse to work), whereas in a cross-build
it would be considered an installable build.
In both cases though, the rpath of installed binaries would point to
the qtbase build dir (because CMAKE_INSTALL_PREFIX would be set to the
qtbase build dir).
This is quite confusing behavior, in more than one way.
Change the build system to consider that an explicit -extprefix should
cause Qt to always be installed, even if -developer-build is
specified.
This means the installed rpaths and on-device install prefix
(CMAKE_INSTALL_PREFIX) will now use the default computed install
prefix, e.g. /usr/local/Qt
It also means that to get a non-installable developer + custom staging
and install (on-device) prefix build, users will have to be explicit
and set all the options
-extprefix ~/qt/qtbase_build_dir
-prefix /usr
-developer-build
Pick-to: 6.2 6.3
Change-Id: Ib560452a4b4778860e0fd7666c76f8a6745773ee
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Allow such a combination
- staging prefix (CMAKE_STAGING_PREFIX / -extprefix) set to the
qtbase build dir
- install prefix (CMAKE_INSTALL_PREFIX / -prefix / on-device prefix) set
to some custom location
even for non-cross builds.
An example would be
configure -prefix /usr \
-extprefix ~/qt/qtbase_build_dir
CMake will put the Qt libraries in the qtbase build dir, ninja install
will not be required, but ultimately in order to run applications,
the Qt libraries are expected to be in /usr.
Support for this scenario was originally added for cross-builds in
062318feb2 , but not desktop builds.
Such a build is useful when you want to have install rpaths different
from where Qt is initially installed to (the staging prefix).
This case doesn't really happen often when targeting desktop
platforms, it's mostly used for cross-compilation (e.g yocto).
Being able to have the same setup with a desktop build is nevertheless
useful for faster iteration on build system issues in such a scenario.
Amends 062318feb2
Pick-to: 6.2 6.3
Change-Id: I42be3628a30025f14eebaf0a79401b54e95cde26
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Instead of complicating the condition even more, just use the value of
QT_WILL_INSTALL which is determined in QtSetup before configure.cmake
is loaded.
The AUTODETECT part is needed to ensure that
-developer-build
implies -no-prefix.
The CONDITION part is needed so that
-extprefix /tmp/sysroot -no-prefix
correctly errors out saying that this can't be a non-prefix build,
unless
-extprefix ${qtbase_build_dir} -no-prefix
is passed.
Pick-to: 6.2 6.3
Change-Id: Ie4f5a91281bf2fbe1bd0744de05d57f43fe992e7
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
Otherwise we get:
Styles ................................. Basic Fusion Imagine iOS
Material Universal macOS Windows
-- Qt is now configured for building. Just run 'cmake --build .
--parallel'
Pick-to: 6.2 6.3
Change-Id: Ie8d009455e4f45c9eb0557c4a08e9d0a94030c3a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
The textual output of otool in recent Xcode releases has changed.
We now look for OBJC_CLASS_RO/OBJC_METACLASS_RO rather than
class_ro_t.
Pick-to: 6.2 6.3 5.15
Change-Id: I86192e91e55d8deb7e5c6790b327855fc0f7e594
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
Qt backing store images should have alpha iff that was
requested by the QWindow's surface format. This changes
wasm to be in line with the other platforms, and enables
use of transparency for Qt windows.
Change beginPaint() to clear the backing store only
if the format/image has alpha. This is also established
behavior Qt's backing stores.
Change-Id: Idafe658e24d864f7c4f9e68ee39cb409982b5852
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: David Skoland <david.skoland@qt.io>
This should've been done already for Qt 6.2.
Pick-to: 6.2 6.3
Change-Id: I2f943254698a4f0f2742619fd7fcab9ac3a5014a
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
This is a cherry modification of 5826a7ad92
in 5.15 branch.
Fixes: QTBUG-102438
Pick-to: 6.3 6.2
Change-Id: I8bdb7cb2537c6df7bb1381871b3cc2446ff1d270
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
...and properly find and link against `libatomic` using find_library.
This fixes the qtdeclarative build on the RISC-V platform.
Initial-patch-by: Sprite <SpriteOvO@gmail.com>
Pick-to: 6.2
Pick-to: 6.3
Task-number: QTBUG-99234
Change-Id: I2b5e4812886ce45cb02bed3106ce8c519b294cbe
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Jörg Bornemann <joerg.bornemann@qt.io>
This shows we're lacking support for the 0b prefix, and, as it turns
out, there's a request for it.
Task-number: QTBUG-85002
Pick-to: 6.3
Change-Id: Ie201c84bf906a7e482b929301699ceb429b53c14
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
This constructor was used in the previous implementation of
clone(). The current implementation uses the compiler-generated
copy-constructor.
Change-Id: Ibae163653e43ceb2b07872b496cd004e50b1e625
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
We need to add specialHTMLTargets to EXPORTED_RUNTIME_METHODS in order
to use it, as Emscripten does not export it.
Also, EM_ASM is not allowed for SIDE_MODULES, so it's better to use
emscripten::val methods.
Change-Id: I9b352ac98e2a961157f5bb36456bec3e35891270
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Add one and reset the wakeAll bit atomically.
This avoids a race in a case where an acquiring thread
is owning the semaphore, and deleting it after a
set number of releases (one for each thread referencing the semaphore).
Two releasing threads could enter the if statement under
futexNeedsWake(prevValue), the counter been incremented at
this point and reached the value being acquired, meaning the thread
acquiring can be awakened by just one of the two releasers,
delete the semaphore, and then the second releaser would access
the now deleted semaphore.
The patch avoids that by unsetting and reading the wakeAll bit
atomically, so only one thread will try to wake all threads.
Pick-to: 6.3 6.2 5.15
Fixes: QTBUG-102484
Change-Id: I32172ed44d74378c627918e19b9e1aaadb5c6d1d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
GNOME sends empty InputMethod event when switching applications
with Alt-Tab. As long as this event is empty, we don't need to
scroll to cursor, because we're not adding any input text to it.
This also fixes "out of scope" bug QTCREATORBUG-26628
Fixes: QTBUG-100039
Task-number: QTCREATORBUG-26628
Pick-to: 6.2 6.3
Change-Id: I3ccfea50ae52f6f0cbf82c29f07944894050e7dd
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
To complement the existing addSecs / MSecs / etc., add a function
that takes any compatible std::chrono::duration.
QTime also features similar functions, but it's also "unique" in that
it uses modular arithmetic (it wraps around in case of "overflow").
I'm not so sure that adding durations to a QTime object therefore
makes sense, and I'm not doing it in this patch.
[ChangeLog][QtCore][QDate] Added addDuration().
[ChangeLog][QtCore][QDateTime] Added addDuration().
Change-Id: I02aa37ff024d7f56fa976dc8f4f73523bdba8d94
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
A previous commit Q_CORE_EXPORTed this class so it could be used in
tst_qevent. But we can also keep it Q_AUTOTEST_EXPORTed and make the
testing of the class subject to QT_BUILD_INTERNAL on the test side.
That's what this patch does.
Change-Id: I9bd5f80ada856b7db4b39dfb59b32bd825416c13
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Sona Kurazyan <sona.kurazyan@qt.io>
There's no advantage to them being inline: Absent de-virtualisation,
clone() is only supposed to be called through the vtable, and the copy
ctor is only supposed to be used in the implementation of clone().
And when the compiler de-virtualises, we don't want the code
duplication associated with inlining.
Enforce this by introducing new macros to hide the boilerplate.
This fixes missing out-of-line dtors in:
- QSinglePointEvent
- QApplicationStateChangeEvent
- QFutureCallOutEvent
Wrong covariant return in:
- QFutureCallOutEvent
And missing clone() reimplementations in:
- QCloseEvent
- QIconDragEvent
- QShowEvent
- QHideEvent
- QDragEnterEvent
- QDragLeaveEvent
While these don't carry extra data or members, a dynamic_cast of the
result of clone() as well as using the expected covariant return value
would fail:
QShowEvent *e = ~~~;
QShowEvent *e2 = e->clone(); // ERROR: converting QEvent* to QShowEvent*
Check that reimplementing clone() is binary compatible (covariant
returns may change the numerical pointer value returned, cf.
https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B).
The copy-assignment operator stays inline for the time being, as the
goal is to = delete it in the future.
This patch covers, roughly, QtCore and QtGui.
[ChangeLog][QtGui][QEvent subclasses] Fixed missing clone()
reimplementations on QCloseEvent, QIconDragEvent, QShowEvent,
QHideEvent, QDragEnterEvent, and QDragLeaveEvent.
Task-number: QTBUG-45582
Task-number: QTBUG-97601
Change-Id: Ib8a0519dbe85a7a8da61050d48be338004dfa69a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Separated from other clean-ups to avoid inanity 'bot complaints.
Change-Id: Ia33f87da224dba7c50bbf14beb642825dc46fe90
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Now that QL1S has its own arg(), we can use that directly instead of
going via QString before calling arg(). Only works in most cases, as
the QL1S::arg() overload set is more limited.
Change-Id: Ie4c566c5998538b1b8a953b1ba4481e0f1663bf7
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Required for porting away from QLatin1Char/QLatin1String in scope of
QTBUG-98434.
As a drive-by, fix qsizetype -> int narrowing conversion warnings for
the touched lines.
Change-Id: Iebcbdbd7cecac09d0a7039e3ef6a4509d33039ba
Reviewed-by: Assam Boudjelthia <assam.boudjelthia@qt.io>
This fixes the "Could not find feature c++2b." error when building a Qt
module with qmake.
The feature is OFF by default for now.
This amends commit b5ed3cb7ba.
Pick-to: 6.2 6.3
Change-Id: Ibabe3ce29275699e66ab1f32d19d583d6bcede9e
Reviewed-by: Alexandru Croitor <alexandru.croitor@qt.io>
All of this connection management code is used only in QtCore and
mustn't be touched by other modules (not even qtdeclarative). So there's
no reason for it to be around and slow down the compilation time of
everything using QObjectPrivate.
Change-Id: If2e0f4b2190341ebaa31fffd16e31313f1b7020f
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
Just to be pedantically correct, but also makes the construction code
slightly more readable.
Pick-to: 6.2 6.3
Change-Id: I29f1c141c0f7436393d9fffd16e2bbf0f361c024
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
In C++20, QDateTime is a direct equivalent of a sys_time<milliseconds>
time point. (Before, it might not have been, because system_clock before
C++20 was not guaranteed to be tracking Unix time, AKA UTC time without
leap seconds.) To be specific, sys_time<milliseconds> corresponds to
a QDateTime using the Qt::UTC timespec.
This patch:
1) adds named constructors taking time_points:
* a generic one taking any time_point convertible (via clock_cast) to
a system_clock (this obviously includes system_clock, but also e.g.
utc_clock)
* another couple taking local_time, interpreted as a duration from
1/1/1970 in local time.
2) adds a named constructor from zoned_time (i.e. a sys_time + a
timezone), that we can easily support via QTimeZone.
3) add conversion functions towards sys_time, matching the existing
to(M)SecsSinceEpoch() functions.
[ChangeLog][QtCore][QDateTime] QDateTime can now be constructed
from std::chrono::time_point objects (including local_time), as
well as from std::chrono::zoned_time objects. Moreover, they
can be converted to std::chrono::time_point using system_clock
as their clock.
Change-Id: Ic6409bde43bc3e745d9df6257e0a77157472352d
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Required for porting away from QLatin1Char/QLatin1String in scope of
QTBUG-98434.
Change-Id: I308d86cefcbfd126929b68f9a853d420840c965f
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Marc Mutz <marc.mutz@qt.io>
std::chrono::year_month_day and related classes offer very
convenient to specify dates.
This patch adds implicit constructors to QDate to support this
convenience, e.g.:
// YYYY-MM-DD, DD-MM-YYYY, MM-DD-YYYY formats:
QDate d1 = 1985y / December / 8;
QDate d2 = 8d / December / 1985;
QDate d3 = December / 8d / 1985;
// Indexed weekday:
QDate d4 = 2000y / January / Monday[0];
QDate d5 = 2000y / January / Monday[last];
and so on.
These are all implemented using the conversion from the std
calendaring classes to sys_days. Conversions between sys_days
and QDate are also added, since they're basically "for free".
I don't expect "ordinary" users to stumble upon it, but it's
worthy mentioning that std::chrono::year *does* have a year
zero (hence, year_month_day in year 0 or below are offset
by one with the corresponding QDate). I've left a note
in the documentation.
[ChangeLog][QtCore][QDate] QDate (and therefore QDateTime)
is now constructible using the year/month/day/week classes
available in the std::chrono library. Moreover, it now
features conversions from and to std::chrono::sys_days.
Change-Id: I2a4f56423ac7d1469541cbb6a278a65b48878b4a
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QAbstractProxyModel::headerData tries to do the "smart" thing and
map sections in the proxy to sections in the source. However there's
no "mapSectionToSource" virtual. Instead, to map horizontal headers, the
code builds a proxy index at row 0 and section N, maps it to the source,
and finds out which source column it gets mapped to. (Same story
for the vertical headers).
... in general this can obviously fail, say you've got a "horizontal
scrambling" proxy model, but in the common case this is OK.
Except, if the proxy is empty (e.g. 0 rows or columns). In this case,
it asks for an illegal index, and if you reimplemented index() yourself
(which you must, since it's a pure virtual in QAPM) and you do bounds
checking, you'll not be pleased at the result.
This turns out to be a massive API liability. To fix this somehow properly,
we can decide that empty models don't get the section remapped (easy).
Less easy is the fact that, when the model does get some data, we have to
emit headerDataChanged() otherwise the views will get broken. So add
this logic too.
Note that QAPM does not normally forward any source model's signal -- a
subclass has to connect to them and handle them explicitly. That's
*another* API liability, all over the place -- data(), headerData(),
flags(), etc.
What I mean by this is that one can create a valid QAPM (by implementing
its pure virtuals) that however is immediately broken by the convenience
that QAPM provides for the rest (data(), headerData(), etc.).
This commit doesn't try and change this in any way, but I'm less and
less convinced of the usefulness of QAPM in its current shape.
Change-Id: I45a8c2139f2c1917ffbf429910fdb92f005f4feb
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: David Faure <david.faure@kdab.com>
We still mentioned the QMAKE_* variables.
Replace them with the OpenGL_DIR CMake variable.
Pick-to: 6.2 6.3
Change-Id: If53c2bff030cf03cb43d10f738949f59ac8dd730
Reviewed-by: Alexey Edelev <alexey.edelev@qt.io>
