path: root/src/plugins/platforms/ios/
Commit message (Collapse)AuthorAgeFilesLines
* iOS: Ensure UIApplicationMain is started before QApplication by wrapping main()Tor Arne Vestbø2013-02-271-28/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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ø <> Reviewed-by: Richard Moe Gustavsen <>
* iOS: Implement QIOSBackingStore in terms of a QOpenGLPaintDeviceTor Arne Vestbø2013-02-271-2/+1
| | | | | | | | | | | | | | | | 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 <>
* iOS: Implement QPlatformOpenGLContextTor Arne Vestbø2013-02-271-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | 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 <>
* iOS: call UIApplicationMain from event dispatcher, and add application delegateRichard Moe Gustavsen2013-02-271-2/+4
| | | | | | | | | 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ø <>
* iOS: Don't add to OBJECTIVE_HEADERS, there's no such thingTor Arne Vestbø2013-02-271-1/+1
| | | | | | | | 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 <>
* iOS: Add missing QuartzCore dependency to platform pluginTor Arne Vestbø2013-02-271-1/+1
| | | | | Change-Id: Ic69a5a7faa9b7f9907d0325260b6b6e2389a4c3a Reviewed-by: Morten Johan Sørvig <>
* iOS: Don't link ios platform plugin to CocoaTor Arne Vestbø2013-02-271-1/+1
| | | | | Change-Id: I2348b19617d3e342cd344bf7d0fa894118cbfae8 Reviewed-by: Morten Johan Sørvig <>
* iOS: Build platform plugin like other platform pluginsTor Arne Vestbø2013-02-271-4/+3
| | | | | | | ... by loading(qt_plugin) Change-Id: I9be438b72be986a991a81c2cf1a3e5047bcf0a60 Reviewed-by: Morten Johan Sørvig <>
* iOS: copy brute-force port of Qt4 uikit plugin into Qt5.Richard Moe Gustavsen2013-02-261-0/+27
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ø <>