If you didn’t already notice, Qt 4.6.0 is out - including our port to Qt 4.6.0 to Symbian. It’s been one and a half year in the making and it’s about time we summarize and look back for a bit. But, before we get into details about that, here are some fact about our current releases:

Qt 4.6.0 for Symbian in brief:

• To test out Qt on your phone simply browse to qt.nokia.com/phonedemos with your phone
• To develop your own applications, download the installer here
• To find limitations and notes about this release go here
• To find the list of public bugs for Qt for Symbian go here
• And, here is the list of of known issues

And of course, here is a video showing some demos made with Qt 4.6.0 running on Maemo and Symbian phones!

Qt 4.6.0 for Symbian development timeline:

March 2008

• Project starts.
• I go over to Oulu and visit the guys from Digia who has done som pre-studies and a barebones Qt port to Symbian.
• Hunting for people inside Qt itself to sign on to the project.

April 2008

• Got Qt collegues to sign on! And got Digia guys as well. We’re now 5 Qt guys and 5 Digia guys.
• We’ve had some Symbian training - descriptors are ridicolous!
• Alessandro arrived from the Berlin office! Will stay in Oslo for half a year.
• Working on qmake bootstrapping and setting up git.

May 2008

• Working on .mmp generator
• Working on Qt autotest for QtCore
• Fiddle with EPOCSTACKSIZE and EPOCHEAPSIZE

June 2008

• “Lighthouse” released internally in Nokia(QtCore + autotests)
• “Pyramid” plan created
• Boating trip!

July 2008

• Jason gets analog clock running in the emulator!
• We work on the Qt event loop in a Symbian world
• We’re playing around with Open C

August 2008

• QtGui compiles and links with RVCT
• Start working on network module
• QtGui running on my N95! (picture)

September 2008

• Learn how to sign .sis files internally in Nokia
• Merged in the network branch into our S60 mainline
• Got a new guy from Digia to join!

October 2008

• FTP example working on an E71 picture
• “Pyramid” is released! (QtGui + QtNetwork>
• QtSVG ported (picture)
• Kristian visits the Boston Webkit team

November 2008

• We play around with flashing phones
• We plan how to move from Qt 4.4 to Qt 4.5 for the port
• WolfenQt (stripped down version) running on the N95 (picture)
• QDesktopServices gets some loving

December 2008

• New event dispatcher merged in
• More work on S60 style
• “Temple” is released!
• Moving to Qt 4.5 work started

January 2009

• Guys from Symbian (Sosco actually) visits and we talked about Out of Memory issues
• Working on menu integration
• Input methods work started
• Better font integration started
• Add more Symbian specific features to qmake

February 2009

• Ran lance tests to check graphics quality
• We get a Symbian guy onboard the project
• We start looking into shared and native bitmaps

March 2009

• “Garden” is released!
• Native S60 style is looking good
• QtWebkit work is starting to speed up
• We start looking at OpenVG
• Qt 4.6 kick-off for Qt Oslo team

April 2009

• QtWebkit running for the first time! (picture)
• OpenVG paintengine is drawing something! (picture)
• Major improvements in keypad navigation
• Frans joins the project too
• Raptor support is added to Qt

May 2009

• Harald helps us with exception handling and OOM code
• Simon joins a few weeks too for helping with Webkit
• Maurice helps to make nice Windows installer packages
• We hold a Qt for S60/Symbian crash course in Oslo for the other devs

June 2009

• Windows 7 is discovered to be OK as a development platform (my machine crashed!)
• “Tower” is released!
• We get Qt running on the Samsung i8910! (picture)

July 2009

• Espen visits Akademy and GUADEC in Gran Canaria
• The rest of Qt start reviewing our Symbian branch
• Another Sosco guy joins our team for Phonon work!

August 2009

• The Qt dialogs are improved for small screen usage
• Start experimenting with .DEF files
• More work on getting automated testing properly working
• Symbian branch is merged into the Qt mainline! SHA: e190e700d707c3000f813c106c27d8f5aeda44d0

September 2009

• Start working on getting automatic binary snapshots up and running
• Exception safety autotests added
• Focusing on package testing, fixing autotests and killing bugs

October 2009

• More webkit work
• Native pixmaps gets some loving
• Jani shows off a cool homescreen demo based on Qt at DevDays. See video
• Colossus is released!
• Alessandro and Espen goes to SEE09

November 2009

• Performance work and planning starts
• We learn how to Symbian Sign!
• Qt 4.6.0 RC1 is released!
• We fix bugs like crazy
• We test packages like crazy
• Qt 4.6.0 final is released!

Qt for Symbian what now?:

It is now the 1st of December and we’ve just celebrated that we managed to deliver 4.6.0 on time. As much as I’d love to rest on my laurels for a little bit, you’re probably asking what is going to happen next now for 4.6.x and a coming 4.7. Here is a short brief of the things we’re looking at:

• Fix deployment for Qt for Symbian (smart installer that downloads dependancies automatically)
  OpenGL ES
• Heavy performance improvements
• Drastically improve the install experience
• Closer integration with Qt Creator
• Fix bugs.
• Proper Symbian Signed for Samsung and Sony Ericsson as well

If this happens for 4.6.1, 4.6.2 or later is not settled yet, but if you pay attention to this blog as well as our commits you will stay informed.

Thanks to:

• My wonderfull co-workers, both in the porting team as well as the rest of Qt
• Our partners: Digia, Tieto and Sosco (now Accenture) and the great developers they gave us (well, we ARE paying for them)
• Other developers and managers in Nokia who has helped with autotests, signing Qt, tradeshows and more
• The early adopters who have tried out Qt and given us feedback!

So, as of today Qt officialy has Symbian support. It took us roughly 20 months. We started with one person, and ended up with 15 fulltime developers. We’ll relax for half a day, then take a deep breath and continue on 4.6.1 and more long-term 4.7. But right now, we need another glass of champagne…

One day I was sitting at my computer, waiting for my build of S60 to finish. I had run my usual round of build commands and custom scripts to speed up the build if but a little, and was expecting to wait for at least 10-12 min. At this point it occurred to me (well, it had occurred to me before): The Symbian build system is really overkill. What could it be doing that’s taking so long, for something that should be relatively simple: compile and link?

So I thought to myself that this can definitely be improved, and that’s how I started the work on a Symbian make specification that is based entirely on qmake and make (no Symbian build chain stuff, although it uses the tools from there), and runs on Linux.

Then you might say “What about the Raptor build system that is supposed to improve things?”. It is true that Raptor improves a lot of the deficiencies of good ol’ abld, but I still felt that the huge Raptor build system is sooo overkill for something really simple. I like to obey the KISS principle. Call it a personal itch!

With this in mind I have two design goals:

1. Ditch all unnecessary file types. This includes bld.inf and MMP files.
2. Be fast!

Whether I’ll be able to fulfill them in the end, time will show, but that’s what I’m aiming for at least.

But let’s get into the gory details. Be reminded that the build system is still in the very early stages, and is not ready for for the end user yet, but if you like to tinker with the latest and greatest, read on. Here’s what works currently:

1. Running configure.
2. Building QtCore.dll with RVCT.
3. Running QtCore.dll
4. Building user applications with RVCT.
5. Running user applications.

Here’s a few things that don’t work yet, but I plan to get them working:

1. Building the host tools automatically (this needs to be done manually ATM).
2. Building QtCore.dll with GCCE (this doesn’t work with the official port either, but as soon as it works there, it should work here as well).
3. Other Qt dlls. QtGui.dll should probably be easy to get compiling, but it needs a few header fixes first.
4. Building user applications with GCCE.
5. Making the process of building a package automatic.

Here’s one thing that will probably never work:

1. Building for the emulator. The emulator won’t run under Wine, so there’s no point in building for it. If the build system gets ported to Windows maybe it’ll be supported, but not before then.

The procedure for getting the system up and running is subject to change as the project goes forward, so instead of posting it here, I have put it in the README.s60-mkspec in the Git repository. To get it, go to http://qt.gitorious.org/+qt-developers/qt/s60-linux-mkspec, and clone the repository from there. Then check out the “working” branch. This branch is often rebased based on the latest work in the topic branches. “master” should not ever be rebased, but many things are missing from there at the time of writing.

Here’s a few short term goals for the project in the following weeks:

1. Get the other modules compiling.
2. Get the process to be more streamlined (e.g. more like the other platforms)
3. Move from ABIv1 to ABIv2. The former is the old way of linking binaries on Symbian. Since this is being superseded by ABIv2, which is binary compatible at run time, but not compile time, it makes sense to only support that.

Together with the other platforms (finally!) we’ve now released the Qt 4.6.0 beta1 for Symbian. Get the nice installer here:

So what has happened since the last release (I’m talking about “Tower” released around 3 months ago).

• We’ve moved into the Qt 4.6 branch. This means we can break the other platforms - yay!
• We’ve added an experimental backend for Phonon (using MMF). It plays audio and video!
• We’ve fixed a lot of bugs! Still lots left though.
• We’ve added the possibility to have a mouse curser on non-touch devices!
• QtWebKit has been updated to a newer version
• The QtScript engine has been completely replaced with a nicer and faster one from WebKit.
• We’ve added daily snapshots.
• Ariya has added some new nice demos. Check out the video below.
• We’ve also removed support for compiling qmake with the Nokia Win32 compiler, but added support for MinGW and Visual Studio 200x instead.

If you want to try out these demos on your own S60 phone, here is what you do. Open your browser on the phone and navigate to:

Then simply click on the link found there, answer yes around 20 times to all the dialogs and security warnings. Then once finally done navigate to Applications and launch fluidlauncher.

For help on getting started with your own application development go here. And then finally, the obligatory video of whats new. This time I used a Samsung i8910 and my old trusty Nokia 5800. Enjoy!

So, with Qt SDK 2009.04, there is yet another release out of the door. Now, the first question you may have is: “Why is there no update to Qt Creator in this release?”. The answer is simple: We are working full steam ahead towards Qt Creator 1.3, which will contain lots of nice features.

We could have rushed some of them into an intermediate release, but then again, testing and packaging takes time. So we decided it would be more useful to release an only slightly tested 1.2.90 technology snapshot, look for feedback from all you out there to verify that there are no severe issues and then continue full steam ahead with the integration of stuff we have been working on.

Since then, we enabled the preliminary Symbian support for the Windows version of Creator. The editor has received some love, featuring an improved indenter and smart auto-completion of braces, comments and quotes. Also, we have exposed the renaming of local variables a bit more. To demonstrate these features, we have prepared a video:

Also, parts of the new refactoring engine, which can be described as improvements on top of the current C++ code model library found its way into Qt Creator. While 1.2.90 already allowed for the renaming, more refactoring will be possible.

We are now going into feature freeze, meaning the last features are now being merged into mainline. It also means that if you want to check out the current state, have a look at the daily snapshots and give feedback on the Qt Creator mailing list.

We will keep you updated with more blogs and screen casts on the road to Qt Creator 1.3. Meanwhile, you can browse the Changes file for features that have been implemented so far. Enjoy!

Have you ever been developing an app, and at some point wanted to know exactly which code was being run, and for how long, when you used it?

On the path to getting Qt inside your Nokia devices, we’ve recently been making use of a special Nokia tool for doing just that, and I thought I would give you a short behind-the-scenes tour of it so that you can see how serious we are about taking Qt everywhere.

If you’ve ever tried to speed up some of your own code before, you probably used some kind of profiling tool. Valgrind is a good example, and one that is heavily used in the development of Desktop Qt.

Desktops normally use x86 processors, but away from the desktop and running on batteries, ARM processors are most widely used. These systems tend to have quite a different architecture from desktop computers, as well as slower clocks and smaller caches. So some effort is needed to make software run fast on them because the performance bottlenecks can also be quite different.

One feature ARM-based chips often have which you don’t find on the desktop is ETM. Using this, the ARM can send trace information about every instruction it executes out through a dedicated debug port in real time, without slowing down execution of the software at all.

As ARMs usually run at hundreds of MHz, ETM creates a large amount of data in a very short time, so you have capture it using an external box with a few Gbytes of RAM. For cost reasons, you won’t ever find an ETM port on a device you buy in the shops, but during development of the devices, special versions are often made with just such a port.

Here’s a picture of a “special device” which is ETM-enabled, along with the Lauterbach PowerTrace II I use to capture the data:

Even with Gigs of RAM, you can only trace for about 10 seconds or so. Although that doesn’t sound like much, it’s actually enough to take a look at almost all interesting use cases.

Ok, so now I’ve got all that data, how do I make some sense of it? This is where FineToothComb comes in.

FineToothComb, or FTC as we usually call it, is a Nokia tool which takes all that ETM data plus some extra information taken from the device at the same time using JTAG, and all the binary code and symbols installed on the device, and then spends some minutes correlating all that together to create a database a few Gigs in size for a each trace.

To see what happened I then use FTC’s “Trace Explorer”, which starts off showing me something like this:

What you can see here is a “MIPS graph”. Time increases to the right, and the number of millions of instructions executed per second goes upwards. The colours represent different threads and processes that ran, with the names and instruction counts for those shown below the graph.

Because of memory latency and caches, you almost never see a CPU running one instruction for every clock cycle. Memory copies especially cause the CPU to spend most of the time waiting, which show up as “low” MIPS values on these graphs.

This first graph gives you the big picture of what happened during your use case. To see more detail you can zoom in on a region of interest. Here’s 165ms:

And again down to just 1.3ms:

Eventually you get down to the level of seeing individual context switches between threads - the operating system in action.

To see what a thread was doing, you simply choose it from the graph and the tool shows you a call stack for that time, along with the time taken (in nanoseconds) and number of instructions run for each call. From that last graph I opened the “lightmaps” stack:

The white lines are blocks of instructions being run from within one function. Red lines are calls from there to other functions, with the total time for that call in nanoseconds show in the second column.
Any call can be opened up to see what it called, in this case I opened the operator>>> call to see that it ended up in a file read which went to the Symbian file server. The tool can even cross over from user space into kernel calls to see what happened there as a result of a user call. Green lines show calls that have been opened up. As you move the mouse over calls, the graph at the bottom highlights the time range for that call so you can see where you are in the trace.

You can also see into any system servers or kernel threads that ran, as well as interrupts. Another feature is statistics of which functions used time and instructions for any block of time. Here are the top 10 functions from the big blue section in the 2nd graph - obviously a PNG decode:

And it can even capture and show what was on the display of the device to help understand the trace later:

Overall it’s really useful for quickly homing in on any code that needs performance optimisation, and because it’s not just a statistical sampling of what happened, it can be used for studying many kinds of use cases, for instance answering a question of why a system is waiting when it should be busy. Most importantly it does all this with the device running at full speed without requiring any special “debug” software build, so you don’t need to guess about how anything is in the “real” case, because this is it.

Using FineToothComb on Qt has already helped us quite a bit with performance of the Qt port to Symbian. Early on in the port, it highlighted some bottleneck functions which were converted from smaller but slower THUMB instructions to faster ARM instructions. It caught when we were not compiling using the ARM’s vector floating point instructions. It also helped with the optimisation of raster rendering functions using ARMv6 and data preloading. In another case it caught the fact that we were using a slow blit operation for the final screen update, when a different parameter would cause a much faster blit to be used.

Even though FTC isn’t a tool that is available outside Nokia, the improvements it can and has found already are, and more of them should be coming your way soon.

I’m going to be at the Qt Developer Days 2009 in Munich, so if you are there too and would like a quick demo of FineToothComb, just track me down and ask!

I promised you daily builds of Qt for Symbian/S60 a few weeks ago, and here they are. Every night at around 02:30 new binaries will be available.

There are two types of files available. You want the latest qt-embedded-s60-opensourceYYYYMMDD-4.6.0-tp1.exe file. The other qt-embedded-s60-opensource-src-4.6.0-tp1.zip is the source package used to create the latest .exe and can mostly be ignored. The .exe contains a Windows Installer as shown below, and here is instructions on how to use it.

There are three Qt .sis files included in the .exe. Most of you (unless you work at Nokia and have an RnD phone) wants to install the qt_for_s60_selfsigned.sis together with the fluidlauncher.sis or whatever application you’re creating yourself.

Works for S60 3.1, 3.2 and 5.0. If you’re using some funky internal RnD SDK, it might work (Hint: use the the “Choose additional folder(s)” option if you’re SDK is not in devices.xml).

The code we’re building from is whatever is HEAD of http://qt.gitorious.org/qt/qt/commits/4.6. In other words if we break the build, no binaries for that day - oh well. At the moment QtScript and QtWekbit are still not there - but soon my friends, soooon.

Update: As of 2009.09.29 the snapshots contains QtScript and QtWekbit as well. Yay we’re so great!.
Update2: Well, we’re not that great it seems. The .dlls gets copied to your epoc32, but they’re not inlucded in the Qt_libs sis files. Fixed now, should be correct in tomorrows snapshots.
Update3: Yepp - was fixed today :D.

Final disclaimer: This is not product quality software. It might make your phone depressed and make kittens cry. Use at your own risk.