Category: Qt

Update on Work

As some of you know, I work for Pelagicore. We do in-vehicle infotainment using open source, Linux and Qt. I’m not in Las Vegas right now, but a whole bunch of colleagues are there, showing of at CES.  This year, we’re doing loads of demos together with various partners. We demo together with Visteon (makes infotainment hardware, and more), Digia (makers of Qt), GENIVI (infotainment platform standardization organization), Cinemo (media indexing, rendering and streaming) and Rightware (cool 3D UIs).

IMG_20130108_111108

One of the fun parts of working at Pelagicore is that you get to see cool hardware. I’ve personally worked with Qt on Intel prototype systems, Freescale iMXs, TI’s OMAPs and more stuff that I can’t mention. This year’s demo setup for CES is based on iMX6. The UI has been developed with DesignIt, our design partner company. Let’s face it, those who enjoy coding generally do not excel at polishing pixels. With their help, we’ve been able to make something really beautiful. The picture I’ve got of the UI itself does not say much of the look and feel, but it has a nice reflection of my kind colleague taking the photos, so I’ll use it to say thanks to him and give some credits ;-).

IMG_20130108_111352

The demo is built around Qt and QtQuick (what else is there :-P) on a Linux platform. It integrates our core platform with all the services you might need. For CES, we have some new stuff in there. I have been involved in the integration of technologies from two other companies.

First, we have Righware and Kanzi, a nice 3D engine with an easy to use studio to create the scenes. The car shown below spins around as you change position with nice lighting and material effects. The demo is integrated as an element in the QML scene, and it is possible to bind to and from Kanzi properties, as well as hook into events from Kanzi UI elements, e.g. 3D slides and buttons.

IMG_20130108_111440

The second piece of technology is Cinemo’s media platform. It indexes, renders and streams video and audio. For instance, you can sync multiple devices showing the same video stream, so that you can share the audio through the main speakers. Again, the video stream is integrated into the QML scene, so you can do all sorts of fancy things with it. The images below show an iPad and our demo system sharing a video stream. As you can see, you can control it from either device, and they are always in perfect frame sync.

IMG_20130108_111136+7

From a business standpoint, I guess CES is one of the highlights of the year. We really get to show our stuff to a large audience. However, since I’m not in sales, to me it means overtime, but also having a chance to work with companies making awesome technology. Also, as an added bonus this year, we got to work closely with our team of former Trolls based in Munich, which always is good fun.

So, to all of you at CES. Come visit our demos! To the rest of you, look our for our platform in your next car!

Components Growing

Looking past the irony that QML will be available for all platforms but WP8 in the short-term, and Nokias previous involvement in the development of QML, it is nice to see the platforms being created.

The last in the row is Ubuntu Phone, others are Jolla’s Sailfish, RIM’s BB10 Cascades, KDE’s Plasma and Nokia’s Components for Harmattan and Symbian. Qt seem to unlock the future UIs for devices.

What is striking is the interaction patterns being established. Nokia Swipe, Sailfish as well as Ubuntu Phone seems to rely heavily on swiping from the sides of the screen. This is, in my experience, the key to a truly one-handed device.

Using Android, you are constantly forced to hold the device in awkward angles or use two hands to reach the home button, be it physical or on-screen. Swiping with the thumb is always possible when using one hand (as long as you have an opposable thumbs), while the two-handed user can swipe using the index finger without feeling hindered by the interface.

From a development perspective, it is interesting to see how the different QML Components are shaped. Ubuntu seems to have some interesting ideas for theming going on, and the other platforms have their own strong points.

One interesting comparison is to look at the API for a single component. Comparing the CheckBox elements of Ubuntu Phone, BB10, Harmattan, Symbian and Plasma gives the following API (only looking at the properties and signals that I regard as relevant to the comparison in question).

Properties

  • text (BB10, Symbian, Harmattan, Plasma)
  • checked (BB10, Symbian, Harmattan, Ubuntu Phone, Plasma)
  • enabled (BB10, Harmattan)
  • pressed (Symbian, Harmattan, Ubuntu Phone, Plasma)
  • hovered (Ubuntu Phone)

Signals

  • onCheckedChanged (BB10, Symbian, Harmattan, Ubuntu Phone, Plasma)
  • onClicked (Symbian, Harmattan, Ubuntu Phone, Plasma)
  • onPressAndHold (Ubuntu Phone)

Where does this leave us? For all platforms, one can use the checked property and its onCheckedChanged signal to act. The rest is in up in the air. Ubuntu Phone seems to split the text from the checkbox while the others keep them together. The enabled property is missing from most platforms. Here, even Symbian and Harmattan, both from Nokia, seems to differ.

Still, as the concepts seems similar, the work to create a cross-platform set of components wrapping the components of each platform should not be an impossible task (looking at checkboxes only, that is). Hopefully the end result will not be a too fragmented API landscape and the involved parties will work towards a common setup of basic properties and signals.

Either way, I’m happy seeing that 2012 was a bad year, 2013 looks very exciting. Seeing all these innovative phone user interfaces being created with QtQuick, I’m happy to work at a company innovating in the automotive space using the same technology.

Disclamer! These findings are based on the API docs only. Feel free to correct me by commenting.

Changed behaviour in Qt 5 beta 2

So, I’ve taken the time to shift my development target at work to Qt 5 beta 2 (from beta 1). Most things work perfectly, however, qmake has changed its behaviour slightly – in a subtle evil way.

First, some background. I’m building a QML plugin. When building it with beta 2, it no longer loads as it could no longer resolve the vtable for one of my classes.

$ readelf -sW /home/e8johan/work/prf/lamprey/lamprey/lib/liblampreyqml.so | grep UND | grep QmlAudioHardware | c++filt 
    45: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND vtable for QmlAudioHardware
    47: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::nameChanged()
    50: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::volumeChanged()
   288: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND vtable for QmlAudioHardware
   301: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::nameChanged()
   308: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND QmlAudioHardware::volumeChanged()

What was this all about? I looked at the source, commit logs, everything – nothing had changed and everything was in place. Inheritance – check, Q_OBJECT macro – check, file listed in HEADERS in the pro-file – check…

Then I started to look at what was actually built. Apparently not the moc…

$ find | grep moc | grep qml
./qml-plugin/build/moc
./qml-plugin/build/moc/moc_qml-plugin.cpp
./qml-plugin/build/obj/moc_qml-plugin.o
./qml-bindings/src/build/moc
./qml-bindings/src/build/moc/moc_http_downloader.cpp
./qml-bindings/src/build/obj/moc_http_downloader.o

Since the software I build worked, I simply built it using qmake && make -j5 and then went for a coffee. When doing qmake -recursive I notices a long list of header files that weren’t found:

$ qmake-qt5 -recursive
...
Reading /home/e8johan/work/prf/lamprey/lamprey/qml-bindings/qml-bindings.pro
 Reading /home/e8johan/work/prf/lamprey/lamprey/qml-bindings/src/src.pro
WARNING: Failure to find: qml_audiohw.h
...

Why?! Apparently, a colleague of mine has already reported a bug, and this is the way that it is supposed to be. I’m not sure that I agree. This totally breaks the point of DEPENDPATH to me.

The fix is easy, so now it works, but I’m not happy with loads of ../include in my pro-files due to the way my codebase is structured. I just wonder if this is what we really want…

Update! and it turns out that, yes, that is really what we do want. Apparently this feature has broken code (VPATH causing the wrong files to be picked up). So this is by design.

Update again! running qmake -Wall -r treats the missing header warning as an error. Highly recommended!

Speaking at Qt Developer Conference

I’ve finally been able to find a time slot to try to summarize the Qt Developer Conference. This year I ended up spending lots of time in our booth, so I’ve visited surprisingly few talks. I’m really hoping that KDAB will be able to sort out the issues that they’ve had with audio, so that they can get them on-line. In the mean time, I’d like to share my reflections of the event. From my own viewpoint, is was great seeing so many familiar faces again. Seeing that the event sold out, i.e. 500+ visitors, was great. I knew that the Qt community was strong, but this is great!

From what they keynotes contained and what people said, I also like the direction that the Qt project is taking. Back to the deploy everywhere is something that I’ve been looking for a long time. I even talked about it at FSCONS last year, even though my topic was Necessitas (which worked too well to do a good tech session on it; what is interesting in install, deploy, run…) Hearing that cross platform is key and that Digia supports bringing it to both iOS and Android during 2013 is great.

Another nice thing is Jolla (not actually on QtDC) and BB10. It is ironic to see that what Nokia saw as a burning platforms is picked as the way forward by two competitors. Let’s hope that they succeed and can show app developers what Qt and QtQuick really can do.

Also, seeing the whole group of service providers working around and inside the Qt project makes me happy. Not only the big ones providing general services around Qt, but also smaller niche players. All are able to live because the productivity boost that Qt gives. Taking Qt to a niche of your own seems to be a great way to build a business.

Finally, I did my speech on the morning the last day. The room was deserted when I arrived, but everything worked. I was even able to convince my laptop to play nice with the projector. I’m happy to say that when I finally got going, it was full. There where even a few people standing along the wall. Thank you all for attending! The slides are on the conference page, but also downloadable from here.

Thanks for everyone making it possible for all the Qt developers to meet in 2012! Let’s all meet again in 2013!

Raspberry Pi

I’ve got a Raspberry Pi since a while back. I placed an order the morning the Pi was released. However, I also have a newborn and a four years old, so progress on the Pi has been slow. Now, finally, I have a setup that I’m pleased with.

I use my Nokia N900 charger, a non-name powered USB HUB, and a d-link DWA-131 wifi USB dongle. This page is a great resource for selecting periphials. The only draw-back right now is that the HUB and Pi draw power using separate supplies. Sharing a single 5V feed would reduce the need to free wall sockets from two to one :-)

For casing, I use a self-printed Raspberry Pi case with GPIO-access. However, I’ve not had time to fiddle around with the GPIOs just yet. The case fits nicely onto my noname USB HUB, so I’ve joined the two using a piece of velcro. The look is not very stylish, but the packaging is nice.

For software, I use the Raspbian image featuring debian built for armv6 with hard-float. I also use the qt50-snapshot from here (look under nightlies). That image is missing qmlscene and qmake, so for development, I guess I have to setup a cross compiler, or spend 4-5 days compilation time building a Qt 5 snapshot on the Pi myself. Not having qmake is sort of ok – compilation times are bound to be long, but qmlscene would had been nice, to be able to do local QML development.

I’ve had Qt 5 working from a snapshot for Debian wheezy with softfloat which had qmlscene pre-built. The framerate is nice, so it felt as if there was true potential there. I’m looking forward to being able to build my own little C++ QML extension and try it out for real.

Pics, code and more info will follow.

Do not dash in deb

When building Harmattan apps using Qt Creator, it is important not to have dashes in your project name. If you do, the generated desktop file will refer to foo-bar, while the app binary and icon will be named foobar. It is a simple fix, but can be confusing at first.

Symptoms: app starts when launching from Qt Creator, but icon looks odd and app cannot be launched on the device.

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.