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.

June 21st 2012

When your wife has been in pain every 15 to 20 minutes for six days and six nights, you appreciate the sincerity when she asks you to take her to the hospital at four in the morning.

Bloodstains in the ceiling of the delivery room. Women are tough!

After a short routine check, we where admitted. Five hours later, Erik, was born.

The day after, we could leave the hospital and go home. His big sister is delighted to have a little brother.

Everything is going well. We are tired, as expected, but my wife is my hero. Give us a couple of weeks and we’ll be back in the game again!

3D Printers in Sweden

Having experienced the MakerBot at work, I bought a EMaker Huxley last year. Once you get into the habit of being able to print any mechanical piece that you need (almost), you are forever hooked. Now, I’m looking to build a larger machine and am sourcing material for a building larger RepRap Mendel Prusa V2.

As the price for material is affected by both volume and the transport, I figured that a bit of joint purchasing would be nice. If you are based in western Sweden (i.e. can get to Gothenburg or Alingsås), or is willing to pay for the postage within Sweden, and you wants to join in, add a comment here or drop me a mail (e8johan, gmail). Being able to build bearings, nuts and bolts by the hundreds makes it feasible to source them from far away, e.g. China, or just to get a better price at the local stores.

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.

QtQuick and Drag-and-Drop – One More Time

As a result of my last blog on QtQuick and DnD I was contacted by both Sebas and Marco. Both are active in the KDE project and face the same issues as I do. Apparently, the Plasma team are also working on DnD in QtQuick. Their approach is based around DragArea and DropArea, written in C++ and handles full X11 DnD, i.e. between processes. Marco summed it up nicely in his mail to me.

…in kde-runtime/plasma/declarativeimports/draganddrop/ …is imported as a c++ plugin and depends only from qt (started its life as a 3rd party plugin written by Gregory Schlomoff)…

My solution (will polish the code for release Anytime Soon) is written in QML/JavaScript and only works within a single process, e.g. for moving items between lists, etc.

KDE has been about extending and completing the Qt software stack to make it easier to build Qt-based software. In this process, they are working on QtQuick as well as Qt. A tips for anyone (including me) looking for missing pieces is to look in the KDE TechBase.

QtQuick and Drag-n-Drop

Implementing drag-n-drop (from now on DnD) in QtQuick is like traveling to an up-side-down world. Instead of dragging something and dropping it on a zone, the dragged item (or, rather, the MouseArea controlling the drag) is responsible for keeping track of where it is.

I’ve experimented with a few tricks to resolve this, and I believe that I’ve sorted the dragging half. The question is if I want to improve the receiving end. The concept is that you have a DragArea – which is just a fancy MouseArea. It has a property, zones, which is a list of QtObjects implementing methods to test if the zone is being hovered and to drop the item on the zone. This makes it possible for me to re-align the world with my brain, where the zones accepting the drops are playing an active role in the DnD.

Still, I have to think a bit about how to simplify the zones. Preferably, I’d like to be able to have a DropZone item that does all the fancy things and just lets the end-user (erhm, QtQuick developer, that is), indicate if the item can be dropped and then handle the onItemDropped event. Will see if I have time to polish this over Christmas.

By the way, the new Qt docs really confuse me. Could someone please reduce all the fancy effects, like having to expand each method to see the details. Also, having the Detailed Description on the top kind of reduces the need for a brief. It also slows down my average use-case, i.e. go to the page of a class, pick a method, click it and read. If I want details, I could go to the page of a class, click more and read. To get to the methods in the new layout, I have to scroll for a while, how much depends on the class, then click the item. Also, sending links to the details of specific methods is no longer readable.

QtQuick and Models

Well, the title says it all, lets get started :-)

Proxy Models

Something that I would love to see in QML is the QSortFilterProxyModel. I guess it needs a wrapper of some sort, but being able to sort and filter – either based on a role and a regular expression, or based on a JavaScript function would make QML even more powerful.

Why is this an important feature? To me, the goal of using QML is to put all user-interface specific code in the QML-half of the equation. Adding capabilities to do sorting, and some filtering, to QML reduces the size of the C++ run-time and further decouples the data from how the data is shown.

Lazy Models

A long time ago (pre 4.7.4) I ran into the issue that when resetting a lazy model (i.e. a model implementing canFetchMore / fetchMore) does not trigger QML to poke at canFetchMore. Very annoying, but sorted in later versions of Qt.

Namespace Clashes

In my experience, QML needs the “::” operator. Binding text to the text from a model using “text: text” does not work. Being able to say “text: ::text“, or “text: data.text” would be nice. Even though the last approach prevents the usage of components with properties named data.

I guess there already might be a way to achieve this, but I’ve not found it. If so, please tell me!