summaryrefslogtreecommitdiffstats
path: root/src/s60main/s60main.pro
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch '4.6' of scm.dev.nokia.troll.no:qt/qtaxis2010-02-121-0/+3
|\ | | | | | | | | | | | | | | | | | | | | Conflicts: mkspecs/common/symbian/symbian.conf qmake/generators/makefile.cpp qmake/generators/symbian/symmake.cpp src/3rdparty/webkit/WebCore/WebCore.pro Conflict resolution was heavily based on manual application of commit 9cc4ae77a73bd28ff495f36f26dd87c78b76b976.
| * Workaround for abld toolchain issue with s60mainMiikka Heikkinen2010-02-081-0/+3
| | | | | | | | | | | | | | | | | | | | When building for ARMV6 with abld toolchain in Symbian, qtmain.lib ends up missing some symbols that are required to link it against GCCE apps. This happens because --dllimport_runtime compiler option is missing in ARMV6 builds of qtmain.lib. Task-number: QTBUG-7952 Reviewed-by: axis
* | Move duplicated code out to a qmake featureThomas Zander2010-02-091-1/+1
|/
* Moved a resource file from the static wrapper app to QtGui.axis2009-10-301-20/+0
| | | | | | | | | | It's more appropriate to have it in QtGui after the framework classes were moved there. This also means that the rsgfix needed earlier is not necessary anymore, since QtGui is not a static library. RevBy: Janne Anttila
* Move the S60/Avkon framework initialization into QtGui.axis2009-09-031-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This way we avoid having a lot of code in a static (and unmaintainable) library. The s60main static library now currently has only one task: to call main(). To move the initialization into QtGui also meant a change in how the S60 framework is created, because we can no longer use the trick where we create and start the the S60 event loop and then have the framework call us back to start main(). The initialization now follows the creation and destruction of QApplication, which is a lot more in line with how other platforms do it. Since S60 doesn't support creating the environment, and *then* starting it (both are executed by the same call), we had to open up the S60 framework construction classes and just mirror what they do. This means that after QApplication construction is done, the S60 framework is initialized, but nothing will run yet and control will return to main(), where the user can start the event loop himself. One of the quirks of this approach is that the construction of the S60 framework makes a new cleanup stack. This means that any active traps will not be active anymore, and leaving without setting a new trap will most likely panic. This shouldn't be a problem for us, since Qt is never supposed to leave, but it means that if anyone uses the cleanup stack without setting a new trap, they will receive a panic. It was considered to add a trap mark in QApplication construction and then removing it on destruction, but it was dropped because leaving from main() is still undefined (even if the old cleanup stack would be restored in the destructor, we wouldn't be able to stop the exception from unwinding the stack, and the cleanup stack would then be unbalanced). RevBy: Jason Barron RevBy: Janne Anttila AutoTest: QWidget passed with same failure count
* Made the static wrapper app headers private.axis2009-08-061-3/+3
| | | | | | | | Even though the static app is public in the sense that it is included in every program, the headers it contains are not. RevBy: Jason Barron AutoTest: tst_headers passed
* Blank line, trailing whitespace etc fixes for s60mainJanne Anttila2009-08-041-7/+7
|
* Long live Qt for S60!axis2009-04-241-0/+55