Allow panels outside of availableGeometry

Panels windows are usually outside QScreen::availableGeometry, because
they will usually set extended struts to reserve the screen area for
themselves, but their own screen() must remain the one in which they
are.
This cause one downstream behavior to KDE
https://bugs.kde.org/show_bug.cgi?id=339846
in which a panel got by mistake few pixels on another screen, and
was immediately reassigned to that screen, because its geometry was
intersecting the new screen availableGeometry() but not the geometry
of its own screen, because itself reserved its own geometry away
from availableGeometry()

Change-Id: If6c9defdef62732473687dd336dbcec582bd0ea2
Reviewed-by: Jørgen Lind <jorgen.lind@digia.com>
Set the _C variants of QMAKE_LINK and QMAKE_LINK_SHLIB in clang.conf.

While it does not look like the clang-based mkspecs had any problems so
far with not having QMAKE_LINK_C and QMAKE_LINK_C_SHLIB defined, it
makes sense to set them to $$QMAKE_CC just like the GCC-based ones so
CONFIG=use_c_linker works as expected.

Change-Id: Ib660d12b001dd7a877b6f03e79715db08a272968
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Stop including g++-unix.conf in the freebsd-clang mkspec.

Most of the settings there end up overwritten by the clang.conf include
that comes afterwards, except for a few things such as QMAKE_LINK_C,
which remains set to "gcc" and breaks things when one uses
CONFIG=use_c_linker.

QMAKE_LFLAGS_NOUNDEF was coming from g++-unix.conf, though, so we now
manually set it in freebsd-clang's qmake.conf.

Change-Id: Ibd16f59d43eb19e72adf4919da9ce3007100b60f
Reviewed-by: Gabriel de Dietrich <gabriel.dedietrich@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Remove incorrect execute file permissions from source files

Amends commit 9c3a58a913a7e59359146264ee59d40d703d4db2.

Change-Id: I292eb9df480a642a65f9065e4fe36bd52c093dc7
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Fix QString::sprintf documentation

QString::sprintf does actually support all length modifiers, including
%lld. The format string is also parsed as UTF-8.

What's worthwile to mention, though, is that %lc and %ls is at odds
with the standard, since wchar_t isn't necessarily 16 bits wide.

Change-Id: I30cd22ec5b42035824dd98e3cdcc79d7adcc953a
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Always lock the DBus dispatcher before dbus_connection_send*

We lock it before dbus_connection_send_with_reply (the async version) in
QDBusConnectionPrivate::sendWithReplyAsync. We weren't locking it before
send_with_reply_and_block and we apparently should. The locking around
the dbus_connection_send function might not be necessary, but let's do
it to be safe.

The lock now needs to be recursive because we may be inside
QDBusConnectionPrivate::doDispatch.

Task-number: QTBUG-42189
Change-Id: I7b6b350909359817ea8b3f9c693bced042c9779a
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
QDBusConnection: Merge the dispatch and the watch-and-timeout locks

We don't need two anymore because they now protect the same thing: the
state of the DBusConnection. The difference existed when it was possible
for two threads to access the DBusConnection at the same time: one doing
dispatching and one doing something else. Unfortunately, even though
DBusConnection supports this, QtDBus doesn't.

From d47c05b1889bb4f06203bbc65f4660b8d0128954 (2008-10-08):
   Details:  if we're removing a timer or a watcher from our list,
   there's a race condition: one thread (not the QDBusConnection thread)
   could be asking for the removal (which causes an event to be sent),
   then deletes the pointer. In the meantime, QDBusConnection will
   process the timers and socket notifiers and could end up calling
   lidbus-1 with deleted pointers.

That commit fixed the race condition but introduced a deadlock.

Task-number: QTBUG-42189
Change-Id: I034038f763cbad3a67398909defd31a23c27c965
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Albert Astals Cid <albert.astals@canonical.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Partially revert "Fix a deadlock introduced by the race condition fix"

The commit was 9361be58f47ec256bf920c378479a02501219c1f (2008-11-17),
referring to the race condition fix that was applied in commit
d47c05b1889bb4f06203bbc65f4660b8d0128954 (2008-10-08). The fix for the
deadlock reintroduced the race condition and the commit message noted
it.

The workaround is no longer necessary since we've fixed the original race
condition differently now (see the previous two commits).

Task-number: QTBUG-42189
Change-Id: I5a83249597a83c4d4caa2ae57964ad3cc61c1d70
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Albert Astals Cid <albert.astals@canonical.com>
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>