Qt wiki will be updated on October 12th 2023 starting at 11:30 AM (EEST) and the maintenance will last around 2-3 hours. During the maintenance the site will be unavailable.

Qt 4.8 Compatibility Issues Symbian: Difference between revisions

From Qt Wiki
Jump to navigation Jump to search
No edit summary
 
(Simplify punctuation)
 
(8 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Outdated|reason=The Symbian platform is no longer supported.}}
{{Cleanup | reason=Auto-imported from ExpressionEngine.}}
[[Category:Qt Supported Platforms]]
'''English'''
'''English'''


=Qt 4.8 Release – Compatibility Issues in Symbian Platform=


This document lists some known compatibility or behavioral issues in [http://doc.qt.io/qt-4.8/ Qt 4.8] ''[qt.io]'' for Symbian Platform, including issues in Qt Components and Qt Mobility. <br /> 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.
= Qt 4.8 Release - Compatibility Issues in Symbian Platform =
 
This document lists some known compatibility or behavioral issues in [http://doc.qt.io/qt-4.8/ 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.'''
'''Note that the content of this page is work-in-progress and will be updated periodically.'''


==Key Press Event Handling==
== Key Press Event Handling ==


This issue refers to [https://bugreports.qt.io/browse/QTBUG-17545 a bug] ''[bugreports.qt.io]'' about “Enter” key press event.
This issue refers to [https://bugreports.qt.io/browse/QTBUG-17545 a bug] 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.
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==
== 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 <span class="caps">API</span> is recommended to be used.
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==
== 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.
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:\private\1234abcd”. 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:\”.
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==
== 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.
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.
Line 31: Line 38:
For instance, look at the following code snippet.
For instance, look at the following code snippet.


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.
<code>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();</code>
 
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.
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.


==QNetworkRequest – Problem with Pipelined Request and “Transfer-Encoding: chunked”==
<code>fileStream << "Test file content line " << i << "";<code>


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 [https://bugreports.qt.io//browse/QTBUG-19480 <span class="caps">QTBUG</span>-19480] ''[bugreports.qt.io]'' and [https://bugreports.qt.io//browse/QTBUG-20924 <span class="caps">QTBUG</span>-20924] ''[bugreports.qt.io]'') and will be also in Symbian, in a future Qt version.
== QNetworkRequest – Problem with Pipelined Request and "Transfer-Encoding: chunked" ==


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 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 [https://bugreports.qt.io//browse/QTBUG-19480 QTBUG-19480] and [https://bugreports.qt.io//browse/QTBUG-20924 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.
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.<br /> Note that sockets are only reused for requests that have pipelining enabled.
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==
== QNetwork - Default Value for Content-Type Header Field Changed ==


An application must always define itself the Content-Type header field in any <span class="caps">HTTP</span> 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 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 <span class="caps">HTTP</span> error. <br /> To avoid this problem applications must add relevant Content-Type header field themselves, see [http://doc.qt.io/qt-4.8/qnetworkrequest.html#setHeader QNetworkRequest::setHeader] ''[qt.io]'' and [http://doc.qt.io/qt-4.8/qnetworkrequest.html#setRawHeader QNetworkRequest::setRawHeader] ''[qt.io]'' .
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 [http://doc.qt.io/qt-4.8/qnetworkrequest.html#setHeader QNetworkRequest::setHeader] and [http://doc.qt.io/qt-4.8/qnetworkrequest.html#setRawHeader QNetworkRequest::setRawHeader] .


==QUdpSocket::readDatagram compatibility break==
== QUdpSocket::readDatagram compatibility break ==


There is a known issue in function [http://doc.qt.io/qt-4.8/qudpsocket.html#pendingDatagramSize QUdpSocket::pendingDatagramSize] ''[qt.io]''. Calling this function causes the datagram header to be lost.
There is a known issue in function [http://doc.qt.io/qt-4.8/qudpsocket.html#pendingDatagramSize QUdpSocket::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 [https://bugreports.qt.io/browse/QTBUG-27152 <span class="caps">QTBUG</span>-27152] ''[bugreports.qt.io]'' for more information.
Workaround for the problem: do not call QUdpSocket::pendingDatagramSize but reserve big enough buffer for data. See [https://bugreports.qt.io/browse/QTBUG-27152 QTBUG-27152] for more information.


==Application crash with <span class="caps">WSERV</span> 64 panic code==
== 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.<br /> The fingerprint of the panic is Symbian panic <span class="caps">WSERV</span> 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:


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.
* Implementation instantiates QWidget based class and later sets Qt::Dialog flag on it.
* The widget is scrollable
* The widget is scrollable
* The widget sets <span class="caps">CSS</span> style sheet, either in forms or in code
* 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.
The easiest workaround for the error is not to set Qt::Dialog afterwards, but to give the flag already in construction phase.


==Qt Quick Components==
</code>class myWidget : public QWidget {
myWidget::myWidget(QWidget *parent):
QWidget(parent, Qt::Dialog),
ui(new Ui::myWidgetForm)
{
ui->setupUi(this);
}
}<code>


===Qt Quick Components – ReadDeviceData Capability Required===
== Qt Quick Components ==


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


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


This issue is mentioned in <span class="caps">QML</span> element documentation, but is highlighted here.
=== 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.
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 [http://doc.qt.io/qt-4.8/qml-text.html#font.pixelSize-prop <span class="caps">QML</span> Text element] ''[qt.io]'' about fonts.
Please see [http://doc.qt.io/qt-4.8/qml-text.html#font.pixelSize-prop QML Text element] about fonts.


===Root <span class="caps">QML</span> Object===
=== 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.
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.
Line 89: Line 120:
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.
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 [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-window.html#details Window element] ''[doc.qt.nokia.com]''
Please see also [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-window.html#details Window element]


'''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:''' 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 [http://doc.qt.nokia.com/qtmobility-1.2/qml-camera.html <span class="caps">QML</span> Camera] ''[doc.qt.nokia.com]'' and [http://doc.qt.nokia.com/qtmobility-1.2/qml-video.html <span class="caps">QML</span> Video] ''[doc.qt.nokia.com]'' elements. <br /> For more information, please see [https://bugreports.qt.io/browse/QTMOBILITY-2055 <span class="caps">QTMOBILITY</span>-2055] ''[bugreports.qt.io]''
'''Note:''' there are known issues especially with [http://doc.qt.nokia.com/qtmobility-1.2/qml-camera.html QML Camera] and [http://doc.qt.nokia.com/qtmobility-1.2/qml-video.html QML Video] elements.
For more information, please see [https://bugreports.qt.io/browse/QTMOBILITY-2055 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 [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-screen.html#details Screen component] ''[doc.qt.nokia.com]''), to ensure that the application works correctly both with Qt 4.8 and earlier versions.
'''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 [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-screen.html#details Screen component]), to ensure that the application works correctly both with Qt 4.8 and earlier versions.


===Orientation locking in PageStack===
=== Orientation locking in PageStack ===


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


Applications using the Qt Quick Component elements [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-pagestack.html#details PageStack] ''[doc.qt.nokia.com]'' and [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-page.html#details Page] ''[doc.qt.nokia.com]'' 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 using the Qt Quick Component elements [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-pagestack.html#details PageStack] and [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-page.html#details Page] 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.
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==
== Qt Mobility ==


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


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


If QSystemNetworkInfo class or <span class="caps">QML</span> NetworkInfo are used at all and application has:
If QSystemNetworkInfo class or QML NetworkInfo are used at all and application has:
 
* ReadDeviceData capability only - then the data might be incomplete
* ReadDeviceData capability only then the data might be incomplete
* WriteDeviceData capability only - then application will fail with a panic
* 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.
This then also means that using Symbian Qt Components in this case requires both ReadDeviceData and WriteDeviceData capabilities.


Please see also [http://doc.qt.nokia.com/qtmobility/quickstart.html Qt Mobility quick start guide] ''[doc.qt.nokia.com]'' about required capabilities in Symbian.
Please see also [http://doc.qt.nokia.com/qtmobility/quickstart.html Qt Mobility - quick start guide] 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.
'''Note:''' to avoid unexpected problems, it is recommended to always include both ReadDeviceData and WriteDeviceData capabilities when using any System Information classes.


===<span class="caps">NFC</span>: Accessing Target That Supports Multiple Access Methods===
=== NFC: Accessing Target That Supports Multiple Access Methods ===


There is a bug in [http://doc.qt.nokia.com/qtmobility/qnearfieldtarget.html#AccessMethod-enum AccessMethod] ''[doc.qt.nokia.com]'' enum definition. It is not possible to have different access flags OR’d together because of enum value definition error in <span class="caps">API</span>.
There is a bug in [http://doc.qt.nokia.com/qtmobility/qnearfieldtarget.html#AccessMethod-enum AccessMethod] 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.<br /> Qt Mobility 1.2.2 has this fixed and TagTypeSpecificAccess flag is set if target supports it.
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. <span class="caps">NDEF</span> and tag type specific access in Qt Mobility 1.2.2.<br /> In this case, checking of access flags returns only TagTypeSpecificAccess due to [http://doc.qt.nokia.com/qtmobility/qnearfieldtarget.html#AccessMethod-enum AccessMethod] ''[doc.qt.nokia.com]'' enum definition bug. This means that following application side workaround is needed to access NdefMessage:
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 [http://doc.qt.nokia.com/qtmobility/qnearfieldtarget.html#AccessMethod-enum AccessMethod] enum definition bug. This means that following application side workaround is needed to access NdefMessage:


Instead of having normal <span class="caps">NDEF</span> access check:<br />
Instead of having normal NDEF access check:
</code>if (accessMethods.testFlag(QNearFieldTarget::NdefAccess) {
// Read or write NDEF messages
}<code>


Application should try for <span class="caps">NDEF</span> access even if TagTypeSpecificAccess is specified:<br />
Application should try for NDEF access even if TagTypeSpecificAccess is specified:
</code>if (accessMethods.testFlag(QNearFieldTarget::NdefAccess) || accessMethods.testFlag(QNearFieldTarget::TagTypeSpecificAccess)) {
// Try to read or write NDEF messages
}<code>


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


===<span class="caps">QML</span> Video and Camera elements and Qt Quick Components 1.1===
=== QML Video and Camera elements and Qt Quick Components 1.1 ===


The new rotation handling of Qt Quick Component 1.1 conflicts with <span class="caps">QML</span> 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 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 <span class="caps">QML</span> 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.
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 <span class="caps">SDK</span> application wizard, disabling is done like this:
If you use application with helper class QmlApplicationViewer generated by Qt SDK application wizard, disabling is done like this:
 
</code>QmlApplicationViewer viewer;
viewer.setProperty("orientationMethod", 1);
viewer.setMainQmlFile(QLatin1String("qml/MyApp/main.qml"));<code>


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


Please see also [https://bugreports.qt.io/browse/QTMOBILITY-2055 <span class="caps">QTMOBILITY</span>-2055] ''[bugreports.qt.io]'' and [https://bugreports.qt.io/browse/QTMOBILITY-2060 <span class="caps">QTMOBILITY</span>-2060] ''[bugreports.qt.io]'' for more details.
</code>QDeclarativeView view;
view.setProperty("orientationMethod", 1);
view.setSource(QUrl::fromLocalFile(QLatin1String("qml/MyApp/main.qml")));<code>
 
Please see also [https://bugreports.qt.io/browse/QTMOBILITY-2055 QTMOBILITY-2055] and [https://bugreports.qt.io/browse/QTMOBILITY-2060 QTMOBILITY-2060] for more details.


===<span class="caps">NFC</span>: QNearFieldTarget::hasNdefMessage() and <span class="caps">NFC</span> Forum Type 4 tag===
=== NFC: QNearFieldTarget::hasNdefMessage() and NFC Forum Type 4 tag ===


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


However, it is possible to read <span class="caps">NDEF</span> messages from the tag if <span class="caps">NDEF</span> message is present regardless hasNdefMessage() return value. <br /> Applications can use following workaround:
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:


This issue is related to [https://bugreports.qt.io/browse/QTMOBILITY-2018 <span class="caps">QTMOBILITY</span>-2018] ''[bugreports.qt.io]'' .
</code>bool targetHasNdefMessage = target->hasNdefMessage();
#ifdef Q_OS_SYMBIAN
if (target->type() == QNearFieldTarget::NfcTagType4) {
targetHasNdefMessage = true;
}
#endif


===Categories:===
if (targetHasNdefMessage)
{
target->readNdefMessages();
}<code>


* [[:Category:Qt-Supported-Platforms|Qt Supported Platforms]]
This issue is related to [https://bugreports.qt.io/browse/QTMOBILITY-2018 QTMOBILITY-2018] .

Latest revision as of 13:23, 23 August 2015

IMPORTANT: The content of this page is outdated. Reason: The Symbian platform is no longer supported.
If you have checked or updated this page and found the content to be suitable, please remove this notice.
This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine.
Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

English


Qt 4.8 Release - Compatibility Issues in Symbian Platform

This document lists some known compatibility or behavioral issues in 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 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 [https://bugreports.qt.io//browse/QTBUG-19480 QTBUG-19480] and [https://bugreports.qt.io//browse/QTBUG-20924 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 [http://doc.qt.io/qt-4.8/qnetworkrequest.html#setHeader QNetworkRequest::setHeader] and [http://doc.qt.io/qt-4.8/qnetworkrequest.html#setRawHeader QNetworkRequest::setRawHeader] .

== QUdpSocket::readDatagram compatibility break ==

There is a known issue in function [http://doc.qt.io/qt-4.8/qudpsocket.html#pendingDatagramSize QUdpSocket::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 [https://bugreports.qt.io/browse/QTBUG-27152 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 [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qt-components-symbian-getting-started.html Symbian Qt Quick Components] 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 [http://doc.qt.io/qt-4.8/qml-text.html#font.pixelSize-prop QML Text element] 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 [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-window.html#details Window element]

'''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 [http://doc.qt.nokia.com/qtmobility-1.2/qml-camera.html QML Camera] and [http://doc.qt.nokia.com/qtmobility-1.2/qml-video.html QML Video] elements.
For more information, please see [https://bugreports.qt.io/browse/QTMOBILITY-2055 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 [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-screen.html#details Screen component]), 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 [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-page.html Page.orientationLock]
* Property [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-screen.html Screen.allowedOrientations]
* Function QmlApplicationViewer::setOrientation()
* Function QDeclarativeView::setAttribute()

Applications using the Qt Quick Component elements [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-pagestack.html#details PageStack] and [http://doc.qt.nokia.com/qtquick-components-symbian-1.1/qml-page.html#details Page] 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, [http://doc.qt.nokia.com/qtmobility/qsystemnetworkinfo.html QSystemNetworkInfo] and the relevant declarative UI element [http://doc.qt.nokia.com/qtmobility/qml-networkinfo.html QML NetworkInfo] (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 [http://doc.qt.nokia.com/qtmobility/quickstart.html Qt Mobility - quick start guide] 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 [http://doc.qt.nokia.com/qtmobility/qnearfieldtarget.html#AccessMethod-enum AccessMethod] 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 [http://doc.qt.nokia.com/qtmobility/qnearfieldtarget.html#AccessMethod-enum AccessMethod] 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 [https://bugreports.qt.io/browse/QTMOBILITY-2024 the bug] 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 [https://bugreports.qt.io/browse/QTMOBILITY-2055 QTMOBILITY-2055] and [https://bugreports.qt.io/browse/QTMOBILITY-2060 QTMOBILITY-2060] for more details.

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

[http://doc.qt.nokia.com/qtmobility-1.2/qnearfieldtarget.html#hasNdefMessage QNearFieldTarget::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 .