For the conflicts in msvc_nmake.cpp the ifdefs are extended since we
need to support windows phone in the target branch while it is not there
in the current stable branch (as of Qt 5.2).
Conflicts:
configure
qmake/generators/win32/msvc_nmake.cpp
src/3rdparty/angle/src/libEGL/Surface.cpp
src/angle/src/common/common.pri
src/corelib/global/qglobal.h
src/corelib/io/qstandardpaths.cpp
src/plugins/platforms/qnx/qqnxintegration.cpp
src/plugins/platforms/qnx/qqnxscreeneventhandler.h
src/plugins/platforms/xcb/qglxintegration.h
src/widgets/kernel/win.pri
tests/auto/corelib/thread/qreadwritelock/tst_qreadwritelock.cpp
tests/auto/corelib/tools/qdatetime/tst_qdatetime.cpp
tests/auto/gui/text/qtextdocument/tst_qtextdocument.cpp
tools/configure/configureapp.cpp
Change-Id: I00b579eefebaf61d26ab9b00046d2b5bd5958812
In cases where QGuiApplication is instantiated by a library
embedded into another application via some plugin mechanism
(for example, Active X controls built using Qt), the QPA platform plugin
and other plugins cannot be found next to the application executable.
In this case, the library should set the application file path to
its deployment location such that plugin paths are set accordingly,
the directory is added to the path and qt.conf is found, should it exist.
Task-number: QTBUG-34989
Change-Id: I4a53104b5121a8d26751129912f999228be45dfd
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Specify the root directory to be the package root. Only plugins
inside the root can be opened (actually also only files). Furthermore
current defaults to the package root now, which in most cases is
identical to previous behavior.
When attempting to load a plugin the path can either be specified in
host format "C:/..." or as plugin absolute "/platforms/...". Check for
both, with preference of latter case, like when qt.conf is used with
/ being used as plugin path.
Change-Id: I7e3da293362488b62a3357c4882ebf5e048dcf95
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
Reviewed-by: Oliver Wolff <oliver.wolff@digia.com>
This isn't a hot codepath, there is no gain to doing this. It introduces
unnecessary bloat (see e.g.
https://www.webkit.org/blog/2826/unusual-speed-boost-size-matters/) and
complicates boosting Qt application startup in cases where argv[0] is
overwritten.
Change-Id: I55b2b98b0de6b06fe7a049de262f3e19936b73db
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Default values should have mark-up to denote that they are code.
This commit changes:
-"property is true" to "property is \c true".
-"Returns true" to "Returns \c true".
-"property is false" to "property is \c false".
-"returns true" to "returns \c true".
-"returns false" to "returns \c false".
src/3rdparty and non-documentation instances were ignored.
Task-number: QTBUG-33360
Change-Id: Ie87eaa57af947caa1230602b61c5c46292a4cf4e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Jerome Pasion <jerome.pasion@digia.com>
999e5162ec breaks QPlatformIntegration
implementations that perform tasks in their constructor that rely on
the event dispatcher. For example creating a QSocketNotifier is not
possible anymore since the event dispatcher is created later on.
This is fixed by introducing an additional virtual in
QPlatformIntegration that gets called after createEventDispatcher().
Two broken platform plugins have been identified so far: eglfs is
creating socket notifiers to read events from input devices and xcb's
input context plugins may use dbus. Both are updated accordingly.
Task-number: QTBUG-33768
Change-Id: I5badb623958a52ab5314ff93dd7d60061f5df70a
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
696060134d introduced the use of
QBasicMutex and QMutexLocker (qmutex.h) but that wasn't #included. I
don't know in what way my build is different, though.
Change-Id: Ie3df3c746fdf1c4735f298c3578cd93a9a14327e
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Tests will typically create multiple QCoreApplications, some of them
with different argv[0] than others, so we can't use a static variable
to keep the cached application name.
Change-Id: Icd97527730558944473a71373326b4a82f1b7cf7
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Various global changes, primarily preprocessor flow, to support the
WinRT platform.
Change-Id: I3fa9cf91d5fb24019362e88fcf205e31b4f810b5
Reviewed-by: Andrew Knight <andrew.knight@digia.com>
The QCommandLineParser class provides a means for handling the command line options.
QCoreApplication provides the command-line arguments as a simple list of strings.
QCommandLineParser provides the ability to define a set of options, parse the
command-line arguments, and store which options have actually been used, as
well as option values.
Done-with: Laszlo Papp <lpapp@kde.org>
Change-Id: Ic7bebc10b3f8d8dd06ad0f4bb897c51d566e3b7c
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Disable the code path which queries /proc/<pid>/exe for the
current executable path, as from a Q_OS_ANDROID perspective,
this executable will be the Dalvik binary. Instead we
get the application directory via the fallback, by
looking in argv[0], since this is set to the location of the
application binary.
Task-number: QTBUG-32852
Change-Id: Ib93050f41cbd47aaf71284e8bfa6a3247131d978
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
QCoreApplication::argv() method was obsolete in Qt4.8
and removed in Qt5.0.
Change-Id: I217402f774f5509c8ca317a35c831ffa5ac2af06
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
The deadlock is caused because the QEvent is destroyed while holding the
event list mutex. And the QEvent may have a custom destructor that will
re-enter the event handlng code.
The QScopedPointer that should destroy the event must be created after
the MutexUnlocker.
Regression introduced by commit f9035587b9
Task-number: QTBUG-31606
Change-Id: I6b2cbc2656eacdec61b641886953f00bf5b3ff36
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Instead of storing the application type as a uint, we use the enum provided
by QCoreApplicationPrivate. The former resulted in a few cases of wrong
logic where the values got mixed up, such as always printing the QtCore
console warning, even for GUI applications.
The qt_eval_is_supported function has been refactored to return enums instead
of magic values, to make the logic easier to read.
The same goes for qt_eval_days_left, which now only concerns itself with
the number of days left. qt_eval_is_expired() has been added to use for
easy checking of expiration date.
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: Ia0e85b2103f790a7e02e0d6e567a477b3145fcb9
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
It is deprecated and clang is starting to warn about it.
Patch mostly generated by clang itself, with some careful grep
and sed for the platform-specific parts.
Change-Id: I8058e6db0f1b41b33a9e8f17a712739159982450
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Empty arguments list could lead to crash, due to access of first element.
Besides, empty application file path will be cached now universally.
Change-Id: Ibe1a668da364d87d8431567dfc999cb394686081
Reviewed-by: Sérgio Martins <sergio.martins.qnx@kdab.com>
Reviewed-by: Fabian Bumberger <fbumberger@rim.com>
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
Task-number: QTBUG-30134
Restore the lines in qcoreapplication.cpp removed by commit
950b35cf97 to ensure QThreadData and
QAdoptedThread object of main thread is destroyed at application exit.
We don't set QCoreApplicationPriavte::theMainThread to 0 as before since
it will be set to zero in QThreadData::~QThreadData()
Change-Id: I8ee56aff5a933ce1d812b07fb00a29ed0839ab6e
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
this required making it compile with QT_NO_QOBJECT. of course this
disables anything related to threading and event processing.
needed for bootstrapping qmldevtools (qmlmin, lupdate)
Change-Id: I6f8bd3996ac7b6eee49a5b8a55143d358abe35ee
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Currently, QCoreApplication::startingUp() returns true even after
a QCoreApplication has been constructed. This patch makes it return
false after it has been constructed and adds checks to QApplication
and QGuiApplication to ensure that it returns true within the
constructor of these classes.
Task-number: QTBUG-2591
Change-Id: Ie511522d35b5658c20be43dd112eae18c205277f
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Reviewed-by: Samuel Rødal <samuel.rodal@digia.com>
This avoids crashes accessing deleted memory when creating a QObject
after the last QObject had been deleted, like a qDebug() in global
destructors.
==41000== Invalid read of size 4
==41000== at 0x5F01ED5: bool QBasicAtomicOps<4>::ref<int>(int&) (qatomic_x86.h:208)
==41000== by 0x5F01309: QBasicAtomicInteger<int>::ref() (qbasicatomic.h:147)
==41000== by 0x5F24051: QThreadData::ref() (qthread.cpp:100)
==41000== by 0x614A984: QObject::QObject(QObject*) (qobject.cpp:681)
==41000== Address 0x6ee73f0 is 0 bytes inside a block of size 152 free'd
==41000== at 0x4A0736C: operator delete(void*) (vg_replace_malloc.c:480)
==41000== by 0x5F240BF: QThreadData::deref() (qthread.cpp:109)
==41000== by 0x6113F6B: QCoreApplicationData::~QCoreApplicationData() (qcoreapplication.cpp:268)
The comment right above the change in qthread.cpp looks eerily similar
to the problem I'm trying to fix. However, the actual change that
introduced the change is not in the Qt public history, so we can't
know for sure what the problem was then.
Change-Id: I0dba895b041fe6cf81e6f8939ca85035cd00aad1
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
The various string properties are good candidates for exposure to QML.
While QCoreApplication itself is unlikely to be exposed to QML directly,
a wrapper exposure also needs these signals in order to react to changes
from QCoreApplication.
Change-Id: I266da6010f1c9300de4bb5e7775a0bdacab7f26c
Reviewed-by: Richard J. Moore <rich@kde.org>
This is necessary for initializing things in a library, which require
a QCoreApplication instance (unlike Q_CONSTRUCTOR_FUNCTION, which runs
before that). Example use cases: KCrash (segv handler), and KCheckAccelerators
(debugging tool triggered by magic key combination).
Change-Id: I5f4c4699dd4d21aea72b007989ba57467e86ed10
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This change makes it possible to use the QML JS debugger with KDE
applications.
Change-Id: Id5838fa34dcb8b54127abc6da6fe7c2e9a5a1c2e
Reviewed-by: David Faure (KDE) <faure@kde.org>
Reviewed-by: Kai Koehne <kai.koehne@digia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@digia.com>
Remove watchUnixSignal(), unixSignal() and associated code. These are relics
which were being used by QWS to detect virtual console switching. Currently
they are not being used at all. The recommended way to watch for Unix signals
in Qt is http://doc-snapshot.qt-project.org/5.0/unix-signals.html.
Change-Id: Id34207cb8853442302a45b2816356da0f973ebb1
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
the condition is supposed to suppress the event emission, not to trash
the return value.
Change-Id: I3e327ceedb909ac29ba975c49b0f039b50eb4ee1
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Listing all files with QDir is slow.
Instead, use argv[0] for zygotized apps and _cmdname() for
non-zygotized.
Apps run through the terminal will fall in the zygotized case,
which is ok.
Note about zygotized apps:
Zygotized apps don't have an executable, they live in a shared
object file.
These apps are run through a deamon that forks and dlopens()
the shared object ( for performance reasons ).
For this reason we can't use _cmdname(), since it just contains
the the file path of the daemon.
On the other hand, non-zygotized apps have a bogus argv[0]
when run through the navigator ( command line is fine ).
Change-Id: I9953e8fa05c9fb11c33b3a38ebab00fe33ba4c44
Reviewed-by: Kevin Krammer <kevin.krammer@kdab.com>
Reviewed-by: Thomas McGuire <thomas.mcguire@kdab.com>
There are more opportunities in QtCore and the rest of Qt to make signals
private instead of public. This is a test-dart to see if there is any
reason not to do this.
It would be nice to make QObject::destroyed private, but as it has a
default argument it would be source incompatible to anyone connecting
to the SIGNAL(destroyed()) instead of SIGNAL(destroyed(QObject*)).
Currently the function-pointer-based connect syntax does not accept
a functor (or lambda) with a different number of arguments than the
signal. Olivier says a fix for that might come in 5.1, but for now
the qfiledialog2 test is changed to not use that anymore.
Also, the function pointer for a private signal can not be assigned to
a local variable, so the qmetamethod test is changed to not do so
anymore.
Change-Id: Iaf776b822f9ba364f2c184df0c6b23811da56e44
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>