Developing for Windows Mobile with QML
-
Hi there,
I have an App that I'm making for Symbian devices in qml, but I'd also like it to run on the Windows Mobile/CE platform.
As of yet I have found no tutorials on how to do this, build it for the WM CE platform that is.Any help would be appreciated.
Aaron
-
When you develop for Windows CE you have first to decide what's your actual target device or range of devices (and compile for the common features available in all of them).
Because of the customization of OS builds (thanks to Platform Builder), most devices running Windows CE5 or CE6 may not have all the dll's and services that you can include in a "large" Windows CE build (this is useful to use less memory and less storage), then there is Windows Mobile 6.x (that despite the release number is actually based on CE5) that has a more consistent "standard support" of dlls and services, but non so standard as in Windows XP/Vista/7.
So, select the target device, get the specific Windows CE SDK for that device (or range of devices) plus either EVC++ 4 or Visual Studio 2005/2008 with Windows CE 5/6 SDK and then you have to try to configure and compile Qt for it.
Usually you have to start with a "generic" build for CE, look at the compilation/configuration errors and warnings to verify what's supported and what's not, tweak a little the compilation switches, try again an so on.
For example, lots of embedded devices disable mouse pointer support (i.e. you don't need the mouse pointer on a GPS navigator controlled by touchscreen) so you usually have to add -D QT_NO_CURSOR to the configuration switches to disable all the Qt code calling mouse pointer management code (else you get compilation errors or runtime errors on those devices).
But "usually" is not "always", for example when I compiled Qt for a Toradex colibri board (running CE6) the QT_NO_CURSOR caused compilation errors instead of avoiding them because the Toradex SDK includes mouse pointer support by default.The most troublesome targets are Windows CE 6 devices because you have to prepare an mkspec profile specific for your target (where you tell QMake/nmake where to find the SDk's include files an libraries, specific compialtion switches and so on).
For more details, look at this link:
"http://www.sereno-labs.com/qt-4-6-2-installation-procedure-friendlyarm-mini-2440-windows-ce-5-0":http://www.sereno-labs.com/qt-4-6-2-installation-procedure-friendlyarm-mini-2440-windows-ce-5-0It explains how to build Qt 4.6.2 for a Friendlyarm board using Windows CE 5, but with a little modifications it works for 4.7.2 too (and with more modifications, with different BSP and SDks you can adapt it to compile for CE 6 for other boards/devices).
-
Hi there L.MCH, thanks for the info,
I tried the tutorial you sent me and it didn't work of course, I have 4.7.2.
What are these modifications your talking about? And in my experience Apps for WinCE 5 work on WinCE 6. Most of them anyway. So why would you need to mod it for 6? Why not have it so it can run on both?Aaron
-
Well, that example was for a specific configuration and board.
The modifications are about selecting the toolchain, the CE SDK files for the specific board and the Qt sources and configuration files.
For example, to build Qt from sources for a Toradex Colibri SODIMM module with a Marvell PXA270 ARM cpu, with MSVC 2005 with platform builder for CE 6.0 R3 and with the toradex SDK for CE 60.
I had to do the following:(N.B with Qt sources in C:\qt\4.7.2CE )
A) Create a custom mkspec folder for ARM and CE SDK compiler settings:
C:\qt\4.7.2CE\mkspecs\wince60colibri600-armv4i-msvc2005
(basically a a copy of wince60colibri600-armv4i-msvc2005 with "CE_SDK = Colibri600" in the qmake.conf file so the Toradex Colibri SDK for Windows CE 6.0 is selected)B) Created a customs SETCE6PATHS.BAT in C:\qt\4.7.2CE\bin with the following content:
bq. set INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 8\VC\ce\include;C:\Program Files (x86)\Microsoft Visual Studio 8\VC\ce\atlmfc\include;C:\Program Files (x86)\Windows CE Tools\wce600\Colibri600\Include\Armv4i
bq. set LIB=C:\Program Files (x86)\Microsoft Visual Studio 8\VC\ce\lib\armv4i;C:\Program Files (x86)\Microsoft Visual Studio 8\VC\ce\atlmfc\lib\armv4i;C:\Program Files (x86)\Windows CE Tools\wce600\Colibri600\Lib\ARMV4I
bq. set LIBPATH=C:\Program Files (x86)\Microsoft Visual Studio 8\VC\ce\lib\armv4i;C:\Program Files (x86)\Microsoft Visual Studio 8\VC\ce\atlmfc\lib\armv4i;C:\Program Files (x86)\Windows CE Tools\wce600\Colibri600\Lib\ARMV4I
bq. set PATH=C:\Program Files (x86)\Microsoft Visual Studio 8\VC\ce\bin\x86_arm;%PATH%
C) Then from C:\qt\4.7.2CE executed the following commands:
bq. set PATH=C:\qt\4.7.2CE\bin;%PATH%
bq. configure -shared -platform win32-msvc2005 -xplatform wince60colibri600-armv4i-msvc2005 -arch windowsce -opensource -release -declarative -no-qt3support -no-openssl -no-opengl -no-openvg -no-webkit -no-phonon -no-phonon-backend -no-accessibility -iwmmxt -qt-zlib -qt-gif -qt-libpng -qt-libjpeg -qt-libtiff -nomake docs -nomake examples -nomake demos
bq. setce6paths.bat
bq. nmake
-
About CE5/CE6 compatibility, it depends on the dlls installed and services running on the specific device you use.
Windows CE 5.0 has a "standard" SDK and usually devices based on it have good compatibility, but it is customizable.
That's why there is Windows CE 5 (customizable with target specific OS builds) and then there is Windows Mobile 6.x (Windows CE 5 with a "standard set" of dll and services common to all smartphones using it).
Then there is Windows CE 6.0 (not Windows Mobile 6.x), easier to customize than CE 5 and without a "standard" SDK, most devices of the same class (i.e. GPS navigators, POS, etc.) usually have the same dlls and services (because of the preset settings in Microsoft Platform Builder), but if you develop an application for a GPS navigator it may not run on a POS device because some dll's are missing.
Then there are some differences at OS level, for example on CE5 your app can use a maximum of 32MB of ram (different low level memory mapping between CE5 and CE6) and some Windows CE functions (usually dealing with low-level memory allocation and interrupt handling) behave differently.