Author: Johan Thelin

QtQuick / QML Experiences

I’m in the middle, or rather, approaching the end of, my very first large QtQuick-based project. I cannot tell you that much, just that it includes a rather large code base of QML, and a semi-large run-time environment written in C++. In this blog entry, and probably some more, I’ll tell you about my experiences.

Productivity

The productivity of QtQuick feels amazing when doing small user interfaces. Especially when just putting something cool together to demonstrate the states and transitions abilities of QtQuick. However, as the deadline approaches I’ve learned that QtQuick development is quick only when compared to writing a Qt/C++ user interface consisting of 100% custom widgets.

Working with a design company, I had to identify potential components, write and test those components and then deploy them through-out the user interface. Simply importing full screens from Photoshop and blowing life into them just leads to code duplication.

The end results looks amazing. All that I’m saying is that having graphics on the screen in 15 minutes does not mean that you will be ready to leave by lunch.

Multi-step Transitions

Transitions in QtQuick is just amazing, but when designers start saying things like “scrub the timeline”, “initial movement to give a sense of direction”, et cetera, I hear “add complexity to your puny state-machine”. Currently, QtQuick lacks support for easily defining a transition over a complex path. The provided easing types do a lot – I, as a developer, thing that they look great, but being able to add key-frames to get that extra punch into the animations without having to use multiple states would be great.

One cool thing that I did learn in this process is that implementing a frame-by-frame animation from a set of PNGs is actually quite easy. Simply add a parallel animation group with the rest of your animations and  linearly iterate the “currentFrame” property, and use said property in the source property of your image element. Felt like an ugly hack, but worked great!

A Linter

QML really needs lint. My current deadline is due to smack me over the head real soon, so I have not got the time to looking into what can be done. However, double-checking names of states, ensuring that image files exist, looking for name-space issues (will talk about this later), et ceterea would be really helpful.

As Qt is open source, I guess it is easy to access a tree representing the parsed source. From there, it is simply a matter of applying rules. But, I have not looked in to this at all, so it might be much harder than I imagine.

qBound on Arm

When using qBound in combination with qreal, it is important to properly cast the upper and lower bounds, e.g.:

qreal x = qBound(qreal(0.2), v, qreal(1.5));

If you forget this, i.e by using the following code:

qreal x = qBound(0.2, v, 1.5);

Your code will happily work on x86, and some other platforms, but not on Arm. This is because qreal is a double on all other platforms than Arm. On Arm, it is a float. This leads to GCC complaining about not being able to instantiate the template.

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!

MacBook Pro, Ubuntu and the Cinema Display

I’ve got a new laptop – a MacBook Pro. The 13″ model with the i7 CPU and no discrete graphics card from ATI or nvidia. Instead one relies on the graphics card built-in to SandyBridge.

This caused some issues with the Cinema Display that I’ve grown so fond of – and it looked as if a driver hack was needed. But, thanks to my helpful colleague Erik Botö, the magic modeline was found. The trick is to lower the refresh frequency. So, for everyone out there, this does the trick:

xrandr --newmode "1920x1200_45.00" 140.92 1920 2032 2232 2544 1200 1201 1204 1231 -HSync +Vsync
xrandr --addmode DP1 "1920x1200_45.00"
xrandr --output DP1 --mode "1920x1200_45.00"

If you want to, you can skip the last xrandr call and simply use the KDE Display Settings tool. The line above gives you a clone setup, which I prefer at work.

Metamorphosis

When I first got to know Qt, it was a cross platform tool. That was really the reason for me to start using Qt. It was a great cross platform tool. At the time, I was using a Tru64 based system with real X-terminals. You know, the ones where the screen really is a stupid terminal connected to the network. Tru64 meant a real Unix, as in non-Linux, setup alongside Alpha CPUs. Great for what the school wanted us to do, i.e. use Matlab and latex.

In this setting, I wanted to program something with a user interface. My experiences from the time was GEM, from the good old Atari ST range, VisualBasic, I’ve used 1.0, 2.0, 3.0, 4.0 and 6.0 – without liking a single version, and some plain win32 from C. I did try MFC a couple of times, but I never grew fond of it. So, the first thing that I tried was xlib, which isn’t fun to use. So, along came Qt (and KDE). I believe that it was Qt 1.42 or something like that. One forgets as years passes by.

Qt configured and built beautifully, and the cannon tutorial had me hooked. Standard widgets, custom widgets, user driven, timer driven… this toolkit could do anything. And it was easy to use.

Years pass and the chronology gets mixed up. I met some fellow Qt users at QtForum. I made my way from a common user to moderator. Then, in a series of sad events, the site was sold and the old owner simply vanished from the Internet. The reaction was to start QtCentre together with the rest of the moderators and build a proper community. I cannot thank Witold enough for all the energy he still puts into this site. He really should get more credit for his work. There are other people there too who work hard, but Witold has been there from day one.

Qt progressed, the X11 version was GPLed. So was the OS X version. So was the win32 version. Qt 4 brought many goodies: modularization, webkit, graphicsview, model-based viewing widgets, etc. The toolkit embraced all platforms and is really a great tool for cross platform desktop development.

My self, I wrote the Independent Qt Tutorial for Qt 3, then the Foundations of Qt Development for Qt 4. I started working with Qt as my day time job. I started speaking about Qt at conferences and user group meetings. What I spoke of was the ultimate cross platform toolkit. My favorite example was that Qt tries to integrate well with Gnome – it does not even pick sides in the KDE vs Gnome competition. The whole root of Qt is its cross platform abilities, and there Qt excels.

Then came changes. Trolltech grew. Nokia bought them. The big fish eat the small.

With the Nokia acquisition came a great energy. Qt was put in the limelight. This was the technology that Nokia would base its future on. Developers were attracted to Qt. Qt DevDays had to move to a larger venue to fit them all in, and it still was crowded.

There where some big company things going on. Name changes – Trolltech, Qt Software, Qt Development Frameworks. Anything works. For me, personally, Trolltech had charm. Bug big companies sometimes act in strange ways. They don’t always agree with themselves and they might have contradicting policies and whatnot.

With Nokia came the push of Qt as a platform of its own. Qt on Harmattan/MeeGo and Qt on Symbian where all of a sudden the core focus of all Qt development. This is not surprising, given that this is where Nokia could apply Qt. The focus of Qt Developer Days changed. Out with the widgets, in with QtQuick and bling. The cross platform nature and roots of Qt where seemingly forgotten.

Do not get me wrong. QtQuick is a great piece of technology and something that I use daily in my job. It helps me be real productive and saves me from writing tons of code to drive rich user experiences.

Then came changes. The Qt strategy of Nokia was replaced with a WP7 strategy.

Not only was WP7 the official way forward. The Qt-based N9 is not to be sold in large markets. Despite positive reviews it looks like it will be a sad tribute to what Qt and QtQuick can do. The question is, who will pick up the ball again? Will there ever be another MeeGo handset? Most likely not, as Intel just pulled out of MeeGo, or just renamed it Tizen. The focus seems to have shifted from QtQuick to HTML5. The big question at the time of writing is what will be the underlaying engine. I’m sure everyone agrees that it will be WebKit, but will it be hosted by Qt or something else?

But now Qt has started to find its roots again. Lighthouse made porting easy. Necessitas puts Qt on Android. Qt for iOS is an ongoing community port. Qt will once again excel as the cross platform solution of choice. The question here is if it is wise to merge the desktops into the QtQuick API. I’m not convinced yet. Being cross platform on desktop also means integrating with the desktops. Current desktops are widget based, and to be true, widgets rock on desktop things. When controlling a machine or writing a mail I don’t want bling, I want predictable, stable widgets that looks like they are supposed to.

Compare this to common device user interfaces. Here there is a difference between applications such as mail and todo apps. Here you want common components that integrate with the platform – much like widgets. These elements usually fit into the limitations of widgets as well. Square, non-overlapping, etc.

Then you have completely custom applications, think Angry Birds, where QtQuick is the ultimate tool. As QtQuick can encapsulate both these user interfaces, it is the ideal tool for this type of device user interfaces.

And the current hype – HTML5? I believe that QtWebkit is the best system for building hybrid web/native applications out there. And integrating QObjects with the JavaScript space much resembles integrating them into QML space.

After chaos; Metamorphosis

I look forward to a new spring for Qt. Having a common Qt core for all applications. QtQuick for device user interfaces and QtWidgets for desktop. The QObject model that we have learned to love and the power of C++ will be available to all. Still, the user interface can be integrated with the platform of choice or fully customized with QtQuick. Code less, create more, deploy everywhere.

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!

The Digital Project

I’ve decided to bread life into an old domain, but let me tell the story from the very beginning. Way back, when leaving university, a couple of friends of mine and myself went looking for a place to keep our projects, personal homepages (yes, we geeks had those back then – sort of a facebook profile, but without the centralization and games). The end result was that we bought the domain digitalfanatics.org and some hosting.

The years passed. From my side, I ran The Independent Qt Tutorial there. Got a job, wrote a book, got a Qt job, etc. For the others, life also progressed. In the end, the result was a site with a broken wiki installation and outdated contents. So, I decided to take over the domain and do something about it.

During the time that passed, I became a software guy. There is no point trying to resist that any more. I did study electrical engineering – microprocessor architecture, digital construction, etc – but I ended up a software guy. Now, I happen to have an urge to explore and write about things. This turned into a plan – Digital Fanatics would be a place where I could write about electronics and cool projects.

The site has been running for about a month now, without any promotion apart from myself twittering now and then. Still, the average reader count has increased to 50+, and the peak day had more than 100 unique visitors. This is far better than I expected and a real inspiration to me.

So, for those interested in smaller system, preferably open source, and such, feel free to visit the new digitalfanatics.org. And, yes, it will still host The Independent Qt Tutorial. It draws an amazing amount of traffic (1000+ daily hits) despite being Qt 3 – I really should find the time to update it for Qt 5 :-)

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.