Cleanup: Remove some obsolete code supporting a pre-4.3 format

Loading a dock window state saved by a Qt 4.2 app is not
something we need to support anymore.

Change-Id: I9ee6e2c742b31114081852e7236cfc8696b9b270
Reviewed-by: Paul Olav Tvete <paul.tvete@digia.com>
Remove unused variable

Also fixes a compiler warning with clang

Change-Id: I99beb7e099477b2b8b53af0e9fd32a7605a6c08a
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
Make QTestEventLoop::exitLoop() thread-safe

QTestEventLoop::exitLoop() is used by QSignalSpy to stop event
processing when the connected signal has been received. The design
of QSignalSpy requires QTestEventLoop::exitLoop() to be
thread-safe, which it wasn't. When QSignalSpy is connected
to a signal in a different thread, exitLoop() was called from
the thread which emitted the signal and not the one in which
QTestEventLoop is running. This caused troubles when killing
the internal timer.

This patch adds a check in the beginning of exitLoop(). If
it is called from a different thread, it will post an event
into the message queue in which QTestEventLoop is running
and execute it there.

Change-Id: Icb8c8ff2f5344800ee6c6125b98c677c7a196c32
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Fix compilation of <atomic> with ICC and libc++

The libc++ header does this:

 #if !__has_feature(cxx_atomic)
 #error <atomic> is not implemented

So we can't enable the feature until the compiler reports true for that
test.

Change-Id: I96f1c7eea8b93d93bd721fe5a85fa987339d091f
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Enable C++11 atomics with Clang

I don't know why it was an #if 0. The __has_feature has been there for a
while. But, just to be sure, we check the presence of the header too.

Change-Id: I36e34c9e8fd4ce55c98966d2fad246b77eb16597
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reenable C++11 for ICC on OS X

It's fixed for the Intel Composer XE 2015 (compiler version 15.0).

Change-Id: I7960b2128743081e905d4b96acf55360f744fc69
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Always invalidate the iOS accessibility cache

This was observed in the weather app, where sometimes we could not find
an items window. This could only be observed in the search results of
the cities. (while VKB was visible).

The old code traversed up to the QQuickListView and then it could not
traversed further up in the parent hierarchy. Because of this it
could also not find the associated window handle.
The reason for this is unknown, but maybe it could be related to the
fact that QQuickListView is a Component.

Regardless of this, invalidate the cache should invalidate everything.
We also traverse through all top level windows, but on iOS there should
not be too many top level windows...

Change-Id: I56a496435bb529a53d5ece8446cd2eeff502af84
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
QAndroidPlatformClipboard: fix build in release mode

Q_ASSERT expands to nothing in release => mode unused.

Change-Id: Ieb9ec4382e925250e1146239ce061763003ff6ba
Reviewed-by: BogDan Vatra <bogdan@kde.org>
Add rpath pointing to Qt libraries in OS X and iOS

This is triggered only when app is using Qt and Qt was built with "rpath"
configuration and project does not specify QMAKE_RPATHDIR explicitly.

Added rpath is made relative to app binary location if target path lies inside
Qt SDK, so all SDK bundled tools and examples will work automatically without
any changes. Tests are an exception here, since they are being run from their
build location by CI, we may not use relative rpath that work only in install
location.

Task-number: QTBUG-31814
Change-Id: I3690f29d2b5396a19c1dbc92ad05e6c028f8515b
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>
Build Qt for OS X and iOS with relative rpath

Defaulting to absolute_library_soname on configure -rpath is no longer
necessary as now we support @rpath install name ids on OS X and iOS.

This also sets QMAKE_SONAME_PREFIX to @rpath for Qt modules when built with
rpath configuration.

This makes Qt libraries relocatable on OS X. Qt SDK is not yet relocatable
though, because plugin location (including cocoa plugin) is still resolved
using absolute path (see QTBUG-14150), also there are several absolute paths
hardcoded in qmake mkspecs pri files.

Task-number: QTBUG-31814
Change-Id: Ie9dffefcd2a946c1580293d433621c1adb7e06c4
Reviewed-by: Jake Petroules <jake.petroules@petroules.com>