Some of you may have noticed a new committer to the Qt git repository. Someone who is tirelessly working night and day, but only seems to make merge commits. I am of course talking about Qt Continuous Integration System, who in addition to never getting any time off, never gets paid either.

This is because Qt Integration is a Python script, written by Simon and Paul, with invaluable assistance from Rohan and Jesper from the QA team. (And just to make sure: “invaluable” means “of immense value, so great that it cannot be measured”, and not “so small that it cannot be measured”.)

So what does this script do? First a little detour: If you are still reading this, you have probably been following the commit logs and seen commits of the type “Merge branch ‘4.6′ of scm.dev.nokia.troll.no:qt/oslo-staging-2 into 4.6″, but you may have wondered: What is a staging branch?

A staging branch is a git branch that is shared between a number of QtDF developers and is tested separately and then integrated into the public branch at intervals. The point of having staging branches is to catch build breakages and regressions before they make their way into the shared repository. Until now, the integration has been done manually, and there was no common baseline to compare against, so it was hard to compare the quality of branches: If there is a failure in one of two branches, is it introduced in the first, or fixed in the other?

Another problem we’ve had recently is that our test farm is now running on virtual machines, but most of the tests were written on real machines. Some tests end up exposing the difference, and suddenly turn unstable because of timing differences or other subtleties. We are fixing these tests of course, but in the meantime, this adds a whole new level of uncertainty to the interpretation of test results.

The Qt Integration script automates the process and solves the problems. The system works roughly like this:

1. Developers push changes into one of the integration branches.
2. Direct push access to Qt’s 4.6 branch is _disabled_.
3. The script takes one integration branch after the other, merges the branch with Qt 4.6 and runs the resulting merge through the autotest system.
4. After a successful build of Qt and the execution of the tests, the script compares against the previous 4.6 results.
5. If there are no new regressions (*), the merged branch is pushed to 4.6
6. However, there is a “blacklist” of test functions that are known to be unstable, and those are allowed to regress without blocking the integration.
7. Then the next staging branch is tested. (goto point 3 :-))

(*) No new regressions means: Tests are failing in 4.6 are allowed to also fail in the integration branch. No other tests are allowed to fail, unless they are blacklisted

Note that at any point, 4.6 contains a version that has already passed the testing process.

What this means is that in theory, the Qt 4.6 branch will always build, and the number of autotest failures will steadily decline. Yes, I did say “in theory”. The biggest limitation is that the system does not currently cover all the supported platforms. Currently we are doing Linux/X11, Linux/QWS, one Windows version, and one Mac version. We are going to add new platforms as we go along, but the system will probably never cover all the Tier 2 platforms. Any failures on the remaining platforms will be caught by the autotests running continuously on 4.6.

This means that we will still keep the 4.6-stable branch, just like before. The only difference is that it should now be even more stable. In theory 4.6-stable could go away in the future, if we could get the test cycle for all of our platforms to be fast enough. Also, please note that we are only running this on 4.6 at the moment. We will extend it to the master-going-to-become-4.7 branch in the not too distant future (but not this year).

Finally, I have to apologize for the lack of cool screenshots in this post. This is a script after all; just move along, nothing to see here…

OK, then, if you insist, here’s one of the script running, taken just moments ago:

A few weeks ago, we had an awesome insane idea: to translate Qt Creator into French. It turned out to be a terrible idea, because it was much more work than what we originally thought.

We started to translate the strings and it didn’t take us long to realize how huge Creator really is, and the list of strings to translate seemed endless. We ended up asking for help in one of the French Qt communities, Qt.developpez.com. Their response was amazing, they worked like crazy on the translations, and thanks to them, the next version of Qt will provide a French version of the tools. From Qt 4.6.0 on, you will have a French version of Qt Designer and of Qt Assistant. Qt Creator 1.3.0 is available in French entirely, including the integrations and the less known plugins.

The translation of thousands of strings, by non-profesionnals, in only a few weeks, have been quite a challenge :). Thanks to Jonathan Courtois, Alp Mestan, Florent Renault, Pierre Rossi for their amazing work on translations. Thanks to Yoann Lopes for the review of some of the tools.

Thanks to great efforts from the community, Qt Creator has translations for German, Spanish, Italian, Japanese, Polish, Russian, Slovenian and now French. Everybody is welcome to participate in those translations or to create a new translation via the GIT repository on gitorious. If you would like to help the French translation, you are welcome on the forums of developpez.net to meet the other translators.

---

Il y a quelques semaines, nous avons eu une idée géniale stupide : traduire tout Qt Creator en Français. Il s’est avéré que cette idée était ingérable, car cela représente bien plus de travail que ce que nous avions initialement imaginé.Après avoir commencé la traduction, nous avons rapidement réalisé à quel point Creator est immense, et la liste des chaînes à traduire semblait sans fin. Nous avons demandé de l’aide à l’une des communautés Qt francophone: Qt.developpez.com. Leur réponse a été incroyable, ils ont travaillé comme des fous sur les traductions, et grâce à eux, la prochaine version de Qt aura une version francophone des outils. À partir de Qt 4.6.0, une version française de Qt Designer et de Qt Assistant. Qt Creator sera disponible intégralement en Français, y compris les plugins dont personne n’a jamais entendu parler…La traduction de milliers de chaînes de charatères, par des amateurs, en quelques semaines, a été un véritable défi :). Merci à Jonathan Courtois, Alp Mestan, Florent Renault et Pierre Rossi pour leur travail sur les traductions. Merci a Yoann Lopes pour la vérification des traductions des outils.

Grâce aux efforts de la communauté, Qt Creator est traduit en Allemand, Espagnol, Italien, Japonais, Polonais, Russe, Slovène, et maintenant Français. Tout le monde peut aider à ces traductions, ou créer de nouvelles traductions, via le dépôt GIT sur gitorious. Si vous désirez aider la traduction française, vous êtes les bienvenus sur les forums de developpez.net pour rencontrer les autres traducteurs.

To everyone using Qt 4.6 from the Git repository: be aware that I introduced a binary-incompatible change. This change is there to stay.

No, we’re not breaking binary compatibility with Qt 4.5. This only affects previous Qt 4.6 versions.

Actually, this kind of change happens all the time. So why am I blogging about this specific change?

Well, the problem is that this change affects QHash, QMap and QVector. And those classes are inlined everywhere in Qt-using code. This means that, if you update Qt across that version, you must recompile all of the Qt-using code, from scratch (i.e., make clean). For KDE developers using trunk, that means recompiling all of KDE.

This change will be included in the upcoming Qt 4.6.0 Release Candidate.

Note: the change is in the 4.6 branch but hasn’t reached the 4.6-stable branch yet. That also means it’s not in kde-qt’s 4.6-stable-patched branch yet. When you next update those stable branches, please remember to recompile everything.

PS: the stable branches aren’t updating not because of Qt not building. It is buiding. The reason why is because our Continuous Integration system experiencing some technical difficulties, like Windows running out of memory, the Symbian buildsystem failing for no apparent reason, the powerful 8-core Mac machines being able to run only one testcase at a time, etc.

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

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

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

With this in mind I have two design goals:

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

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

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

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

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

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

Here’s one thing that will probably never work:

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

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

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

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

Many people have expressed some confusion over the the S60 port of Qt and where to find the relevant branches, so I thought I’d give a little update on where things are happening:

When the port was still young, it lived in the qt-s60 repository on gitorious. Here, both the master branch and feature branches coexisted happily. This however changed when the S60 port was merged back into the 4.6 branch of Qt. After this the master branch in the qt-s60 repository became abandoned.

Since this branch will not be used for development anymore, I deleted it today. This does not mean that the repository is dead though. The Qt for S60 developers still use the repository to develop feature branches, and we will continue doing this in the near future. When they are done, they will be merged back to a branch in the Qt repository (like 4.6, 4.7 or master). So unless you want to track a specific feature branch of interest to you, all the relevant S60 development happens in qt/master.

So what about contributions? After the merge of the S60 port, the rule is simple: Submit all merge requests to the Qt repository, even if the request is based on code found only in the qt-s60 repository. This is easier for you (one single place to submit to) and for us (one single place to monitor).

A couple of other notes on contributions related to S60 code:

• Be careful when you deal with code that can throw a Symbian leave. These have to be wrapped in special conversion macros. See this page for more information: Symbian exceptions safety.
• Coding style. Traditionally Symbian has had its own coding style with a different indentation and naming scheme. This style does not apply to S60 code used in the Qt library; We still use the same style that we always have! If you need a cheat sheet to the Qt coding style, look here: Qt Coding Style. You might also want to read the Qt Coding Conventions. Update: If you are using Carbide, you can download the Qt_Code_Style.xml template. To add it, just go to Window > Preferences... > C/C++ > Code Style and import the file you just downloaded.
• There are still problems when compiling Qt for hardware using GCCE. The emulator should work fine though. We hope to get this fixed in the future.
• The rest of the contribution process should be explained in the Qt Contribution Guide.
• Update: The win32-mwc mkspec that was used in earlier releases has been deprecated and is not supported anymore. You need to use either Microsoft Visual Studio or MinGW and use “-platform win32-msvc2008″ or “-platform win32-g++”, respectively.

(a.k.a., Qt 4.7)

Borrowing the term from our Symbian / S60 friends, who have stopped using this naming scheme already, I’d like to point out that the Qt 4.6 and master branches in our Gitoriuous repository have diverged.

What does this mean? Well, if you build master now, Qt will tell you that it’s version 4.7.0, not 4.6.0. For example:

$ qmake -v
QMake version 2.01a
Using Qt version 4.7.0 in /home/tmacieir/obj/troll/qt-main/lib
$ moc -v
Qt Meta Object Compiler version 62 (Qt 4.7.0)
$ $QTDIR/lib/libQtCore.so
This is the QtCore library version 4.7.0
Copyright (C) 2009 Nokia Corporation and/or its subsidiary(-ies).
Contact: Nokia Corporation (qt-info@nokia.com)

Build key:           i386 linux g++-4 full-config
Installation prefix: /home/tmacieir/obj/troll/qt-main
Library path:        /home/tmacieir/obj/troll/qt-main/lib
Include path:        /home/tmacieir/obj/troll/qt-main/include

And if you’re following Qt development using Git, it might be time to start tracking the 4.6 branch instead:

git branch 4.6 origin/4.6
git checkout 4.6

That’s about it. We haven’t started merging 4.7 features yet. We don’t know yet when it will be released, nor much about what’s going to be in it. (Ok, we have some opinions on date and content…)

And before anyone panicks, no, we’re not adopting the naming scheme either. This was just to write a longer title than two letters, two digits and one punctuation

We’ve managed to keep a very boringstrict numbering scheme for Qt for years. I remember when we released Qt 4.4 and our Chief Troll was interviewed by a Norwegian newspaper. After he had listed the new features coming in, the reporter commented something like, “4.4? You should call that release 13 or something!”

Other products have had a more, erm… relaxed numbering:

• Windows: 3.0, 3.1, 3.11, NT 3.5, 95, NT 4, 98, 98 SE, 2000, ME, XP, Server 2003, Vista, Server 2008, 7
• Solaris: started as Unix 6, 7, III, IV, V, V R2, V R3, V R3.2, V R4; merging with SunOS: 4 BSD, 4.1 BSD, SunOS 1.0, 2.0, 3.0, 4.0; resulting in: Solaris 2.0, 2.5, 7, 8, 9, 10

What’s your take on what Qt’s sequence numbering should be? Give your reply how Qt past releases should be numbered and how we should go from here. Be creative!

We all want to get access to new features, but we also want to get stable things. These two goals seems contradictory and in a sense they are. If you want to live in the edge you have to accept some “early adopter problems” but if you want to have only rock solid features, you need to let them mature and “gain experience”. With our new open development process people can get access to all of our newly developed features while they are still in the making, therefore gaining valuable insight on what’s coming in the next release. The problem appears when people uses that “bleeding edge” code to start developing things, how can we provide “stable bleeding edge” features?

The solution is more or less obvious, have a master branch where everything is committed and a master-stable branch that is slightly behind master but it is guaranteed to compile. It seems simple and problem free, however there is still one pending question. How “slightly behind” is master-stable from master? Up to last week, master-stable was manually updated, which led to fewer updates and not so “bleeding edge” code. From this week on we have implemented automatic update of master-stable, so now master-stable will be updated as soon as everything is ready, no human intervention required.

The system goes like this:

1. Whenever there is a change committed to master, that change triggers a build in all of our tier 1 platforms.
2. If the build is successful, then a build on all of our tier 2 platforms is triggered.
3. And if that build is successful, our CI system will push changes from master to master-stable.

Voila, master-stable updates itself! So from now on you have no excuses not to use master-stable to check out what’s happening in Qt while enjoying a “stable bleeding edge” branch.

The avid reader would have noticed that it is the first time my name appears on this blog. I joined Trolltech on September 2007 and I’ve been the QA manager for Qt for the past two minor releases (4.4 and 4.5) and currently I’m busy handling Qt 4.6

This year again a gaggle of geeks went to Akademy from the Qt/Troll office, most of them flew there on Friday in a too-long 14 hour travel trip (office to hotel). For next year we should really choose a location that is easy to reach for the majority of our contributors.
But this is where the complaining stops, I’ve been having a great time. I saw various thought provoking keynotes and spent hours talking to old and new friends.
I loved that the lunch-breaks were long, so you could walk to a new restaurant every day and try out all the great food. I think the worst food I had here was a bit-too-simple spaghetti with only a red sauce. But it still tasted good

This is a conference of geeks and naturally this means lots of talking. And a good percentage of that about computer stuff. I’ve been talking about git migration with various people and noticed I should really get more people to help out perfecting vng.googlecode.com

For instance I opened a discussion point about kDebug() which taught me a lot. So, the assumption I always had was that kDebug (and qDebug() )will completely be gone in end-user versions of my software. Which means that I can add as many debug statements as I want and it will not have any negative result on the size or speed of the final shipped executable.
To my big surprise distros like Suse have always shipped binaries where the debugs were still executed but by default just went to /dev/null
This means that when I added a kDebug() in a loop and printed some QRectF all those floats are still converted to strings only to be discarded and slowing down execution. Which is a sad surprise as my users will see the software being much slower than it could be.
In KDE4.2 this behaviour has been committed to kdelibs as the upstream default, whereas in kde3 only distros patched it. The good think is that it lead to the discussions. The end result is a much better awareness of the issue and how it affects apps. Last I heard was that Andreas is looking into fixing all issues using an updated kdebug macro. \o/

I spent a total of 9 days at Akademy at it was very tiring, but also quite satisfactory. I didn’t blog much as I use identi.ca, follow me there for more details. I still have to go though my notes and todos which I’ll get to in the coming days. This year no KOffice core developers were there so the couple of KOffice-libs discussion points I prepared didn’t get attention.

The internet connection was not great, just too many people for wifi to handle (bug in the protocol?) which had the upside that nobody felt all that guilty just wandering into town or sitting down on the beach with our great green Qt towels discussing code and community. I think that discussing code and technical stuff is only a small part of what makes these conferences successful for a community. The part where you get to know the people you work with in face to face chatter is at least as important. Its just easier to see that name on IRC or in email as a real person if you know his background and hobbies.

Random thoughts;
Its been too long since I walked on flip-flops. My toes got hurt after just one afternoon.
It took me only one day to get used to the colder (~20C) Norwegian weather. Its compatible enough in my mind
Spanair may be part of the SAS group, its not the same quality. Legspace is…painful.
Git seemed to have gotten a lot of support. The people that don’t support it are mostly in the “haven’t actually ran it” camp. (did I mention vng?)
Free software conferences gather the smartest people whom are always up for some fun discussion topics. Even after my bedtime

Platform: Windows XP with SP3(now we only support Qt/S60 on it.)

1. SYMBIAN Development Environment

For downloading the packages, you need to register an account in the forum of Nokia,
http://www.forum.nokia.com/main/registration/registration.html

1-1. Carbide.C++
http://www.forum.nokia.com/Tools_Docs_and_Code/Tools/IDEs/Carbide.c++/
http://sw.nokia.com/id/7710eba7-4da7-4ddc-a52a-53b506cadb4a/Carbide_cpp_v2_0_en.exe

Carbide.C++ 2.0
Carbide_cpp_v2_0_en.exe 203MB

1-2. S60 Platform SDKs for Symbian OS, for C++
http://www.forum.nokia.com/info/sw.nokia.com/id/ec866fab-4b76-49f6-b5a5-af0631419e9c/S60_All_in_One_SDKs.html
http://sw.nokia.com/id/577ad48d-290c-4bb5-8bdf-779ea8a5bc6c/S60_5th_Edition_SDK_v1_0_en.zip

S60 Platform SDKs for Symbian OS, for C++, 5th Edition
S60_5th_Edition_SDK_v1_0_en.zip 622MB

2. Installation

Please install above 2 packages in default path.

Installation order: Carbide.C++, S60 SDK.

After Carbide.C++, you may need to install ActivePerl-5.6.1.638-MSWin32-x86.msi:

http://downloads.activestate.com/ActivePerl/Windows/5.6/ActivePerl-5.6.1.638-MSWin32-x86.msi

And you also need to use Git to get Qt from Qt S60 Git Repo, better to download this version of Git.

Please also make sure the path of our perl(default: C:\Perl\bin) should be in front of the perl from git(default: C:\Program Files\Git\bin) in PATH.

Please run this, Start->Carbide.c++ v2.0->Configure environment for WINSCW command line.

3. Build Qt with S60 5.0 Public SDK

cd C:\git
git clone git://gitorious.org/+qt-s60-developers/qt/qt-s60.git
cd qt-s60
set PATH=C:\git\qt-s60\bin;%PATH%
configure -platform win32-mwc -xplatform symbian-abld -openssl-linked -qt-sql-sqlite -system-sqlite
make debug-winscw

4. Build Examples

cd C:\git\qt-s60\examples\widgets\analogclock
qmake
make debug-winscw
C:\S60\devices\S60_5th_Edition_SDK_v1.0\epoc32\release\winscw\udeb\epoc.exe
“Menu”(or click the middle one of the 3 buttons)->QtExamples->analogclock

You got it!

BTW, it’s my first blog here.

About two weeks back, the Qt repository was made available to the public. Since then, we on the S60 team have been dying to do the same, and finally, we are able to make our branch of Qt available to all of you!

On the master branch you can see all the latest development of the S60 port, and everyone is free to clone and submit merge requests, just like for mainline Qt.

In order to compile the branch, I suggest reading the installation instructions at pepper.troll.no. There is also a very nice webcast to get you started.

Unfortunately, compiling Qt for the actual device is not possible unless you own a license to the RVCT ARM compiler. While it is possible to compile Qt with the GCCE ARM compiler, the binaries will not run due to shortcomings in GCCE when dealing with static data in DLLs. We’re hoping that this problem will be rectified in the future. Compiling for the emulator should be a breeze though, and the majority of code can be tested there.

Welcome to the world of Symbian!

The repository is located at http://gitorious.org/+qt-s60-developers/qt/qt-s60.

Update: Right now the master branch will only compile with a beta version of Open C that is not yet released to the public. We are told that it is to be released very soon, but in the meantime, it should be safe to comment out the parts that fail to compile. We are sorry for the inconvenience!