Qt 5 released!

The wait is over: Qt 5 is now officially the latest Qt version. And the guys at Qt Studios made a very "qt" video about it.

KDE is a giant ecosystem built on and heavily relying on Qt. Many Qt developers are KDE active contributors, and many KDE contributors came up to work with Qt for a living. For example, there's KDAB. And, of course, a new Qt release affects KDE a lot. KDE's major version is the same as Qt's. We're in KDE 4 because it uses Qt 4. KDE 5 (which will still take some time) will need a whole port to Qt 5.

This may cause some fear and uncertainty to the KDE users that were there in the early stages of KDE 4. KDE 3.5 was amazingly stable. When Qt 4 was released, the obvious path of porting KDE to Qt 4 was followed. However, considering KDE's size and the many incompatibilities between Qt 3 and 4, that was terribly hard, and KDE suffered for a long time with this. Many bugs originated at the port survived until KDE 4.4 or 4.5, which is not long ago. A lot of users migrated to other desktop environments in the occasion, keeping in mind a horrible image of KDE.

Nevertheless, everything promises a much less painful port this time. From the Qt 5 Docs:

"Qt 5 is highly compatible with Qt 4. It is possible for developers of Qt 4 applications to seamlessly move on to Qt 5 with their current functionality and gradually develop new things leveraging all the great items Qt 5 makes possible."

And that doesn't look like just propaganda. The list of source incompatible changes list seems reasonable, and KDE Frameworks 5.0 is being worked on. This is a time where unit tests are most helpful. Since this year, Nepomuk has its own tests framework. As Nepomuk is split into various services (File Watcher, File Indexer, Storage) that run in different processes, it's quite hard to test some changes in it. And what can be said about testing a whole port to Qt 5 without automated tests?

By the way, in Nepomuk, I've be working on some minor tasks in the last two weeks. Briefly, I investigated an optimization in RegExpCache, a class that mainly checks if a string matches against a list of regular expressions. It turns out Qt's QRegExp class is implemented as a Nondeterministic Finite Automaton, and so matching is not done in linear time. Thus, the straightforward trial of making a RegExp that is the union of many RegExps didn't work. Now, I'm trying to fix another bug, related to the File Watcher. This made me learn a lot, and probably another post will follow just about that one :)