Development: wxWidgets port to Symbian

Current State

wxSymbian development was discussed in this thread and Jordan Langholz started working on it. However he couldn't be joined since more than a year so the development is stalled. We only have the latest available snapshot of his work.

Device Types

There are 2 main types of devices / SDK's, Nokia and UIQ. Nokia is similar to WindowCE smartphone in that it has no pointer and only a 2 button menu system and UIQ which is PocketPC like.

Setting up the build environment

Windows

There are several IDE's available, namely Carbide.c++, Carbide.vs and Code Warrior. For UIQ there is another tool called VistaMax which claims RAD type design abilities.

Download IDE's from here.

Carbide.c++ comes in a free version that lacks some features, and in a paid developer and enterprise version. I tried the free version and wasn't greatly impressed. Compared to Visual Studio it was an easy call which one to use. There may be some features that are better in the paid version, including on device debugging.

Carbide.vs is a plugin to Visual Studio 2003. There is no VS 2005 version available, nor did it seem there will be in the future (there was talk on the Nokia forum that Microsoft kept something secret in 2005). The fact there is no VS 2005 version could limit the future of this plug in, but for the moment it has had a recent release so seems to still be supported by Nokia. It was very easy to install and compile the hello world template in Visual Studio.

I didn't try CodeWarrior. If you compile wxSymbian on CodeWarrior it won't work as the ifdef's are different. If any CodeWarrior expert has the time it probably wouldn't take too long to correct.

Download the SDK and install it in a path without spaces. Make sure you have ActivePerl installed as explained in the release notes included in the SDK.

Download the UIQ add in if you want to target that platform.

When you pick the SDK to download, if you want to debug in the emulator you need to pick the correct type. SDK's with "WINS" in the name work with Carbide.vs and those with "CW" work with Carbide.c++ / CodeWarrior. The release builds for a device work in either, so for example if you want to compile a V9.2 Symbian SDK there is no WINS version to download, but you can still use the CW version to compile for the physical device in Carbide.vs

The SDK must be installed on the same driver as your development work. Moving it to a different drive after installing seemed to work at first go but actually didn't and was quite hard to correct (ie registry hacks etc). So be careful and install in the correct directory to start with.

Linux

Read the latest guide about installing the SDK under Linux (thanks to Mathieu Cartoixa).

Notice that for all versions of SDK up to 3rd edition gcc 2.95, which has many problems with C++ programs, including but not limited to frequently crashing on valid code, is used. There is a gcc 3 for Symbian version at GCC for Symbian improvement project page but the project unfortunately seems to be inactive now.

Development State

Currently I am using the HelloWorld example that comes with the Series 60 SDK and adding widgets source files to it, getting each in turn to compile.

All the basics like strings, dates, files, thread, bitmaps, app, frame, menu etc are all working fine.

Currently working on testing on devices, then sockets and other UI components.

Internally, Symbian uses UTF string encoding. At the point that the Widgets UTF build mode is released in the future, this will clean up a bunch of the string code in the Symbian port.

Known Issues

Heap Access

The Symbian heap works a bit differently to a more traditional one. Global objects are strongly discouraged and it seems any that allocate memory in their constructor will crash on Symbian < V8.1. If you are developing on Symbian above 8.1 then it should all be OK, I've noticed no issues on the Nokia test device with global memory allocates that certainly do crash the 6.1 emulator. It is still strongly discouraged but.

The following code will crash the app, and at this point I know of no solution

   // Global Object
   wxString MyString = _T("AllocateBuffer");

   // Inside some event handler (for example)
   MyString += _T("123123123123123");    // AV

The reason is the += tries to realloc the string buffer that was allocated in a global "startup" context, where the context is now the running app.

Note that if you have the following it is OK because wxString doesn't allocate memory until something is assigned to it, in this case it will happen after the program has started. This is because wxString internals don't allocate until something is assigned to it.

   // Global Object
   wxString MyString;

   // Inside some event handler (for example)
   MyString += _T("123123123123123");    // NO AV

But this will still fail at program exit because the string buffer was allocated in a global object constructor.

   // Global Object
   wxString MyString = _T("AllocateBuffer");

   // Inside some event handler (for example)
   wxString AnotherString = MyString + _T("123123123123123");    

Bitmap Handling

If you try to load a bitmap inside a paint handler, the program will crash. This is because bitmap loading internally in Symbian is asynchronous and fires a reentrant paint. At this point I can't work out how to trap it before the internal Symbian draw function is called. Loading a bitmap inside a paint handler seems like a poor idea anyway.

This fails

   MyClass::OnPaint()
   {
       wxPaintDC dc(this);
       wxBitmap myBitmap;
       myBitmap.LoadFile();   // AV
   }

This works

   MyClass::SomeFunction()
   {
      myBitmap.LoadFile();
   }

   MyClass::OnPaint()
   {
       wxPaintDC dc(this);
       myBitmap.Whatever
   }

Other sources of information

Project file formats are discussed at [1]

The Nokia forum is helpful for SDK questions, a Google search doesn't find much. Also NewLC has a helpful message board.

--VZ 14:47, 12 April 2007 (PDT)