Since 9c8d1ca18b, the test would fail
when High DPI scaling is enabled:
FAIL! : tst_QWidget::translucentWidget() Compared QImages differ in device pixel ratio.
Actual (actual): 2
Expected (expected): 1
.\tst_qwidget.cpp(8913) : failure location
Set the device pixel ratio on the expected pixmap to fix this.
Change-Id: I517495931c2c6b1f49125bb4b5836e304bdbf545
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
The function calculating a correction for the size of
windows metrics depending on screen would bail out when high
DPI scaling was disabled. This is wrong since the correction
is also needed in that case, delete the clause.
Task-number: QTBUG-64890
Change-Id: Idef22e18fc616a211ccac48400490fc52393a338
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
- use range-based for loops where possible
- use nullptr
- use member initialization
- remove a lot of C-style casts
- use override
- fix some signedness warnings
- add some missing break statements
Task-number: QTBUG-76493
Change-Id: Ica6ed65ec29e958406e54d816b8a679ed81bd177
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
When a prepared statement is still alive after the database was removed
with QSqlDatabase::removeDatabase(), the cleanup routine is trying to
access the driver which is no longer alive which results in a crash.
Fix it by checking if the driver is still alive similar to
5f66486cc2.
Fixes: QTBUG-43889
Change-Id: Ib466a76d014e32c055d203bda15b075ad3dff3d9
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Reviewed-by: Jesus Fernandez <jsfdez@gmail.com>
This reverts commit 5859f7d0d9.
Reason for revert: the blocker for qtdeclarative has been merged
(in qtdeclarative/c060f6e765a2f155b38158f2ed73eac4aad37e02).
Change-Id: Ie69cb1567417173f543e88f659658fe03ba28830
Reviewed-by: Liang Qi <liang.qi@qt.io>
Cleanup QTableView autotest:
- use range-based for loops where possible
- use nullptr
- use member initialization
- use new signal/slot syntax
- remove a lot of c-style casts
- use static invocations
- use override
- instantiate objects on stack instead heap to avoid memleaks
Change-Id: I52fee26697b1732afa9f965e600d4c59551370ce
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Change-Id: I71c6a10f6593ac28bf8f60d9db8d167cf88715cb
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
The logic was changed in ee82f8661 to only draw a window background
when the window was textured, and otherwise ask for a clear window
background. This has an unfortunate side-effect on macOS 10.15 that
the window's title bar will be partially transparent and reflect the
content under the window, with a blur effect.
It also inadvertently broke the use-case of setting the NSWindow
background color explicitly.
With this patch we're back to the behavior before ee82f8661, and
users who still want to have a non-borderless window with a clear
background can still do this by setting the background color to
the clear color manually.
Task-number: QTBUG-77637
Change-Id: I8a11bc46e6393b29a37f002ea123a987048106b9
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
When setting a DPI in xrdb, it should have the same effect on apps that
enable scaling and apps that don't (including Qt4 and GTK applications).
That's what happened in Qt 5.13, while the recent changes removed that
division, and as a result the fonts were huge in Qt5 apps compared
to Qt4/GTK/kwin/plasmashell/krunner (which don't scale, but do honor
the font DPI).
Change-Id: Icd7be2d15a9b50982ae624e41bd9e546f315d58b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Tidy up QDateTime::offsetFromUtc's doc, in the process. We don't take
DST into account for dates before the epoch; that should be mentioned
when saying we take DST into account. Also, referring to *this as the
"current" time begs to be misunderstood.
The \class comment also misleadingly claimed that we don't take into
account any changes to time-zone before DST; where, in fact, we only
ignore DST changes before 1970, not changes to standard offset.
Change-Id: I090e668edf0338c825f5afcc67f894579a129c46
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
There is no year 0 in the proleptic Gregorian calendar, so QDate()
won't be happy if asked for a date in it. Tweak scanning of the data
we get from MS-Win so as to avoid a date calculation that could
otherwise happen in year 0 when constructing
QDateTime(QDate(1, 1, 1), QTime(0, 0, 0), QTimeZone("Australia/Sydney")).
Added a test for this case, which Oliver Wolff has kindly verified
does reproduce the assertion failure. However, Coin is unable to
reproduce, as all its MS builds are configured with -release, so
Q_ASSERT() does nothing. (The relevant code then skips over year 0,
albeit for the wrong reasons, and gets the right results, albeit
inefficiently, leaving no other symptom by which to detect the
problem.)
Fixes: QTBUG-78051
Change-Id: Ife8a7470e5bd450bc421e89b3f1e1211756fc889
Reviewed-by: Qt CI Bot <qt_ci_bot@qt-project.org>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
This reverts commit 521a85395d.
Having libraries resolved to absolute file paths by configure has
annoying consequences:
1. The Qt installer needs to unabsolutify paths in all kinds of files.
This is error-prone and fragile.
2. It hurts Qt's relocatabilty. The absolute paths are unlikely to be
right on different systems.
3. Qt's configure must imitate linker behavior correctly to do the
resolution right on every platform, which is hard to get right.
Consequently, the disadvantages of 521a8539 outweigh the advantages.
Task-number: QTBUG-72903
Change-Id: I3e159c46a1348963615b95614e56f026ecb2aefd
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
...and change the return value of makeThreadLocalNativeContextCurrent() to
a bool since we expect this to mirror QOpenGLContext::makeCurrent().
Change-Id: I339507152e461fe28fcf7fe777165e6d0072f055
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
After these two classes were no longer marked final clang started
complaining because their dtor is not marked virtual.
Amends 9dc594b2bf
Change-Id: I42b78c0b444935d3e0cb4d476d3881fd5fb5c3cb
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The code followed a pattern used elsewhere whereby a return value is
transmitted out of a task executed on a separate thread by way of
shared ownership of the value using QSharedPointer.
In the present case, however, the pattern was applied to an argument
of the task, not its return value, so remove all the sharing machinery
and just copy the argument (a QString) into the task (a lambda).
Change-Id: Ib997322ed70201781b6012c7e4f945b124b05868
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
QList<QPoint> is horribly inefficient™ (on 32-bit platforms).
Fix by using a QVector instead.
Change-Id: Id85cb71404f329049c3e9997e51113035569e1b4
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
It turns out that QWaitCondition is a std::condition_variable_any. The
_any variant works with any mutex type, but requires a native mutex
for the native condition variable. So, QWaitCondition and
std::condition_variable_any both require two different mutexes: the
one the user passes in, and an internal one.
std::condition_variable, however, only works with std::mutex, and
since both are backed by the native API, condition_variable can use
the mutex passed in by the user instead of having to use an internal
one.
So, port from 2 × QWaitCondition + QMutex (2 × native cond + 2 ×
native mutex + Qt mutex) to std::condition_variable + std::mutex (2 ×
native cond + native mutex), shaving the overhead of two additional
mutexes (one Qt, one native) as well as the memory allocation
performed by QWaitCondition (for its Private).
Speeds up the writeOnly case by ~1/8th:
PASS : tst_QReadWriteLock::writeOnly(QReadWriteLock)
RESULT : tst_QReadWriteLock::writeOnly():"QReadWriteLock":
- 39,703 msecs per iteration (total: 39,703, iterations: 1)
+ 34,950 msecs per iteration (total: 34,950, iterations: 1)
Change-Id: I196cb13a27242fc1cb99723dfab5b2e5f8522143
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Volker Hilsheimer <volker.hilsheimer@qt.io>
Most of these are unique_locks because they call QWaitCondition::wait()
and it doesn't feel right to use qt_scoped_lock if the lock is dropped
within the scope.
Change-Id: I506eede63008dad135c21112e578da4f7684e528
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
- don't write explicit meta functions, use std::conditional
- = default the default ctor
The class is already not trivially-copyable, so making the default
ctor trivial doesn't change the ABI.
Change-Id: I8e35bbbb35973c9ff8fc48dfbfc10061de4bfd30
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
The example snippet was using app.installTranslator() even
installTranslator() is a static function. And since app is a
QApplication instead a QCoreApplication this could lead to the
assumption that a QTranslator can only be used for gui applications.
Therefore use the correct static invocation
QCoreApplication::installTranslator().
Change-Id: Ia3ce00f25230c2fe2bdc159ec14c88c961924651
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
...if there is one and the concept is applicable in the first place.
Change-Id: Iab202c1c1cdd229f4910159de4cae7ce30805ea9
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Typically caught in vkQueueSubmit().
The WaitIdles that can be hit upon cleanup must be guarded by
!deviceLost because they inexplicably cause an infinite blocking
wait when the device was already reported as lost. (with NVIDIA
at least)
Change-Id: I7142e2461e1aed9ee3068b2b963cdf2c678ca4e0
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Starting with D3D11. The other backends will follow later.
Change-Id: I4f165c9f1743df0fb00bdce1e898917575bf5f6e
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
When interfacing with reality (i.e. native platform APIs provided in C,
ObjC, or COM), each of the APIs has its own idea of what types it likes
to use for sizes, points, rects, etc.
Out of the hundreds of warnings Qt Creator throws at us with the default
clang check level when opening one of the rhi backends not a single one
is useful. Regardless, let's try getting rid of what we can. This mostly
involves throwing in int/uint conversions in order to get the signedness
change warnings to shut up. The things that are either unacceptable to
change or are beyond our control are left untouched.
Change-Id: I6e4cb7cd373bf48dc990eaf83344242bbf30bd66
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
QColorVector and QColorMatrix are default-constructed following the
Qt philosophy of types always being well-defined. The corner-case where
we need uninitialized versions of these types for performance reasons
is handled explicitly.
Change-Id: I629334d1ffc63563ec9fd1298c623946e0799d1d
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
The device can be lost when physically removing the graphics adapter,
disabling the driver (Device Manager), upgrading/uninstalling the
graphics driver, and when it is reset due to an error.
Some of these can (and should) be tested manually, but the last
one has a convenient, programmatic way of triggering: by triggering
the timeout detection and recovery (TDR) of WDDM. A compute shader
with an infinite loop should trigger this after 2 seconds by default.
All tests in tests/manual/rhi can now be started with a --curse <count>
argument where <count> specifies the number of frames to render before
breaking the device. Qt Quick will get an environment variable with
similar semantics in a separate patch.
Change-Id: I4b6f8d977a15b5b89d686b3973965df6435810ae
Reviewed-by: Christian Strømme <christian.stromme@qt.io>
Found while cleaning up SPDY remains: I've noticed that for H2 case
I never check if incomingSslConfiguration is nullptr or not, but
the code several lines below - does it, which looks kind of moronic.
This configuration is initialized when the delegate is created, so
no need to have this if-statement. Instead, assert, making this
behavior a requirement.
Change-Id: I90fb84337be925a3288252aa2491b4c23d6c6cbb
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
At first glance, libraryPathMutex is only recursive because
setLibraryPaths(), addLibraryPath() and removeLibraryPath(), all of
which lock libraryPathMutex, may call libraryPaths(), which does, too.
This is easily fixed by splitting libraryPaths() into public
libraryPaths() and private libraryPathsLocked(), the latter expecting
to be called with the libraryPathMutex already held. And this is what
this patch does.
However, on second glance, the building of the initial app_libpaths
calls a monstrous amount of code, incl. QLibraryInfo, and some of
that code probably re-enters one of the library-path functions.
So while this patch is a step towards making libraryPathMutex
non-recursive, it's probably not the end.
Change-Id: I3ed83272ace6966980cf8e1db877f24c89789da3
Reviewed-by: Ulf Hermann <ulf.hermann@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Results on my machine:
PASS : tst_QReadWriteLock::writeOnly(QMutex)
RESULT : tst_QReadWriteLock::writeOnly():QMutex:
3,607 msecs per iteration (total: 3,607, iterations: 1)
PASS : tst_QReadWriteLock::writeOnly(QReadWriteLock)
RESULT : tst_QReadWriteLock::writeOnly():QReadWriteLock:
39,703 msecs per iteration (total: 39,703, iterations: 1)
PASS : tst_QReadWriteLock::writeOnly(std::mutex)
RESULT : tst_QReadWriteLock::writeOnly():std::mutex:
3,697 msecs per iteration (total: 3,697, iterations: 1)
PASS : tst_QReadWriteLock::writeOnly(std::shared_mutex)
RESULT : tst_QReadWriteLock::writeOnly():std::shared_mutex:
5,727 msecs per iteration (total: 5,727, iterations: 1)
PASS : tst_QReadWriteLock::writeOnly(std::shared_timed_mutex)
RESULT : tst_QReadWriteLock::writeOnly():std::shared_timed_mutex:
5,921 msecs per iteration (total: 5,921, iterations: 1)
(the 'nothing' test of course doesn't work with writing, as writing to
the same QString from different threads is UB)
Change-Id: Ia78b54963a51eaf6563ce0d243316a3337056a83
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
In QImageReader, also replace a QMutex with a QBasicMutex, making the
code similar to the corresponding code in QPicture.
Change-Id: Ia1cd546eccd3662837762e506235e350b7a08647
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
By setting the accepted action to be the one from the response it will
enable the user to set the drop action in their code and this will be
reflected at the platform level.
Change-Id: I7b9459b228c00ef01d91649b3405316729713164
Fixes: QTBUG-77427
Reviewed-by: Morten Johan Sørvig <morten.sorvig@qt.io>
Cleanup QtWidgets tools examples:
- use member-init (clang-tidy)
- fix includes/don't include QtWidgets globally
- include own header first
- use nullptr (clang-tidy)
- avoid c-style casts
- use QVector instead QList
- use QItemDelegate instead QStyledItemDelegate
Change-Id: Ibe9440cdf711e5cc2138c054864edebe1fc95731
Reviewed-by: Paul Wicking <paul.wicking@qt.io>
We need to have the right idea of robustness, so check for extension.
Fixes: QTBUG-78107
Change-Id: I26987269e5c50bee20e2e3cc6d75f91a6c9af25e
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
QFileSystemWatcher has open bugs, so users should be able to help
troubleshoot.
Change-Id: I6b703e25f294944469d20fd36012b6a55133732a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Found while preparing SPDY retirement.
Change-Id: I30f923fdeb0f6f0b5e808a3e7b7d81ddb9c4ef12
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
If an app wants use a debug framework of Qt, it is still expected that
the app should link against the release version, and just set
DYLD_IMAGE_SUFFIX=_debug when running the app.
This was not the case before, where the CMake Config files told CMake
to link explicitly against the debug libraries. This caused crashes
due to the Qt plugin loader mechanism still trying to find a release
platform plugin, which in turn would load release libraries, and thus
the application would end up loading both debug and release plugins.
Make sure the Config files in a framework case always reference the
release libraries (even though this might be counter intuitive).
Otherwise users of the Debug Config files would always get
crashes.
Fixes: QTBUG-78131
Change-Id: I88b1dc421477ad186012ca67b328a891128eb568
Reviewed-by: Cristian Adam <cristian.adam@qt.io>
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
src/corelib/global/qnamespace.qdoc:3279: (qdoc) warning: Can't link to 'QGuiApplication::setHighDdpiScaleFactorRoundingPolicy()'
src/corelib/time/qislamiccivilcalendar.cpp:49: (qdoc) warning: Can't link to 'QJijriCalendar'
src/network/ssl/qsslsocket.cpp:1510: (qdoc) warning: Can't link to 'QSslConfiguration::defaultCaCertificates()'
src/network/access/qhttp2configuration.cpp:49: (qdoc) warning: '\brief' statement does not end with a full stop.
src/gui/text/qtextformat.cpp:532: (qdoc) warning: Undocumented enum item 'TableBorderCollapse' in QTextFormat::Property
src/gui/text/qtextdocument.cpp:2066: (qdoc) warning: Undocumented enum item 'UnknownResource' in QTextDocument::ResourceType
src/gui/kernel/qguiapplication.cpp:3500: (qdoc) warning: Undocumented parameter 'policy' in QGuiApplication::setHighDpiScaleFactorRoundingPolicy()
Change-Id: I3573ef98cf9b58d16525c356270fe009fdffcf45
Reviewed-by: Shawn Rutledge <shawn.rutledge@qt.io>
Cleanup QTableWidget autotest:
- use range-based for loops where possible
- use nullptr
- use member initialization
- use new signal/slot syntax
- remove a lot of C-style casts
- use static invocations
- use override
- instantiate objects on stack instead of heap to avoid memleaks
Change-Id: I99ed144caab88d648d5ab987ce0963fbc6f1197d
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
QSharedPointer is made for passing around by value. It is unclear why
in so many repeated cases a QSharedPointer is created on the stack,
then a copy of it is new'ed up, passed into a lambda to be deleted
inside it.
First, it requires an additional heap allocation. Because it's passed
as a raw pointer to QSharedPointer, however, there's also always the
danger that it's leaked by seemingly-innocuous changes such as adding
an early return from the lambda (and some of them could really use
one, with the ifs nesting several levels deep).
All this is not needed, though. It's perfectly ok to store a copy of a
QSharedPointer, by value, in a lambda, and keep one copy outside
it. Poor man's std::future, if you will.
So, do away with all that, just pass the shared pointer by value into
the lambda, and, as a drive-by, replace some ephemeral QLists with
QVLAs. In one case, replace a QPair<int, int> with a struct to make
the code using that type more accessible ('first' and 'second' are
really, really bad variable names if they, in fact, represent
'startOffset' and 'endOffset').
Also port directly to shared_ptr / make_shared. Saves one memory
allocation each, due to the co-allocation of payload and control
block, and even though there's QSharedPointer::create, which does
this, too, std::shared_ptr is simply much lighter on the use of
atomics (copying a QSP ups two ref counts, copying a std::shared_ptr
just one). Since these variables live behind the API boundary, there's
no reason not to prefer the more efficient alternative.
Change-Id: I4b9fe30e56df5106fc2ab7a0b55b2b8316cca5fe
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Mårten Nordheim <marten.nordheim@qt.io>
The volume names displayed did not match those of Windows
Explorer; for example "New Volume (X:)" would be displayed for
mapped network drives.
Replace GetVolumeInformation() and manual formatting by the
normal display name of IShellItem.
Fixes: QTBUG-78043
Change-Id: Ia742b7733e8ddc31e9506f15d90d065b985a111d
Reviewed-by: André de la Rocha <andre.rocha@qt.io>
Since b3fc5e1ea3,
topData()->initialScreenIndex has always been short-lived: it only
remembers the screen in case the widget parent is a QDesktopScreenWidget
(gotten from QDesktopWidget::screen()), only until the window is
created. Then it is reset. In the case of exec() we need to avoid
calling setScreen() twice, because that would set the screen once, then
forget which screen it was supposed to be on, then set the screen again
when exec() calls popup(). This is achieved by using the stored
eventLoop pointer to detect that popup() is being called from exec(),
and avoid calling setScreen() a second time in popup(), because exec()
already needed to call createWinId() before it created the event loop.
Amends 82da8306bc
Task-number: QTBUG-76162
Change-Id: I70da517b9d530630e59d103cb2a1ce11c897b2c8
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Joni Poikelin <joni.poikelin@qt.io>
