summaryrefslogtreecommitdiffstats
path: root/src/plugins/platforms/ios/qioseventdispatcher.mm
Commit message (Collapse)AuthorAgeFilesLines
* iOS: Ensure UIApplicationMain is started before QApplication by wrapping main()Tor Arne Vestbø2013-02-271-12/+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ø <tor.arne.vestbo@digia.com> Reviewed-by: Richard Moe Gustavsen <richard.gustavsen@digia.com>
* iOS: support stand-alone qApp->processEvents callsRichard Moe Gustavsen2013-02-271-2/+7
| | | | | | | | Rough implementation to support stand-alone processEvent calls. We probably need to revisit this code to fix corner-cases later on. Change-Id: I72d5639dab599b4d0017aaa52b922f4185a50337 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: implement QEventLoop support in the event dispatcherRichard Moe Gustavsen2013-02-271-2/+6
| | | | | | | | | | | 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>
* iOS: support killing timersRichard Moe Gustavsen2013-02-271-12/+42
| | | | | | | Implement the remaining timer functions in the event dispatcher Change-Id: Ie323962c898a2ee95ea60a8ca63b93cbd4544fd1 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: call UIApplicationMain from event dispatcher, and add application delegateRichard Moe Gustavsen2013-02-271-36/+22
| | | | | | | | | 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>
* iOS: QIOSEventDispatcher: implement timer supportRichard Moe Gustavsen2013-02-271-17/+119
| | | | | Change-Id: I1966a64e6535f32005681db37b4fe5d89dafc70c Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: QIOSEventDispatcher: add runloop source for processing eventsRichard Moe Gustavsen2013-02-271-6/+55
| | | | | Change-Id: I6cd649a493dab9a982d71921f19d2a9252fc14b0 Reviewed-by: Tor Arne Vestbø <tor.arne.vestbo@digia.com>
* iOS: fix build issue, dont link against cocoaRichard Moe Gustavsen2013-02-261-1/+1
| | | | | | | | | 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>
* iOS: copy brute-force port of Qt4 uikit plugin into Qt5.Richard Moe Gustavsen2013-02-261-0/+154
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>