Month: December 2011

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.