| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
The iOS event dispatcher has been split into two; one dealing with the
QPA event processing, which we should always do, and one dealing with
the longjumping that we do when running the user's main on a separate
stack.
Change-Id: I1f819db33c608aad130ff23cbbadcf84363a32d2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@qt.io>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Remaining uses of Q_DECL_OVERRIDE are in:
src/corelib/global/qcompilerdetection.h
src/corelib/global/qglobal.cpp
doc/global/qt-cpp-defines.qdocconf
(definition and documentation of Q_DECL_OVERRIDE)
tests/manual/qcursor/qcursorhighdpi/main.cpp
(a test executable compilable both under Qt4 and Qt5)
Change-Id: Ib9b05d829add69e98a86238274b6a1fcb19b49ba
Reviewed-by: Lars Knoll <lars.knoll@qt.io>
Reviewed-by: Ville Voutilainen <ville.voutilainen@qt.io>
Reviewed-by: Olivier Goffart (Woboq GmbH) <ogoffart@woboq.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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Export it for use by the iOS platform plugin. Also
move QCFSocketNotifier, and export for use by the
Cocoa platform plugin.
This is a pure code move with no intended behavior
changes, in anticipation of using the Core Foundation
event dispatcher as the default Qt Core event dispatcher
on OS X.
Change-Id: I43677d2f6f3c1d0ed0415c964225aa97d2f13078
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
| |
In anticipation of moving it to QtCore.
The call to QWindowSystemInterface::sendWindowSystemEvents() has been
moved to QIOSEventDispatcher by making processPostedEvents() virtual.
Change-Id: I9e03be4153a9f5f34e9a0ac942cdff572a44c318
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@theqtcompany.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We used to support calling QEventLoop::exec() from within a processEvent
recursion and still jump down to the root native runloop, but this does
not work as intended due to how QEventDispatcherCoreFoundation uses
flags in its ProcessEventsState for e.g. deferred wake up or timer
updates. The logic in QEventDispatcherCoreFoundation assumes that
the next recursion to processEvents will be handled by itself, so
that it can interpret the flags in ProcessEventsState. The iOS
event dispatcher subclass, QIOSEventDispatcher, does neither of
these things, and should only be used from a 'clean' state.
Change-Id: I44fa156feecc45772806002465c35bef0797ead2
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of trying to hook into various places where we might be in a
situation where the root event loop should exit, and then enabling the
runloop-observer, we always keep the observer active, and then do the
relevant checks whenever the run-loop exits.
The reason for checking if the event loop is running is that iOS will
enter and exit the root runloop as part of normal operation, eg due to
flicking a scroll view and switching the runloop mode, so we need to
ensure that we're actually supposed to exit the root event loop.
Change-Id: I9b84b47ee45e0c9e2b1d2ebb5a432ea92700b324
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We already supported re-entering QApplication::exec(), so adding support
for handling a generalized QEventLoop::exec() was nothing more than
removing the qApplication->in_exec condition in processEvents() and
the QThreadData::current()->quitNow condition when interrupting the
event loop. Everything else is just renaming and rewording, now that
the feature is not specific to QApplication::exec().
This means dialogs such as QFileDialog opened in the main() function
will show something on screen, as we then fall back to the iOS root
run-loop handling, while at the same time supporting QApplication
exec once the dialog closes.
We still don't hadle recursive QEventLoop:exec() at the root level,
as that would require multiple stacks and detailed application
knowledge about when to create them.
Change-Id: I334a362d85796341a343ce82f3104ff5866bdc3f
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Our previous event loop integration had two unfortunate flaws:
1. We would call qt_user_main() from a timer, after returning from
didFinishLaunchingWithOptions. This had the effect of showing the
iOS application window long before the Qt application UI had been
set up, resulting in a 1-2 second flash of black/pink between the
launch image disappearing and the actual application showing.
2. We spun a nested event loop, where our implementation of the
different event loop modes did not perfectly match the Apple
implementation. This resulted in scrolling being busted in
some cases such as when showing the virtual keyboard for
Emoji characters.
These two issues have now been solved by calling the user's main()
from didFinishLaunchingWithOptions. Normally this would not work, as
the user's main would call QApplication::exec() at the end of their
main(), which would block and we would never return back from the
didFinishLaunchingWithOptions callback, resulting in no UI on screen.
We work around this by longjmp'ing out of QApplication::exec(), back
into didFinishLaunchingWithOptions, so that it can return. Again,
this would normally not work, as the call stack where QApplication
and friends would live would get smashed as the application
continued executing. We work around this by allocating a block
of stack space at the start of main(), which we then redirect the
stack pointer to before calling the user's main. This results in
the whole stack of the user's main() and below being preserved, even
if we longjmp out of the call stack (which then restores the
stack pointer).
This approach should work fine together with garbage-collection as
well, since the mark-and-sweep phase will walk the stack from the
stack pointer to the stack base, including sections of the stack
that were part of qt_user_main() and live in the reserved area.
One case where GC will fail though is if it happens as part of the
qt_user_main() call, where the GC will not mark anything in the
'real' callstack below UIApplicationMain(), but this is not
expected to happen.
The size of the reserved stack can be controlled through the
Info.plist key 'QtRunLoopIntegrationStackSize', as well as the
'QtRunLoopIntegrationDisableSeparateStack' key to disable the
separate stack approach completely. This will fall back to the
old approach. The amount of stack space used by the user's
main can be determined by enabling a special debugging mode,
using the 'QtRunLoopIntegrationDebugStackUsage' key.
Change-Id: I2af7a6cfe1a006a80fd220ed83d8a66d4c45b523
Reviewed-by: Simon Hausmann <simon.hausmann@digia.com>
|
| |
|
|
|
|
|
|
| |
Move iOS event dispatcher from platform plugin to platform support, so
that it can be used by multiple iOS platform plugins.
Change-Id: I9041b2de5e00e5fe8f30af2dfd922b4f5c594802
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Create the QCFSocketNotifier class in platform support
which contains shared socket notifier support for
the Cocoa and iOS plugins. Remove the old code from
the Cocoa plugin.
The Cocoa code had one QCocoaEventDispatcher-specific
call: maybeCancelWaitForMoreEvents. Create a forwarding
function that is passed to QCFSocketNotifier.
Change-Id: Ibf9bd4745ba4f577a55f13d0cc00f5ae04447405
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
With this patch you can now expect the following code to work:
QEventLoop l;
QTimer::singleShot(1000, &l, SLOT(quit()));
l.exec();
Change-Id: Ic73e37affaadf8a859787d84ac02c15621ac7a29
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
| |
Change-Id: I1966a64e6535f32005681db37b4fe5d89dafc70c
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
| |
Change-Id: I6cd649a493dab9a982d71921f19d2a9252fc14b0
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
|
|
|
|
| |
Make sure the libraries dont depend on Cocoa. This will be
picked up by libtool, and make all apps and examples link
against cocoa too (which will ofcourse fail)
Change-Id: I5654bb08c4ed376fc7ee74da422d903270a8af38
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
|
|
The plugin has been renamed from uikit to ios.
Other than that, the plugin will now build, but do nothing. Most of
the Qt4 code is preserved, with a rough translation
into the Qt5 qpa API. A lot of code has simply been commented
out so far, and most lacking at the moment is the event dispatcher
which will need to be rewritten, and the opengl paint device
implementation. But it should suffice as a starting ground.
Also: The plugin will currently not automatically build when
building Qt, this needs to be enabled from configure first.
Change-Id: I0d229a453a8477618e06554655bffc5505203b44
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
