| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
All remaining pieces are gone, configuration included.
Relevant CMakeLists and configure.cmake were regenerated.
Fixes: QTBUG-76502
Change-Id: I667b5da7e3802830d236d50b5e9190c2ee9c19e2
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
|
|
|
|
|
|
| |
Change-Id: I691ecbaf9ea0796decbb48fd62b25d0a2941d979
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Timur Pocheptsov <timur.pocheptsov@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 494376f980e96339b6f1eff7c41336ca4d853065), 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>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new modular configuration system requires one global
header per module, that is included by all other files in
this module.
That header will later on #include the configuration file
for Qt Network. For now it defines the Q_NETWORK_EXPORT
macro for this library.
Change-Id: I9c45d425baf881c431ed71fd457c7feb2c123855
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
| |
From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see
http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/
Updated license headers to use new LGPL header instead of LGPL21 one
(in those files which will be under LGPL v3)
Change-Id: I046ec3e47b1876cd7b4b0353a576b352e3a946d9
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qt copyrights are now in The Qt Company, so we could update the source
code headers accordingly. In the same go we should also fix the links to
point to qt.io.
Outdated header.LGPL removed (use header.LGPL21 instead)
Old header.LGPL3 renamed to header.LGPL3-COMM to match actual licensing
combination. New header.LGPL-COMM taken in the use file which were
using old header.LGPL3 (src/plugins/platforms/android/extract.cpp)
Added new header.LGPL3 containing Commercial + LGPLv3 + GPLv2 license
combination
Change-Id: I6f49b819a8a20cc4f88b794a8f6726d975e8ffbe
Reviewed-by: Matti Paaso <matti.paaso@theqtcompany.com>
|
|
|
|
|
|
|
|
|
| |
- Renamed LICENSE.LGPL to LICENSE.LGPLv21
- Added LICENSE.LGPLv3
- Removed LICENSE.GPL
Change-Id: Iec3406e3eb3f133be549092015cefe33d259a3f2
Reviewed-by: Iikka Eklund <iikka.eklund@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Recreating QCoreApplication could cause a crash in QNetworkAccessManager
constructor. That was caused by an invalid shutdown detection introduced
in f273d6fbc02055ff3999adc0df76360ca0670435.
Task-number: QTBUG-36897
Change-Id: Ib5bba773a2a4fcde690a3a93680aef551aae3a5b
Reviewed-by: Peter Hartmann <phartmann@blackberry.com>
|
|
|
|
|
| |
Change-Id: Ic804938fc352291d011800d21e549c10acac66fb
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
|
|
|
|
|
|
|
|
| |
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
|
|
|
|
|
|
|
|
|
|
| |
Use an include guard in headers to ensure the header is not included
more than once. Make the header guard match its file name.
Also, cpp files should include their own headers first (but below config.h)
Change-Id: Iecf5da23c0f8e6d457f67657b88ef7557bde9669
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
|
|
|
|
|
|
|
|
|
|
| |
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The original architecture of the QtNetwork bearer support hosted the
engines in the application's main thread, but this causes some problems.
If the QNetworkConfigurationManager is constructed in a worker thread,
then it is populated asynchronously without any notification when it is
done (the app gets incomplete or missing results)
Fixing that by restoring the earlier behaviour of using blocking queued
connections to wait for the lists to be populated caused a regression,
as some applications deadlock because the main thread is waiting on the
worker thread at this time.
By introducing a dedicated worker thread for the bearer engines,
QNetworkConfigurationManager can be safely constructed in any thread
while using blocking queued connections internally.
Task-number: QTBUG-18795
Change-Id: Iaa1706d44b02b42057c100b0b399364175af2ddb
Reviewed-by: mread
(cherry picked from commit 5f879c55e531165cc2569b03c3796d0f33d0a0b7)
Reviewed-by: Jonas Gastal <jgastal@profusion.mobi>
Reviewed-by: Murray Read <ext-murray.2.read@nokia.com>
Reviewed-by: Alex <alex.blasche@nokia.com>
|
|
|
|
|
|
|
| |
Replace Nokia contact email address with Qt Project website.
Change-Id: I431bbbf76d7c27d8b502f87947675c116994c415
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
|
|
|
|
| |
Change-Id: I02f2c620296fcd91d4967d58767ea33fc4e1e7dc
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current code was meant to be a thread-safe initialisation that
also ran a couple of extra steps. But it wasn't. While it's ok to call
qAddPostRoutine(), the call to updateConfigurations() was
thread-unsafe. It is possible that another thread got the pointer to
the Private before updateConfigurations() finished.
So instead protect the initialisation with a mutex.
It's possible that the value of the pointer becomes visible to
other processors before the other contained values, so use
atomics here.
To call qAddPostRoutine safely from the main thread, use the trick
of deleteLater() (which is thread-safe) in another thread connecting
to a slot.
Change-Id: If9bab88138755df95a791f34b0be8684207979d7
Reviewed-on: http://codereview.qt-project.org/5028
Reviewed-by: Qt Sanity Bot <qt_sanity_bot@ovi.com>
Reviewed-by: Bradley T. Hughes <bradley.hughes@nokia.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes in 4.8 led to a timer being created in the wrong thread.
I have restored the invokeMethod used to call startPolling() to solve
this problem.
Reviewed-By: mread
(cherry picked from commit e9e95f75e7c1e8325c2acce0087ff8677d773779)
Change-Id: I8b89fa89766679beb2d469f9bbd1f5e2233f061b
Reviewed-on: http://codereview.qt.nokia.com/138
Reviewed-by: Markus Goetz
|
|
|
|
|
|
|
| |
Updated version of LGPL and FDL licenseheaders.
Apply release phase licenseheaders for all source files.
Reviewed-by: Trust Me
|
|
|
|
|
|
|
|
|
|
|
|
| |
startPolling() is called by each engine, so before it would start
multiple singleshot timers. So I moved the timer to the class
and check if it has already been started before it is activated
again. So that we just use one timer.
Task-number: QTBUG-17219
Reviewed-by: Iiro Kause
Reviewed-by: Kranthi Kuntala
(cherry picked from commit 2506b86828ca8140c2f22d85a4378df40899b132)
|
|
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://qt.gitorious.org/qt/pages/GitIntroductionWithQt
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12
|