The Qt Mobility teams are working full steam to bring you new APIs and extend our Qt developer offering.

To that end, we are very pleased to share the Technology Preview of our latest APIs.
This set of new APIs will be matured, with your help, and released later this year as QtMobility 1.1.0.

As you may know, we have also worked hard to resolve issues within the QtMobility 1.0.1 release, and to that end, earlier today we released our 1.0.2 package. While the quality of 1.0 is of the highest importance, we did not want to delay in sharing our drafts here for 1.1, as we believe that sharing early and often with you helps to achieve robust, high quality APIs.

Those longer term veterans understand that the Technology Preview releases are the best opportunity for you to help shape our new APIs before they solidify.

Releasing a Technology Preview early on like this however has some limitations for those reviewing. Specifically, given the early stage of development we have included only minimal backend support. But it is better to release the API drafts early and give you the opportunity to review and contribute before things become too settled.

On the subject of Contributions:
Your contribution toward desktop backends in particular is always most welcome as the program are firstly prioritising mobilie platforms; specifically Symbian and Maemo. (And later this year in Q3/Q4 we change our default development environment to Meego! )

Some detail on the logistics of how to go about reviewing this Technology Preview release:
This time round we are introducing ‘DevNet’ to the process.
DevNet facilitates better API review and communications.
Each of the new APIs will be individually introduced via Wiki on DevNet at http://developer.qt.nokia.com/.
There will also be a forum thread for each API, where you can share your review comments and track progress of the API as it matures toward Beta.
Good eh!? we certainly hope so
Also, let us know how you feel about that.

Ok, so whats in the box this time round!?
This Technology Preview contains 8 new APIs and also, in a few cases, some extensions to the existing APIs that were introduced in 1.0.
We are also introducing Qt Quick (QML) bindings for our APIs and several of those too are shared in this preview!

The list is as follows:

Service Framework API (Out-of process)

Document Gallery API

Maps/Navigation API

Organizer API

Landmarks API

Camera API

Versit/Organizer API

Telephony Events API

Feedback API

Contacts API

You can download the source package from:
ftp://ftp.qt.nokia.com/qt/solutions/qt-mobility-opensource-src-1.1.0-tp.tar.gz
ftp://ftp.qt.nokia.com/qt/solutions/qt-mobility-opensource-src-1.1.0-tp.zip

Some APIs have been worked on a little more than others but overall, we believe they are in good shape for you to commence your review. Backend implementation wise, most of the APIs have the Maemo 5 backend which is currently our primary development environment.
For each API there is an example application that demonstrates usage.
Please note that Symbian SIS packages are not provided within this technology preview release as the backend is still under heavy development.

We hope you enjoy this early preview of the ongoing work and as always,
please continue to contribute, as your feedback is very valuable in helping us get it right!

Thank you,

Gerard and Min.
On behalf of the Qt Mobility Program team

Its here!
For those in Europe enjoying a well deserved vacation by the side of a pool, or indeed for the rest of us around the world working hard on our projects, the availability of this package should come as very good news.

The team, have worked very hard to ensure that our 1.0.2 package addresses those critical fixes (P0, P1 errors) that we communicated about on our recent alert post.

In short, the more prominent APIs issues were: Location API crashes on Symbian platforms and Sensors API failing on Maemo 5.

So we are very happy/relieved to be able to say that the promised 1.0.2 package has now arrived and can be downloaded from our Qt Solutions webpage.

Also, coming very soon…your chance to download the technology preview release and be the first to try the next set of new APIs!! Not long to wait now at all

We hope you enjoy!

Kind regards,
Gerard & Min.

On behalf of the Qt Mobility Team.

Qt 4.7.0 string freeze is now in effect. No changes to strings will be accepted from this point.

Qt aims at being fully internationalized by use of its own i18n framework. Localization to languages we have no internal resources for needs to be provided by the community. If you would like to contribute your own translation please look at the Qt Localization guide.

QML is starting to approach its initial release. Those who have been using QML for a while can rejoice, for this means that we’re no longer changing everything and the stability of having an actual release can now be seen on the horizon (although maybe I’m just bitter because I had to change Samegame again today, because the QML behavior underneath has changed in what should be the last destabilizing change of this release). To celebrate, I’m going to do some blog posts on QML; just some various brain dumps on how to get the most out of QML. I think this is useful, largely because I think that QML is so amazingly powerful when you do get the most out of it. For now, getting the most out of QML is sadly limited to just awesome, fluid UIs. It’s still worth it. Since the docs explain how to get started and animating your UIs with QML, I’m going to start from the other side here. Presumably a lot of labs readers are C++ developers, and are wondering how they can get the most out of QML even though they write C++. In this case you can get a lot out of QML from using it as the UI layer on top of your C++ application logic. So here are the ‘recommended best practices’ to think about, so that you can make your next application QML-compatible from the start. Since this is basically just separation of the UI layer and the application logic layer, these practices are probably a good idea anyways. (Note that this is NOT the model-view-controller pattern, even though there is some overlap.)

Separating the UI from the application logic, QML style, starts at design time. Think about what it is that your application really does. Naturally you’ll want to have a fluid, aethetically pleasing yet eminently usable user interface for it, but that part comes later. Your application may interface with a custom database, or it may play a game, or it may perform complex calculations over and over. For simple things, like just accessing web content or adding two numbers, you can make do with what comes with QML, such as the integrate QtScript or XmlListModel. For everything else, there’s Qt C++. If your application is, for example, interfacing with a custom database then you’ll likely be implementing that interface in C++ still. Because the layers are separate you should implement, on its own, the C++ parts that drive the application logic.

When writing the C++ layer, you want to end up with a QObject derived class which exposes all the relevant application data through properties, signals and slots. For a database example, you would have properties that get set to provide the connection details, then you would have signals when the connection state progresses, and then you would have some way of getting the data. Depending on the data, this could be slots that return a value, properties that include whole models for viewing in the UI, or a mixture with slots that might update the data in the models exposed through properties. This is similar to existing Qt APIs for data objects. If you look at QAction, you will see that it provides a variety of properties for setting details about the action as well as a signal when the action is triggered. Looking at QAction as an example, it also has slots for manipulating properties. While this is not necessary for QML, it is perfectly acceptable for use from C++. Another example would be the folderlistmodel plugin in src/imports/folderlistmodel, A final real-world example would be the system info API in Qt Mobility which you could expose to QML and then just pick up and use due to the property based interface.

For the most part it really is as simple as just using properties, signals and slots. The only QML specific advice I’d give is to think more declaratively. The techincal requirements for QML integration are easy to meet, but for something that’s really easy to use with QML it helps to consider the declarative approach when designing the interface. This is not incompatible with a good C++ interface. The main difference is with the use of properties. From C++, properties are little more than a convenience for the documentation. But from QML, properties are the primary method of interaction. It will be more useful from QML to have a boolean property isOn than to have turnOn and turnOff slots in C++. It will also be a lot easier than having a toggleOnOffState() slot and a getOnOffState() slot. Because properties are the main method of interaction for QML, it’s also better to have properties rather than just slots when passing data in or out of the C++ class - even when the communication is strictly one way. This is because the declarative approach thinks in terms of properties (The state is on. I want the state off.) rather than imperative steps (The state is on when getState()==true. If getState()==true, setState(false).). Other minor details from thinking declaratively are to always remember to have a notify signal for properties, and to allow the properties to be set in any order instead of having strict initialization order requirements. It’s a subtle distinction though, and in the end though you’ll just have a C++ class with a black box implementation and an interface comprised of properties, signals and slots. Such a class can then be used by a variety of things to construct a full application by adding a UI. From this class, you can add a C++ QWidget UI, a QML UI or something else (perhaps a pyside UI) on top to create a full application.

As this is a best practices approach, it includes a test plan. You’ll want to test this with automated unit tests before even writing your first UI. Because you want a C++ part completely separate from the UI, it needs to be tested separately to any of your UI front ends. This can seem like a lot of overhead, but the actual data part is usually quite small compared to the UI. If it isn’t then it’s probably something really hairy and you need the extra testing anyways .

The advantage of having a completely separate UI and data layer is that you can alter or add new UIs at a moments notice. Imagine ‘themes’ that can change the entire look and feel, not just a few colors and pixmaps. Even better, imagine the ease in which you can port your application to a completely different platform. I think Qt’s cross-platform widgets do a fine job on some of the desktop platforms, although that is debatable. Less debatable is how well they do when porting your app from a desktop platform to a 240×320 keypad phone and a 800×480 touchscreen phone. With such radical changes in the form factor and basic I/O devices, there is no alternative to a complete UI rewrite if you want to have an excellent UI. But if you have the UI and data layer completely separated, you can easily rewrite the entire UI in QML, and get the same functionality behind it with a simple recompile. So while ‘write once, deploy everywhere’ is an impossible dream with the UI across phones (and similar devices) you don’t have to give up hope on the application logic, which was the harder one to write anyways.

A second advantage is that the separate UI and data layer allows them to be developed individually. While a developer is writing and testing the data logic, a designer can prototype and write the UI with dummy data. Then the unification of the two to make a real application becomes really simple. Or, for free software projects, if the developer has a great idea but wrote a lousy interface for it, then a designer has a much lower barrier towards contributing to make it more usable. He could just write a UI in QML and, at least in cases where the C++ logic was deployed via the QML plugin system, actually create and use it without needing to compile or even read the ‘intimidating’ C++ code.

It might be Qt specific, but my advice for future designs is to expose the application logic in a QObject derived class, using properties, signals and slots for the interface. You can then expose it through a QML or C++ plugin, use it with a QML or C++ UI, or even run unit tests on it directly. This design helps with modularity where it counts, in the data layer, and allows UI swapping at will (or even at runtime, if you’re so inclined).

Ever since we introduced the Qt WebKit integration, it has rapidly become one of the most popular features within Qt. Enabling the development of web applications is crucial for meeting market demands. We see an increasing amount of Qt being used for web enabled device creation – from netbooks and mobiles to TV’s and a broad range of home media devices – therefore we see a need to provide device manufacturers with more means to make packaging and security of web applications easier on devices.

In light of this we are pleased to announce that we have started to build a web application framework, Qt Web Runtime, on top of Qt and Qt WebKit, which will enable web apps to be more powerful than before.

One important objective with Qt WRT is to enable a W3C-standards-based web runtime, so you will be able to package apps and deploy them to smartphones (or a variety of embedded devices) just like with regular apps. One of the key advantages is that you can access many of the device resources like camera, contacts, messages, etc. simply by using JavaScript APIs.

A quick example of how to get access to the accelerometer of a device is illustrated by the small piece of code below. You register for notification of events pertaining to acceleration (on the channel AccelerometerAxis) through startChannel() and your provided callback functions get called whenever there is any acceleration around any axis of the device.

var wrtSensors = nokia.device.load("sensors");
wrtSensors.startChannel(callback, "AccelerometerAxis", errorCallback);

function callback(data) {
       console.log("x-axis: " + data.axisX + " y-axis: " + data.axisY + " z-axis: " + data.axisZ);
}      

function errorCallback(err) {
       console.log("Ouch, " + err.message + "error code:" + err.code);
}

Just like Qt runs cross-platform, Qt WRT is planned to run across different platforms and devices. Taking Web Runtime to Qt means that this technology will be open sourced and part of Qt’s new open governance model. We really hope, in the coming months, that you will be interested in contributing to the success of Qt Web Runtime and how we govern it together.

We are working on a feedback/contribution infrastructure and will provide more info as soon as we have more pieces in place, so that we can develop Web Runtime together with you - in the open. As part of Qt’s public roadmap and our open governance model, you all have the opportunity to be involved in how Web Runtime evolves and grows, and we are looking forward to seeing you involved in that process.

So today, the journey with Web Runtime begins. A snapshot of the current Qt WRT code has been placed on get.qt.nokia.com/qtwrt to give you an idea of how Qt WRT looks today. Note that this snapshot of the code only works on Nokia N900. Subsequent releases will support more platforms and devices, so stay tuned since we plan to share more code with you within the coming month.

If you want to provide some feedback or join the discussion, please head over to the QtWRT forum on the Qt Developer Network.

I like July. There are many good things about this month, like having no snow in Oslo or no night in Oslo (technically we do, but it’s an hour or two long only). Another one of them is, like Harald said, vacations. And though I like mine very much, the one I’m thinking of is about most of Finland being on vacation. That means less emails, less things I need to handle. And in turn that means I have some time for free thinking.

A couple of weeks ago, I was discussing on the #meego IRC channel with Arjan van de Ven and some others about timers. He had come to me with a suggestion for a new API in Qt which would match the glib g_timeout_source_new_seconds and related API. Arjan is the reference when it comes to conserving power on Linux systems. He’s the author of PowerTOP, Timechart and his blog is full of information on this subject (unfortunately he doesn’t seem to blog often, which is a pity).

What he explained to me is that many timers in applications don’t need an exact precision, but just a ballpark. More importantly, it’s better for the battery life if the CPU sleeps as most as possible, so batching up the wakeups within one application and across the applications achieves interesting results. We sacrifice precision in favour of battery life. As he explained to me, Glib will create a hash of some session attributes and then schedule wakeups at this fraction of a second, called “perturbation”. All applications use the same session attributes, so all applications calculate the same perturbation. And since these values are constant for the duration of the session, we have wake-up points spaced one second apart from each other.

Why doesn’t it simply choose a constant value instead of calculating? Something like 0? Well, the answer is that you want to save battery power on your device, but you want to decrease network congestion. Imagine that you’re on a network with other devices using the same algorithm. Also imagine that you have synchronised your system’s clock with an outside source via NTP. If everyone wakes up at the same time, there’s a possibility that they will all try to use the network at the same time, causing collisions and thus retransmissions.

Now, this isn’t news to us. I remember discussing the idea of coarse timers with Brad more than once, and possibly with some others. But we’ve never actually done it, because we didn’t have a good algorithm.

So I sat down at my workstation two evenings and I hashed out a basic implementation, including a new QAbstractEventDispatcherV2 class and an enum to QTimer. Then I improved the algorithm while on the flight to Finland, to attend Akademy 2010 in Tampere — as usual, it’s when you’re on battery power that you worry about saving battery

Instead of two modes that Glib offers you (high precision and seconds-backed), I implemented three, aided by C++ overloading and one enum. The enum is given so that you can choose the current mode (QTimer::HighPrecision) or if you want to choose the seconds-backed implementation (currently called QTimer::VeryCoarse, API reviews clearly not done yet). My implementation of the seconds-backed algorithm doesn’t calculate a perturbation, though: it simply rounds the fraction of second to the nearest second (as well as your interval).

How can I get away with using a perturbation of 0, unlike Glib, you may ask? The difference is in how we calculate time in Qt. Glib’s main loop uses the g_get_current_time function, which returns the actual time, like Qt’s QDateTime::currentDateTime or currentMSecsSinceEpoch (new in 4.7), which are adjusted by NTP. Qt’s event loop, however, uses a feature of Unix systems called “monotonic time”, which is not adjusted by NTP, and returns a value that never goes backwards nor jumps (hence the name “monotonic”, related “monotonous” because it’s very boring). The monotonic timer is exposed in Qt as of 4.7 with the new class QElapsedTimer.

The other big new feature I added is the new, default mode. I’ve made QTimer default to an adaptative algorithm which I’ve called QTimer::Coarse (again, I haven’t done API reviews yet). Remember: we’ve been telling you for years that QTimer is not precise, so I’m taking the opportunity to make it imprecise. But I’m not going overboard, so I chose a maximum absolute error of 5%. This number also gave me the two boundaries for the adaptative algorithm: 20 ms and 20 seconds.

For 20 ms, 5% error is 1 ms, so the adaptative algorithm would introduce errors of less than the calculation granularity. So instead, if you specify a timer of 20 ms or less, we’ll simply switch to the high-precision mode. This means all your 16 ms timers (to reach 60 fps) will continue working as they did before. Similarly, at 20 seconds, the error I can introduce has reached 1 second, so we simply switch to the seconds-backed algorithm. For this case, all your 30 second timers for network timeouts will be rounded to the second.

Between 20 and 100 ms (except for 25, 50 and 75 ms), we simply round off the wakeup time. So if you ask for a 23-millisecond interval, your code will wake up first at 22 ms, then at 24 ms later, then 22 again, etc. So in average you get 23 ms, but it’s always a bit off.

For the other cases, the algorithm will introduce up to 5% errors to try and align wakeups. The algorithm I implemented simply checks if the interval [expected-ε, expected+ε] (where expected is the precise wakeup time and ε is the 5% error) includes one of the preferred wakeup times. If it’s possible to wake-up at a full second, it will do so. Otherwise, it will check if it’s possible to wake up at 500 ms after the full second. And then other instants…

More than that, it chooses what boundaries to wake up based on what your timer is a multiple of. If you have an interval multiple of 500 ms, it will try to wake up at a multiple of 500 ms (that is, 0 or 500). It’s multiple of 250 ms, it will try to wake up at a multiple of 250 ms (0, 250, 500 and 750). And so forth for 200, 100, or 50 ms. If your interval is not a multiple of 50 ms, like an interval of 623 ms, you’re just weird and the code won’t do you much good

The interesting net effect of this is that timers drift slowly over time. They drift towards a preferred boundary and will reach it within 20 cycles (in the worst case). Once they’ve reached the preferred boundary, they will lock to it and become rather precise.

Take the following as an example: now the time is 40120.673 seconds and you ask for a 400 ms timer, we calculate that the maximum absolute error is 20 ms and our preferred wakeup time is a multiple of 200 ms. The first wakeup time would be 40121.073 and the closest multiple there is 40121.000. Given the maximum error we can introduce, we’ll schedule a wakeup at 40121.053, that is an interval of 380 ms. The next timeout will be at 40121.433, then 40121.813. After that, we realise that the instant of 40122.200 is within reach, so we choose that one. And after that, what we realise is that we can wake up at 400 ms intervals precisely.

While for one timer this isn’t very useful, a normal application has a couple of timers running, and a system has several applications running. Now applications will ask the kernel to wake up at the same instant, so the kernel can in turn schedule a long sleep and wake up the CPU from deep sleep only when needed.

The above isn’t perfect, though. For one thing, if you start two 400 ms timers, depending on the time that you started them in, the algorithm might decide to drift them in different directions (because 1000 isn’t a multiple of 400). So your application will instead be consistently waking up every 200 ms. So you still need to find your own way of synchronising events.

Arjan also pointed out that Linux since 2.6.28 has a feature that allows applications to inform the kernel what their timer slack is, via prctl(2) (though the PR_SET_TIMERSLACK constant doesn’t seem to be documented). I’m not sure how to best use this feature to save power. What I’d like is to tell the kernel, at the moment that we’re going to sleep, what our slack is, so we can avoid one extra syscall. Arjan told me that, if we can make use of it, he’ll add that syscall to the kernel

And I did try the code in existing applications. Actually, I have been running KDE for now two weeks with different versions of this code, without ill-effects. In fact, the number of wakeups per second in complex applications like plasma-desktop seem to have diminished. Such complex applications often load plugins that do independent tasks. I noticed that plasma, for example, starts 62 timers of 2 seconds on my workstation (a little less on the laptop). With my code, that is all reduced to one or two wakeups (on the laptop, the startup is slow enough that it always crosses a boundary and thus plasma will wake up twice a second).

Anyway, about the title of this blog… when I wrote it, I actually was reminded of “Einstein’s biggest blunder,” but which today is under debate because Einstein might have been right even when he thought he was wrong.

Happy hacking and happy holidays. See you in August (± 5%).

It’s vacation time in Finland, which means less emails, which means more time for blogging

First, we’re happy to report that Qt 4.7 for a potential future Maemo 5 update (*) is progressing nicely. Next to dozens of Maemo 5 specific bug fixes, we’re also happy to announce that a few new features for Maemo 5 have entered 4.7-fremantle. Since the N900 doesn’t support multiple touch input, QGesture support was off by default in Qt 4.6. For Qt 4.7, we managed to add support for single touch gestures, like tap and tap-and-hold, which makes touch-friendly UIs friendlier to write. Users of Qt Mobility’s Bearer Management should be happy to know that Qt’s internal auto-connect-when-offline mechanism can be entirely disabled via QMaemoInternetConnectivity::setAutoConnectEnabled(). And on top of that, the new 4.7 features also run nicely on the N900, most notably QtDeclarative.

Qt 4.7 experimental packages can be found in Maemo’s extras-devel repository. Scratchbox SDK users can install them by running fakeroot apt-get install libqt4-experimental-dev.

Experimental support for the experimental Qt 4.7 packages for the experimental MADDE (0.6.84) environment (as shipped with the Qt Nokia SDK) can be found here. Check the README for installation instructions.

We’d like to ask all of our Qt 4.6 users to give Qt 4.7 a try. All bugs can be reported as always at bugreports.qt.nokia.com. Happy development

(*) “potential” means it might or might not happen and we have no clue if and when

Two months ago, we introduced the Qt Developer Network. We decided to start with a closed beta phase to iron out the worst quirks and most annoying bugs. We sent out invitations to those who had pre-registered and contacted us directly. During the following weeks we have gathered immensely valuable feedback and lots of meaningful bug reports and suggestions for improvement.

A big thanks to everyone who participated in this first phase, we wouldn’t be where we are today without you!

Time to enter the next phase

Photo by Paula Rey on Flickr

Yesterday late in the afternoon, we rolled out the last missing feature to proceed into public beta: the tagging system.

Most of you are probably familiar with the concept of tagging. Pieces of content can be associated with an unlimited amount of keywords - think flickr - and sorted by said keywords. Our tags work across all types of content - forum threads, wiki pages, FAQ, the blog and static pages for now, eLearning, videos, Qt books and more is planned. Together with the implemented rating system, it will be a blast to find information related to your area of interest.

We think now is the time to open the site to everybody who wants to participate. Although we’re not feature complete yet, we have everything in place to build a great place of Qt knowledge and exchange.

Welcome on board!

PS: Marius has all the details of the latest roll-outs on the DevNet Blog.

Qt 4.7.0 Beta2 is now available for download from the Qt Download Page. Source packages (.zip and .tar.gz format) and binary packages (for Mac Cocoa, Mac Carbon, MinGW 4.4.0 and Visual Studio 2008) are available.

Note the naming change of Mac packages compared to Qt 4.6.x has been repeated in this second beta. This reflects the fact that Cocoa is now the primary Mac platform for Qt. Binary packages for Carbon will be discontinued from Qt 4.8 onwards, but will continue to be shipped for the remainder of the 4.7.x series.

The purpose of this second Beta release is to allow the scope change of Qt Multimedia as well as provide a better base to produce a good quality public 4.7.0 release candidate.

We´re also making snapshots of Qt Creator 2.1 available today. Used together with Qt 4.7 Beta2, these snapshots provide a full preview of Qt Quick. Qt Creator 2.1 includes an early preview of the Qt Quick Designer, as well as support for working with Qt Quick projects, and editing and debugging QML code. Snapshots are available for download from http://qt.nokia.com/developer/qt-qtcreator-prerelease.

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

If you would like to provide feedback, you can do so using the Qt Bug Tracker. If you want to contribute code, documentation or autotests to Qt, all the information you need to get started can be found at qt.nokia.com.

We screwed up! A serious bug in Qt 4.6.3’s QtOpenGL module on Windows went undetected through reviewing, the auto-test system and quality assurance! The bug causes a device context leak, and after 9999 repaints, the program stops updating its widgets. The bug is fixed in our repositories and will not appear in our next releases. Until then, if you are compiling Qt from source, you can use the this patch.

Two weeks ago I announced here on Labs that we were committed to an Open Governance model for Qt and related projects. I have read all the comments posted on the blog and those sent to me by email. I even had the chance to meet Robin Burchell in person and we had a very nice chat about the process, and the issues we’re facing. He also had some constructive suggestions.

In the meantime, we’ve begun to try and address some of the low-hanging fruits I referred to. Since last week, the Qt repositories on Gitorious are synchronised at a 59-minute delay, instead of 12 hours (that is, every 15 minutes we push what the internal repositories had 59 minutes prior). The delay will remain for the time being, as a measure of safety, but we’ll revisit later the time to see if we can reduce it further.

I’ve also begun asking my colleagues about moving all of our internal and non-confidential development discussions to the open. The result has been very positive so far. For example, the Mobility programme decided to engage the MeeGo community directly in the open. Of course, Qt Creator has had its open mailing list for over a year and a half. As for Qt, we’re setting up the infrastructure, and discussing with the team working on the Qt Developer Network to see if we can reuse theirs.

What’s next, you ask? Well, the next step is to get started on discussing the Open Governance itself. For that, we’ve set up a mailing list server and a wiki:

Mailing list

http://lists.qt-labs.org

Wiki

http://qt-labs.org

I have already subscribed to the mailing list and I’ve urged my colleagues and friends to do the same. In a couple of days, I’ll start the discussion by posting some ideas we’ve been toying around internally. The delay is just to ensure that interested people have had the time to subscribe.

As the discussion goes by, we’ll record decisions and consensus on the wiki, as well as items that we haven’t had the time to discuss, but we still need to address. This is to try and avoid having anything fall through the cracks — though of course it should be understood that there will be scenarios we won’t think of.

A non-exhaustive list of what I expect to see discussed there is as follows:

• The lifetime of a patch: from “code written” to “accepted in the master repository”
• The decision-making model for accepting or rejecting contributions
• The tools that will support us in that process
• Release management: how often do we release Qt, who decides what’s in it, when we’re ready, etc.
• QA management: what kind of testing will be done, on which platforms and who is responsible for them
• Dealing with unexpected situations
• Bootstrapping of the model: how we will divide the responsibilities initially and who will first occupy the positions

Like I said, some of these aspects we’ve already begun thinking of. Some of them we’ve been doing that for years. Others we’re only beginning to understand the impact of Open Governance. And of course there are things we haven’t thought of, so we’re waiting for your contribution on them.

I’m personally expecting a couple of brilliant ideas to be put forth to solve some of the problems we’re facing

We just got a few new things on our web which might be of interest you.

In cooperation with KDAB and ICS we’ve recorded two modules of the Qt Essentials training and have posted them as videos. Well, unlike most of postings here, this is not a cutting edge stuff at all , but we believe it is useful for all those who just start with Qt. We are ready to do more in this area. You can tell us what that should be by filling out this feedback form. An interesting fact which motivates us and tells us that we are probably doing a right thing is that videos from the Developers Days 2009 and others in the past are still (7 months passed…) highly popular. More than 100 people them per day watch them since the start in Dec 2009.

BTW feedback, the Qt Learning Survey 2010 is open now. Please tell us about your learning needs and use a chance to win an N900.

Cheers!

Development on Qt mobility APIs is ongoing. The Nokia Qt SDK beta included the mobility 1.0.0 APIs and then the 1.0 release of the Nokia Qt SDK included the 1.0.1 mobility APIs. As part of our ongoing development an important issue has been unearthed that affects Symbian applications that use Mobility APIs that were created using the Nokia Qt SDK beta.

As of now, all developers using the Nokia Qt SDK beta to create Symbian applications that make use of the 1.0.0 Mobility APIs must
1) Move from using the beta version to the 1.0 version of the Nokia Qt SDK, and
2) Repackage Symbian apps created with the Nokia Qt SDK beta with the newest available Qt libraries; to ensure the mobility 1.0.1 APIs are included.

Why?
We have discovered an issue that causes apps bundled with the 1.0.0 mobility APIs to crash if the device carrying the app is updated with a newer version of the Qt libraries (specifically the Mobility 1.0.1 APIs). Specific technical reasons are detailed below.
While this is absolutely regrettable, and we are working hard on preventing this from being able to occur in future, it is important to note that
a)    This issue applies to the 1.0.0 Mobility APIs contained in the beta version of the Nokia Qt SDK only
b)    This issue is limited to Symbian applications (that use the 1.0.0 Mobility APIs) only

Specific causes
This breakage is due to the fact that Mobility did not set the 1.0.0 version tag.

On platforms other than Symbian, a missing qmake version tag is interpreted as 1.0.0.
On Symbian however, the missing tag is translated into 10.0.0 and gets encoded into the library binary.

Unfortunately once Mobility set the 1.0.1 version, the Symbian library version was downgraded to 1.0.1 too.

This prevents any application built against Mobility 1.0.0 from linking against libraries shipped with the 1.0.1.

The result is:

1. Apps built against 1.0.1 work fine against 1.0.1 libraries
2. Apps built against 1.0.1 work fine against 1.0.0 libraries
3. Apps built against 1.0.0 work fine against 1.0.0 libraries
4. Apps built against 1.0.0 –crash- against 1.0.1 libraries and beyond

Note that this break affects Symbian apps based on the 1.0.0 Mobility APIs only.

The most likely solution is to continue with the existing versioning schema so that 1.0.2 libraries remain compatible with 1.0.1 applications.

Processes are being put in place that will enable a greater level of Binary Compatibility testing, including finalization of an agreement with a test partner in order that we make all efforts to avoid such BC problems in the future.

In summary, here is what this means for you

table.tableizer-table {border: 1px solid #CCC; font-family: Arial, Helvetica, sans-serif; font-size: 12px;} .tableizer-table td {padding: 4px; margin: 3px; border: 1px solid #ccc;} .tableizer-table th {background-color: #104E8B; color: #FFF; font-weight: bold;} If you are… Action required Using Nokia Qt SDK final for Maemo/MeeGo development None Using Nokia Qt SDK final for Symbian development None Using Nokia Qt SDK beta for Maemo/MeeGo development None Using Nokia Qt SDK beta for Symbian development (apps that use the 1.0.0 Mobility APIs) Repackage any Symbian application containing Qt libraries from Nokia Qt SDK beta to ensure 1.0.1 Mobility APIs are included
AND
Develop using the final 1.0 version of the Nokia Qt SDK from now on

Other points of note regarding the 1.0.1 patch

Several quality issues are now known with this release. The more significant of these are associated with the Location and Sensors APIs.

Specifically:
* Location API

– Due to a packaging bug the shipped version of the Location library is incompatible with Symbian devices.

* Sensors API

Sensors Library - On N900 devices, QAccelerometer and derivative sensors require root privileges, and can’t be used by normal users.

The sensors defect only affects N900 (Maemo 5 / Fremantle).

* Other less severe issues have also been detected including documentation linking.

To that end, the program team are prioritizing resolution of the key issues and a new and higher quality patch release is under development.

Our target is to provide that patch within four weeks.

We will provide status updates weekly on the QtMobility info letter list, in order that you have visibility of the progress.

We apologize for any inconvenience caused.

Qt Mobility Program Team.

Recently I presented a small Qt 4.6 based demo on the LinuxTag in Berlin, as an example of something you could do with the Nokia Qt SDK. It combined existing projects like the Tiled map editor and the Box2D physics library with Qt Mobility’s sensors API for reading out the accelerometer. It looks like this on the N900:

Andreas has demonstrated before that integrating Box2D and QGraphicsView is easy. In this demo I have used the generic object layer support in the Tiled map editor to conveniently define the starting points and properties of some boxes, including the definition of the colliding parts of the rather minimal tile based background.

The big red boxes around the sides are a quick hack to prevent any of the dynamic boxes from leaving the scene. Since indeed, turning your device will change the gravity applied to the boxes as appropriate. This was the first time I’ve used an accelerometer and I expected it to be somewhat more complicated, but combining the sensors API in Qt Mobility with Box2D was as easy as:

    QAccelerometerReading *reading = mAccelerometer->reading();
    b2Vec2 gravity(-reading->x(), -reading->y());
    mWorld->SetGravity(gravity);

As documented, the accelerometer gives us the force applied to the device relative to freefall. When the device is in rest, this is the exact opposite of the applied gravitational force. Hence we have to reverse the x and y readings when turning them into the gravitational force applied to the Box2D world. One little caveat: as of Qt Mobility 1.0 the application will need to run as root on the N900 to be able to get any values out of the accelerometer. This is bug QTMOBILITY-326.

Here is the demo in action:

The complete sources of this demo are available on gitorious.org, on the ‘qtarcade’ branch. The repository includes the necessary classes from Tiled and Box2D so that it’s easy to try it out.

With Qt Creator 2.0 and the Nokia Qt SDK 1.0 released last week, it could not be easier to start hacking and implement your own crazy ideas. Who will be the first to get his cool Qt app signed for free and distributed on the Ovi store?

A while back I wrote about the Qt/Lighthouse prototype port for for NaCl. Since then some progress has been made, but most importantly Native Client is now available in the Chrome Dev channel:

If you’re feeling brave and you want to try for yourself, here’s how:
1) Subscribe to the Google Chrome Dev channel (Edit: looks like Standard Chrome 5 is sufficient.)
2) Start Chrome with the “–enable-nacl” command line flag
3) Navigate to http://chaos.troll.no/~msorvig/qtnacl/animatedtiles/

Source code is available at gitorious.

Just a quick heads-up that we have chosen a new name for the Lighthouse platform (as discussed the Remodelling post). The Subcommittee of Renaming has been hard at work in the intervening months, reviewing and considering all the 17576 possible TLAs.

We ended up with: QPA.

Unfortunately, the precise meaning was lost in the subcommittee paperwork, so we no longer know what the abbreviation stands for. However, we can guess: “Q” almost certainly stands for Q and “A” could be Architechture. “P” is more problematic (no, not that), but might be something like Platform, Process or Plugin.

The changes have already been pushed to the repository. The practical consequences are:

• configure -embedded-lite is now configure -qpa (but the old way still works).
• Q_WS_LITE is now Q_WS_QPA
• The _lite filename convention is changed, so qplatformintegration_lite.h is now qplatformintegration_qpa.h (but you don’t care about that, because you were smart and included QtGui/QPlatformIntegration, right?)
• Since we were already renaming: QGraphicsSystemCursor is now QPlatformCursor

The codename is still Lighthouse, though. In other news, I have been taking pictures of lighthouses:

The Qt Mobility 1.0.1 package is available!

As promised, this release finialises the Multimedia APIs. Additionally, as you would expect, the release also addresses a number of reported issues and we have also included some Symbian and Maemo 5 backend updates (please see the package release note for specifics).
But the main attraction in this release is the Multimedia.

Multimedia is, as many of you are aware, a little larger, and potentially a little more complex, set of APIs. The complexity arises not only from a feature level, but also from a need to address both high level application developer use cases, and low level/low latency APIs use cases.
To date, we had been addressing those needs separately, by providing low latency APIs in Qt and high level APIs in our Qt Mobility project delivered Qt solution packages.

What became apparent was the need to modularize QtMultimedia and simplify access for our developers. To that end, we have created our QtMultimediaKit, which offers developers a single module containing the Low Level APIs and High level APIs.
These Low Level/Low Latency APIs are exactly those previously found in Qt as QtMultimedia.dll.
The High Level APIs are those which we have matured through Qt Mobility.
Together they offer a powerful arsenal for our multimedia developers

The new QtMultimediaKit module will be available to both Qt and Qt Mobility development projects and is included for your usage in our 1.0.1 package.

Note: We now realize that introducing QtMultimedia in Qt 4.6 was a premature step, given our desires to make Qt more modular. These APIs in Qt’s QtMultimedia library will be deprecated and no longer maintained after Qt 4.7, given that the same APIs will be present in the Qt Multimedia module. Therefore, it is reccommended that the QtMultimediaKit module be used for new code. An associated blog on making Qt more modular was published earlier on our Qt 4.7 post.

Liciencing:
The 1.0.1 package is available both under our Commercial and also Open Source licensing agreements.

So, with this finalization of the Multimedia API, the package now comprises a total of 10 APIs which are considered FINAL with more soon to follow.

The list so far:

Service Framework

Bearer Management

Messaging

Contacts

Versit

Publish and Subscribe

Location

System Information

Sensors

Multimedia.

You can obtain these APIs in Qt Solutions and use as an add-on to Qt, or you can find them shipped within the Nokia Qt SDK.

We’re open for contribution:
We very much encourage and apprieciate your contributions for backends to other platforms, or indeed extensions to the APIs. So please keep the input coming. Help and guidelines are available here.

So whats next?
Several more APIs are currently being drafted and we plan to share those with you soon for your feedback.

*As a reminder, our whitepaper is a good starting point for those as yet unfamiliar with the new Qt APIs for mobile development.

Kind regards,
Gerard on behalf of the Qt Mobility team.

A major focus of the 2.0 release is the support for developing Qt applications for Symbian and Maemo. I think, we have made great progress to make it easy and fun to develop for Symbian and Maemo.
Still setting up everything for Symbian or Maemo development is not trivial, so I wouldn’t recommend doing it manually. Instead try the Nokia Qt SDK, which we also released today. See this blog post for more information on the Nokia Qt SDK.

On the Creator side that involves major improvements to the project page, a new target selector in the mode bar, support for deploying to devices, starting applications on devices and debugging symbian and maemo targets. While those features are mobile specific, quite a few improvements are also relevant for desktop applications.

As explained in this blog post, we have removed most of the Qt Quick/QML support for the 2.0 release. We plan on releasing Qt Creator 2.1 together with Qt 4.7 and thus offer tooling for Qt Quick from the first moment. For those who like to try Qt Quick, by the end of the week our snapshots will be from the 2.1 branch. And we’ll release a 2.1 rc together with the Qt 4.7 rc.

Apart from those 2 areas, we have been working on a lot of stuff. I’ll pick a few favourites out of the changelog, but frankly a lot more was added then can be covered in a blog post. See also our previous post about the release candidate, beta and alpha.

Andre already blogged about the improved gdb support. That is with gdb 7, we use the python bindings to offer improved displays for complex types. Due to being based on python the data dumpers are more easily extended for your own types. The docs explain how to do that.

Our .pro file parser is now much faster and more accurate. And the parsed information is now used better for the codemodel, e.g. the DEFINES variable is used. Also reparsing is now multithreaded.

,
Creator 2.0 Options Dialog

The options dialog got a nice new look, which should make it faster and easier to change settings. We added a smart filter that allows your favorite option faster by typing the label. For example in the screenshots to the right, we filtered for “indentation” and Creator shows the Text Options and FakeVim pages.

Also we extended the Search in multiple files to support regexps and to also support replacing. Don’t forget that you can search for all usages of any C++ symbol with Ctrl+Shift+U and rename any C++ symbols with Ctrl+Shift+R.

The biggest external contribution to the 2.0 release is the mercurial plugin by Brian McGillion. Thanks Brian. The FakeVim plugin got quite a bit of love by Martin Aumüller, who contributed over 100 commits to it. Thanks Martin.

If my git foo is correct the 1.3.0 release and 2.0.0 release differ by almost 5000 commits by 71 different people.

You can download binary packages from here.

As always we welcome feedback via the usual channels:

• Bug Tracker
• Mailing List
• IRC: #qt-creator on Freenode

The lights start to fade, the audience goes quiet, the curtains start to rise, spotlight on, drum-roll…

I have the great pleasure to finally announce the 1.0 version of the Nokia Qt SDK. It is available for download on the usual location at Forum Nokia as of now. In addition to the final Windows and Linux versions we also added a beta version for MacOSX 10.6 as well.
In case you have been using the Release Candidate, the integrated updater will allow you to get your installation up-to-date, there is no need to reinstall.

In related news, there is now a public beta of Nokia signing Symbian apps for free and the Ovi Store will accept Qt apps starting in the next month. Read more about this.

This final release contains the following components:
• Qt Creator 2.0 final
• Qt Simulator 1.0 final
• Qt Mobility libraries
• a current version of MADDE
• Symbian packages
• Smartinstaller packages for Symbian
• the experimental Remotecompiler
• Documentation for all components

Please use our Bugtracker to report bugs and provide feedback (select the “Nokia Qt SDK installer” project).

Changelog for the 1.0 release:
• Installer:
  • [QTSDK-10] The Nokia SDK installer attempts to install by default an unsigned “USB network driver” for MS Windows (needed by Maemo?)
  • [QTSDK-57] Can’t install or upgrade the SDK on Linux/amd64
  • [QTSDK-63] Qt Creator is not killed before uninstall
  • [QTSDK-70] Mac: “internet enable” the disk images
  • [QTSDK-72] mac install missing QtMobility headers for maemo target
  • [QTSDK-74] installation completes with progress bar at 97%
  • [QTSDK-87] problems when installing with sudo
  • [QTSDK-90] Application hangs on windows when trying to use ContactManager
  • [QTSDK-92] Cannot build for Symbian with out-of-the-box Nokia Qt SDK
  • [QTSDK-96] SDKMaintenanceTool timeout for checking repository
• Simulator:
  • [QTSIM-8] make the close button in the Maemo theme functional
  • [QTSIM-40] Mobility Multimedia Examples cannot be compiled for Simulator

The Qt Assistant development team would like to announce the immediate availability
of a source tarball containing the compat version of Qt Assistant.

This version has served well for a couple of years, starting from Qt 3.x, and
was actively maintained and developed till Qt 4.4. We now removed the source from the
upcoming Qt 4.7 release, though we noticed that there are still dependencies from
certain applications on this old version. To be able to use them without much hassle,
we made the source compiling with all recent Qt versions and put it here:

ftp://ftp.qt.nokia.com/qt/source/qt-assistant-qassistantclient-library-compat-src-4.6.3.tar.gz