Sputnick's blog

It's been a while that we have announced a new release. Somehow, 0.4.2 and 0.4.3 never made it to the frontpage… Anyway, we haven't been lazy and quietly worked on bringing you a brand new feature release: quassel-0.5.0!

You can find most features we have added in the FeatureLog, and if you are really interested, you can also browse the Git history. A list of the most important things has been added below for your convenience. First though I want to get a few important notes out:

Client/Core protocol, database schema and config file update: As mentioned before, a 0.5 Quassel Core will not work with a 0.4 client and vice versa. You will have to update both components. First time you run a 0.5 core or client, the config files and database will automatically be updated to the new format. Downgrades are not supported, so do make a backup if you intend to go back to 0.4 afterwards!

A note for distro packagers: We will maintain a 0.5 branch in our repository that will receive important bugfixes, but no new features. We will probably also do periodic 0.5.x releases from this branch, while new and shiny stuff is being added to the master branch. If you maintain Quassel on a distro that suffers from version or feature freezes, you should make sure to track the 0.5 branch instead.

Read on for a short list of the most important features, then head over to the downloads page to grab it while it's still sizzling!

As we have tagged a 0.5 release candidate now, which has made its way in Kubuntu Karmic and Jaunty backports, among others, we should point out that the client/core protocol used in 0.5 is not compatible to the 0.4.x releases anymore. This means you'll need to use a 0.5-rc1 client with a 0.5-rc1 core. Same for current git master, of course. The protocol change gives you a great performance boost in the core, in particular for startup, shutdown, and joining/quitting large channels. So it's definitely worth it :)

As this is isn't an official release yet, it's not linked from the download page. However, you can find binary builds for Windows and MacOSX here.

People closely following our development in git will have noticed that we have tagged a 0.4.2 release back in May. Some distros also have been shipping 0.4.2 for quite a while now. However, there never was an official release announcement. Why?

We have recently tagged a bugfix release for the stable branch, appropriately named 0.4.1. Users of 0.4.0 are heavily recommended to upgrade. Note that no new features have been added; users of the development version from git should not use 0.4.1 as it would be a downgrade.

Some of the bugs fixed include:

• Correctly display images in the web preview in static builds
• Improve selection and multi-line paste behavior
• Fix cert handling for identities
• Create a proper default identity for new networks
• Improve ping timeout detection (don't time out after 30 seconds with a shaky connection)
• Fix bufferview sorting
• Updated and new translations: Slovenian, Russian, French, Czech, German, Turkish
• Improve flood control (avoiding Excess Flood in most cases)
• Various improvements to the build system

You can grab the new release from our download page; many distributions also have updated packages available already.

After about three months of hard work, the Quassel Team has tagged the brand-new and extra-shiny 0.4.0 release for you! And for extra convenience, we even have updated our downloads page! To reach this important milestone, 432 commits went into Git since 0.3.1.

As usual, you can find most features we have added in the FeatureLog, and if you are really interested, you can peruse the Git history. Let me highlight the most important things right here though.

This was one of the comments our new shiny application icon caused, and it was even suggested as our new tagline. I LOL'd :)

I would like to thank again Mr. Oxygen Nuno Pinheiro for his terrific artwork for both KDE4 and Quassel. Most of the icons you see in Quassel are made by him and the rest of the Oxygen Team. Kudos!

We have been fading out our old logo, the All-Seeing Eye, during the past few weeks. This was created by John "nox" Hand, who deserves kudos for his work as well, of course. Thank you! Your logo has served us well for a long time, but now it's Oxygen all the way...

New Quassel artwork coming to a release near you in only a few days!

With Qt 4.5-rc1 recently released, we've stumbled over a strange issue with Quassel. A binary compiled against Qt 4.4 would completely freeze when used with Qt 4.5. This problem mostly hit users on binary distros trying out Qt 4.5. As it turned out, recompiling Quassel against Qt 4.5 magically fixed the problem - but of course, this is not an option for distro packagers, as they will have to provide packages built against 4.4 at least until 4.5 hits their distros proper.

So we hunted for that bug, to no avail at first, but then EgS stumbled over dug into the strange dungeons of his memory, and there found lurking a blog entry by one of the Trolls:

Well if you leave the code as it is then you will either get a crash in your code or it will simply cause the application to hang because the QRegExp object passed into QString::indexOf() is no longer modified. The good news is that there is a solution which you can use now even if you are not switching to Qt 4.5 straight away. What you should do is change the calls from QString::indexOf() to QRegExp::indexIn().

We found one location in our code where we did this, and changed that:

- matches[i] = str.indexOf(regExp[i], qMax(matchEnd[i], idx));
+ matches[i] = regExp[i].indexIn(str, qMax(matchEnd[i], idx));


This seems to fix the issue, and Quassel binaries built against Qt 4.4 now reportedly work with 4.5.

What I don't get: I can see how "not modifying the QRegExp object" causes our code to hang here, and why the above makes it work again. But why the fringle does a mere recompile against Qt 4.5 fix that issue as well? Does the regexp magically become modifiable again? Luck? Karma? Voodoo? Anybody can help me out there? ;-)

Qt has this nice feature that you can embed arbitrary files into your binary, and access these so called Resources via special paths starting with a colon. For the longest time, Quassel has exclusively relied on resources and embedded all its data files, including icons, into the binary. This had the advantage that we could always be sure to find all required files at a certain location and need to provide fallback mechanisms. It also meant that Quassel binaries didn't need to be installed; they were completely standalone and could just be run from any location. Quite nice especially on a platform like Windows that does not have standard locations for all sorts of data files. And on Linux, whose various flavors still do not always agree where stuff should go.

Now, where's the problem with that approach? For once, the binaries get bigger. Maybe not on the file system (having dozens of small files tends to waste a lot of space due to fragmentation and partial blocks), but certainly in RAM. It also increases loading times a bit. Then there was the issue with translations. We would embed all translations into the binary - obviously a waste of space even though each individual language file is surprisingly small. The LINGUAS variable, restricting the languages to be built, helped a bit, but not much. Distros tend to provide language packs, so support for external files would be needed.
But the real killer was KDE integration - KIconLoader, for example, wouldn't look into our binary to find an icon, obviously. So for KDE support, we needed to install the icons separately. Consequently, Quassel gained support for that a while ago, complete with some confusing cmake options. Over time, we got more data files, such as .knotifyrc for KDE's notifications, and networks.ini containing predefined network definitions. As it turned out, our build system installed them in locations that would be re-found at run-time only by pure luck, if at all. And it would fail completely on Mac and Windows.

I have fixed that in the past couple days, and Quassel now has proper data file handling. Read on for more information, in particular if you are a distro packager!

One of the more enduser-confusing issues with Quassel used to be its storage locations for settings and the backlog. The various platforms Quassel supports handle the storage of configuration much differently. Qt helps us there with abstracting this away, and giving us for example QSettings, which allows for the storage of configuration data in the platform's native format without having to bother about platform issues. In particular, this means that settings go into the XDG location on Linux (usually in $HOME/.config/), into .plist files on Mac, and into the Registry on Windows.

All nice and dandy, but what to do with data files, such as the sqlite storage? Well, Mac has a standard location for that, as does Windows (%APPDATA%). On Unixoids, such data traditionally goes into $HOME/.. And that's where the trouble started.

Title says it all. If you want to meet one of the Quassel hackers, you have a chance to find me in Brussels on February 6th-8th. I will make sure to not miss the Beer Event on Friday evening, of course :)