| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avkon provides a default app server when an app is started as a server
app. This allows any app to be started as a server app.
The Qt Avkon removal bypassed this, calling the base-class function
instead, which prevented apps from starting as server app unless they
explictly created a server.
Now Qt also creates a default app server, which implements no services,
so that any app can be started as a server app, even if Avkon is not
present. This allows Symbian^4, configured with -no-s60, to boot.
Task-number: QTBUG-14457
Reviewed-by: Jason Barron
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Qt upgrade was failing since the s60main.rsc is being locked by
S60 application framework. And when installer detects that
old version of Qt has already been installed it first tries to
uninstall the old one and then install the new one. The uninstallion
failed since the file was locked by the running Qt application.
It should be noted that this patch fixes the Qt upgradibility only
for Qt versions where patch is included. I.e. the versions before
4.7.2 need a different mechanism to be upgradable. This different
mechanism is based on partial upgrade SIS packages as described in
QT-4052.
Task-number: QT-3471
Reviewed-by: Axis
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avkon dependencies can be configured out with the -no-s60 configure
flag, conversely Qt on Symbian will use Avkon if -s60 is configured.
These changes are intended to keep or introduce binary compatibility
between the s60 and no-s60 configurations. To do this, it has been
necessary to introduce stub equivalents of the CAknAppUi related
classes into the no-s60 configuration, and override all Avkon framework
virtual functions in the QS60Main... classes.
Other than that, these changes are mostly just correcting the use of
the Q_WS_S60 flag so that it only refers to Avkon dependencies.
Reviewed-by: Sami Merila
|
| |
|
|
|
|
|
|
| |
Now s60main.rsc file is also infixed, making infixed and vanilla builds
indepenendent of each other.
Task-number: QTBUG-9065
Reviewed-by: Shane Kearns
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
| |
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.
|
| |
|
|
| |
Not sure why the migration classes should be are \obsolete.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| | |
|
|
|
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
|
