Author: Johan Thelin

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!

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.