In client code I often see code like:
startTimer(1000); //ms
Let the code to be self-explaining. So provide overload
method that takes std::chrono::milliseconds as arg.
QTimer already has std::chrono support, but QObject does not.
Change-Id: Ib348612ce35f1a997b4816fe9e864775cbcbec16
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
now that configureapp does not use it any more, qmake is the only
remaining user. and the license headers already claimed that this code
is part of qmake ...
Change-Id: I9b8a16f8f2b432d2b1143efbdd1f0042305ccc0c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since we can tell the MSVC version from the compiler now, each of the
qmake.conf files is now the same, so let's just have "win32-msvc" and be
future-proof. Likewise for win32-clang-msvc.
qplatformdefs.h was already common.
Since we can't obtain the MSVC version from the unified mkspec name any
more, I dropped the warning level during the qmake bootstrap to reduce
the number of warnings that need to be disabled from compiler version to
version.
There is no point in keeping the old mkspecs, but configure will re-map
the -platform argument to the unified spec as necessary, to keep
existing configure command lines working.
[ChangeLog][Visual Studio] Qt now has a common mkspec for all Visual
Studio versions, called "win32-msvc". The old names which contained the
version number are now gone (but qmake scopes based on the old names
continue to work). The version of the compiler can be obtained from the
MSC_VER and MSVC_VER variables (for example, for Visual Studio 2015,
those contain the values 1900 and 14.0, respectively). Those variables
are also available with the Intel compiler (win32-icc) and with Clang
(win32-clang-msvc).
Done-with: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change-Id: Ib57b52598e2f452985e9fffd14587c0a77a5c09c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
We're asking the compiler anyway, so we can fully use this information
just as well. Note that this actually happens after the spec itself has
been processed, so it was necessary to delay the version-specific flag
handling as well.
Change-Id: Ib57b52598e2f452985e9fffd14587b581d946022
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
instead of hardcoding the compat version in the spec, run cl.exe (which
needs to be around anyway) to figure out what version to emulate.
Change-Id: I6eae97fe9a78f8e340ecdabcdc0d48738497c6d2
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
this makes it consistent with the determination of the default
include/library paths. this makes sense, as it's possible to switch the
sdk/toolchain after building qt (within reason).
a side effect of this change is that for compilers which emulate other
compilers, both the real and the emulated version are now made
available.
Change-Id: Icfcc672c0d2e3d1b5e622993c366063d70ad327c
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
static builds of qt have been embedding their qml files via the qt
resource system since qt 5.7, so the code which attempted to deploy them
into mac bundles (introduced in qt 5.2) is useless nowadays.
Change-Id: I830cd2b660f7cab42a46ec8e002a42d9d299b528
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
the code was broken since 5.0, as it still hardcoded the version number
4 for the plugin basenames.
wince is not supported any more, so there is no point in trying to
restore the code to function.
at a later point, we'll make QTPLUGIN universal enough to cover both
static and dynamic deployment.
Change-Id: I0911ce4aff7a799dd471d6218e046f13dca6d49e
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
They were implied to override QPlatformIntegrationPlugin::keys()
but it was removed before releasing Qt 5.0.
Change-Id: Ia1f1ad27b7511b1141887f5dcde0dadeb2e5cabf
Reviewed-by: Paul Olav Tvete <paul.tvete@qt.io>
Many of the tests still use the old connection signal/slot syntax for
tests. Since I recently made a change to one of the tests within the
Widgets/Util folder, I went through and updated the entire folder to the
Qt-5 connection syntax.
Change-Id: Iaaa5a38858eed41fbc897b66ef291f08458505f1
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
We can use QOverload since Qt 5.7 (it depends on Q_COMPILER_VARIADIC_TEMPLATES
which is required since Qt 5.7).
Use it in the examples to show the best practice.
qOverload currently can't be used because it requires c++14.
Change-Id: I94a3c0db9d551fe169fa3d19c07ec0b329d5946c
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
For instance, if we are passed a QFile to a path that does not exist, being told
"No such file or directory" is significantly more useful than being told
"Device not writable".
Change-Id: I0cc72322f868f06ae2f77b3d0fac7e2094a1d2c7
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
detecting the machine tuple must happen before committing qdevice.pri.
Change-Id: Ic37eda42fff805d6e1edb5dd92898abd59d6bdc9
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
this fixes the x-build for raspberry pi, as that spec refers to the
sysroot.
the path setup doesn't require the device options to be in effect yet,
so it was sufficient to move the existing spec reload to a later point
in time.
Change-Id: Idc521aa13ff441931e954c7c9004472cf7061ee1
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
initially, the idea was that QLibraryInfo would receive a
pre-sysrootified ExtPrefix from the builtin qt.conf. matching this
against the sysroot would then tell us whether to sysrootify the Prefix
from a "regular" qt.conf as well.
however, this would have lead to some major ugliness and inconsistency
between the code paths, so i changed my mind.
unfortunately, i failed to adjust the remaining code, leading to
169a40d51 entirely breaking sysrootification ...
the proper (and nicely consistent) solution is to introduce a
SysrootifyPrefix key to qt.conf. this is user-accessible as well, so as
a bonus it is now possible to adjust the setting at qmake installation
time. incidentally, this omission was the last thing that prevented
using the same qmake host build for any imaginable configuration of the
same qt version ... i think.
Change-Id: Ic0eebf21f93651f6374628c0ad8b206d696a4a7e
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
GCC produces false positives for maybe_uninitialized when compiling with
-Og in these three places. Simply initialize the variables to silence
it. This should be entirely cost-free for normal compilation.
Change-Id: Iab778a6ba25993f78f190e928c1fcc2dbd8b2fcd
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The changes are motivated by the following reasons:
1. SHGetFileInfo() needs to be COM-intialized per thread.
Microsoft's documentation for CoInitalizeEx() is quite
unambiguous about this.
2. Following point 1, using a thread from the global thread
pool means we would taint every such thread with the
COM-initialization state. This may result in unexpected
behavior in other parts of the application. Moreover,
systematic COM-uninitialization can be expensive and
can't be recommended in this case.
3. Even though the timeout duration is pretty generous, the
logic is wrong and could lead to serious errors should
the call to SHGetFileInfo() actually take too long. This
is because we let the thread run with references to the
main thread's stack, namely a reference to the file name
string, and pointers to the result variable and SHFILEINFO
struct.
Running a dedicated thread allows us to ensure points 1
and 2. Point 3 is ensured by making a local copy of the
file name and using local instances for the info struct
and the result. Then, provided the thread has not been
cancelled, we can copy the info and result values back
into the main thread's stack referenced memory areas.
This also removes all need for QWindowsThreadPoolRunner
which will remain in the code base nonetheless.
Change-Id: Ic9c2d6204ac015aa409db2b57a09837361203291
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Andy Shaw <andy.shaw@qt.io>
Adds linux-generic-g++ which can be used for simple cross-building to
well-behaved Linux targets.
Change-Id: I20423249cbcaaf7fc2c65e46b737e682d9222e38
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Laszlo Agocs <laszlo.agocs@qt.io>
Before VS 2013 ToolsVersion contained a .NET version
number (e.g. "4.0"). Since VS 2013 ToolsVersion is the same as the
Visual Studio version number (e.g. "12.0"), which is also the default.
We always wrote "4.0" (except in one special case which used
"14.0"). This doesn't bother Visual Studio itself, but other tools
like PVS-Studio.
Remove the ToolsVersion attribute from generated VS projects for VS
2013 and newer.
Task-number: QTBUG-57694
Change-Id: I7a3bc4534c492e9540f6b968bee8a969980df63f
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Change dcd2f829 introduced fake files with the extension .cbt for custom
build tools that generate code from C++ source inputs. The moc_predefs.h
header file falls into this category, because it is generated from
dummy.cpp.
It turns out that these fake files have to exist. Otherwise the
custom build step is executed on every build. That means re-moccing all
mocables on every build.
Fix this by actually creating the fake .cbt files with some
explanatory comment in them.
Task-number: QTBUG-57695
Change-Id: I251294334425d9914677787d8ba6da1169b4cca5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
QPA headers are shipped as private symbols, so they should be marked as such.
This helps distros to check which applications/libraries need recompiling
on each Qt patch update.
Task-number: QTBUG-57060
Change-Id: Ie09d4d10e1edb5127d45a05a3dfa3f4c9dd012f2
Reviewed-by: Dmitry Shachnev <mitya57@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io>
Missing logic when refactoring image manipulation methods into QtGui
in c52bb03090.
Task-number: QTBUG-57723
Change-Id: I7b55d4451d35faf5fd794daa0b80acbd712f30cd
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@qt.io>
No need to pollute the debug output when attempting to load a program
binary which then gets rejected, because this is not fatal. We will
simply recompile from source then.
Change-Id: I762b7c66fc1ccdf8ab73d720ee10a349c287628b
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
Reviewed-by: Andy Nichols <andy.nichols@qt.io>
We chose to use UTF-8 as it allows us to ensure there's no mistaking the
hostname in case the locale is changed, if the host name contains
characters outside of US-ASCII.
But this didn't work because the code that wrote the hostname always
used the local 8-bit codec instead of UTF-8. On Unix, we used the
result of gethostname(3) directly, which is supposedly on the locale codec.
This commit doesn't fix Windows, which requires _wgetenv, the plan being
to encapsulate that with a qEnvironmentVariable() method.
[ChangeLog][QtCore][QLockFile] Fixed a bug that caused QLockFile not to
recognize a stale lock file if the machine's hostname contained non-US-
ASCII characters, on Unix. A Windows fix is still pending.
Task-number: QTBUG-49640
Change-Id: Ib9d045544ff370ec901626658a84ec4e6575fe21
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Callers can persist a QModelIndex which was not persisted before in a
slot connected to the signal, and such a persisted index must be updated
in the course of the layoutChange.
Store the indexes to persist after emitting the signal.
Task-number: QTBUG-32981
Change-Id: Ibee4c0d84817d72603a03fe5b22fdeefeac0695e
Reviewed-by: David Faure <david.faure@kdab.com>
Similar to the fix in the parent commit, incorrect updating of the
internal data structures during layout changes can lead to dangling
pointers being dereferenced later. Moves are treated as layoutChanges
by this proxy by forwarding to the appropriate method. However, data is
incorrectly cleared prior to that forwarding. Remove that, and let the
layoutChange handling take appropriate action.
Change-Id: Iee951e37152328a4e6a5fb8e5385c32a2fe4c0bd
Reviewed-by: David Faure <david.faure@kdab.com>
In sourceLayoutAboutToBeChanged the source model update is ignored if
the affected parents are filtered out anyway. The same logic is
attempted in the sourceLayoutChanged slot, but there the early-return
logic is applied too late - the mapping is cleared before performing the
early-return. Because pointers into the mapping are used in the
internalPointer of QModelIndexes in this class, persistent indexes used
later will segfault when attempting to dereference it.
Additionally, if a parent becomes invalid as a result of the
layoutChange, it would be filtered out by the condition in the loop,
resulting in a different result in the comparison of emptiness of the
parents container.
Fix that by persisting the parent's container, and performing the test
for early-return before clearing the mapping.
Task-number: QTBUG-47711
Task-number: QTBUG-32981
Change-Id: If45e8a1c97d39454160f52041bc9ae7e337dce97
Reviewed-by: David Faure <david.faure@kdab.com>
The QCompleter documentation mentions QFileSystemModel while the code
sample still uses QDirModel. This patch fixes this by updating the code
sample.
Change-Id: I99a0d2419efcf781af3e9530508df088d77fbbfa
Reviewed-by: Sze Howe Koh <szehowe.koh@gmail.com>
Reviewed-by: Topi Reiniö <topi.reinio@qt.io>
Benchmarking showed most time rendering in rgb64 mode was spend on
memsetting the buffers because they were not declared with a primitive
type.
This patch changes the buffers to quint64, but leaves refactoring
function arguments to a later patch in the dev branch.
Change-Id: Iacc81b0d8e9570b1975dffb85c955b0aabb096a7
Reviewed-by: Eirik Aavitsland <eirik.aavitsland@qt.io>
there is no point in iterating BAR if FOO is (or became) empty.
Change-Id: I86c89bf0ad726a5ab7ead990a27ef7cc32caebbf
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
this is of marginal value, as only our own code ever messes with
QMAKESPEC, and we mostly stopped matching on the spec in favor of
compiler and platform flags.
Change-Id: Ibdd9a9c85067623f0f1f064d139d23b4e6b0677d
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
since ab0cc305, the spec will be replaced by an entirely new one during
configuration, and so needs to update the path separator for
$$shell_{path,quote}(). however, the latter didn't happen, as the spec
reloading doesn't go through the "real" spec loading path.
Change-Id: I45ab3156b8e040f683328ac46e48b09c2eb94ef7
Reviewed-by: Joerg Bornemann <joerg.bornemann@qt.io>
This tag was never spelled "PlatformToolSet". The correct spelling
is "PlatformToolset" (lower case s). VS itself can load qmake-generated
projects despite this misspelling, but tools like PVS-Studio are
bothered by it.
Task-number: QTBUG-57435
Task-number: QTBUG-57694
Change-Id: Ib70e8561f1827e195194bcf518445b2909a8d8c0
Reviewed-by: Jake Petroules <jake.petroules@qt.io>
It allows to set shortcuts for the standard buttons in
QDialogButtonBox.
Restore Qt4's behavior for the "Don't Save" button on macOS
by setting a shortcut for it (it was Cmd-D before Lion,
now it's Cmd-Delete).
Change-Id: I6b56f68f37670962178693a8983d9fe550540856
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@qt.io>
This has always been true, but hasn't been documented well enough, so
triagers are giving incorrect information in bug reports (eg QTBUG-47711
and QTBUG-53221). That incorrect information is being treated as truth
by Qt users which take action based on incorrect information. That is a
problem, so try to make the documentation clear.
Change-Id: I4e44a9a0675cdd7d9289ec209ae32d5a92899fc9
Reviewed-by: David Faure <david.faure@kdab.com>
A child widget without a native handle would previously not be treated as
exposed or active, even if the closest QWindow actually was, resulting
in qWaitFor returning false and QVERIFY failing.
Change-Id: I9df41cbac7aeab63bfa59d8ac77880591393c085
Reviewed-by: Simon Hausmann <simon.hausmann@qt.io>
Because it was a function-level static, the QFactoryLoader was getting
destroyed out-of-sync with the bearer thread stopping. Under normal
conditions, the thread stopped first (~QApplication / ~QCoreApplication
via qAddPostRoutine), and the static got destroyed when the process
exited. However, if QApplication leaked or if the destruction order is
wonky (as seen in PyQt5), the thread could still be running when the
plugins were already unloaded.
With the loader a member variable, it gets destroyed when the thread
stops.
Note: in Qt 5.7, QFactoryLoader no longer unloads the plugins (since
commit 494376f980), so this crash cannot
happen in that version.
[ChangeLog][QtNetwork][Bearer management] Fixed a bug that could cause a
crash on application exit, depending on the order of destruction of the
QCoreApplication object and the QtDBus manager thread.
Task-number: QTBUG-56228
Task-number: QTBUG-52988
Change-Id: I33dc971f005a4848bb8ffffd147853376f82de2a
Reviewed-by: Lorn Potter <lorn.potter@gmail.com>
Reviewed-by: Edward Welbourne <edward.welbourne@qt.io>
This is required for the next commit.
Change-Id: I73fa1e59a4844c43a109fffd148c8c3e3a100c79
Reviewed-by: Oliver Wolff <oliver.wolff@qt.io>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io>
The process of loading a plugin is examplified by the qLoadPlugin
function (though not all users of QFactoryLoader use this function, they
all do something similar):
const int index = loader->indexOf(key);
if (index != -1) {
QObject *factoryObject = loader->instance(index);
if (FactoryInterface *factory = qobject_cast<FactoryInterface *>(factoryObject))
if (PluginInterface *result = factory->create(key, std::forward<Args>(args)...))
return result;
}
QFactoryLoader::indexOf already locked the mutex, but not
QFactoryLoader::instance. This commit fixes that.
Note that calling the virtual create() in the plugin's factory is not
protected by the mutex. Each plugin's factory must be thread-safe and
also create an object that works on any thread too. It's also the
responsibility of the caller of qLoadPlugin to ensure that it's called
thread-safely.
Task-number: QTBUG-42855
Change-Id: I63e21df51c7448bc8b5ffffd148ebee33d4c47de
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Timestamp is necessary for testing custom mouse event handlers e.g. what
Qt WebEngine uses for handling triple and quadruple mouse clicks.
Based on commit 181ee8f9ff
Task-number: QTBUG-56223
Change-Id: I2bf840f326255333eec83ca8c42f087cb7deb1fb
Reviewed-by: Kai Koehne <kai.koehne@qt.io>
