| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|