| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
configure.exe
mkspecs/common/symbian/symbian.conf
src/gui/graphicsview/qgraphicswidget.h
src/gui/kernel/qapplication.cpp
src/gui/text/qtextlayout.cpp
src/openvg/qpixmapdata_vg.cpp
src/s60installs/s60installs.pro
tools/runonphone/main.cpp
tools/runonphone/serenum_unix.cpp
qtextlayout.cpp fixed up together with Eskil.
Kept the configure.exe from 4.7 without recompile.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Configure parameter -qtlibinfix will now change also plugin names
of plugins built and installed with Qt in Symbian.
Default plugin path is changed to: /resource/qt<libinfix>/plugins.
Other plugins besides the ones installed with Qt are not renamed.
With infixed configuration, Qt can be installed on a phone that already
has a Qt installed on ROM without interfering with the ROM version of
Qt.
Note that since s60main.rsc resource cannot deployed with infixed Qt,
and infixing it is somewhat problematic, currently the phone needs
to have proper Qt installation, too, for infixed Qt to work.
It also means that any changes to Qt that would affect s60main.rsc
cannot be tested on real device using infixed builds. Since this file
is unlikely to need changing, this should not be a big problem.
Task-number: QTBUG-9065
Reviewed-by: Jani Hautakangas
|
| | |
| |
| |
| |
| |
| | |
This enables it to be used by all Symbian build systems.
RevBy: Miikka Heikkinen
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
It reuses almost everything from the original pkg generator, but the
code had to be restructured to accomodate for the new makefile
generator. In addition a few new codepaths and profile changes had to
be introduced to cope with the fact that this mkspec puts files in
different places than Symbian does (inside $QTDIR/lib instead of
$EPOCROOT/...).
This enables the pkg generator to generate correct pkg files for Qt
itself, but applications will not work yet because they also require
generated rss files.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
