Packaging Qt 5

As Qt 5 approaches alpha, it is more and more interesting to try using it outside the comfort of developer machines. For that, packages are needed.

Thanks to vgrade I found the qt-spec-effort project on Gitorious. This git contains a nice script that populates an OBS with the Qt packages. Perfect for my needs. I had to employ some minor tweaking to get things going, so my clone can be found here.

One thing that possibly could affect Qt 5 is the version of XCB, the new X protocol C bindings. When upgrading the existing packages for libxcb and friends I ran into a split package. Apparently, xcb-util was split into five packages (xcb-util, xcb-util-wm, xcb-util-renderutil, xcb-util-image, xcb-util-keysyms), so the packaging turned out to be a bit more tedious than expected. Still, the spec-files are available from the xcb-spec-effort git that I setup. The only consequence of this was that I had to be more specific when specifying dependencies for Qt 5’s qtbase (it is all on Gitorious).

So, now, all I need is a good way to measure and optimize QML performance. The swaplogger tool serves the first purpose (spec file in this clone). Now, all that is left is the optimization part :-)

Building the QML Run-time

I visited OpenSourceDays 2012 this weekend. I did my presentation and met some people, but could not attend any other sessions. This was part due from the site being out of power when I got there (talk about Murphy at a large scale) and part because I wanted to enjoy beautiful Copenhagen with my family.

In my presentation I wanted to discuss how to approach the problem of building a run-time environment for a QML user experience. The choice is (as always) between time and quality. In this particular case, quality means how free the user experience designer is from the run-time implementation.

After the talk, I enjoyed a discussion with Mario Boikov. I argue that it is ok to use root context properties, i.e. global singleton variables in QML-space, to share states. He argued that presenting everything as QML registered types that QML instantiates gives better QML. I agree and disagree, as always ;-).

By using root context properties, it is clear to QML that it is a singleton instance. It is also a very handy way to expose plain QObjects to QML. Just add the odd Q_PROPERTY and Q_INVOKABLE macro and add it.

By exposing state-representing objects as registered types, one has to handle the singleton back-end (if it exists) through a wrapper class registered to the QML type system. This adds complexity on the C++ side. This, I feel, is ok, as the C++ developers are the ones with system knowledge. Any complexity related to technology should be handled here. From QML, this approach gives you prettier bindings. You can find a property of the service to something, and you can avoid the Connections solution to reacting to signals.

What you do lose on the QML side, is the clear message that the particular object is a singleton. You also (potentially) introduce allocations and deallocations of the wrapper object. This shouldn’t be an issue, especially not as such a QML design would trigger those either way. Still, as an old school embedded engineer, memory fragmentations is a scary thing.

QML is a wonderful thing, but the language and tooling are new to us all. I suppose discussions as the one above will lead to some sort of best practice being established. In the mean time, lets benchmark and compare notes. What gives the prettiest code, where do you lose performance, what did the Trolls intend for us :-)

The Irony of the Real World

Qt does not sell mobiles. As a consumer, Qt is a technicality. Right now, the experience and availability of apps sell phones. Qt is just a tool for us developers to implement those experiences. Despite this, it is interesting to compare the Nokia N9 and the new WP7-based Lumia handsets. The market’s reaction to both, and the irony of it all.

Sweden is a highly developed smartphone market. Almost everyone has a smartphone. Flat rate data subscriptions are cheap. Both N9 and Lumia are sold here, and are advertised.

The reviews are interesting. In mobil.se’s comparison, the N9 lose out because the platform is bound to die, thus have fewer apps. In the same organisations yearly awards, the N9 win three out of four applicable categories (the Sony Ericsson Mini Pro won the value-for-your-money-award). The N9 also went straight to the top of the selling charts at katshing.se, and in the telekomidag.se review of Lumia, the final words praise the N9 “Sister model N9 with MeeGo was a (albeit late) eye-opener, for Lumia is feeling more of oh well-character. Skilled in every way – but we have seen most things before.” (google translation of “Systermodellen N9 med Meego var en (om än för sen) aha-upplevelse, för Lumia blir känslan mer av jaha-karaktär. Kompetent på alla sätt – men vi har ju sett det mesta förut.”)

Following this trail, the latest sad figures from Nokia report that things aren’t going that well. Telling your customers and employees that your current unique product is dead, then delivering a mainstream product later does not help improve business. Bloomberg has looked at various analysts’ estimations of sales figures, and they estimate 1.4 million N9 where sold 2011, while the Lumia is estimated to have sold 1.3 million (estimates range from 800k – 2M).

The interesting part in all these comparisons is that the N9/MeeGo platform is not being pushed by Nokia. They do not want to sell it. The Lumia, on the other hand, is being pushed by the biggest marketing budget Nokia ever has spent on a single product. The Lumia series is being expanded, apps are emerging.

I am sure that Nokia/Microsoft will succeed. I had a VHS system at home, even though Betamax was technically superior. The cost for success will be to turn Nokia from a leading brand into a mainstream supplier, no more important than HTC or Samsung. Sad for Nokia, sad for Finland, sad for what could have been for Qt. Launching N950 alongside N9 and following up with multi-core models would had been great. Also, seeing that MeeGo Harmattan more or less was Maemo with Qt, Intel’s drop-out would not have been the end of the world.

Still, from a Qt developer, this, in combination with the openly governed Qt Project means that Qt will stay a cross platform tool. The risk of seeing it being sucked into a life as a (great!) single platform is no more. Qt/iOS, Qt/Android and Qt/MeeGo give a bigger target area than WP7 has. And if the WP8 platform is to follow desktop, Nokia just jumped from one burning platform to another, since they are going HTML5.

Intel Graphics – 3D Artifacts

So I’m running a 13″ MacBook Pro with Ubuntu. It has the 2.7GHz Dual-core Intel Core i7 processor with integrated graphics. I’m running the i915 driver (which is what Ubuntu set me up with). Now, everything seems ok, until I run something 3D with (I think) transparent surfaces.

I can spot the issue in SuperTuxKart, but in Minecraft, I don’t have to look for it. It looks awful. I’ve included two screenshots – one from daytime and one from night. Notice that the noise in the image actually is noise, i.e. it changes all the time.

Also, when running the Minecraft game, the rest of the desktop gets messed up too (font rendering, etc) but as soon as I turn it off, everything is working again. Very annoying.

Anyone out there, perhaps you, who know how to solve this? I’d be really thankful!

Opportunities

As fall approaches and the weather turns wet, I have happy announcement to make. Pelagicore, where I work, and our efforts in using Open Source in the in-vehicle infotainment business have been noticed. We just received 20MSEK investment from Fouriertransform (English / Swedish). This means even more Linux and Qt hacking for me! *happy*

Rendering Issues

I’ve run Kubuntu on an old MacBook Pro (revision 5.1) for over a year now, and it has worked great. However, last week, it became more or less unusable. It seems that some sort of blending operation results in noise.

When using the machine with some composition effects, it was completely unusable – moving a window resulted in a square or static noise. All edges of plasma widgets where covered in noise, etc. Disabling all effects meant that I can use the machine again, however, some noise prevails.

As you can see from the screenshot at the top of this post, it is visible in the panel. It is also visible in elements such as the slider and the upper right corner of the desktop folder plasma widget. Another factor is that the noise sometimes disappear when a repaint is forced, but it is “physical” enough to get caught in a screenshot.

So, dear lazy web, do you recognize this from somewhere? Is it the drivers? Is it something in kwinrc? Or is it hardware (perhaps graphics memory) failing?

Update. Thiago from Tro^H^H^HNokia Qt Development Frameworks^W^W^W^WIntel (apparently at a new job) told me to clear the image caches. Read the comment, follow the instructions, and everything works again!

Mythbuntu 11.04 and the Remote

I decided to do some server maintenance today, so I upgraded my Mythbuntu client to version 11.04. I upgraded the backend server as well, but that went smoothly, so I guess that isn’t of public interest.

The client is based on the Asus AT3ION-I Deluxe motherboard. Having upgraded the client, the boot time went from seconds to minutes, and the remote stopped working. After some dmegs, lsmod and Google action it turned out that this was due to the mceusb driver. It loads when the remote is detected, it then crashes, makes the hid-philips-asus.sh script lock the boot process for about three minutes and prevents the correct driver from being loaded. The fix, to blacklist mceusb, is described in the ArchLinux wiki.

N900^H^H – Less Could be More

I’m a happy user of the N900 – an ageing device. As I recall it, I saw it for the first time in real life at Qt DevDays 2009. So, basically, my phone is older than my laptop, and I’m happy about it.

Yesterday, Nokia removed two zeroes from my old workhorse and announced the N9 – a Qt driven phone. You can find a detailed spec here (thanks Ubuntufreak). What I’m excited about is:

  • Unibody. Nokia’s phones have been a bit on the plastic side for my taste in the past.
  • Capacitive (i.e. multi-point) touch. This has really been the N900’s weak point recently.
  • Proper Linux, i.e. MeeGo. No virtual machine layer as in Android, native binaries on a powerful platform.
  • Qt – everywhere!

So, now the only remaining question is – is this a device that will keep me happy for the next three years?

Pidgin to Replace Skype

A while back I wrote about the need for a Skype-competator. We discussed this at work and decided to try to transition to XMPP and libjingle a.k.a. Google Talk. Many thanks for all commenters leading me this way.

The decision that we decided to go for was Pidgin (largely because some colleagues prefer OS X). On (k)ubuntu, Pidgin works with video + voice out of the box. It even detected the Mac Book Pro web camera right away – very nice! As Pelagcore is an all-geek-company, the internal transition has been smooth.

Basically, what the solution relies on is XMPP and libjingle. Jingle being an extension to XMPP for voice and audio.

So, what do I miss?

  • The ability to fix spelling errors by going back through the chat history
  • The ability to call land lines from within the application

There is also something that I have to look into – I just need to find the time (and colleagues to bother).

  • Is it possible to make group calls (group chat does work, but with voice and (optionally) video?

Apart from this, all that is left is convincing everyone that I interact with to make the transition.

Distributed MythTV Support Script

It has been a long time since I had time to play with my MythTV setup, but now it finally works. It turns out that the biggest hurdle was not to split the functionality, nor to configure the channels (one just has to get one’s head around the way that MythTV looks at receivers, channels and providers…). The big hurdle was that one of my frontends are connected over WiFi.

The issue was that the frontend application was launched before the WiFi connection was established. This resulted in the frontend running some sort of configuration guide each time the system was booted. Having realized the source of the issue, disabled the autostarting of the frontend and added my own autostart script:


#!/bin/bash

TRIES=0

ping 192.168.1.201 -c 1
RES=$?

while [ "$RES" -ne "0" ]
do
sleep 1
ping 192.168.1.201 -c 1
RES=$?

let "TRIES+=1"
if [ "$TRIES" -gt "100" ]
then
exit -1
fi
done

mythfrontend --service

Here, 192.168.1.201 is the IP of the backend. The script ensures that the backend can be pinged before the frontend process is launched. The end result is a stable boot every time.