path: root/src/plugins/platforms/ios/
Commit message (Collapse)AuthorAgeFilesLines
* Enable Universal Links on iOSLars Schmertmann2020-05-191-0/+20
| | | | | | Pick-to: 5.15 Change-Id: I05b5bede49f619576dd9ab37444f7cb5fe0f15f0 Reviewed-by: Tor Arne Vestbø <>
* iOS: Use the non deprecated application:openURL functionAndy Shaw2018-04-181-3/+2
| | | | | | | | | | | In iOS 9.0, the original application:openURL function was deprecated and replaced with a newer one. As iOS 9.0 is no longer supported we can safely switch to the new one. This is also required to prevent a crash when the LSSupportsOpeningDocumentsInPlace and UIFileSharingEnabled keys are set to true in the Info.plist file. Change-Id: I59a7ee82e3ddb2777ef78e28b964ef8666c629af Reviewed-by: Tor Arne Vestbø <>
* Updated license headersJani Heikkinen2016-01-151-14/+20
| | | | | | | | | | | From Qt 5.7 -> LGPL v2.1 isn't an option anymore, see 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 <>
* Fixed license headersJani Heikkinen2015-02-171-1/+1
| | | | | Change-Id: Ibebe1318d1c2de97601aa07269705c87737083ee Reviewed-by: Oswald Buddenhagen <>
* Update copyright headersJani Heikkinen2015-02-111-22/+14
| | | | | | | | | | | | | | | | | | 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 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 <>
* iOS: Let QScreen manage UIWindow and root view-controllerTor Arne Vestbø2014-07-231-40/+0
| | | | | | | | | | Instead of having the application delegate set up a UIWindow and root view-controller, we move the responsibility to QScreen, since in a multi screen scenario we will need one UIWindow per screen, as well as one root viewcontroller per window. Change-Id: If5b0d44b8f8a697d830b33b4fe420bff56a7629b Reviewed-by: Tor Arne Vestbø <>
* iOS: Add helper for getting the iOS platform integration instanceTor Arne Vestbø2014-07-211-2/+3
| | | | | Change-Id: I550d345ab0f8bcba1225c425464e198d43d9fda8 Reviewed-by: Richard Moe Gustavsen <>
* iOS: Forward [UIApplicationDelegate handleOpenURL:] to QDesktopServicesTor Arne Vestbø2013-11-291-0/+20
| | | | | | | | | | | | | | | | | | The user may use QDesktopServices::setUrlHandler() in combination with the appropriate Info.plist keys (CFBundleURLTypes, CFBundleURLSchemes) to react to URL requests from other applications. This is among other things useful for handling OAuth authentication from applications such as Dropbox. See: We protect against recursive URL opening, but an application may still redirect a request to open a URL by opening another URL, eg a website. Task-number: QTBUG-35201 Change-Id: I9f1d246206c5594b1b65bb11fa98c6bcdefc443e Reviewed-by: Richard Moe Gustavsen <>
* iOS: Don't enable translucent statusbar for iOS6 on iPadsTor Arne Vestbø2013-11-251-2/+5
| | | | | | | It's only available on iPhone/iPods. Change-Id: I61b45c84ddb2b3db46fff36286a6582406fa7d26 Reviewed-by: Richard Moe Gustavsen <>
* iOS: Change show() to imply maximize, and showFullScreen() to hide status barTor Arne Vestbø2013-11-221-0/+16
| | | | | | | | | | | | Matches the Android behavior, and gives an easy and predictable way to show true fullscreen windows that is similar to how one would do it on a desktop platform. We keep the statusbar visibility in sync with the window state of the active window. Change-Id: Ia4b99e03f83e19f9ef56cc99b9d477cc6da4c734 Reviewed-by: Richard Moe Gustavsen <>
* iOS: Don't keep around reference to a single QIOSViewControllerTor Arne Vestbø2013-11-201-4/+1
| | | | | | | | We might have more of them in a multi-screen setup or when implementing support for modal windows using sub-viewcontrollers. Change-Id: Ibe98273a13af981fffe2704a2c05bfd9d3f3e9e0 Reviewed-by: Richard Moe Gustavsen <>
* iOS: Remove background color for UIWindow and UIViewController's root viewTor Arne Vestbø2013-11-141-4/+0
| | | | | | | | They were handy while debugging the iOS platform plugin, but should not affect users who link against debug libraries, so let's just remove them. Change-Id: I61b157e81130e5d951c22892e00f71e593082b1d Reviewed-by: Richard Moe Gustavsen <>
* iOS: Handle key window as part of QWindow activationTor Arne Vestbø2013-11-141-1/+1
| | | | | | | | The default UIWindow may not be the only UIWindow around in a multi screen setup. Change-Id: Ia7243190321a1416e577634bf5e010dd67d482e6 Reviewed-by: Richard Moe Gustavsen <>
* iOS: Interleave Qt application main() with iOS startup sequenceTor Arne Vestbø2013-09-131-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <>
* iOS: Change main-wrapper logic to not require changing the user's mainTor Arne Vestbø2013-09-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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ø <>
* iOS: Get rid of QIOSMainWrapperApplicationDelegateTor Arne Vestbø2013-07-151-52/+13
| | | | | | | | We only control the application delegate in the wrapped case anyways, so QIOSApplicationDelegate is good enough for our use. Change-Id: Ib738592dc306c5b6652632b9ae4dab431639a89a Reviewed-by: Richard Moe Gustavsen <>
* iOS: Remove need for separate qtiosmain libraryTor Arne Vestbø2013-06-121-1/+47
| | | | | | | | | | | | | | | | | | | | 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 <> Reviewed-by: Richard Moe Gustavsen <>
* iOS: use an explicit pointer to qiosViewControllerRichard Moe Gustavsen2013-04-191-0/+2
| | | | | | | | | | | | | As it stood, we always relied on the root view controller being a QIOSViewController if isQtApplication() returned true. For mixed application, this might not always be true as native code can choose to replace the root view controller at times, or even rip it out, and place it as a child of another (e.g UISplitViewController). This change will give an extra protection against that. Change-Id: I0cb85796a8b82f9037c32f9e85e04e1dc7aad8e2 Reviewed-by: Tor Arne Vestbø <>
* iOS: Ensure UIApplicationMain is started before QApplication by wrapping main()Tor Arne Vestbø2013-02-271-23/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Set background color of UIWindow and root UIView to burn your eyesTor Arne Vestbø2013-02-271-2/+4
| | | | | | | Convenient to aid debugging during development of the platform plugin. Change-Id: Id429ca95e0452385ee8def1fe4a1bb7de175ba3e Reviewed-by: Richard Moe Gustavsen <>
* iOS: create top-level UIWindow and UIViewControllerRichard Moe Gustavsen2013-02-271-0/+18
| | | | | | | | Create a UIWIndow with a view controller and a view where we can reparent our QIOSWindow views inside. Change-Id: Ic90707d3ebe1af970a3aa2aa0f8c0f4be192456a Reviewed-by: Tor Arne Vestbø <>
* iOS: call UIApplicationMain from event dispatcher, and add application delegateRichard Moe Gustavsen2013-02-271-0/+89
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ø <>