summaryrefslogtreecommitdiffstats
path: root/src/gui/s60framework
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch '4.6-s60' into 4.6axis2009-11-042-0/+96
|\
| * Moved a resource file from the static wrapper app to QtGui.axis2009-10-302-0/+96
| | | | | | | | | | | | | | | | | | | | 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
* | Fix trivial qdoc errorJason McDonald2009-11-041-1/+1
|/ | | | Reviewed-by: Trust Me
* Cleaned up the API of the Symbian event hooks.axis2009-10-211-8/+15
| | | | | | | | | | | | | | | The two major points were: - Replacing "s60" with "symbian" in all event handling functions, since there is nothing S60-specific about them. - Replace the Symbian event types with the encapsulating QSymbianEvent container. This allows us to cope with more types of events in the future without having to add new virtual functions. AutoTest: QWidget passed Task: QT-1156 RevBy: Jason Barron RevBy: Shane Kearns RevBy: Sami Merila
* doc: Fixed the wording in some \brief commands.Martin Smith2009-10-162-2/+2
|
* doc: Replaced \obsolete with \warning.Martin Smith2009-10-143-59/+76
| | | | | | Warning: This class is provided only to get access to S60 specific functionality in the application framework classes. It is not portable. We strongly recommend against using it in new applications.
* Fixed a crash in menus on Symbian.axis2009-10-051-11/+10
| | | | | | | | | | | | | | | | | | | | The reason for the crash was the following: When we make menu entries in Qt, we assign each item an arbitrary command ID. This is because Symbian usually puts the items in a resource file and refers to them by ID, but we need to be dynamic. These command IDs are also assigned to cascading menu items (sub menus). When we then get a callback in RestoreMenuL with one of submenu IDs, we used to ask Symbian to construct the menu items for them, but Symbian doesn't know about them. Fixed by avoiding call into S60 code if the ID belongs to Qt. Also put a cap on the number of menu items. It's very unlikely that anyone will reach it, but it's better to have an actual check. Task: QT-646 AutoTest: Manual testing went fine RevBy: mread
* Doc: silence qdoc warnings in S60 specific documentation.Volker Hilsheimer2009-10-031-2/+2
| | | | Not sure why the migration classes should be are \obsolete.
* Compile if QtCore is not in the include path when one includes <QtGui/QtGui>Olivier Goffart2009-10-011-1/+1
|
* Compilation with pedantic or when QtCore is not specified in the include pathOlivier Goffart2009-10-011-1/+1
| | | | | | Note that i also removed the #error since the enum is already updated in master Reviewed-by: Gabi
* Compile when one includes <QtGui/QtGui> without putting explicitly all Qt ↵Olivier Goffart2009-09-301-1/+1
| | | | subdirs in the include path
* Added support for using custom application objects on S60.axis2009-09-2310-468/+470
| | | | | | | | | | | | | | | | With this patch, the application developer can use his own CEikApplication, CEikDocument and CEikAppUi classes with Qt, by deriving from QS60MainApplication, QSMainDocument and QS60MainAppUi, respectively. He can then register a factory function in the QApplication constructor to have his own objects created during the framework initialization. This patch also fixes some Qt code style issues. RevBy: Jason Barron RevBy: mread RevBy: Sami Merila RevBy: Shane Kearns
* Update license headers again.Jason McDonald2009-09-096-24/+24
| | | | Reviewed-by: Trust Me
* Merge branch 'minimizeWrapperApp' into 4.6axis2009-09-036-78/+78
|
* Move the S60/Avkon framework initialization into QtGui.axis2009-09-037-0/+794
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