| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Reviewed-by: Trust Me
|
| |\
| |
| |
| |
| |
| | |
Conflicts:
src/gui/kernel/qevent.cpp
src/gui/kernel/qgesture.cpp
|
| | |
| |
| |
| | |
Reviewed-by: Trust Me
|
| |\ \ |
|
| | |/
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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
|
| |/
|
|
| |
Reviewed-by: Trust Me
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
Not sure why the migration classes should be are \obsolete.
|
| | |
|
| |
|
|
|
|
| |
Note that i also removed the #error since the enum is already updated in master
Reviewed-by: Gabi
|
| |
|
|
| |
subdirs in the include path
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
