| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of using a define to rename the user's main() function during
compilation, we leave the user code alone, and inject our wrapper one
step earlier in the process, at the application entry point 'start'.
This entry point is provided by crt1.o, which is normally linked into
the application automatically. The start() function sets up some state
and then calls main(), but we change the start() function to instead
call our main wrapper.
Instead of shipping our own crt1 binary/sources, we make a copy of
the appropriate crt1.o at build time, and modify its symbol table in
place. This is unproblematic as long as we keep the same length for
the wrapper function name, as the symbol names are just entries in
the global string table of the object file.
The result is that for the regular Qt use-case the user won't see
any changes to their main function, and we have more control over
the startup sequence. For the hybrid use-case, we no longer rely
on the fragile solution of having our back-up 'main' symbol in
a single translation unit, which would break eg with --load_all,
and we don't need to provide a dummy 'qt_user_main' symbol.
OSX 10.8 and iOS 6.0 introduced a new load command called LC_MAIN,
which places the state setup in the shared dyld, and then just
calls main() directly. Once we bump the minimum deployment target
to iOS 6.0 we can start using this loader instead of LC_UNIXTHREAD,
but for now we force the classic loader using the -no_new_main flag.
There's also a bug in the ld64 linker provided by the current Xcode
toolchains that results in the -e linker flag (to set the entry
point) having no effect, but hopefully this bug has been fixed
(or Apple has switched to the LLVM lld linker) by the time we
bump our deployment target.
Change-Id: Ie0ba869c13ddc5277dc95c539aebaeb60e949dc2
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
|
| |
Change-Id: Ic8c5181d753925de0d8cd5fcb5e1347429ff5ba3
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
| |
Change-Id: I39858fe835c131d5c681db535f2ec9308e2f8223
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We can combine the hybrid and non-hybrid use-cases into a single static
library if we are careful about which symbols are included in which
object files. By limiting the main() and qt_user_main() functions to
their own translation units, the linker will only pick them up if they
are missing at link time (the user's program do not provide them).
This technique is resilient to the -ObjC linker flag, which includes all
object files that implement an ObjectiveC class or category, but will
fail if the -all_load flag is passed to the linker, as we'll then have
duplicate symbols for either main() or qt_user_main(). The latter should
not happen unless the user provides the flag manually, and in the case
he or she does, there's ways to work around it by providing less global
flags such as -ObjC or -force_load.
Change-Id: Ie2f8e10a7265d007bf45cb1dd83f19cff0693551
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For the typical Qt app the developer will have an existing main() that
looks something like:
int main(int argc, char *argv[])
{
QGuiApplication app(argc, argv);
return app.exec();
}
To support this, we provide our own 'main' function in the
qtmain static library that we link into the application, which calls
UIApplicationMain and redirects to the 'main' function of the application
after the event loop has started spinning. For this to work, the applications
'main' function needs to manually be renamed 'qt_main' for now. In a later
patch, this renaming will happen automatically by redefining main from either a
header file, or more likely, from the Makefile created by qmake.
For the case of an iOS developer wanting to use Qt in their existing app
the main will look something like:
int main(int argc, char *argv[])
{
@autoreleasepool {
return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class]));
}
}
This is supported right now by just linking in libqios.a without libqiosmain.a.
QGuiApplication should then be created e.g inside the native apps application
delegate (but QGuiApplication::exec should not be called).
In the future, we plan to but use a wrapper library that
brings in all the Qt dependencies into one single static library. This library will
not link against qtmain, so there won't be a symbol clash if the -ObjC linker option
is used. We should then add the required magic to the future Objective-C convenience
wrapper for QML to bring up a QGuiApplication, which would allow using Qt from
storyboards and NIBs. This would also be the place to inject our own
application delegate into the mix, while proxying the delegate callbacks
to the user's application delegate.
Change-Id: Iba5ade114b27216be8285f36100fd735a08b9d59
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We build on top of the QPlatformOpenGLContext implementation to get
automatic support for QBackingStore-based painting. Since the OpenGL
renderer does not clear the backingstore between frames, we actually
also get support for partial updates, and we get the benefit of an
accelerated paint engine for Qt Quick 1 without setting a GLWidget
as the viewport, which would cause issues such as an extra QWindow.
This patch also removes the dependency to QtOpenGL and QtWidgets, which
were leftovers from the Qt4 platform plugin. In Qt5 the needed GL bits
are in QtGui.
Change-Id: Id9b736bfb2e4aec56c0fa9f5b7b4d8bff8e3d1dc
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The iOS platform GL context is an EAGLContext, which is wrapped by
the new class QIOSContext. The class takes care of makeCurrent()
and swapBuffers(), but defers framebuffer management to the
corresponding QIOSWindow.
At the moment only a single framebuffer is created, and changing the
geometry of the QWindow does not trigger any sort of invalidation of
the buffers.
The implementation assumes OpenGL ES2.x support. Though strictly
speaking we could support ES1 for QtGui, it serves little purpose
as Qt Quick 2 requires ES2.
This patch also disabled touch event synthesization until we have
figured out where we will maintain the connection to UIWindow.
QPlatformOpenGLContext::getProcAddress() for getting extensions is
implemented by using dlsym() to look up the symbol. This should not
present any issues for App Store deployment, like dlopen() would.
Change-Id: I166f800f3ecc0d180133c590465371ac1642b0ec
Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
|
| |
|
|
|
|
|
|
|
| |
This change will let you call QApplication::exec() instead of UiApplicationMain
from main. Also added an application delegate that we will need sooner
or later for catching application activation events.
Change-Id: I4edba5ce2059a804782d67c160755fc0e2e5267d
Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
|
| |
|
|
|
|
|
|
| |
We should add to HEADERS, so that moc will realize it needs to run on
the headers.
Change-Id: I582e989e4faf0835c4bf9a677cbd8ac075559319
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
| |
|
|
|
| |
Change-Id: Ic69a5a7faa9b7f9907d0325260b6b6e2389a4c3a
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
| |
|
|
|
| |
Change-Id: I2348b19617d3e342cd344bf7d0fa894118cbfae8
Reviewed-by: Morten Johan Sørvig <morten.sorvig@digia.com>
|
| |
|
|
|
|
|
| |
... by loading(qt_plugin)
Change-Id: I9be438b72be986a991a81c2cf1a3e5047bcf0a60
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>
|
