ppc/ppc64 and 32-bit x86 have been dead for a while.
consequently, the legacy macx-g++-64 spec was most probably not used.
which in turn meant that NATIVE_64_ARCH was never set (in particular on
windows hosts ...), which means that the android ndk host auto-detection
was effectively broken.
the arch code in mac/default_post.prf was also never triggered, so nuke
it as well.
Change-Id: Ic0775e40b273a22e0a15808cac328e0df33c2155
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
According to MSDN, the zero value of ICONDIRENTRY bHeight and bWidth
fields mean a maximum icon size 256 pixels. So QtIcoHandler::option()
should return 256 instead of 0 pixels for such icons. Also there is
fixed wrong seek offset at the second call on this method.
http://blogs.msdn.com/b/oldnewthing/archive/2010/10/18/10077133.aspx
Task-number: QTBUG-48103
Change-Id: I99f0c9720fd58889045b0c73c51498f2065b0b91
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Reviewed-by: aavit <eirik.aavitsland@theqtcompany.com>
By serializing the capitalization value of QFont, it ensures that it is
correctly preserved when QPicture streams it and later plays it back.
Subsequently the QDataStream version has been bumped up to account for the
change of the data format for serializing QFont.
[ChangeLog][QtGui][QFont] QFont now serializes the capitalization setting.
[ChangeLog][Important Behavior Changes] QDataStream version bumped up to
17 to account for changes in the serialization of QFont.
Task-number: QTBUG-15214
Change-Id: I042680760e5a69d18d41e786b7500a3eebbe562f
Reviewed-by: Mitch Curtis <mitch.curtis@theqtcompany.com>
Calling runOnUiThread() only queues calls that comes from a different
thread then the UI thread. The problem with the current solution is that
we can't promise or rely on the calls being delivered in the same order
they were called. Another consequence of the old behavior is that we
potentially cause long lasting synchronization points, which can cause
the application to become unresponsive or in worst case result in a
deadlock. With this change all calls to runAction() will be queued on
Android's main message queue (aka the UI thread) and return immediately.
Change-Id: I50a4273ae9ba8ad17fb2c50ccd57449e4fbc12f9
Reviewed-by: Eskil Abrahamsen Blomfeldt <eskil.abrahamsen-blomfeldt@theqtcompany.com>
It was just documented as a method and signal so far, even though it
already was a property. This patch merges both documentations into one.
Change-Id: I3fb4090b773ba8762ad9e830303812887b75add3
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@theqtcompany.com>
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
The correct macros can be easily checked by running:
.../arm-linux-androideabi-gcc -E -dM - < /dev/null | grep -i ANDR
Otherwise we're just relying on the user to set up explicitly the
toolchain to target Android
Change-Id: I7b68521f43031c13da99b07626360d0702bff4ca
Reviewed-by: BogDan Vatra <bogdan@kde.org>
According to the SCXML specification, the state-machine can exit the
interpreter loop when a final state has been reached. This happens after
finishing a macro-step or when it ends up in a final state right after
startup (e.g. when the only state is a final state). This patch adds a
virtual method which can be used to detect this reliably.
Change-Id: I594e952a4972dd70d4089a2c4ce1c86880568eb9
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
It sends a shortcut override event directly, which should go
though QPA anyways.
Change-Id: Ie2c6f45cd44222cd9be8846099573dcd2968a77c
Reviewed-by: Lars Knoll <lars.knoll@theqtcompany.com>
QDBusConnectionPrivate can only be a client or a server, not both, so
the DBusServer and DBusConnection pointers can be shared, like the
QDBusConnectionInterface and QDBusServer pointers in the other anonymous
union.
Change-Id: I9a75ad8521ae4e5cbbe5ffff13d1baa8ab83c42f
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
P2P connections don't have senders and receivers, so asking
QDBusConnection to connect to a signal with a sender was a mistake
(added in 5368e44a86). Due to an internal
bug, this never presented itself -- double fault.
Fix the connection so that we don't get unit test failures when the bug
is solved.
Change-Id: I9a75ad8521ae4e5cbbe5ffff13d1a78b7dea6d07
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
This commit moves the code that finishes the signal-slot connection into
the QtDBus auxiliary thread. That is necessary because we're holding the
lock for writing while making blocking calls. The auxiliary thread might
be waiting for us to release that lock while processing some previous
message.
Change-Id: Iee8cbc07c4434ce9b560ffff13d0521b94a51833
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
This is an optimization but is required. Instead of going through the
entire (dis)connectSignal() stack to add/remove matching rules for the
NameOwnerChanged bus signal and call into our serviceOwnerChangedNoLock
slot, create a static hook that will match the signal and simply add/
remove the rules as needed.
The required part is that this avoids a recursion into connectSignal().
The next commit will move this code to the QtDBus manager thread and we
won't be able to call connectSignal() from there (it would create a
deadlock).
Change-Id: Iee8cbc07c4434ce9b560ffff13d074ce90ad02d4
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
In two commits, we will attempt to call this function from the manager
thread, so we need to be sure this function works from there. Right now,
it would deadlock in QDBusPendingCallPrivate::waitForFinished(), inside
QDBusConnectionPrivate::sendWithReply().
The solution is simple: expand sendWithReply to the sendWithReplyAsync
function it calls anyway, but tell the internal DBusPendingCall to
finish before we call waitForFinished().
Change-Id: Iee8cbc07c4434ce9b560ffff13d0749013d771ab
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
That function was added in the previous commit, so deduplicate the code
from QDBusAbstractInterfacePrivate::initOwnerTracking().
Change-Id: Iee8cbc07c4434ce9b560ffff13d06f1d9fb0cde5
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
With kdbus, we won't have a regular signal, but instead a special
message. So keep the logic of what to do in QDBusConnectionPrivate.
The #ifdef is to make sure the bootstrapped qdbuscpp2xml continues to
build in cross-compilation environments.
Change-Id: Iee8cbc07c4434ce9b560ffff13d06f0d9904cb6d
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
They were used when we called the libdbus-1 message-sending functions
from any thread, which meant that the callbacks could be triggered on
any thread. Since we moved the message-sending to one thread only (the
manager's thread), there's no need for the event fallback anymore.
Since they're also always[*] running on an aux thread, there's no point
in checking for the presence of a QCoreApplication instance anymore. I
don't think there has been a need for this for many years, as the event
dispatcher has been decoupled from QCoreApplication for a long time.
[*] exception: the callbacks are first called in the thread that invoked
QDBusConnection::connectTo{Bus,Peer}, before we've done the
moveToThread.
Task-number: QTBUG-43585
Change-Id: Ic5d393bfd36e48a193fcffff13b73758c798d6b0
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
The two global statics for the session and system buses aren't necessary
if they can't outlive the global static for QDBusConnectionManager
anyway. So merge them there. The extra mutex is necessary because the
QDBusConnection::connectToBus function will lock the regular mutex.
This solves a potential memory leak at exit as a side-effect. Before
this change, the session and system QDBusConnection object got destroyed
in the main thread during global destruction, so it had to post an event
to the QDBusConnectionManager thread to finish the destruction of the
private. However, QCoreApplication is already gone by this point, so the
QEvent::DeferredDelete event never got delivered.
After this commit, there's no global static to destroy the
QDBusConnection (there is no QDBusConnection holding a reference), so
the object gets destroyed in QDBusConnectionManager::run()'s cleanup
code.
Change-Id: I9a75ad8521ae4e5cbbe5ffff13d1b967ee1a7a7e
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
Now we know that all timers and socket notifiers get created only in the
QDBusConnectionManager thread.
Incidentally, this reduced code duplication.
Change-Id: I27eaacb532114dd188c4ffff13d5075a8d2efb0b
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
With this, we now know that all messages sent are sent from the same
thread. This simplifies greatly the handling of the socket.
Task-number: QTBUG-43585
Change-Id: Ic5d393bfd36e48a193fcffff13b73758087344ed
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
This is intended to simply the handling of the socket in the
future. Now, we know that all calls to send_with_reply are placed only
from the manager's thread.
Task-number: QTBUG-43585
Change-Id: Ic5d393bfd36e48a193fcffff13b737575c231927
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
No need to check for the local loop if that's the first thing
QDBusConnectionPrivate::sendWithReplyAsync will do. The side effect is
that this now allocates memory for the QDBusPendingCallPrivate object,
but loopback messages aren't that common to be worth the special casing.
Task-number: QTBUG-43585
Change-Id: Ic5d393bfd36e48a193fcffff13b73756ab802ba2
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
They're pretty much the same, clearly a copy & paste. Instead, merge the
two codepaths so that we don't run the risk of applying a change in one
part and forgetting the other.
Task-number: QTBUG-43585
Change-Id: Ic5d393bfd36e48a193fcffff13b737560f6753be
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
Each application will have one thread dedicated for this, for all
QDBusConnections. I wouldn't mind sharing such a thread with other uses
in Qt, provided none of them ever block (the QProcessManager thread
comes to mind, but it's going away soon).
The cost associated with this change in this commit is so far rather
minimal. All incoming D-Bus calls need to be handled after an event is
posted anyway, to avoid deadlocking on reentering libdbus-1 functions
that acquire locks still held. The cost is the one more thread running
and the cost of synchronizing them when an event is posted.
The benefits far outweigh that cost: no longer will we have problems of
QtDBus failing to run if the main system or session connections are used
before QCoreApplication is run. Moreover, events can be received and
handled in aux threads even if the main thread is blocked on some
operation.
Note: this commit may not be testable (tst_qdbusconnection may fail)
Task-number: QTBUG-43585
Change-Id: Ic5d393bfd36e48a193fcffff13b737556ccd11a8
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
This simplifies the code a little by having a single code path. More
importantly, we no longer need to call the evil function
dbus_connection_send_with_reply_and_block. That function acquires a lock
on the socket transport inside libdbus-1, which means all threads need
to wait until the one call gets unblocked before they can continue.
To do that, this commit reimplements the QDBus::Block part of
QDBusConnectionPrivate::sendWithReply by reusing the existing call to
sendWithReplyAsync() and then doing a blocking-wait with
QDBusPendingCallPrivate::waitForFinished().
By using (Q)DBusPendingCall and the threaded connection approach (next
commit), now we never block on the socket. That also means the code to
call dbus_pending_call_block() is no longer necessary and the
waitForFinished() function itself can be considerably simplified.
As a side-effect of no longer blocking, a number of pre-existing race
conditions that used to be hidden showed up.
Note: this commit deadlocks without the threading (next commits).
Task-number: QTBUG-43585
Change-Id: Ic5d393bfd36e48a193fcffff13b73754954a3f7d
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
It used to return the sent message's serial ID, but we never used that.
So simply use boolean instead.
Change-Id: Ic5d393bfd36e48a193fcffff13b73753ccf47759
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
Reviewed-by: Albert Astals Cid <aacid@kde.org>
The cost of connecting a signal may be a bit high, but it's comparable
to looking up the invokable method. However, QMetaMethod::invoke has a
higher cost than a signal-slot emission -- though in any case they're
both dwarfed by the cost of allocating the QMetaCallEvent and the
posting of it.
This is much more readable, though.
Change-Id: Iccecbecbe6288fb3b6d16578fdff3f203b6db29c
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
Reviewed-by: Albert Astals Cid <aacid@kde.org>
This is because the socket activity will move to a different thread;
QDBusConnectionPrivate* can be queued, QDBusConnection can't easily.
Change-Id: I82722016018b7fcfb246cda6043469fadbfd987d
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
Instead of connecting to the "NameOwnerChanged" signal. This has better
performance, is simpler to implement and is future-proof: when we switch
to kdbus, there won't be a "NameOwnerChanged" signal to connect to. On
the drawback side, this will use slightly more memory.
Change-Id: I5801b8027949f041309567a493000fe7de9bf227
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
Reviewed-by: Albert Astals Cid <aacid@kde.org>
We increase the reference count of the connection during delivery of an
incoming message, so it's possible that the corresponding deref will
drop the last reference to the connection: another thread may have
called disconnectFromBus/Peer. However, during destruction we try to
drain the incoming socket queue, so we need to acquire the dispatch lock
again.
The solution is to always use deleteLater(), which means the
deleteYourself() function is unnecessary.
Change-Id: I27eaacb532114dd188c4ffff13d507039fcf7b6a
Reviewed-by: Albert Astals Cid <aacid@kde.org>
Reviewed-by: Alex Blasche <alexander.blasche@theqtcompany.com>
- Remove unneeded member variables.
- Use new connection syntax in createActions()
to assemble the menu there, removing the createMenus()
function.
- Use a QButtonGroup for the sizes with the style metrics as id.
- Streamline code, rename variables for clarity.
- Introduce static functions returning the list of states/modes and
their names in display order to IconPreviewArea, removing the
duplicates.
- Split actions to open sample icons provided from source directory
or standard pictures location to make sample icons more prominently
visible.
- Check and display @2x images and add tooltips showing device pixel
ratio and actual size.
- HighDPI: Add groupbox displaying screen name and device pixel
ratio, connect to screen changed signal and update icons panel
accordingly. Add check box for toggling Qt::AA_UseHighDpiPixmaps.
- Adjust documentation
Task-number: QTBUG-18680
Task-number: QTBUG-46615
Change-Id: Ice96e9898f168ef2a30e9f46cb260ed57ae015f0
Reviewed-by: Topi Reiniö <topi.reinio@digia.com>
Fixes GPU memory leak when window is created/deleted dynamically and
repeatedly. EGL context used to own EGL surface, but the context
outlives the surface if window is created/deleted dynamically. The
EGL surface is now owned by the window and destroyed with it.
Change-Id: Ib949261ef6e77217018e60aad3e36e4a6d2eaba0
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
The use of ccache leads to QMAKE_CXX definitions of the form:
QMAKE_CXX = $${CCACHE} $${CROSS_COMPILE}g++
The previous test required QMAKE_CXX to be a single valid (absolute or
QMAKE_PATH_ENV-relative) path to an existing file, which was not
compatible with definitions of QMAKE_CXX like the one above.
Fix this by using only the first value in QMAKE_CXX, which usually
points to the compiler executable, or to the ccache executable in the
above case.
Task-number: QTBUG-47951
Change-Id: Iade3136f03493593b067fb7742fb997f92377425
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Introduce the methods setError(), setErrorAndEmit() to consistently
set the internal error state.
Change-Id: I4ff951d100cf5e9f9a7e27135bb52188cde99853
Reviewed-by: Alex Trotsenko <alex1973tr@gmail.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
-no-opengl is not a supported option when compiling for WinRT or Windows
Phone. Hence bail out early to avoid compilation errors at later stage.
Task-number: QTBUG-48041
Change-Id: I449b8935b95f0b75139a0f7bfa13256ea3fe95e5
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Calling constScanLine() is an extra function call, just for doing
"data + y * width". Also, we are checking d again, even though we
already know it's there.
The constScanLine() call is responsible for up to 15% of the total
CPU time spent in pixel().
Change-Id: Ia7a8e0a6d62fb257d1b22d91f062b66e9cfd349a
Reviewed-by: Allan Sandfeld Jensen <allan.jensen@theqtcompany.com>
Windows Runtime port supports non-fullscreen and multiple windows.
Change-Id: I6f4791a7c329ece88e5f6f9910f3635a7bfef3f8
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
If no_generated_target_info is not set, VERSION is set, and
there is no .rc file that belongs to the project, qmake creates a
.rc file that contains information about the target's version
and copyright, for example. This resource handling is also
supported by WinRT and we can add this information to the target.
On Windows Phone, winresrc.h (which is needed for resource
handling) is not available though. When trying to add a .rc file
to a project in Visual Studio, it also complains about winres.h
not being available. Instead of hacking around the issue, we
just should not support this behavior on Windows Phone.
Change-Id: Ie962bfa790916fed23294110062e3572a0e317f9
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
Inside Visual Studio these files (INSTALLS) will end up in deployment.
They do not make sense there and might even cause clashes, which prevent
the project file from being loaded (for example when a qrc file is added
to "Resource files" and "Deployment files")
Change-Id: Ifa68c52a83b2bf3948738c7aa1cf9c56b331dc80
Reviewed-by: Andrew Knight <andrew.knight@intopalo.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@theqtcompany.com>
This symbol will exist with different ELF versions, allowing us to know
which version of Qt a given library or application was linked
against. When this symbol gets used, automatic packaging tools will
extract the dependency. The trick here is that the application uses
qt_version_tag without knowing which version is current, but the linker
resolves it to the current version and records that.
For example, if this were used with Qt 5.5, RPM's find-requires on an
application using QtCore would print:
libQt5Core.so.5()(64bit)
libQt5Core.so.5(Qt_5.5)(64bit)
libQt5Core.so.5(Qt_5)(64bit)
Whereas find-provides on QtCore would print:
libQt5Core.so.5()(64bit)
libQt5Core.so.5(libQt5Core.so.5)(64bit)
libQt5Core.so.5(Qt_5.0)(64bit)
libQt5Core.so.5(Qt_5.1)(64bit)
libQt5Core.so.5(Qt_5.2)(64bit)
libQt5Core.so.5(Qt_5.3)(64bit)
libQt5Core.so.5(Qt_5.4)(64bit)
libQt5Core.so.5(Qt_5.5)(64bit)
libQt5Core.so.5(Qt_5)(64bit)
Therefore, automatic dependency resolution would have the information it
needs to conclude that the application requires Qt >= 5.5.
Change-Id: I049a653beeb5454c9539ffff13e3fec9aeb50197
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This linker script is only enabled for systems with GCC or GCC-like
compilers, though technically it should work on the BSDs too (will
enable after testing). For regular modules, this declares one ELF
version "Qt_5" and places all QtCore symbols inside, then it declares
unused ELF versions "Qt_5.x" for each older minor release. For modules
declared "internal_module", all symbols are placed in version
Qt_5_PRIVATE_API.
The big advantage of an ELF version is that, when we do Qt 6, both
versions of QtCore could be loaded in memory without conflicts and all
symbols would be resolved to the correct library. No module can talk to
both at the same time, but this avoids mistakes of loading them
indirectly by plugins.
The extra Qt_5.x versions will be used in the next commit.
Change-Id: I049a653beeb5454c9539ffff13e3fe6f050fdf31
Reviewed-by: Lisandro Damián Nicanor Pérez Meyer <perezmeyer@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@theqtcompany.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Since Windows Vista, the OS keeps an extra set of names for each
interface, which are identifier-like and more friendly than previously,
but not the user-description.
For example:
previous name: "{2B09D370-A032-4478-8444-495AD9301D67}"
new name: "wireless_6"
friendly name: "Local Area Connection* 12"
Change-Id: I7de033f80b0e4431b7f1ffff13f995f983689f06
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
The has been present since Windows 2000 and most functions we need have
been present since Windows XP and Windows CE 5.0. There's no need to do
runtime detection anymore.
This was necessary in Qt 4.2, when this code was introduced, because we
still supported Windows 98 and Me, including Windows platform SDKs that
lacked the necessary header definitions.
Change-Id: I076d1e8bbd53469a24fad72cf58b1905e737f52a
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@theqtcompany.com>
Future-proofing against a future version of the Linux kernel adding a
"FooTracerPid:" before the TracerPid entry.
Change-Id: I42e7ef1a481840699a8dffff140347457902900f
Reviewed-by: Simon Hausmann <simon.hausmann@theqtcompany.com>
