Qt 4.8 Compatibility Issues Symbian

English

[toc align_right="yes" depth="3"]

Qt 4.8 Release - Compatibility Issues in Symbian Platform

This document lists some known compatibility or behavioral issues in "Qt 4.8":http://doc.qt.io/qt-4.8/ for Symbian Platform, including issues in Qt Components and Qt Mobility. These issues are mainly known in Nokia Belle Feature Pack 1 and Belle Refresh releases context, as they include Qt 4.8. But it should be noted that they might have implications in earlier releases too.

Note that the content of this page is work-in-progress and will be updated periodically.

Key Press Event Handling

This issue refers to "a bug":https://bugreports.qt.io/browse/QTBUG-17545 about "Enter" key press event.

On receiving an "Enter" keyPressEvent, QKeyEvent::text()::length is 1 in Qt 4.8 as against 0 previously. Qt 4.8 now works according to specification, whereas earlier implementation was not correct.

OpenC Network Function setdefaultif() Not Supported Anymore

Qt 4.8 does not use OpenC for connectivity which means that the setdefaultif() has no effect on connectivity since that is internal behavior of OpenC. Thus application must use explicit sockets or other means to set the default connection. In any case Qt Bearer Management API is recommended to be used.

Interpretation of Directory Paths

In earlier versions there was some inconsistency in interpreting Symbian directory paths either as relative or as absolute paths. In Qt 4.8 this has been fixed. This means, however, that some paths may get interpreted differently in Qt 4.8 than in 4.7.4, and application behavior may change. One such case is using drive letter as a path.

Let’s have file path, say, "E:". This is a relative path. If the Symbian application has not set the current working directory to be anything else, this path then refers to the private directory of the application - "E:234abcd". In Qt 4.7.4 path "E:" was interpreted in some functions as if it was an absolute path, referring to the root directory "E:quot;.

Flush Stream

Several C++ file operations are supposed to flush file stream handles. In previous Belle Symbian release (Qt 4.7.4) stream flush did not flush all the way to disk. This may have caused incorrect behavior if several processes were reading and writing to same files.

In Qt 4.8 this has been fixed. The file operations that are supposed to flush file do it. This however may have a performance penalty on Symbian devices. If application does a lot of file flushing, it may be a lot slower in Nokia Belle Feature Pack 1.

For instance, look at the following code snippet.

QString fname("testfile.txt");
 QFile file(fname);
 if (!file.open(QIODevice::WriteOnly))
 return;
 QTextStream fileStream(&file);
 for (int i=0; i < 1000; i+'') {
 fileStream << "Test file content line " << i << endl;
 }
 file.close();

C+ input "endl" causes a file stream to flush. Running this code causes 1001 flushes, the last one coming from QFile::close. Running this code on Belle FP1 is very slow.

If application is running slow on Belle FP1, the first thing to try is to remove unnecessary flushes. To fix the code above, change the line doing the actual write to the next one.

fileStream << "Test file content line " << i << "";<code>

== QNetworkRequest – Problem with Pipelined Request and “Transfer-Encoding: chunked” ==

This has been a known issue in Qt platforms prior to version 4.8 but is highlighted here. The problem has been fixed in some platforms (see "QTBUG-19480":https://bugreports.qt.io//browse/QTBUG-19480 and "QTBUG-20924":https://bugreports.qt.io//browse/QTBUG-20924) and will be also in Symbian, in a future Qt version.

The problem occurs if pipelining is enabled in the QNetworkRequest [qt.io] and server reply contains “Transfer-Encoding: chunked” and “Connection: close” headers, and '''if the request is not retry-able'''.

This causes the consequent request to fail as Qt tries to send the next pipelined request using the same socket.

Workaround for the problem: if pipelining is disabled in the request, a new socket will be used.
Note that sockets are only reused for requests that have pipelining enabled.

== QNetwork - Default Value for Content-Type Header Field Changed ==

An application must always define itself the Content-Type header field in any HTTP request. Qt has had a fallfack for a missing Content-Type header field however. In Qt 4.7 version the value was "application/x-www-form-urlencoded", but in Qt 4.8 it has been changed to "application/octet-stream".

An application that has previously used this feature to include Content-Type header field may now have its request fail with server dependent HTTP error.
To avoid this problem applications must add relevant Content-Type header field themselves, see "QNetworkRequest::setHeader":http://doc.qt.io/qt-4.8/qnetworkrequest.html#setHeader and "QNetworkRequest::setRawHeader":http://doc.qt.io/qt-4.8/qnetworkrequest.html#setRawHeader .

== QUdpSocket::readDatagram compatibility break ==

There is a known issue in function "QUdpSocket::pendingDatagramSize":http://doc.qt.io/qt-4.8/qudpsocket.html#pendingDatagramSize. Calling this function causes the datagram header to be lost.

Workaround for the problem: do not call QUdpSocket::pendingDatagramSize but reserve big enough buffer for data. See "QTBUG-27152":https://bugreports.qt.io/browse/QTBUG-27152 for more information.

== Application crash with WSERV 64 panic code ==

This error has been encountered so far only in Belle Refresh. However, it might occur also in Belle FP1.
The fingerprint of the panic is Symbian panic WSERV 64 and the related trace message "[Qt Message] Cannot do transparency operations on opaque window". The panic may happen if the implementation has these features:
* Implementation instantiates QWidget based class and later sets Qt::Dialog flag on it.
* The widget is scrollable
* The widget sets CSS style sheet, either in forms or in code

The easiest workaround for the error is not to set Qt::Dialog afterwards, but to give the flag already in construction phase.

class myWidget : public QWidget {

myWidget::myWidget(QWidget *parent):
QWidget(parent, Qt::Dialog),
ui(new Ui::myWidgetForm)
{
ui->setupUi(this);
}

}

== Qt Quick Components ==

=== Qt Quick Components - ReadDeviceData Capability Required ===

Due to changes in the platform implementation in Belle Feature Pack 1, application that uses "Symbian Qt Quick Components":http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qt-components-symbian-getting-started.html and has WriteDeviceData capability, '''must''' now include also ReadDeviceData capability.
Otherwise application fails with a panic.

=== Font Size in Pixels vs. Points ===

This issue is mentioned in QML element documentation, but is highlighted here.

Some application user interfaces may be corrupted if the font size has been defined in pixels. With Belle Feature Pack 1 there will be devices that have different resolution (e.g. Nokia 808 PureView) than previous Symbian devices. This means that if text font sizes have been defined in pixels, it has been fixed for a certain resolution.

Please see "QML Text element":http://doc.qt.io/qt-4.8/qml-text.html#font.pixelSize-prop about fonts.

=== Root QML Object ===

All applications that are meant to be used both in portrait and landscape orientations, or in landscape only, and are using Qt Quick Components '''must''' use Window or one of the inherited elements as their root element. Otherwise application layout will be broken when device is rotated to landscape orientation. '''Size and coordinates of the Window element must not be explicitly set'''; Window will automatically take the size of the screen in current orientation. If the application uses different layout definitions for portrait and landscape modes, it should bind its layout state to property Window.inPortrait. Binding it to any other orientation related property may cause screen flicker when orientation is changed.

Applications locked to portrait mode can use also other root elements. In that case, the root element size must be explicitly set or the application UI may not become visible.

Applications wishing to do their own custom orientation handling must not use Window as their root element. To be compatible both with Qt 4.7 and Qt 4.8, such applications should set the attribute Qt::WA_SymbianNoSystemRotation for the QDeclarativeView from their cpp code. Then, those applications are free to set width, height, and rotation properties of their root element as they like.

Please see also "Window element":http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-window.html#details

'''Note:''' applications should not include Qt Quick Components import in their code unless they really use the components. If components are used, then applications should use Window or one of the inherited elements as their root element, as explained above. Unnecessary import of Qt Quick Components may cause issues.

'''Note:''' there are known issues especially with "QML Camera":http://doc.qt.nokia.com/qtmobility-1.2/qml-camera.html and "QML Video":http://doc.qt.nokia.com/qtmobility-1.2/qml-video.html elements.
For more information, please see "QTMOBILITY-2055":https://bugreports.qt.io/browse/QTMOBILITY-2055

'''Note:''' when Window element is used as the root, in some cases it is best to lock the orientation both in the cpp code (QmlApplicationViewer::setOrientation() - or) and in the Window element (Screen.allowedOrientations, please see "Screen component":http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-screen.html#details), to ensure that the application works correctly both with Qt 4.8 and earlier versions.

=== Orientation locking in PageStack ===

Qt and Qt Quick Components provide a number a ways to lock the screen orientation
* Property "Page.orientationLock":http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-page.html
* Property "Screen.allowedOrientations":http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-screen.html
* Function QmlApplicationViewer::setOrientation()
* Function QDeclarativeView::setAttribute()

Applications using the Qt Quick Component elements "PageStack":http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-pagestack.html#details and "Page":http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-page.html#details should use only the property Page.orientationLock for this purpose. The other methods may or may not work correctly, and most likely the result is different in Qt 4.8 compared to Qt 4.7.4. Using the Page.orientationLock property, the locking is set separately for each page of the application.

Applications not using the Page element are free to use any of the other provided alternatives to lock the screen orientation. However, using the Screen.allowedOrientations property is recommended.

== Qt Mobility ==

=== SystemNetworkInfo - ReadDeviceData and WriteDeviceData Capabilities Required ===

Due to changes in the platform implementation in Belle Feature Pack 1, "QSystemNetworkInfo":http://doc.qt.nokia.com/qtmobility/qsystemnetworkinfo.html and the relevant declarative UI element "QML NetworkInfo":http://doc.qt.nokia.com/qtmobility/qml-networkinfo.html (Qt Mobility API) need now both ReadDeviceData and WriteDeviceData capabilities.

If QSystemNetworkInfo class or QML NetworkInfo are used at all and application has:
* ReadDeviceData capability only - then the data might be incomplete
* WriteDeviceData capability only - then application will fail with a panic

This then also means that using Symbian Qt Components in this case requires both ReadDeviceData and WriteDeviceData capabilities.

Please see also "Qt Mobility - quick start guide":http://doc.qt.nokia.com/qtmobility/quickstart.html about required capabilities in Symbian.

'''Note:''' to avoid unexpected problems, it is recommended to always include both ReadDeviceData and WriteDeviceData capabilities when using any System Information classes.

=== NFC: Accessing Target That Supports Multiple Access Methods ===

There is a bug in "AccessMethod":http://doc.qt.nokia.com/qtmobility/qnearfieldtarget.html#AccessMethod-enum enum definition. It is not possible to have different access flags OR'd together because of enum value definition error in API.

Qt Mobility 1.2.1 (and earlier) had a bug that it never set the TagTypeSpecificAccess access flag even though target supported it.
Qt Mobility 1.2.2 has this fixed and TagTypeSpecificAccess flag is set if target supports it.

Above mentioned issues make it difficult to handle targets that support e.g. NDEF and tag type specific access in Qt Mobility 1.2.2.
In this case, checking of access flags returns only TagTypeSpecificAccess due to "AccessMethod":http://doc.qt.nokia.com/qtmobility/qnearfieldtarget.html#AccessMethod-enum enum definition bug. This means that following application side workaround is needed to access NdefMessage:

Instead of having normal NDEF access check:

if (accessMethods.testFlag(QNearFieldTarget::NdefAccess) {

// Read or write NDEF messages

}

Application should try for NDEF access even if TagTypeSpecificAccess is specified:

if (accessMethods.testFlag(QNearFieldTarget::NdefAccess) || accessMethods.testFlag(QNearFieldTarget::TagTypeSpecificAccess)) {

// Try to read or write NDEF messages

}

Please see also "the bug":https://bugreports.qt.io/browse/QTMOBILITY-2024 about this issue for more details.

=== QML Video and Camera elements and Qt Quick Components 1.1 ===

The new rotation handling of Qt Quick Component 1.1 conflicts with QML Video and Camera elements. The video or the camera viewfinder can be misplaced in the screen. This happens more often in landscape orientation, also with applications that lock into landscape. Having no rotation in the application does not help. The problem happens only if application uses Qt Quick Components 1.1.

The work-around for the problem is to disable the new rotation handling of Qt Quick Components 1.1 and to use the old rotation handling. This is done by setting QDeclarativeView property "orientationMethod" to value 1. The old rotation handling has different rotation effects. The new orientation handling must be disabled in the beginning of application before setting the main QML file. It cannot be dynamically switched on or off during later execution. Setting the property in older environments does nothing. The work-around is safe in all environments.

If you use application with helper class QmlApplicationViewer generated by Qt SDK application wizard, disabling is done like this:

QmlApplicationViewer viewer;

viewer.setProperty("orientationMethod", 1);

viewer.setMainQmlFile(QLatin1String("qml/MyApp/main.qml"));

With QDeclarativeView the same thing is done in a similar fashion:

QDeclarativeView view;

view.setProperty("orientationMethod", 1);

view.setSource(QUrl::fromLocalFile(QLatin1String("qml/MyApp/main.qml")));

Please see also "QTMOBILITY-2055":https://bugreports.qt.io/browse/QTMOBILITY-2055 and "QTMOBILITY-2060":https://bugreports.qt.io/browse/QTMOBILITY-2060 for more details.

=== NFC: QNearFieldTarget::hasNdefMessage() and NFC Forum Type 4 tag ===

"QNearFieldTarget::hasNdefMessage()":http://doc.qt.nokia.com/qtmobility-1.2/qnearfieldtarget.html#hasNdefMessage returns always false for NFC Forum Type 4 tags, even when the tag has NDEF messages present.

However, it is possible to read NDEF messages from the tag if NDEF message is present regardless hasNdefMessage() return value.
Applications can use following workaround:

bool targetHasNdefMessage = target->hasNdefMessage();

1. ifdef Q_OS_SYMBIAN

if (target->type() == QNearFieldTarget::NfcTagType4) {

targetHasNdefMessage = true;

}

1. endif

if (targetHasNdefMessage) {

target->readNdefMessages();

}

This issue is related to "QTMOBILITY-2018":https://bugreports.qt.io/browse/QTMOBILITY-2018 .