| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The hybrid allocator introduced a new export to qtcore.dll and made
all apps link to it when they linked with the corresponding qtmain.lib.
However, this made all apps depend on this new export, and since that
export is not present in early 4.7.x release, these apps would not run
with the Qt DLLs from those releases, which breaks Qt's compatibility
guarantees for patch releases. This change makes apps compatible with
all 4.7.x releases again.
For export frozen Qt builds (the sort that should be compatible across
all 4.7.x releases), qtmain.lib no longer forces a static import link
to qt_symbian_SetupThreadHeap(). Instead it dynamically loads
qtcore.dll, looks up qt_symbian_SetupThreadHeap(), and calls it if
present. If the function is not present, or on emulator builds where we
know that qtcore will use the system allocator creation function, we
call the system allocator creation function.
For export unfrozen builds, there is no compatibility between builds or
releases, so we do use a static import link to
qt_symbian_SetupThreadHeap(), as we have to use the qtcore dll we have
built with it anyway.
This has been tested as follows:
S60 3.1 SDK, def files not frozen. App compiled against latest code
runs on the corresponding DLLs, and does not start with 4.7.0, which
is what we expect.
S60 3.2 SDK, def files frozen. App compiled against latest code runs
on the corresponding DLLs with the new allocator, and runs on 4.7.0
DLLs with the old allocator. Which demonstrates compatibility.
S60 5.0 SDK, def files not frozen, debug build. Same result as for
the 3.1 SDK, which demonstrates debug build working too (all other
tests are release build tests).
S60 5.0 SDK, def files frozen, debug build. Same result as on S60 3.2
SDK, which demonstrates debug build working with def files.
Symbian^3 SDK, def files frozen. Same result as on S60 3.2 SDK,
demonstrating Symbian^3 compatibility.
Symbian^4, code and tests compile and does not affect running.
*** This change is only required for 4.7. It is not needed for 4.8+ ***
*** If this change appears in 4.8+, it can be reverted. ***
Task-number: QT-4080
Reviewed-by: Shane Kearns
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
newallocator_hook.cpp had #include <u32std.h> for the definition of
SStdEpocThreadCreateInfo. This header is not available in earlier S60
platforms. But we do not need the full definition of
SStdEpocThreadCreateInfo, so a forward declaration is used instead.
Task-number: QT-3967
Reviewed-by: Shane Kearns
|
| |
|
|
|
|
|
|
|
| |
The hybrid heap allocator has been copied from Symbian^4 (MCL wk36
initially) and is installed by qtmain.lib as the initial allocator
for Qt apps.
Task-number: QT-3967
Reviewed-by: Shane Kearns
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
New export in corelib that is called from the qtmain wrapper to setup
the thread heap. This allows 7k of code to be shared, and makes it easier
to disable or upgrade the allocator in future releases
Task-number: QTBUG-4895
Enable new allocator by default
Rename of headers as _p.h to avoid syncqt adding them to applications
move inline functions from .inl -> .h, document & rename macros
remove #if 0 from the dla header, implement getpagesize properly
squashed after sanitisation
Task-number: QT-3967
Reviewed-by: mread
|
| |
|
|
|
| |
Task: QTBUG-10680
RevBy: Trust me
|
| |
|
|
|
|
|
|
|
| |
MMP_RULES_DONT_EXPORT_ALL_CLASS_IMPEDIMENTA must not be included in
s60main build, otherwise some symbols will not be relocatable when
linked against from gcce build.
Task-number: QTBUG-11804
Reviewed-by: Alessandro Portale
|
| |
|
|
| |
This reverts commit faff1c60a2a7f6ebef90249e759bdf822c8b17de.
|
| |
|
|
|
| |
Inline all the code that is used from QtCore as we should not assume QtCore
is present for a static library linked into random 3rd party applications.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | | |
|
| |\ \
| |/
| |
| |
| | |
Conflicts:
mkspecs/features/symbian/platform_paths.prf
|
| | |
| |
| |
| | |
Reviewed-by: Trust Me
|
| | |
| |
| |
| | |
Reviewed-by: Trust Me
|
| | |
| |
| |
| |
| |
| |
| | |
Previously only leaves from QtMainWrapper() were forwarded.
Task-number: QTBUG-6422
Reviewed-by: axis
|
| | |
| |
| |
| |
| |
| |
| | |
This is needed because they become a static library that is linked
into every application.
RevBy: Espen Riskedal
|
| |\ \
| |/ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Destroying the control environment also pops items from the original
cleanup stack which is not owned by the control environment.
This is a platform issue (and does not occur in 9.3 & 9.4).
To avoid this causing a panic, the s60main is changed to not push items
on the cleanup stack (instead, it TRAPs the call to main(), and deletes
its allocations manually).
A further 9.2 cleanup stack crash was caused when application construction
fails (because of missing resource files). The resulting exception would
bypass deleting the control environment, and return from main with the
wrong cleanup stack active.
This is resolved by doing the TRAP / cleanup / throw manually instead of
using qt_trap_throwing (The control environment cannot be pushed to the
cleanup stack, because it owns the cleanup stack at that time).
This isn't a 9.2 specific bug, but rather is revealed by 9.2 because the
missing resource file is non fatal in 9.3 and 9.4.
Fixes many autotests which have crashed on S60 3.1 since the cleanup
stack swapping patch.
Reviewed-by: axis
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
|
|
|
| |
The new build system doesn't support Symbian resource files, so it
must be precompiled. New applications shouldn't need any though.
I forgot this in the last commit.
|
| |
|
|
|
|
|
|
|
|
|
| |
When using STDCPP in Symbian^3, the definition for uncaught_exception
*must* be provided before any attempt to include e32base.h is made.
This is because STDCPP support disables the standard Symbian definition
of uncaught_exception, so the version from <exception> needs to be used
instead.
Reviewed-by: Jason Barron
|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
| |
<exception> header was missing from sqt60main_mcrt0.cpp, causing
Symbian builds to break.
Reviewed-by: axis
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| | |
| |
| |
| |
| |
| | |
Conflicts:
src/s60main/qts60main.cpp
|
| | |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Conflicts:
demos/boxes/glshaders.cpp
demos/boxes/vector.h
demos/embedded/fluidlauncher/pictureflow.cpp
demos/embedded/fluidlauncher/pictureflow.h
doc/src/desktop-integration.qdoc
doc/src/distributingqt.qdoc
doc/src/examples-overview.qdoc
doc/src/examples.qdoc
doc/src/frameworks-technologies/dbus-adaptors.qdoc
doc/src/geometry.qdoc
doc/src/groups.qdoc
doc/src/objecttrees.qdoc
doc/src/platform-notes.qdoc
doc/src/plugins-howto.qdoc
doc/src/qt3support.qdoc
doc/src/qtdbus.qdoc
doc/src/qtdesigner.qdoc
doc/src/qtgui.qdoc
doc/src/qtmain.qdoc
doc/src/qtopengl.qdoc
doc/src/qtsvg.qdoc
doc/src/qtuiloader.qdoc
doc/src/qundo.qdoc
doc/src/richtext.qdoc
doc/src/topics.qdoc
src/corelib/tools/qdumper.cpp
src/gui/embedded/qkbdpc101_qws.cpp
src/gui/embedded/qkbdsl5000_qws.cpp
src/gui/embedded/qkbdusb_qws.cpp
src/gui/embedded/qkbdvr41xx_qws.cpp
src/gui/embedded/qkbdyopy_qws.cpp
src/gui/embedded/qmousebus_qws.cpp
src/gui/embedded/qmousevr41xx_qws.cpp
src/gui/embedded/qmouseyopy_qws.cpp
src/gui/painting/qpaintengine_d3d.cpp
src/gui/painting/qwindowsurface_d3d.cpp
src/opengl/gl2paintengineex/glgc_shader_source.h
src/opengl/gl2paintengineex/qglpexshadermanager.cpp
src/opengl/gl2paintengineex/qglpexshadermanager_p.h
src/opengl/gl2paintengineex/qglshader.cpp
src/opengl/gl2paintengineex/qglshader_p.h
src/opengl/util/fragmentprograms_p.h
src/plugins/kbddrivers/linuxis/linuxiskbdhandler.cpp
src/plugins/mousedrivers/linuxis/linuxismousehandler.cpp
src/script/parser/qscript.g
src/script/qscriptarray_p.h
src/script/qscriptasm_p.h
src/script/qscriptbuffer_p.h
src/script/qscriptclass.cpp
src/script/qscriptclassdata_p.h
src/script/qscriptcompiler.cpp
src/script/qscriptcompiler_p.h
src/script/qscriptcontext.cpp
src/script/qscriptcontext_p.cpp
src/script/qscriptcontext_p.h
src/script/qscriptcontextfwd_p.h
src/script/qscriptecmaarray.cpp
src/script/qscriptecmaarray_p.h
src/script/qscriptecmaboolean.cpp
src/script/qscriptecmacore.cpp
src/script/qscriptecmadate.cpp
src/script/qscriptecmadate_p.h
src/script/qscriptecmaerror.cpp
src/script/qscriptecmaerror_p.h
src/script/qscriptecmafunction.cpp
src/script/qscriptecmafunction_p.h
src/script/qscriptecmaglobal.cpp
src/script/qscriptecmaglobal_p.h
src/script/qscriptecmamath.cpp
src/script/qscriptecmamath_p.h
src/script/qscriptecmanumber.cpp
src/script/qscriptecmanumber_p.h
src/script/qscriptecmaobject.cpp
src/script/qscriptecmaobject_p.h
src/script/qscriptecmaregexp.cpp
src/script/qscriptecmaregexp_p.h
src/script/qscriptecmastring.cpp
src/script/qscriptecmastring_p.h
src/script/qscriptengine.cpp
src/script/qscriptengine_p.cpp
src/script/qscriptengine_p.h
src/script/qscriptenginefwd_p.h
src/script/qscriptextenumeration.cpp
src/script/qscriptextenumeration_p.h
src/script/qscriptextqobject.cpp
src/script/qscriptextqobject_p.h
src/script/qscriptextvariant.cpp
src/script/qscriptfunction.cpp
src/script/qscriptfunction_p.h
src/script/qscriptgc_p.h
src/script/qscriptmember_p.h
src/script/qscriptobject_p.h
src/script/qscriptprettypretty.cpp
src/script/qscriptprettypretty_p.h
src/script/qscriptvalue.cpp
src/script/qscriptvalueimpl.cpp
src/script/qscriptvalueimpl_p.h
src/script/qscriptvalueimplfwd_p.h
src/script/qscriptvalueiteratorimpl.cpp
src/script/qscriptxmlgenerator.cpp
src/script/qscriptxmlgenerator_p.h
tests/auto/linguist/lupdate/testdata/recursivescan/project.ui
tests/auto/linguist/lupdate/testdata/recursivescan/sub/finddialog.cpp
tests/auto/qkeyevent/tst_qkeyevent.cpp
tools/linguist/shared/cpp.cpp
|
| |
|
|
| |
RevBy: Trust me
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
RevBy: Trust me
|
| |
|
|
| |
RevBy: Trust me
|
| | |
|
| | |
|
| |
|
|
|
| |
Contains some smaller fixes and renaming of macros. Looks big,
but isn't scary at all ;)
|
| | |
|
| |\ |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Squashed commit of the branch haralds-haralds-qt-s60-topics/topic/exceptions,
which also contains the full history.
Rev-By: Harald Fernengel
Rev-By: Ralf Engels
|
| |/ |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
These functions are really Symbian functions and not S60 specific so
they should be named as such. Also, our public API should use the Qt
convention and not the Symbian convention so remove the 'L' even if
it is a leaving function at the moment.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
QSymbianControl::HandleResourceChange contained global event handling.
So Qt handled same issues unnecessarily (for each shown top level
widget). Now this global event handling is encapsulated to
s60ResourceChange (new method) called by s60main. In addition,
qs60style generated unnecessary resize events. If widget was
fullscreen or maximized, then this caused incorrect resize events
(old size delivered). With these changes, qs60style just informs
widgets of style change (similarly as in qstylesheetstyle).
Task-number: 251085
Reviewed-by: Jason Barron <jason.barron@nokia.com>
Conflicts:
src/gui/kernel/qapplication.h
src/gui/styles/qs60style.cpp
|
| |/
|
|
|
|
|
|
|
|
|
|
| |
inside QtGui, we do not need to export those QMenu[Bar]::symbianCommands
through our public API, anymore.
This commit moved the code of QMenuBar::symbianCommands to
QMenuBarPrivate::symbianCommands and made that one static.
QMenu[Private]::symbianCommands was apparently unused -> deleted.
RevBy: Jason Barron
RevvBy: Markku Luukkainen
|
| |
|
|
|
|
|
| |
CQtS60MainAppUi::HandleCommandL to the new QApplication::s60HandleCommandL
so that it is in QtGui rather than in the static app wrapper.
RevBy: axis
|
| |
|
