When I started working with Qt back in 2003, what appealed the most to me was the network and GUI parts. The network part because I love network programming and have ever since I started with programming. The GUI part because of my demo scene background, but also because I never managed to get a working GUI for my apps, I just didn’t have the patience to learn all the different platform specific (horrid!) APIs. I’m a bit lazy in that way. Being a huge Linux fan didn’t make the situation better. And there was Qt, making it easy and consistent. For a C++ programmer, GUI programming with Qt on the desktop was and is just wonderful. There’s a problem though, and I’ll make a bold claim. Most programmers aren’t that much into making good and fancy GUIs. We can cope with assembling them, perhaps, and it feels great to present a functional GUI to your grandma (”I made it, ‘ma!”), but at least I get a headache whenever somebody suggests that I redesign the GUI because of this and that principle. I’m a programmer. Fiddling with a GUI just isn’t my thing.

These days we are seeing a paradigm shift in the way UIs look, and how they are written. Yes, I used the term “paradigm shift” ;-), kudos to Thomas Kuhn ;-). One of the most misused terms in our times, it’s a typical manager buzzphrase that doesn’t make sense unless you really don’t care (just translate it into “awesome new stuff”, now it makes sense) or if you know what it means. In this UI context it actually works though ;-). I don’t know if I know what it means but I’ll explain what I think it means. If this interpretation changes, then that will just lead to infinite terminology recursion but enough about that. People talk about paradigm shifts when you change your entire view of how something works. It’s really about leaving your comfort zone and looking at things with completely different eyes, and then maybe wondering how on earth you could have seen things differently in the past. “I want to be a lumberjack!!” These shifts happen at different levels of impact but you see them all around you. I think they are often seen in places where the world takes a huge leap forward somehow. I can think of a number of examples (”fatherhood”) but I’ll leave that as an exercise to the reader ;-).

On the UI front, designers are taking over. Tools and languages are improving, and the graphical designers, who have been at the mercy of programmers in the past, are not going to be anymore. As for programming languages, we’re going to see less need for compiled code and traditional APIs. Less of the imperative way of thinking (the programmer’s way) and more declarative. Who cares which button is added to the layout first or second, in whatever order? Nope, it’s about how the designer wants it to look, and behold, it ends up exactly as the designer wants it. Also, the designer doesn’t expect his UI to perform badly. That’s going to seen as a bug in the framework.

I’m a programmer, and us programmers aren’t ending up unemployed. I don’t think designers can or should go much beyond the design. What I do think is that programmers will be forced to write even more UI-agnostic code than they have in the past. Instead of writing C++ code that toggles the connection between objects and enables/disables and hides/shows GUI elements based on events, we’ll have to write APIs that expose the properties, the knobs and handles that affect them. This is not yet another MVC movement, this is about writing beans; library code with no UI whatsoever. There’s a huge difference. And the designer will have perfect freedom to redesign the UI based on just that. Developers will have no control over the UI. In particular accessing elements in the UI shouldn’t really be allowed at all (e.g., calling findChild() on a QFileDialog, ugh!). Instead we expose objects and properties to the UI layer, and cross our fingers and hope that the designer makes use of our functionality. Having less UI features exposed that we can use from C or C++, will for some be quite a painful change.

I cannot convince everyone. As a programmer, you really have to see what happens when you make the change. But I warn you, it will be hard to look back. The designers will suddenly feel like an integral part of the development team, making iterations upon iterations of their UIs and testing them in real-time on the target platform, using the _real_ features instead of just faking them. The “compiled code” doesn’t change at all while the UI is evolving. The designers won’t even need to talk to programmers at all. I honestly think we’ll see a lot more designers emerge from their dark caves and join software projects. This, of course, is seen from a programmer’s point of view. The designers will maybe think “Finally, I don’t have to deal with those… interesting programmers!”.

It’s a paradigm shift. What a wonderful world :-).

PS: Qt 4.7 will be the first version of Qt that incorporates Qt Quick, a feature that moves us closer to the world-as-described-above. Search for QML, Declarative UI, Kinetic, Qt Quick and so on with your favorite search engine, text, images and video. We’re keeping our cards close (a bit too close perhaps) for the first release but this technology will evolve rapidly after its first release.

Several of the Trolls are right now in Manaus (Brasil) at the Bossa Conference 2010 and we’re having a great time. The conference is hosted by INDt here in Brasil, and the topics covering Qt directly are:

• QML
• QtWebkit
• Next generation widgets, and
• Shipping Qt apps on Symbian

but there are also talks about KDE, Ubuntu, Maemo etc.

In my talk I’m explaining how to go from nothing to having your own Qt app on the Ovi Store. So for that purpose I created a little app wich is a “mobilized” touch version of our old Tetrix example. See image below. It’s not fantastic in any way, but I thought it might be interesting for some to install it on their phone and try it out.

There are two ways of getting this app on your phone:

Method 1: (recommended)

1. Install Qt 4.6.2 (Symbian)
2. Install BossaTetrix (normal version)

Method 2: (experimental)

1. Install BossaTetrix (Smart Installer version)

Note: Version 2 is not stable and I’ve had limited success with it. The Nokia Smart Installer is still in beta! - so if you just want something that works, go for Method 1.

My current highscore is Score: 529 Level: 2. Post your score as a comment

Oh and btw, my app is not in the OVI store yet- As I said, the Nokia Smart Installer is still in beta and the OVI site still needs some changes before Qt apps can be uploaded, but we’re one step closer, and I now basically know the whole complete process involved.

Twitter feed about the conference here.

It’s been a more quiet week. Here are the highlights:

• Robert implemented support for private browsing in PluginViewQt (33180).
• Jedrzej continued upstreaming QtScript API and bug fixing in it (34843, 34850, 35387).
• Andreas hooked up QNetworkReplyHandler to Qt 4.7’s support for the HTTP OPTION verb (34647).
• Jarkko, Nicholas, Kim and Noam fixed various bugs in the MediaElement backend, the accelerated compositing support and WebGL to Qt mapping.
• Diego continued improving layout test coverave with the Qt DRT (35694, 35255).
• Holger tweaked performance by avoiding unnecessary calls to QFont::detach (35569).
• Jocelyn and Tor Arne fixes various issues with the build system (forwarding headers, shadow builds without build-webkit but only qmake)

In addtion we have now a weekly build and we’ve started another round of API review.

QtWebKit is a part of Qt and we’ve always released them together. With a rapidly growing development community we’d like to decouple QtWebKit from Qt’s releases. It is a project on its own, it’s developed as part of the WebKit project and therefore deserves its own release. We’re going to call the first standalone release simply QtWebKit 2.0.

What does a standalone release mean?

We want to make QtWebKit release available to anyone using Qt, as a source package to install into your existing Qt installation. QtWebKit 2.0 is going to work with Qt 4.6 and 4.7. We will continue to ship QtWebKit in the src/3rdparty/webkit directory in Qt releases, too. It will simply contain the latest stable release. Inside of Qt this will be covered by commercial support.

In the near future we are going to create the release branch and aim for a final 2.0 release in May. I’m going to post future updates about the releasing and branching to our development mailing list webkit-qt@lists.webkit.org.

Unless you’ve been living under a rock, I’m sure you’ve noticed that a while ago we moved to a new public bug tracking system using Jira. The transition was bumpy, and we are still trying to iron out the kinks – however, I think that we can all agree that the system in general is a great improvement over our old proprietary solution. Having a public bug tracker is a vital organ in any living open source organism/community, and we love having it. Although it increases the transparency for how we do our bug fixes, we have yet to be as clear with our processes – until now. Thus, I present to you the ultra-failsafe guide to making a quality bug report for Qt:

Story:
Felix is a happy Qt user that has just downloaded Qt 4.6.2. He anxiously unzipped the file, and starts the compilation. He grabs a cup of tea and takes a short walk. Shortly thereafter he returns, and erupts in delight as he realizes that everything has finished compiling and that he can finally run his favourite Qt demo: affine!
However, his happiness is short lived, as he sees that the demo crashes as soon as he attempts to use the rotate slider. Oh the agony! Luckily, diligent Felix decides to file a bug report – knowing, that if he creates a detailed quality report, the hard-working Trolls in far away lands may fix it for him. This will not only help himself, but any other kindred spirits that encounter the same issue as well.

This is what he did:

1. Visit bugreports.qt.nokia.com (create an account if it’s your first time)
2. Use the “Quick Search” field in the top right to try to find any similar bugs. If you find one, then leave a comment with any additional information you have, as well as clicking “Vote for it” in the left side menu.
3. If you don’t find a bug report which matches your issue, then click “Create New Issues”
4. Select the appropriate project and issue type. In this case, Qt and Bug.
5. Fill out the fields…

Summary

Enter a short but descriptive text explaining the bug in a sentence.

Affects Version

Select the Qt version where you’re able to reproduce the bug.

Components

Select the component which best fits the location of the bug.

Description

A longer text describing, step by step, the minimum amount of actions required to reproduce the bug. Mentioning the expected outcome as well as the actual outcome is also a necessary step to gain a mutual understanding of the problem between the reporter and the assignee. Also, a vital piece of information in crash reports is the stacktrace. Retrieving a stracktrace is platform specific, however, all of them require that Qt be built with debug symbols. If you compiled Qt yourself, then make sure you supplied “-debug” during configure time. If you’re using binaries, then make sure you’ve installed the corresponding debug packages. Paste the stacktrace in the description if it’s not terribly long, else attach it as a text file. Finally, please supply any more details that you may have in this field. For instance “This bug only occurs if I have compositing enabled”, or “This is a regression from 4.6.1”.

Environment

Input as detailed description of your operating system, window manager, compiler, and any other pertinent information needed to reproduce the bug.

Attachment

This often neglected field is perhaps one of the most important. Here is where you can make a simple application that reproduces the bug and attach it. Ideally, a stand-alone main.cpp file which only has the bare minimum amount of code needed to reproduce the bug should be attached. A unit test, screen shot, or longer stacktrace is also incredibly useful.

Source Req ID

Leave blank

Followed By

Not needed

6. Click “Create”

Here’s a screenshot of the bug report that Felix made:

Felix can now either start hacking on Qt to find a solution and file a merge request, or wait until a Troll prioritizes, schedules, and fixes the bug for a release.

In short:
Always provide as much information as possible together with your bug report. The more the better. Also, please specify if a bug is a regression or not. If it is, then specify what version it worked in last. Finally, supplying a testcase main.cpp is a sure-fire way to land in the “fasttrack” of bug resolution and into the hearts of the Trolls. Also, providing a testcase is a great means of preventing the same bug from cropping up in the future as a regression.

By creating a high quality bug report, you will gain priority over those less descriptive, and your chances of a speedy resolution increased. If after all your hard work we still reject your bug, then please don’t take it personally. Instead, add a comment in the report and explain your situation so that we can re-evaluate it. After all, we also make mistakes.

Finally, I would like to extend a very warm thanks to all our incredible bug reporters, community members and customers. Although we may not fix the bugs as quickly as you may always like, your feedback is incredibly valuable for us, and we look forward to seeing your quality bug reports in the future at bugreports.qt.nokia.com!

(Important) Edit:
Please file any WebKit bugs at http://trac.webkit.org/wiki/QtWebKitBugs instead.

Albert Einstein has been quoted as saying that “insanity is doing the same thing over and over again and expecting a different result.” Apparently this is a misquote, and the original quote actually belongs to Rita Mae Brown, but that’s not important right now. What’s important is that most Qt applications are crazy.

Background
I’ll explain. Some readers may remember Gunnar’s excellent blog series about graphics performance, how to get the most of it in Qt. He mentioned the fact a few times, that text rendering in Qt is slower than we’d like.

To see why text rendering is so slow, we need to look at what happens when you pass a QString into QPainter::drawText() and ask it to display it on screen. A QString is just an array of integer values which are defined to signify specific symbols in specific writing systems. How these symbols should actually look on the screen is defined by the font you have selected on your painter.

So the first step of drawText() is to take the code points and turn them into index values which reference an internal table in the font. The indices are specific to each font, and have no meaning outside the context of the current font.

The second step of drawText() is to collect data from the font which describe how the glyph should be positioned in relation to the surrounding glyphs. This step, the positioning of each glyph is potentially very complex. Several different tables in the font file need to be consulted, with programs and instructions that e.g. do things like kerning (allowing parts of certain glyphs to “hang over” og “stretch underneath” other glyphs) and placing one or more diacritical marks on the same character. Some writing systems also allow complex reordering of glyphs based on context of the surrounding characters, as explained by Simon in his blog from 2007. This complex shaping of the text is currently handled by the Harfbuzz library in Qt.

The third step applies only if the text has a layout applied to it. The layout would be the part which breaks text into nicely formatted lines. In Qt, this could be based on HTML code, using QTextDocument or WebKit, or it could be a simpler layout, just making the text wrap and align within a bounding rectangle. The former isn’t supported by QPainter::drawText(), so I’ll focus on the latter. Using information from the shaping step, the text layout calculates the width of unbreakable portions of the text and tries to format the text in a way which looks nice on screen but which does not expand beyond the bounds set by the user.

In the fourth and final step, the paint engine takes over. Its job is to draw the symbols retrieved in the first step at the positions calculated in the second and third step. In most of Qt’s performance-sensitive paint engines, this is done by caching a pixmap representation of the glyph the first time it is drawn, and then just redrawing this pixmap for every call. This is potentially very quick.

While these four steps may be slightly intertwined in Qt today, this is in principle what happens every single time you call drawText() and pass in a QString and a bounding QRect. Yet, in very many cases, both the text, the font and the rectangle remains completely static for the duration of your application, or at least for the main bulks of it. And this is the insane part: a lot of time is wasted here. Qt already provides QTextLayout as a way to cache the results of the first three steps and pushing this directly into the paint engine. However, QTextLayout is somewhat complicated to use, it has overheads related to its other use cases, and it stores a lot more information than what is needed specifically for putting the symbols on the screen, making it unsatisfactory in very memory sensitive settings.

QStaticText!
We decided there was a need for a specialized class to solve this problem. We named it QStaticText, and it will be available in Qt 4.7. QStaticText has been optimized specifically for the use case of redrawing text which does not change from one paint event to another. We’ve tried to keep the memory footprint to a minimum, and currently it has an overhead of approximately 14 bytes per glyph (including the 2 bytes per unicode character in the string, which would assumably already be part of the application), as well as about 200 bytes of constant overhead.

In the rest of this blog, I’ll show some graphs to illustrate the benefits of using QStaticText for drawing text. QStaticText is supported by the raster engine (the software renderer used as default on Windows), the opengl engine and the openvg engine. For now, I’ll focus the attention of this blog on the raster engine and the opengl engine. I’ll also focus on the following platforms: Windows/desktop, Linux/desktop and the N900 (also running Linux, of course.) Note that the hardware on the Windows and Linux machines is different, so the results will not be comparable from platform to platform.

Benchmarks for fifty character, single-line text
The benchmark I’m running is this: drawing the same 50 character string over and over again in each paint event and measuring how many “glyphs per second” we can achieve using different techniques to draw the text. I am testing the following text drawing mechanisms:

When testing on the OpenGL paint engine, the graph will also contain results for QStaticText with the performance hint QStaticText::AggressiveCaching. This is a hint to the paint engine that it is allowed to cache its own data, trading some memory for speed. It is currently used by the OpenGL engine to cache the vertex and texture coordinate arrays that are passed to the GPU when drawing the glyphs.

On Windows
Lets start off with the results for the raster engine on Windows. As I said, the measurement is in “glyphs per second”, i.e. the number of symbols we can put to the screen during a second of running the test. The measurement is based on the frame rate of the test, which is taken as the average of nine seconds of execution per test case. Note that cleartype rendering was turned off in the OS during the test. The difference between a drawPixmap() result and a drawStaticText() result would be larger with cleartype turned on, but cleartype is not generally supported when caching the text in a pixmap, since the pixmap will inevitably need to have a transparent background, and you can’t do subpixel antialiasing on top of a transparent background. Therefore all the benchmarks are run without subpixel antialiasing to get a better comparison.

As you can see, the fastest way to draw text is to cache it in a pixmap and draw this, as pixmap drawing is extremely fast on modern hardware. However, in many circumstances you don’t have the memory to spare for this kind of extravagance, and drawStaticText() pushes over half as many glyphs per second as the equivalent drawPixmap() call. It is also three times faster than a regular drawText() call.

Using the OpenGL paint engine instead, performance of drawPixmap() shoots through the roof:

The other bars look small in comparison, but drawStaticText() using the aggressive caching performance hint in fact pushes out 5,6 million glyphs per second in this benchmark, while a regular drawText() call manages a measly fifth of that.

On Linux
Similar numbers occur on Linux:

Using drawStaticText() gives you more than a 2x performance boost over using drawText(), and drawPixmap() is a little bit less than 1,5 times the speed of drawStaticText(). When using the OpenGL engine, the difference is smaller:

As you can see, drawing a cached pixmap on Linux desktop is only slightly faster than drawing the static text item when aggressive caching is used. The hardware and the driver both play a part here, but at the very least we can see that both outperform drawText() by seven or eight times.

On N900
All the benchmarks so far have been on the desktop, where memory is cheap. Caching a few text items as pixmaps may not be the proverbial drop on those platforms, and as we have seen, using pixmap caching has the potential of being really fast. On an embedded device, however, we need to be a little bit more careful when we allocate big chunks of memory, so something like QStaticText, which is both lean and fast, can be a great tool on these platforms. So lets look at a few benchmarks for the N900 as well.

For the raster engine on the N900, the drawText() baseline performance on the N900 is currently nothing less of horrible, as you can see from the following chart:

This is of course a puzzle which will be investigated closer, as there’s no reason why it should be this much slower to call drawText(), but for now we recommend using the native engine or a QGLWidget viewport on this device. At least it makes the other bars look really large in comparison. A more interesting result is that drawStaticText() can push as much as two thirds the number of glyphs per second as when just drawing a single pixmap that covers the same area, so we have a pretty good ratio of performance on this device.

As we see from the following chart, similar numbers can be achieved when using the OpenGL engine:

Conclusion
The benchmark results displayed here so far are for a single-line piece of text, thus there is no need for the third step in the overview from earlier, where the text is formatted based on a layout. This has some implications, namely that the drawText() call can skip the third step as outlined in the beginning of the blog, as it does not need to do any high level text layout. On text which requires this in addition, performance will be even worse with drawText(), but approximately the same with drawStaticText() and drawPixmap(), since the layout step has already been done in advance. Another thing to note is that the text is fairly long and fairly dense. For shorter texts, and/or text which has more space (such as a multi-line string might have), the performance of drawStaticText() may very well be greater than that of drawing a pixmap, since the number of pixels touched becomes a greater factor in the equation.

An interesting measurement which is not included here, is the CPU load of the different functions also. We don’t have any formal benchmarks for that at the moment, but since less time is spent on CPU intensive work when using drawStaticText() over drawText(), the CPU will have more free time to do other stuff, which is a good thing. And another pleasant discovery we made while benchmarking QStaticText on the N900, is that you have to increase the number of draw-calls made per frame to a pretty high number for it to visibly factor into the time spent in the paint event. This means that even with, say, fifty strings, the drawStaticText() calls should not be any considerable impact on the performance of the application. Swapping the front and back buffers will still be the main bottle neck, which is a suitable ideal.

So the bottom line is: If you are using drawText() in your application to draw text that is never or very rarely updated, then you might consider using QStaticText instead when you start building against Qt 4.7, and we’d love to hear what you think about the API and the performance once you get a chance to try it out.

This week i was attending Tokamak 4 in Germany, the KDE Plasma meeting. I’m a Plasma contributor in my spare time so it’s always nice to meet face to face the people I’m working with. The event was hosted by Novell in the Suse office. It was very well organized and I even met some people behind this distribution. I was there to present QML and also gather the usual feedback from KDE/Plasma. I was also exiting to work on the new “project” launched couple of weeks ago : the Plasma-mobile project. The scope of this project is to bring Plasma and by extension KDE technologies on mobile phones. Plasma has already a dedicated user interface for desktop and netbook (The netbook shell) but a new baby will join the family.

After a lot of discussion, the idea was basically to have something that would work on almost all mobile devices and designers would be
able to provide a custom interface for each kind of device, without changing one line of code! How we can achieve that ? The idea is
actually very simple So, while we started working on it, another group started thinking about kdelibs and how we could get rid of “not so necessary” dependencies for the mobile world and decrease the memory footprint of it. Sometimes this kind of work doesn’t get into the user’s face but is really necessary for the overall user experience. These guys rocks, at the end of the meeting they had a very nice plan : basically a KDE for Desktop, Tablet, and Mobile. Check out the details here : http://mail.kde.org/pipermail/kde-maemo/2010-February/000059.html

Thanks to Qt and KDE infrastructure we are able to deploy our applications everywhere. Thanks to Plasma we are able to provide great organic interfaces and services everywhere. And thanks to vendors we are actually able to deploy all of this stuff on real devices

Technically speaking we decided that we would code all the “backend” for the mobile shells in a way that they would have a “view API” that would be used by designers to create different interfaces for different devices (as it’s well known that there is no such thing as an interface that works well for all kinds of devices). To create the interfaces we used QML (the new Qt declarative language to design rich UIs).

It was a really good experience! In the first day we almost didn’t code a line and just discussed a lot what would be a good interface for Intel’s device Compal Jax10. Meanwhile we wanted to create a concept that would be easily adapted to the Nokia N900 too. After long hours of brainstorm and discussions on the white board we came with an idea and Nuno (one of the Oxygen designer) started to do a mockup and some icons so we would be able to play with it.

After we had the basic images, Artur (MoRpHeUz) and me started prototyping the basic stuff only in QML so it was really easy to tweak the transitions and states and Nuno was constantly giving feedback. This experience was really nice for all of us: sometimes we just did it wrong but then gave some ideas to Nuno and sometimes it was just like what he thought! With half a day we already had a prototype using QML so we knew exactly how the shell would behave.

Having the whole idea our minds we just went to the white board and started discussing the C++ bits of the backend, in order to achieve a
good architecture that would really fit inside the “Plasma way of thinking” (TM). Basically Marco, Artur, Aaron and me discussed in the
board and tried to figure out what were the missing bits for our solution and what needed to be done on libplasma and how the backend
would be coded to achieve a good result.

Last night, on one hand after hours of hacking/thinking/bug fixing and on the other hand in just one day Artur and me finished the first
draft of the mobile shell! It was really nice and I think that it’s just going to blow minds when it’s finished. Right now we have a full
shell using Plasmoids all around and all important concepts implemented. Of course we need to improve the code that is a little
bit ugly right now and polish it like doing the notification bar (for battery, wifi signal), decide how we are going to deal with
notifications (it’s already in our mind) and of course deal with remote widgets that just depend on the notification thing as libplasma
is already taking care of the difficult stuff behind the scenes. There is still a lot of work to make this user interface ready to production but I’m quite confident that we’ll make it really quickly.

Watch out the screenshots and videos below to know more about Plasma running on mobile devices. And if you’re interested about the decisions behind the concept, check out this other post about it (http://blog.morpheuz.cc/28/02/2010/the-mobile-concept/ and http://www.notmart.org/index.php/Software/A_mobile_Tokamak)

KDE has nice people, nice technologies that can run on other things than a regular desktop computer. The future looks promising…

Box2D is an Open Source rigid body 2D physics engine for C++. It’s currently (2.0.1) released under the MIT license, which is quite permissive. Box2D is used by, among other things, Gluon (http://gluon.tuxfamily.org/), which is a game library from KDE in-the-making.

Integrating Box2D into your Qt application is quite easy, and this blog shows you how to get started. First of all:

* Step 1: Download Box2D from Google Code: http://code.google.com/p/box2d/
* Step 2: Build it (I had to insert a few #include <cstring> to get it to build)
* Step 3: Build and try the test bed application: Box2D/Examples/TestBed/
* Step 4: Read the manual: http://www.box2d.org/manual.html
* Step 5: Continue reading this blog to hook up the two frameworks…

The library doesn’t seem to install, so I just compiled it in-source and used it directly.

What I found during my approx 2 hour study today was that Box2D manages a world with bodies, similar to how QGraphicsScene manages items. In short, you create a world object and populate it with elements. Some bodies are static, like the ground, and some dynamic, like a bouncing ball. You can define joints, masses, friction, and other parameters, define a gravity vector, and then start simulating. Box2D doesn’t require a graphics system - any scene graph with elements that you can move and rotate should do fine. Graphics View works quite well. I’ve based this code on the provided “Hello World” example that comes with Box2D.

The world object defines the bounds of the coordinate system and the gravity vector. It feels very similar to QGraphicsScene. The bounds are, according to the docs, not enforced, but I got many run-time aborts when items are outside these bounds so you better make the world large enough to cover all your items.

  // Define world, gravity
  b2AABB worldAABB;
  worldAABB.lowerBound.Set(-200, -100);
  worldAABB.upperBound.Set(200, 500);
  b2World world = new b2World(worldAABB,
      /* gravity = */ b2Vec2(0.0f, -10.0f),
      /* doSleep = */ true);

Bodies in Box2D have a position and an angle, and you can assign a shape to it (convex polygon or circular). This feel similar to how QGraphicsItem has a position and a transform. In fact with 4.6 the rotation property fits perfectly with the angle in Box2D (except Box2D uses radians and rotates the opposite direction from QGraphicsItem). This example shows how to create a body, and then assign a rectangular shape:

  b2BodyDef bodyDef;
  bodyDef.position.Set(0.0f, -10);
  b2Body *body = world->CreateBody(&bodyDef);

  b2PolygonDef shapeDef;
  shapeDef.SetAsBox(100.0f, 10.0f);
  body->CreateShape(&shapeDef);

Bodies can either be static or dynamic. Static bodies simply don’t move. By default, bodies are static. To make a body dynamic, you assign a positive mass. The easiest way to do that is to ask Box2D to calculate mass and rotational inertia by looking at the shape of the body. So modifying the above slightly:

  shapeDef.density = 1.0f;
  shapeDef.friction = 0.5f;
  body->CreateShape(&shapeDef);
  body->SetMassFromShapes();

That’s really all there is to it. When you’re ready, advance the simulation step by step by calling b2World::Step like this:

  world->Step(B2_TIMESTEP, B2_ITERATIONS);

After calling this function, Box2D will have adjusted positions and angles of all bodies. So if you have corresponding items in Graphics View, you can just update their positions and rotations like this:

  void adjust()
  {
    // Update QGraphicsItem’s position and rotation from body.
    b2Vec2 position = _body->GetPosition();
    float32 angle = _body->GetAngle();
    setPos(position.x, -position.y);
    setRotation(-(angle * 360.0) / (2 * PI));
  }

Notice the negative Y (as Graphics View, like the rest of Qt, has a Y component that points downwards), and the negative rotation which is converted to degrees.

That’s really all there is. Create the world, add body elements, assign mass, and start the simulation. Use the angle and position to adjust your QGraphiscItems, and enjoy :-).

The above video shows my first Box2D + Graphics View application in action. You can find the full sources here: qgv-box2dtar.gz. I’ve tried to experiment a bit with how Box2D bindings for Qt could be done. For now I’ll leave it as an experiment.

Looots of things happened while I was on vacation :). Among other things a new backend for audio/video elements using the Qt Multimedia framework and initial work on WebGL support.

• Antti implemented a QGraphicsWebView::resizesToContents property (34885).
• Robert added Web Inspector support to the Qt DRT, adding another 27 more tests (33096).
• Jedrzej fixed QScriptValue::toIntXXX methods (34847).
• Noam implemented support for passing QWebElement objects though JavaScript (34901) and fixed a Canvas clipping bug in GraphicsContextQt (r32405).
• Ariya implemented QWebFrame::scrollToAnchor (29856).
• Yael fixed a bug with SVGs not being rendered when used as background-image from a data URI (33630).
• Noam fixed support for perspective and 3D transforms with the Qt implementation of GraphicsLayer (34960).
• Diego fixed Qt DRT issues (35131, 34955).
• Andras added support for text zooming to Qt DRT’s EventSender (35159).
• Nicholas implemented a new backend for Video and Audio elements based on the Qt Multimedia Framework (34631).
• Afterwards Noam connected this new backend to the Qt GraphicsLayer implementation, to allow the QGraphicsVideoItem of the MediaControl to become part of the GraphicsLayer’s scene (35276).
• Laszlo made the Qt DRT compile on Symbian (31589).
• Jesus removed QGVLauncher from the tree. It’s all been merged now into WebKitTools/QtLauncher (35292).
• Jarkko landed a first version of WebGL support for the Qt build (35153).
• Jocelyn and Lars created a script that allows a build of the combined WebKit sources on Symbian, allowing us to work around bugs in the toolchain and finally create debug builds for arm with rvct (https://lists.webkit.org/pipermail/webkit-qt/2010-February/000149.html).

One of the most frequently asked question after the Qt for Maemo 5 release was: “How do I create a home screen widget with Qt?”. Well - the wait is over

To play around with the “Hello World” widget shown in the screen shot, install qt4-maemo5-homescreen-example on the device (it’s in Maemo’s extras-devel repository). To get the source code, run apt-get source qt4-maemo5-homescreen-example in your Scratchbox (or clone the gitorious repository). Check out the README file for info on how to create your own Qt home screen widget. Happy home screening

In other news, we’ve also added an example on how to create control panel applets with Qt, you can find it in the Qt for Maemo 5 source code repository.

Do you recognize this pattern?

void MyWidget::contextMenuEvent(QContextMenuEvent *event)
{
    if (conditionsAreMet) {
        QMenu menu;
        menu.addAction(action1);
        menu.addAction(action2);
        menu.addAction(action3);
        QAction *selectedAction = menu.exec(event->pos());
        doSomething(selectedAction);
    }
}

It’s one of the more established patterns in Qt, nice and easy on the eye. But it hurts to say that this is one of the patterns that can lead to unpredictable flow of logic and chaos when debugging. The reason is that it gives the impression that exec() blocks everything until the menu, or dialog, is closed. And that’s sort of the case, but in reality Qt “indiscriminately” continues to process events while the dialog is shown. So you can get (unexpected) event function calls, and slot invocations, while waiting for input from a menu or dialog.

main() => Qt’s eventLoop() => contextMenuEvent() => Qt’s eventLoop() => timerEvent()

(if timerEvent opens a dialog with exec)

main() => Qt’s eventLoop() => contextMenuEvent() => Qt’s eventLoop() => timerEvent() => Qt’s eventLoop()

So what can this unexpected recursion lead to? From looking at the code at the top, it’s easy to think that your whole app is basically blocked while the menu or dialog is shown. But this isn’t the case. Only local code execution stops (as it usually does when you call a function that has not returned yet). Here are some examples of what can happen:

* Network data can arrive (readyRead() slot invocation)
* Timers can fire (timerEvent() can be called)
* You may recurse into the same event handler over again (e.g., don’t open a QMessageBox::critical in a slot connected to QTcpSocket::bytesWritten())

For QMenu, two mechanisms prevent same-eventhandler recursion, and this covers 95% of the problems that could occur. One is that QMenu is sort of modal. That means that it sort of takes over mouse activity while it’s visible, which makes it inherently hard to right-click on the widget which is now below it without QMenu getting the event instead. If you could, then a second menu would pop up. That’s one. The second mechanism is that because QMenu is a window, the window with the MyWidget instance on it loses the mouse grab. So even if you opened that menu while receiving mouse move events (which typically come in high numbers as you move the mouse around), the moment the menu is open, the originating MyWidget instance stops getting mouse events. It also loses focus temporarily, so you can’t invoke the keyboard handlers either (context menus events can be triggered from pressing the funny key on your keyboard with a pictogram of a keyboard). And there’s some code to make sure you can’t open a new top level menu while another is already open.

So, Qt has covered most cases where reentering the event loop could cause a problem: you can’t send mouse and key input to the originating widget. For menus. But what about non-modal dialogs? For example, opening a QFileDialog when somebody presses the ellipsis button (Browse…). If that dialog isn’t modal, then you _can_ press the button again. And again. Fun!

void MyWidget::mousePressEvent(QMouseEvent *event)
{
    // if this dialog was non-modal, you could just press the mouse again
    QString dir = QFileDialog::getExistingDirectory(…);
}

Qt has covered this problem as well. QFileDialog’s static (exec-like) functions, which also reenter the event loop, always create a modal file dialog (steals focus and stops mouse events to parents). Qt to the rescue!

Conclusion:

Reentering the event loop is evil, but normally causes no harm. In Qt 4.5 we added alternative functions to our dialogs. The open() pattern was introduced:

void MyWidget::contextMenuEvent(QContextMenuEvent *event)
{
    if (conditionsAreMet) {
        QColorDialog *dialog = new QColorDialog;
        dialog->open(this, SLOT(dialogClosed(QColor)));
    }
}

void MyWidget::dialogClosed(const QColor &color)
{
    colorize(color);
}

By using open() instead of exec(), you need to write a few more lines of code (implementing the target slot). But what you gain is very significant: complete control over execution. Now, the event loop is no longer nested/reentered, you’re not blocking inside a magic exec() function, and it’s clear that it’s the modality state of the dialog that decides how you can interact with the MyWidget instance. And because it makes sense, the dialogs are Window Modal by default.

Unfortunately a “patch” sneaked into the Qt Creator 1.3.1 build that was delivered with the Qt SDK 2010.02, that makes Qt Creator crash for all Windows users using TortoiseSVN.

QTCREATORBUG-710

This affects only the Qt Creator build inside the SDK and only for the Windows platform, not the Qt delivered with it for development. Also, the Qt Creator 1.3.1-only packages are unaffected.

Today we updated the Windows SDK downloads on the Qt download pages and the customer areas with fixed builds. If you suffer from the problem above, please download and install either the updated SDK packages, or the Qt Creator only packages (make sure that you get SDK packages names 2010.02.1).

We apologize most sincerely for any inconvenience this has caused.

Back in October of ‘09, Paul announced a windowing system plugin architecture for Qt. Actually, he introduced the lighthouse research project as a port to whatever architecture you may desire.

Subsequently, Morten and MBM posted about using lighthouse. Additionally, we’ve heard about some interest both inside and outside of Qt Developer Frameworks. That’s fantastic. We’re really excited about the potential of the project, and it’s nice to hear that some of you are too.

While this is still very much in the research stage (Have I said that already?), it’s high time we start nailing down some of the interfaces, and sharing our ideas about where this thing is going.

Press any key to continue: _
Early on, lots of shortcuts were taken to get things going. One of these was user/window system input handling. Somehow those mouse movements, keyboard clicks, resize events and so on need to make it into Qt. The initial strategy placed methods in QApplicationPrivate, which processed the input events before delivering them with QApplication::sendSpontaneousEvent().

This strategy posed two important problems:

First, from a code organization perspective, asking developers to access methods in a class called *Private feels wrong. Looking at the corresponding header file, src/gui/kernel/qapplication_p.h, it says:

This file is not part of the Qt API. […]
This header file may change from version to version
without notice, or even be removed.

And just in case you thought we weren’t serious:

We mean it.

Problem #2 is a technical one, with its roots in the way that QEventLoop interacts with modal dialogs. In brief, the handler for an event doesn’t return until any such dialogs (QComboBox, for example) have finished. This wreaks havoc with input systems that expect the event handler to return before dispatching any subsequent events. Try an early version of the vnc plugin with the groupbox example if you want to see what I mean. Click on the combo box and marvel at the lack of response from this point on.

We elected to address both problems by creating a new class, QWindowSystemInteraction. The intention is that this class is to provide interfaces for all of the events a window system might need to tell Qt about by way of the handle*Event() static methods. You should not instantiate or subclass QWindowSystemInteraction.

For example, what used to be:

#include "QtGui/private/qapplication_p.h"
...
QApplicationPrivate::handleResizeEvent(topLevelWidget, newRect);

Is now:

#include <QWindowSystemInterface>
...
QWindowSystemInterface::handleResizeEvent(topLevelWidget, newRect);

If you pulled from the gitorious repository recently, and your plugin doesn’t compile because of missing QApplicationPrivate:: methods, it’s worth checking to see if you need to make this change. The minimaldfb plugin is an excellent reference for the current state of development.

Within the implementation, events that might trigger a new event loop are queued, allowing the handler to return. Processing then waits until the next iteration of the event loop.

QWindowSystemInterface currently handles events related to:

• keyboard
• mouse
• wheel
• geometry change
• enter
• leave
• quit

A final caveat before I cut you loose to explore:
This is still in development. Anything other than the handle*Event methods will likely disappear.

This week’s highlights include bugfixes, performance improvements and much improved layout test coverage

• Noam fixed bugs with the GraphicsLayerQt implementation used for accelerated compositing during animations (34681, 34761).
• Yael implemented support for window.showModalDialog (25585, 34755).
• Jedrzej continued on improving and completing QScriptValue (34575, 34592, 34749, 34793).
• Diego implemented pageNumberForElementById() in the Qt DRT, which makes us pass 10 more layout tests (34777)!
• Ariya (welcome back on webkit hacking!) implemented a mapping from image interpolation quality to QPixmap transform types 34629). Sometimes WebKit can determine that a faster but lower quality scaling algorithm may be used for drawing images, and that’s now passed down to QPainter.
• Afterwards he continued on speeding up clipping operatings by using a faster method with QPainter to determine the combined clip region (32375). Also we use a few less cycles in constructing QBrush objects by re-using an existing object when setting the stroke color (34874).
• On Friday Diego implemented LayoutTestController::dumpFrameLoadCallbacks() in the Qt Drt, adding another 9 more new passing tests (34702).
• Chang re-enabled support for the app cache in the Qt DRT, adding 33 more passing tests out of 43 (34713).
• In QtLauncher it’s now possible to toggle the use of QGraphicsView as well as accelerated compositing via the menu at run-time (34844, r54654).
• Janne found a workaround for a bug with isNan on Symbian (34170).

Hello. I am Keijo Virtanen from the Symbian Devices, Application SW team within Nokia. We recently released some UI extensions to Qt on Gitorious. These extensions are UI libraries optimized for a touch interface. They will initially target the Symbian platform, but like with all Qt technology our ambition is to make this cross platform.

Some of you might have heard of Orbit. That was the internal project name that was used for an extension library we are building on top of Qt. The project was started since we felt that Qt needed additional UI and mobile domain specific APIs to be truly compelling for in particular mobile development. Until we are ready with the developments and productize this, including putting a proper name on it, we will temporarily call it “UI Extensions for Mobile”

Like with the Qt mobility project (new Qt APIs for mobile development), we also in this case aim to make the Qt APIs useful for other - additional - relevant use case scenarios. We are still working on the best way to publish new UI components that are based on Qt.
As this project is very much a work in progress, we would very much like some feedback, so please have a look at the code and let us know what you think.

Earlier today, we released Qt 4.6.2 for Maemo5 to coincide with the opening of Mobile World Congress in Barcelona.  Now I am pleased to announce that Qt 4.6.2 is also available for all of our other supported platforms.

Qt 4.6.2 provides the usual mix of bug fixes, performance improvements and documentation fixes, but it also includes two new items.  The first is the aforementioned Maemo5 support graduating from Beta to Release status (note that there is a separate qt-maemo5-opensource-src-4.6.2.tar.gz source package) and the second is the Nokia Smart Installer (see blog post here for the details).

As usual, you can get all the packages from the Qt Download Page and you can read the latest documentation at http://qt.nokia.com/doc/4.6/index.html.

For those using the public git repository, a “v4.6.2″ tag will appear soon.

As always, your feedback on Qt is appreciated. If you have any comments or bug reports, we’d love to hear from you.
Please file your bug reports at: http://bugreports.qt.nokia.com. If you want to contribute to Qt, all the information you need to get started can be found at: http://qt.gitorious.org.

Qt 4.6.2 is released, and in addition to all the bug fixes in it, we’ve also snuck in a feature or two, especially for the Symbian platform. One of interest is the ability for Qt to make use of the beta version of the Nokia Smart Installer, which makes it easier to deploy your Qt application to Symbian phones.

Using the Nokia Smart Installer

This is how you make use of it in short:

1. Download and install Qt for Symbian 4.6.2
2. Download the Nokia Smart Installer v 0.9 (beta)
3. Unzip it on top of your installed Qt for Symbian folder
4. Code your cool mobile application
5. Run qmake && make release-gcce to create yourapp.exe
6. Run make sis to create yourapp.sis
7. Run make installer_sis to create yourapp_installer.sis
8. You have an application ready for deployment!

When the user now installs yourapp_installer.sis on their phone, the Smart Installer will go on-line and get all the dependencies that your Qt application requires, typically Qt and QtWebkit + Open C. If these packages are already installed on the phone, the Smart Installer does nothing. So, it is a little bit like an “apt-get for Symbian” has been wrapped around your application. See below for a nice drawing of how it all works (click for full size).

The benefit of such a binary is twofold. It ensures the phone gets the up to date and correct versions of Qt and its dependencies, and it also dramatically reduces the file size of the application you are shipping.

Trying it out

If you’re an impatient person and just want to try out how an application using the Smart Installer works, then click the link under the image below. It will install the Qt demos (fluidlauncher and the other demos and examples) using the Smart Installer on your phone.

Tip: To get less prompts when installing, sign your app properly. Go to symbiansigned.com and Express Sign yourapp.sis, then wrap it with the Smart Installer and Express Sign yourapp_installer.sis as well. The example above still has fluidlauncher self-signed, so there are more prompts than needed. At the moment, if everything is properly signed you are looking at five prompts for the user to answer - and we’re working on getting that down to only two or three.

If you have trouble using the Smart Installer, go to qt.nokia.com/phonedemos and you can download the Qt demos where all dependencies are included in one big package and no network access from the phone is required.

It’s still in beta!

Now the Nokia Smart Installer for Symbian is still in beta, but we want you to try it out. At the moment it won’t be possible to get any “smart” Qt applications into the Ovi Store - but it is just a matter of time before that becomes possible.

Stability wise it works pretty well on the 3.2 and 5.0 phones we’ve tested (5800, N78, N97 mini etc.) but we’ve had some issues with some of our N95s where wlan fails in mid-download. Please test and give feedback to the developers in this forum. We want to hear about any usability as well as functional issues you discover.

EPL release and the Symbian Foundation

The Nokia Smart Installer for Symbian is not directly developed by the Qt developers, but we’re helping out the team in Finland/India with patches and QA. At the moment the code is not yet available for download - but we are in the process of preparing the code for contribution to the Symbian Foundation, so this should be resolved shortly.

After two technology previews and one beta, we’re happy to announce that Qt for Maemo 5 has gone gold (official platform page).

To celebrate, here’s the usual video. While we used an ugly prototype with plastic covers for the TP1 videos, we’re now showing Qt on an actual retail N900:

Since the beta, a lot of things have happened.

• Kinetic scrolling has been improved, QTableView now scrolls smoothly instead of doing 2 fps
• Several widgets got larger hit zones to make them more usable with touch
• Read-only combo-boxes were changed to Maemo value buttons
• QSpinBox got a new look
• Auto-rotation (portrait/landscape) is now supported via window-flag, no more manual D-Bus usage required
• Lots of input method improvements. Predictive text, mult-line text, symbol pickers and input method hints work reliably.
• OpenGL ES improvements
• QtWebKit theming issues fixed
• And lots of smaller fixes here and there

There are some features that need a bit of explanation.

QSpinBox got an overhaul. The Maemo 5 style guide deprecated spin boxes, so the native theming is not drawing any spin buttons. QSpinBox is used in a lot of places, so we’re bending the style guide a bit, using a separator found in another widget with custom plus/minus buttons. To make it finger touch friendly, the spin buttons are enlarged and placed at either end of the control:

QComboBox is deprecated in the Maemo 5 style guide. However, it’s a very commonly used component, so we decided to support it as well as possible. A read only QComboBox is now rendered as a Maemo 5 value button. When invoked, a dialog slides in and allows the user to pick a value. A read-write QComboBox will display its items in a classical popup, but the items are large enough to be finger input friendly. Here’s a read-write QComboBox, also showing the predictive text coming from the Maemo 5 input method:

Kinetic Scrolling has been updated, and has been disabled by default for QGraphicsView. This is due to QGraphicsView based widgets usually having deeper control over clicks and moves, so the kinetic scroller would introduce a race condition between scrolling, dragging and interacting. It is up to the widget developer whether he wants to enable kinetic scrolling on a graphics view, or use the mouse events for other interaction modes.

QtWebKit - you might notice that it doesn’t use the native widgets. This is in line with Maemo’s native browser, that doesn’t use the native widgets either. Maemo currently uses images for theming, which can’t be stretched or modified according to the web page’s needs, and also have big issues with transparency. In order to have functioning web pages, one of Qt’s vector based styles needs to be used, currently defaulting to the plain windows style.

We’ve added some examples to the beta that illustrate how to deeper integrate with Maemo, for example on how to handle rotation, stacked windows and various window states. Lots of question on our IRC channel could simply be answered by saying “look at the xyz example”. Since Maemo look&feel is quite different of any desktop Linux, we’ve also added a widget gallery example (in the package libqt4-maemo5-examples, path /opt/qt4-maemo5/examples/maemo5/widgetgallery) that shows how Qt widgets look on Maemo.

Happy experimenting

A note on PR 1.1 vs. PR 1.2

So we released Qt 4.6.2 for Maemo 5 - what does that mean concretely? It means that we’re done with the Maemo 5 port. Now, the only device that ships with Maemo 5 is the N900. The current N900 firmware (called PR 1.1) ships with Qt 4.5, and that can’t be easily replaced. Just like every Qt release takes some time to enter upstream Linux distributions, it will take a few weeks of testing and integrating for Qt 4.6 to appear with the next N900 firmware update (called PR 1.2). In the meantime, we provide the usual packages for PR 1.1 in Maemo’s extras-devel.

There’s a chicken-egg situation, though. We need a stable release, otherwise PR 1.2 won’t be able to integrate Qt. However, all that’s in the open is PR 1.1, which has some issues that hit us:

• Text color in Hildon banners and notes is wrong (white on yellow)
• Styling issues with QComboBox
• Auto-rotation not working
• Unreliabilities with OpenGL ES

Qt on PR 1.2 doesn’t suffer from these issues. In PR 1.2, Qt will also be installed in /usr, not in its current /opt/qt4-maemo5 ghetto. This means that all Qt 4.6 applications should be rebuild once PR 1.2 comes out (which is a good idea anyway).

A note on MADDE, Qt Creator etc.

So far, MADDE has not been released, so the Scratchbox based official Maemo 5 SDK is still the only supported development environment. Experimental MADDE support for Linux, Mac OS X and Windows can be found here. Please refer to the README files for installation instructions. We’re trying to get Qt Creator with MADDE support to a decent level before PR 1.2 is released.

A note on Qt 4.5 compatibility

The 4.5 version of Qt that is currently available for Maemo 5 is a community port that is not supported by us. All the core Qt APIs are of course source and binary compatible also on Maemo 5. However, the community extensions done to Qt 4.5 are not, so minor changes might be in order.

A note on desktop compatibility

Though Maemo 5 has a relatively high resolution (800×480), the screen estate is limited due to widgets being quite large in order to be finger touch friendly. Check the screen shot of the widget gallery - you can fit about 5 buttons on the screen before space runs out. In addition, the Maemo style guide is quite strict on defining on how UIs should look & feel, as opposed to most desktop systems, where you can get away with almost anything. As said before, the standard Qt APIs are binary and source code compatible to desktop systems, however, some re-arranging of UIs is in order.

Where do I get it?

Short story: Add Maemo’s “extras-devel” repository and type “fakeroot apt-get install libqt4-maemo5-dev”. Qt will be installed to “/opt/qt4-maemo5″. The long story can be found on the wiki. The version number for this release is 4.6.2~git20100212-0maemo1.

The source code repository is at http://qt.gitorious.org/qt/x11-maemo.

How to get into contact?

You can reach us via the “qt-maemo-feedback” mailing list (see Mailing List instructions), or on the “#qt-maemo” IRC channel on irc.freenode.net. For bug reports, you can use our bug tracking system at http://bugreports.qt.nokia.com. Please set the bug’s component to “Maemo 5″.

Thank you

A big thank you goes to the Maemo Qt community who initially brought Qt to Maemo, the KDE and Qt communities for providing valuable feedback, Colin Guthrie for fixing several N900 Phonon issues, and everyone else inside and outside of Nokia who contributed to the effort

So whats in the box?
8 APIs at a Beta level of maturity, 3 new APIs at a Technology Preview level of maturity, some new demonstration applications and many more updates

If you were the kind of kid who liked to rip the wrapping of your pressie and get straight to playing, then you will be interested to try the new demo applications first.

We have included:
Flickr demo , which displays a list of flickr images corresponding to the users current location, (or for demo purposes, a hard-coded location is used if there is no GPS source).

Weather Info demo
This displays the weather forecast at the users current location or again, for demo purposes, if no GPS is found then a default location is used. (As you can see its pretty hot these days in Brisbane).

“Lightmaps” demo which is an update to an older demo you may have seen, it shows a lookup of the local street map based on the users location, as determined by GPS.
If no GPS is detected a default location is selected.

The above all utilise the new Bearer Management and Location APIs.

In total there 27 examples. Although some are fairly sparse simple API feature examples, others are a little more interesting, like the above.

Also, for those who like to take their time and get a understand things before diving in, you may enjoy reading our new Whitepaper which covers all of the Beta level APIs.

What else?
Oh yeah, in addition to the source package with documentation updates we have sis and debian packages for you to try on your Maemo and Symbian devices.
Our webpage will direct you toward where you can obtain the downloads.

For those wondering how you can contribute:
The team are moving as fast as they can to offer new APIs, documentation and examples.
There is a lot of work ahead for us, and some great new APIs we hope to include in the future. The todo list is ever growing and our efforts, to be honest, are prioritizing first our Symbian and Maemo platforms. What we would benefit from is contributions toward other Qt platforms which are currently on a lower priority list for the team, but certainly would offer value to developers.
Note: Where we are introducing one of our APIs into Qt, we will first ensure appropriate platform support coverage is in place.

Next steps?
We will continue to mature the APIs and, for most, finalize in the next months.
Sensors and Camera APIs, which are currently at a Technology Preview level of maturity are likely to finalize a little later, as we hope to validate those, with your input, for a while longer.
Other APIs under development include: Document Gallery, Service Framework (out of process), Landmarks, Calendar and many more are on the list to be scheduled.

Have fun with the release and we welcome your feedback and contributions.

kind regards,
Gerard.

PS..
For those of you lucky enough to be attending MWC 2010 in Barcelona you will be able to see some of our demos at the Qt Booth. Its also a good opportunity to meet some of the Qt team face to face. The trolls are located in Hall 1 at stand #1E44.

Following the hacky Mac OS X MADDE support, we’ve finally managed to bring the Qt 4.6 beta for Maemo 5 also to Windows developers.

Usual disclaimer: Use at own risk. This is a temporary and unsupported measure until full Qt 4.6 support is added to MADDE and Qt Creator.

The following assumes that MADDE was installed to C:\MADDE\0.6.14. If not, please adjust the paths in the instructions below.

1. Install MADDE
2. Download qt4-maemo5-windows-20100210.tar.gz to C:\MADDE\0.6.14
3. Open a MADDE shell and use the following commands to unpack Qt 4.6 Beta into the fremantle sysroot:
   cd /sysroots/fremantle-arm-sysroot-2.2009-51-1-qt453
   mkdir opt
   cd opt
   tar -xzvf /qt4-maemo5-windows-20100210.tar.gz

Now, go to your favorite project and type /sysroots/fremantle-arm-sysroot-2.2009-51-1-qt453/opt/qt4-maemo5/bin/qmake and make. Hint: If you use qmake a lot, you can copy qmake.exe to a more convenient location, or set your $PATH environment variable to save some typing.

Happy MADDE’ing