I know that is quite silent about the Qt Windows CE port is the past, but be asured Qt for Windows CE has not been forgotten at all.
A lot of Windows CE bugs and issues have been fixed for Qt 4.6.

Some people might have noticed that a short while ago Windows Mobile 6.5 was released. Unfortunately this was a little bit to late to fully support officially Windows Mobile 6.5 in Qt 4.6.
But the good news are that we will have some support for Windows Mobile 6.5 in Qt 4.6 and will fully support it for Qt 4.7.

Qt 4.6 will contain mkspecs for Windows Mobile 6.5 and it also will contain support for the new style. This means that Qt 4.6 applications look native on Windows Mobile 6.5.
It is also worth mentioning that the new animation framework is fully supported on Windows CE, which allows some really nice effects. This means that Qt is really able to leverage the Windows Mobile experience to new heights or in more appropriate words (I am not a marketing guy.): Qt can help you to deliver astonishing applications for Windows Mobile.

Since screenshots tell more than words, here are some:

The famous Text Edit.

A styled Tab Widget.

The new List View highlight.

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.

Someone sent me an e-mail asking what happened to the freedesktop icons I blogged about back in february so I realized I should probably write a followup. I’m happy to say that it has been merged into Qt 4.6 for some time already. If you look up the documentation for QIcon, you will find a new function QIcon::fromTheme(…) which essentially does what QtIconLoader::icon(…) did. Meaning Qt applications can now make use of the icon themes that KDE and GNOME ship with and use by default.

Since freedesktop icon themes only come as standard on X11 based desktops, you cannot use themed icons on other platforms such as Windows and Mac directly. This will simply return the fallback icon you provide. Allowing this would have forced us to decide on a standard icon theme as well as bloat the application by an extra few megabytes that many applications do not need. Instead we decided to leave this choice entirely up to the developer by making it possible to bundle themes such as Oxygen or Tango as part of the application resources and pointing to it using QIcon::setThemeName(…) instead.

This should make those pure Qt applications look a lot more integrated into the X11 desktop! Among other things, our trusty old Assistant client was modified to use the theme icons:

Screenshot showing of Assistant running on GNOME in 4.6.

Here is the same application running on KDE 4.

For those of you who don’t read the new Qt blog website, where Qt Marketing and Product Management talk about “corporatey” stuff (affectionately called the “PHB blog” by our developers), we’ve just announced that our brand, new bugtracker is public: see http://bugreports.qt.nokia.com.

So, I won’t repeat everything that is in the other blog (it is, after all, written by Marketing, so it should be better written than this thrown-together “reblogging”). I’d just like to highlight one important point that Adam made in his blog:

The Qt Bug Tracker isn´t simply a read-only view into the bug tracking system used by Qt developers, it is the bug tracking tracking system used by Qt developers.

The previous solution was an in-house system we had built over the years. It started as a distribution list for the Qt developers back in the day, then got an automatic tool to reply to the emails received and assign numbers, a robot to collect incoming emails and add to the database. Internally, we’ve had a rich-client to access that database and manipulate our own bugs. But communicating with the reporters was always very difficult.

This new tool is different. Everything is on the web. And you get to vote on issues, even watch if they change.

This is another step in our opening up of our development model. Enjoy!

Do you know the main advantage of a Hummer? It can go pretty much everywhere, that’s why many armies are using it. If I talk about a Hummer it is because QGraphicsView can go pretty much everywhere too. Recently I was lucky enough to get a N900 (generously given by Jesper, don’t know for how long though) so I decided to test Qt on it. I mainly work on QGraphicsView here at Qt Development Frameworks so it was a way to test the speed of my toy (:p). Since I’ve also been a KDE user and developer for quite a bit, I thought I could try KDE on it and more precisely Plasma.

So I downloaded the Maemo 5 SDK and started building KDE and Qt with it.

First thing you have to know is that scratchbox is not easy to set-up because you always face problems and compiling inside scratchbox is really slow. The link step is a bit broken and you have to specify manually where are the libs you link with (apparently it’s expected to be like that). It seems odd… Anyways, after a couple of hours I had Qt 4.6 (Fremantle branch) up and running. I was quite happy to see that it performs well (if you are using the right things). Animated tiles are running smoothly and painting demos as well (using opengl es2 graphicssystem).

After this initial success I tried KDE. This was more painful than I originally thought. Broken packages (mysql-server), out-dated packages (shared-mime-info for instance) and the worst : CMake crashed during the configure step. I solved that by downloading the 2.8 RC version that I built myself. But after a couple of hours of fighting and debugging I got this:

Link to youtube video

As you can see Plasma is running fine on this device. Of course a lot of work is needed to make it “finger” enabled (the actual applet handles are not really appropriate) but it’s a good start and Plasma is flexible enough to allow that. I have created a separate “shell” called plasma-mobile (Plasma already has the desktop and netbook shell) and I pushed that on the KDE playground. It also needs a lot of work to integrate well with the device (battery, network, profiles and so on) but the goal is to invite people to contribute to Plasma in order to offer a real alternative to the hildon-desktop. Plasma already has many many features/applets that we can just use on the N900. This also comes with a global effort to bring KDE technologies to the device as Kevin said in his blog. You can also participate in discussions on the KDE mailing-list for Maemo.

So yes Plasma is also a hummer, it runs everywhere but it’s the luxury version.

Since there is currently no official Spotify client that can run on Embedded Linux (wine doesn’t run on arm architectures), and since I really wanted to have access to my Spotify account from my N900, I decided to give the open source Spotify client library called “despotify” a run. This is a library of C functions used to access different parts of the Spotify API for use with premium Spotify accounts.

By playing around with the console clients that are included with despotify, I was able to access my play lists and play songs perfectly. However, I was unable to use any of the GUI front ends to despotify that I could find. My guess is that they do not play well with Maemo 5 as they were originally written for the n800-series.

Inspired by the fact that all this stuff actually existed, I decided to write my own front end to Despotify, using Qt 4.6. The results can be found in Gitorious, at:

http://qt.gitorious.org/qt-labs/qtspotify

To build the application, first compile and install despotify as explained here.

Make sure you enable “pulseaudio” as the back end for despotify by editing the Makefile, as the default gstreamer back end has some threading issues and will cause crashes if you access the GUI while it’s playing. When you are done, do a “make install”.

To build the front end, you also need to have Qt 4.6 available. For best results on the N900, use the Maemo branch of Qt.

When you are done, copy the executable to your phone and start it up. Use the menu to log in, and the search field to search for music. If you want to access your play lists, select the “Retrieve play lists” menu option and they will pop up in the search field menu.

This is what it will look like:

Note that this is an early version, so there are still bugs and some missing features (e.g. you don’t get more than fifty results for a search) that I intend to implement when I get the time, but the client should be usable as it is.

I have shown parallax sliding example long time ago. It was certainly inspired by the increase use of such an effect in the so-called home screen, typically in the mobile platform. Since there has been also an increase interest on Qt for Symbian example programs, I decided to recycle that old example and to turn it into something that fits the form-factor and user experience on the phone. Thus, the demo is (re)born.

The code is in Graphics Dojo repository, find it in the parallaxhome subdirectory. For a touch device, you can tap on the icons on the bottom bar to switch between different pages (enjoy the subtle bump effect of the icons). With a non-touch device, left and right arrow keys are your friends. The heart of this parallax effect is the difference of speed between the graphics items (those wonderful food photos) and the background. The above screenshot demonstrates that exactly: on the right side, although now the page (with the weather icon) has been shifted from the center one (with the home icon), you can see that these two pages mostly share the same background portions.

Exercise for the reader: use the panning trick to shift between one page to another. If you feel brave, add some kinetic effect, too.

As a last note, this will be my last Graphics Dojo example. For future Qt-related code examples, please check my personal blog on a regular basis (e.g. just track the posts tagged with qt).

May the training spirits be with you! Namárië.

I had the pleasure of talking to some fellow state machine enthusiasts at DevDays in Munich. Here are some of the topics that were brought up, in randomized order:

Verification. How can you check that your state machine is sane, or rather, how can you disprove that it’s criminally insane? Currently there isn’t a way to do that. We tried to design the API so that many (most?) semantic errors will be caught at compile time. But that doesn’t get us all the way, unfortunately; what happens if you forget to specify the initial state of a compound state, for example? The QStateMachine::error() signal is there to report such cases; if the state machine detects a semantic error at any stage of executing its algorithm, it emits the error() signal. But maybe it would be nice to have a function that can run a set of standard sanity checks before the machine is started?

Performance. We currently implement the SCXML algorithm more or less exactly as it’s specified. I don’t yet know how well it scales wrt number of states and transitions; well, I have one benchmark where the running time grows exponentially, but there are many different configurations that need to be investigated (flat vs nested state machines, sequential vs parallel states, custom events and transitions vs built-in ones, etc.). Is anyone out there creating state machines with thousands of states, and if so, are you seeing performance issues?

Lazy population of states. For large compound states, it can make sense to only create the contents of the state when (if) the state is actually entered. To do that, you need only create an initial state, and reimplement QState::onEntry(). You need to create the initial state because the state machine will request it _before_ the compound state is entered (and QState::initialState() is not virtual…). In your onEntry() implementation, use a flag to check whether the state is being entered for the first time, and if so, create the remaining child states and add transition(s) to them from the initial state, as appropriate. The state machine actually does similar kinds of lazy initialization internally; the signal associated with a QSignalTransition is only connected when the transition’s source state is entered, for example.

Debugging. There’s no straightforward way to debug state machines in Qt 4.6. What’s needed first is a “debugger client” interface that the state machine can use to deliver notification of e.g. state changes. This interface would then serve as the basis of debugging tools. It would be nice to have a visual representation of the machine (tree view?) highlighting the current state, be able to “step” the state machine execution, set breakpoints on transitions, inspect the event queues, and so on. P.S.: If you’re building Qt from sources, there’s a QT_STATEMACHINE_DEBUG define that you can enable in qstatemachine.cpp; this will cause the state machine to spew out a log of everything it’s doing. This output can be difficult to parse humanely, though, especially when your machine has nested states.

Why QtCore? Couldn’t the state machine framework be in a library of its own? Yes, it could, but we chose to put it in QtCore so it can easily be used anywhere, without introducing new dependencies. The QtCore library grows by about 5% (150K) due to the state machine classes. Note that it’s still possible to remove the framework from compilation by using the qconfig tool, just like you can with the animation framework (also part of QtCore) and several other features in Qt.

Multithreading. How do you use state machines with threads? Well, there are a few things you should know. Firstly, the state machine classes are reentrant, meaning you can have multiple state machines running at the same time (one per thread, say). Secondly, the QStateMachine::postEvent() function is _not_ thread-safe, meaning that it’s not safe to call postEvent() on the _same_ machine from different threads; you’ll have to manage the synchronization yourself if you want to do so (but maybe QStateMachine::postEvent() should be made thread-safe, like QCoreApplication::postEvent()?). Thirdly, if you’re using signal transitions, there is no restriction on whether the object emitting the signal lives in the same thread as the state machine or not; the state machine will always create a connection of type Qt::AutoConnection, meaning that the connection will be queued if the object lives in a different thread. This means that the state machine can be processing events in its own thread concurrently with the signal being emitted in another thread, without you having to worry about synchronization.

See you in San Francisco, maybe?

Today marks the 10th Birthday of Qt Embedded! It was 10 years ago today that we first came up with the notion of an “embedded” version of Qt to serve the industrial sector and the infant higher-end handheld/CE market. At the time, the project was called “Qt/FB” (Qt for FrameBuffers).

This first version of Qt Embedded was built around the idea of a QPaintDevice for QImage. This notion (through multiple rewrites) eventually developed into some of the biggest architectural improvements in cross-platform Qt: generalized paint engines (the raster paint engine being the “frame buffer” one); window surfaces/backingstore; and Alien (non-native child widgets). These were critical improvements that then opened the door for easier platform porting (Mac OS X and Symbian/S60 benefit much from them), and accelerated paint engines, and now graphics systems, for OpenGL and OpenVG.

From simple beginnings on iPAQ and Cassiopeia handhelds and industrial devices, then, as the foundation for Qtopia, on the Zaurus and eventually phones like the Greenphone and the Neo and various cool consumer electronics devices (some of which we could never tell you about), Qt Embedded functionality was ever richer.

Embedded targets have changed a lot in 10 years - OpenGL ES is now commonplace, and the “PDA” has been completely hybridized into mobile phones. Touch screen quality and user-expectations for beautiful fluid interfaces now well-exceeding the demands on the desktop, creating ever more challenges.

We have learned a huge amount in this time about what it takes to put Qt on the “low end”. Paul’s recent blog entry about Lighthouse shows how the learning is still bubbling away, and with Qt for Symbian S60, Qt for Windows CE, and Qt for X11 on Maemo devices, the low end will of course remain a very important focus for us, with performance in all parts of Qt a key concern - bringing benefits to all Qt platforms, including the desktop.

It was announced at Qt Developer Days in Munich yesterday, but as a long standing Qt tradition states: “The release isn’t out until the Release Manager blogs about it.” So, here it is: Qt 4.6.0 Beta 1 is now ofiicially available.

This release improves on the Tech Prevew 1 release by adding a large number of fixes for bugs and documentation issues, and by finalizing the Gestures API.

The Beta release is available as a source package (there’s just one type of source package now, with .tar.gz and .zip versions that have identical contents), and as pre-built binary packages for Windows, Mac OSX (Carbon and Cocoa), and making its debut with this release, Symbian.

You can get the packages from the Qt website here, or from our ftp site. You can also find the latest documentation at http://qt.nokia.com/doc/4.6-snapshot/index.html.

As with the Tech Preview, we would like constructive feedback on this Beta from the community of users and developers. if you find a bug, you can submit a fix or an autotest that demonstrates the bug via the public qt repository on http://qt.gitorious.org. Alternatively, if you have any bug reports or suggestions, whether they relate to the code, the documentation, or something else Qt-related, just follow the instructions for submitting feedback.

In conjuction with this Beta release, we are launching The Qt Blog, a new site that will include product and roadmap information, details on Qt usage, and other topics that interest the Qt community. The Qt Blog is available now at http://blog.qt.nokia.com.