Declarative UI is one of the big things on the Qt Roadmap for Qt 4.7 and 4.6.x. I already enjoyed working with the Qml language and the developers behind it for quite some time - and believe me, this one will fundamentally change the way slick Qt UIs are designed and look like! If you have not checked it out yet, do so … although it is not yet part of the Qt package, it is very mature, and just fun to experiment with

Anyhow, a technology like this of course does not come out of the blue, neither do the tools to support it - I think the first discussions about a Visual Editor for a language yet-to-be-invented on the basis of the QGraphicsView framework started in summer 2008! In early 2009 I first heard about the name “Qml”, and was soon the lead of a development project, with right now 5 people working full time in this project. One of the most important decisions we had to make early on was for a cool project name - we eventually settled for “Bauhaus”, as a reminiscence to the famous German school for design.

Back to the facts: What I want to share with you today are our plans for supporting Declarative UI / Qml in QtCreator. This is an important one, because with Declarative UI we target not only the traditional Qt/C++ developers, but also more design centric people - the goal is to let both share the same language, from early prototyping until the final product. We can only achieve this with good tools in place.

Here are the things we are currently working on for the next major version of QtCreator:

Qml Text Editor - We already have some basic syntax highlighting / formatting support in QtCreator 1.3, but in the QtCreator master branch we are right now working on really mature Qml/JavaScript support. This will include all the goodies you kind of expect these days: Code completion, context sensitive help, …

Visual Qml Editor - After all, we are talking about graphical user interfaces, and you will not make UI designers happy just with a text editor . Here we decided for a fresh start and developed the components for the Visual Editor from the ground up. Interestingly, we are using Qml heavily ourselves here - e.g. in the Property Editor and States View.

Seamless Integration - It is no either text, or visual editing: You want to use both, and quickly switch between both. This is why we deeply integrate the Visual Editor into QtCreator, share the same Undo/Redo history and are also preserving the Qml file formatting as much as possible when doing file changes.

Debugging - We integrate the Qml debugger, which allows you to inspect the qml item tree and its properties at runtime, to check framerates, to evaluate JavaScript expressions and so on inside QtCreator.

Enough said - Nigel recorded a nice video showing you how the support currently looks like:

If you want to try it out yourself, we also packaged a technical preview of creator, qmlviewer/qmldebugger and the declarative examples & demos in one installer:

qt-creator-win-opensource-1.3.80-qml-tp1.exe (Windows 32 bit)
qt-creator-linux-x86-opensource-1.3.80-qml–tp1.bin (Linux 32 bit)
qt-creator-mac-opensource-1.3.80-qml-tp1.dmg (Mac OS X)

Disclaimer: The binaries are unsupported, and are only meant for early testing. In fact they are based on an untested snapshot of Qt, and an (almost) untested version of QtCreator! If you want to use qml for production work, stay with QtCreator 1.3.1.

Of course we are interested in all kind of feedback, preferably via the bug tracker or on the qt-creator mailing list.

Recently, Qt Declarative for Qt 4.6.0 got released. We got a lot of requests for Maemo 5 support (well - some people just wanted to play the SameGame on their N900 ). And voilà - declarative hit Maemo’s extras-devel repository. Obligatory screenshot:

Currently, the following packages are available:

• libqt4-maemo5-declarative: The QtDeclarative library
• libqt4-maemo5-declarative-dev: The development package, contains the headers for QtDeclarative
• libqt4-maemo5-declarative-dbg: The debugging symbols, for more meaningful backtraces
• qt4-maemo5-declarative-qmlviewer: The “player” for QML based apps
• qt4-maemo5-samegame: The SameGame demo

To just get the SameGame, all you need to do is

apt-get install qt4-maemo5-samegame

(provided that you enabled the extras-devel repository). And the neatest thing - with the N900’s text editor, you can program your own QML applications directly on the phone. Launch them from the xterm with /opt/qt4-maemo5/bin/qmlviewer ./myapp.qml

No need to stop hacking just because space is too constraint to get out your laptop

Obligatory note: Qt 4 for Maemo 5 is still in tech preview status, reports about molten N900s will be met with a compassionate “Told you”.

For a long time the standard layouts shipped with Qt’s have been built around the concepts of linear and grid layouts. In the QLayout regime they are represented as QBoxLayout and QGridLayout. In the QGraphicsLayout regime they are represented as QGraphicsLinearLayout and QGraphicsGridLayout. We therefore started early this year with research on a new layout. The efforts of that culiminated into the QGraphicsAnchorLayout.

Motivation

We have quite often seen that the existing layouts in Qt can not always do what you want with just one layout. Take for instance Qt Linguist’s “Find dialog”.
The dialog is made up of four box layouts and one grid layout for the checkboxes inside the groupbox.

(note that Qt Designer does not illustrate the layout inside the groupbox or the toplevel layout)

In addition, in order to achieve this simple arrangement it uses three levels of nested layouts.
Luckilly, if you design it in Qt Designer it is quite easy, but you might not get it right at first attempt. Of course, doing it programmatically makes it even worse. The result are probably far from how a UI designer would specify the arrangement. We think that an anchor layout will narrow that gap in a lot of cases.

Concept

The QGraphicsAnchorLayout is a very flexible layout, yet the concept is simple. By creating an anchor between two edges of two layout items you are giving the anchor layout a constraint to fulfill. In the simplest case you are just saying that the distance between the two layout edges should be a fixed distance. You can do this with the left, right, top, bottom and the “center edges” of any layout item. You can also have an edge that has several anchors connected to it. This is not possible with linear layout and it is partly possible with a grid layout. This allows you to build up the structure the layout should have. The layout will then try to fulfill the constraints you have given it by potentially growing or shrinking the layout items. You can also configure each anchor to grow or shrink if that is preferred.

The API for configuring the layout structure reflects this concept. The addAnchor() function is all that you need to configure the structure of the layout, but we added some convenience functions for anchoring corners (surprise, addCornerAnchors()) and for fitting the size of an item to another (addAncors()). Thus, the following code will ensure that the left edge of item findEdit is always connected to the right edge of the item findLabel. In this case it means that there will typically be a bit spacing between the items, and the spacing will always be the same.

   anchorLayout->addAnchor(findLabel, Qt::RightAnchor, findEdit, Qt::LeftAnchor);

You can also anchor an item to a layout edge. If the edge of an item is anchored directly or indirectly to a layout edge, it’s geometry will react to changes in the layout geometry:

   anchorLayout->addAnchor(anchorLayout, Qt::LeftAnchor, findLabel, Qt::LeftAnchor);
   anchorLayout->addAnchor(findLabel, Qt::RightAnchor, findEdit, Qt::LeftAnchor);

Of course, you can also anchor items the same way in the vertical dimension.

Now, with this brief introduction we can go back to Qt Linguist’s “Find Dialog” example as I gave above.
It turns out we can make the same arrangement with just one anchor layout.

This is how the code could look like:

    QGraphicsAnchorLayout *l = new QGraphicsAnchorLayout;
    QGraphicsWidget *w = new QGraphicsWidget(0, Qt::Window);
    w->setLayout(l);

    // label, line edit and "Find Next" button
    l->addCornerAnchors(l, Qt::TopLeftCorner, findLabel, Qt::TopLeftCorner);
    l->addCornerAnchors(findLabel, Qt::TopRightCorner, findEdit, Qt::TopLeftCorner);
    l->addCornerAnchors(findEdit, Qt::TopRightCorner, findButton, Qt::TopLeftCorner);
    l->addCornerAnchors(findButton, Qt::TopRightCorner, l, Qt::TopRightCorner);
    // group box
    l->addCornerAnchors(l, Qt::BottomLeftCorner, groupBox, Qt::BottomLeftCorner);
    l->addCornerAnchors(groupBox, Qt::TopRightCorner, findEdit, Qt::BottomRightCorner);
    // cancel button
    l->addCornerAnchors(findButton, Qt::BottomLeftCorner, cancelButton, Qt::TopLeftCorner);
    QGraphicsAnchor *anchor = l->addAnchor(cancelButton, Qt::AnchorBottom, l, Qt::AnchorBottom);
    anchor->setSizePolicy(QSizePolicy::Minimum);
    l->addAnchor(cancelButton, Qt::AnchorRight, l, Qt::AnchorRight);

    // Done!
    scene.addItem(w);

Note, for simplicity the code does not populate the group box with items, since that is easier done with a grid layout. Thus, the anchor layout reduced 4 layouts into one.

There’s a lot of interesting things I could mention here, but I would then be just repeating what’s already written in the documentation, so if you are interested I suggest you take a look at that.

Conclusion

The anchor layout has some attractive properties. For some setups it provides a more intuitive API that is closer to how the UI designer would specify it. It is also very flexible: You can construct free-form graphs of anchors where one edge might be anchored to several other edges. You can modify size policy of each anchor, which means there is little use for a spacer item. You can also modify the spacing to be both a positive and negative value.

Of course, the anchor layout is not the silver bullet and in a lot of cases you are better off with just using a linear or a grid layout. The anchor layout is a flexible layout, and there is a price you have to pay for that: For some arrangements it can be very verbose compared to a linear layout, since you don’t have to anchor each item together (the “anchoring” is implicit by the order of the items).

Read the rest of this entry »

At the Munich DevDays we got a lot of questions about QML - first among them was where to download it. To celebrate DevDays in San Francisco we are releasing binary snapshots that you can download now for Windows, Mac and Linux.

For those of you who couldn’t attend DevDays, QML helps you create exciting UIs like this:

Remember - QML still isn’t released so it isn’t as solid as we’d like, but it should be enough for you to get started. The packages include a full version of Qt Creator - simply create a new QML project, let your creative juices flow and press play to view your creation in the QML viewer.

When Qt 4.6 is released, we’ll make another more up to date package. As we approach this milestone we’re focusing our attention on writing tests, squashing bugs, updating docs and giving the examples a little love - so by Qt 4.6 QML should be even better!

Do you know the main advantage of a Hummer? It can go pretty much everywhere, that’s why many armies are using it. If I talk about a Hummer it is because QGraphicsView can go pretty much everywhere too. Recently I was lucky enough to get a N900 (generously given by Jesper, don’t know for how long though) so I decided to test Qt on it. I mainly work on QGraphicsView here at Qt Development Frameworks so it was a way to test the speed of my toy (:p). Since I’ve also been a KDE user and developer for quite a bit, I thought I could try KDE on it and more precisely Plasma.

So I downloaded the Maemo 5 SDK and started building KDE and Qt with it.

First thing you have to know is that scratchbox is not easy to set-up because you always face problems and compiling inside scratchbox is really slow. The link step is a bit broken and you have to specify manually where are the libs you link with (apparently it’s expected to be like that). It seems odd… Anyways, after a couple of hours I had Qt 4.6 (Fremantle branch) up and running. I was quite happy to see that it performs well (if you are using the right things). Animated tiles are running smoothly and painting demos as well (using opengl es2 graphicssystem).

After this initial success I tried KDE. This was more painful than I originally thought. Broken packages (mysql-server), out-dated packages (shared-mime-info for instance) and the worst : CMake crashed during the configure step. I solved that by downloading the 2.8 RC version that I built myself. But after a couple of hours of fighting and debugging I got this:

Link to youtube video

As you can see Plasma is running fine on this device. Of course a lot of work is needed to make it “finger” enabled (the actual applet handles are not really appropriate) but it’s a good start and Plasma is flexible enough to allow that. I have created a separate “shell” called plasma-mobile (Plasma already has the desktop and netbook shell) and I pushed that on the KDE playground. It also needs a lot of work to integrate well with the device (battery, network, profiles and so on) but the goal is to invite people to contribute to Plasma in order to offer a real alternative to the hildon-desktop. Plasma already has many many features/applets that we can just use on the N900. This also comes with a global effort to bring KDE technologies to the device as Kevin said in his blog. You can also participate in discussions on the KDE mailing-list for Maemo.

So yes Plasma is also a hummer, it runs everywhere but it’s the luxury version.

So, are we in the future yet? It is 2009. Where are all the flying cars and personal jet-packs ? Surely we would all be wearing metallic outfits (complete with Employee Visualization Appendage) by now.

The Future Is A Canvas

Back in 2006 a little bit of the future arrived when QGraphicsView was introduced, we were aiming to replace our old QCanvas API with something more flexible and powerful.
It turns out that it is great for creating dynamic, smooth and animated GUIs. Over time it has become the backbone for next-generation user-interface projects like KDE’s Plasma and Qt Declarative UI.

Yet, for all its dynamic, smooth goodness, there are some missing pieces in the puzzle. People are creating full user interfaces in graphicsview, but Qt offers only the most basic widget types to help them out. In many cases it is enough to offer basic primitive types. But if you want to integrate with the platform you are running on or want to use more complex widgets, it becomes difficult.

The Shiny New Stuff

This is why we have started a research project aimed at providing a basic widget-set based on QGraphicsItem. It is a natural extension of the Next Generation Itemviews project. We will take the opportunity to look at how to improve the widget API, internal structure and how we do widget styling and theming.


HotWheels by Leap Kye on flickr

One of the lessons we have learned is that graphics hardware is generally happier when moving pixmaps around, than when drawing lines and shapes again and again. This has implications for the styling API, since our current QStyle is based around drawing complex controls imperatively. It would be better to build our widgets as a graph of (cached) primitive elements that can be transformed and updated individually if necessary.
Similarly it also makes sense to make the input regions in the widget into separate elements in that scene graph.

But, for all our fascination with the new and shiny, we should not forget that our existing widgets contain years of accumulated experience in the form of code that handles all sorts of weird and wonderful corner cases. We don’t want to go though the pain of re-discovering all these cases. It makes sense to re-use existing logic and behavioral code by moving this code into classes that can be used by both the old and the new widgets, when possible. This will also allow us to directly test and verify the internal widget logics independent of the widget front-end.

Still Kinkin’ It Old School ?

We are not forgetting our QWidget based widgets. They will get some initial benefit of better tested back-ends and hopefully some code cleanup. I also have some ideas that will drag QWidget kicking and screaming into the future, but I’ll leave those for another blog-post. Always leave the audience wanting more.

Talk To Us

Even though we are currently working full time on getting Qt 4.6 out the door, the widgets-ng repository is already public and we are already hanging out on #qt-widgets-ng on irc.freenode.net .
I will be attending the Qt Developer Days in München next week, and there will be several developers from the Qt Widgets Team attending the San Francisco event too. Feel free to discuss anything widget related (or any random topic, really) with us. See you there!

Something we’ve been trying out recently with Qt Declarative UI is a Plasma integration. A characteristic of plasmoids is that they tend to have their own unique UI design. Integration of Declarative UI with Plasma has the potential to make it much easier to design such plasmoids. There is also the potential to help make plasmoid development easier by providing a declarative language that is designed specifically for fluid user interfaces, and is more accessible to designers without C++ knowledge. And it also has the potential to facilitate the construction of highly animated plasmoids, like the weather example which animates the clouds and rain/snow all separately. As a prototype we are hoping that its use will provide constructive feedback which enables Declarative UI to truly fulfill these potentials.

There is one very tricky aspect to Declarative UI’s Plasma integration. That is that there are large sections of Plasma code which are already written, containing widgets and QGraphicsItems, which might like to add some declarative parts but are certainly not going to re-write themselves. Declarative UI is based on existing Qt technologies, GraphicsView in particular, and can be integrated into existing applications. We just have very little experience with doing that right now and are still investigating how well this works, so feedback on this issue is warmly welcomed. We do intend to get things so that, as much as possible, existing Qt code can easily add Declarative UI bits to its UI when and if they want. You certainly won’t have to rewrite your application to use Declarative UI if you’re happy with your Graphics View solution. In fact, the prototype Plasma integration makes the existing Plasma QGraphicsWidgets directly usable in QML without altering their code at all (we’re still checking how well this works though).

We’re hoping that, at some point in the future, people will have Declarative UI as another one of their options for how to build their plasmoids. An especially compelling one if it’s to be heavily animated or they don’t like coding.

Below is a screen shot showing some of what we have so far. On the left is the weather example, and those are Plasma::PushButtons being used in the middle. On the right is a data source example, printing all the information it can get from the time data source. On the right, below the QML plasmoid, is the file watcher plasmoid showing the full QML source for the data source example just above it.

A few weeks ago, the LinuxTag 2009 took place in Berlin. Of course some of us Trolls went there to present Qt. We ran a little booth where we had the possibility to talk to many Qt users (and future Qt users).

But that was not all. Some Trolls gave talks about very interesting topics. And because on that day I found my camera somewhere in my pocket, it made sense to film some of the talks (three to be exact) and share them with those who were not able to travel to Berlin. Here we go -in chronological order-…

Creating Qt Creator
Free Software Development at Nokia, Qt Development Frameworks

Speaker: Matthias Ettrich

“Nokia Qt Development Frameworks - the former Trolltech - announced earlier this year that they will open up their software development process and establish a new contribution model. One pillar of this change is a more permissive licensing under the terms of the GNU LGPL. In addition, Qt source code repositories will be made publicly available and contributions from desktop and embedded developer communities will be encouraged.” more…

New user interface paradigms on mobile devices

Speaker: Matthias Ettrich

“Today’s mobile devices have large high-resolution screens, touch input and significant graphics power. Applications on such devices no longer compete on features, but on graphical “wow”. It is not even unusual to hear people buying apps just because they have a cool UI.” more…

Advanced Graphics Programming with Qt

Speaker: Ariya Hidayat

“This talk highlights several key features of Qt graphics programming, including the low-level, immediate-mode painting system and 2D scene graph provided by Graphics View. To ensure a successful smooth and attractive user interface, this can be complemented by animation, Web engine, scripting, and graphics effects, which will be suitable discussed as well.” more…

As with any Qt API, the Qt Declarative QML API that we expose needs to be carefully thought through to provide a consistent and intuitive developer experience.

One area of inconsistency has been the mixing of nouns and verbs. A declarative language describes what, not how. An example of this is the SetProperties element. This element describes the changes to one or more properties in a particular state. The SetProperties name has a distinctly imperative flavor. It implies an immediate action and fails to capture the nature of the element. Changes to properties in a state are merely overrides that will be restored when the state is left. These factors lead to the proposed renaming of SetProperties to PropertyChanges.

We are currently in the process of reviewing the entire QML element API. We expect the review to be complete by the end of August, though it may take a little longer for the proposed changes to propagate into the code. Unfortunately, if you are a Qt Declarative early adopter you will need to update your code. In order to help with this there is a list of changes and pending changes in the src/declarative/QmlChanges.txt file in the kinetic-declarativeui branch of the Kinetic repo.

BTW, if you’ve been experimenting with Qt Declarative we’d love to hear what you’ve been doing and how you’ve found using QML.

Here’s a video of a game we’ve written with Qt Declarative UI:

This completely functional implementation of Same Game is 334 LOC, 127 lines of QML and 207 lines of simple Javascript for handling the game logic. Considering that it includes animated movement and visual effects, that seems rather impressive. But LOC is not a very well defined metric - if you really want to see just how simple Qt Declarative UI makes things then checkout the source from the kinetic repository on gitorious (the kinetic-declarativeui branch) and look for yourself . Don’t worry, those 334 lines include some comments to help explain what’s going on. This demo does have a lot of stuff packed into those lines though, including dynamic object creation and great potential for custom themes.

So have a look at the Qt Declarative UI branch if you want to play with this powerful and emerging technology - or just with the games we’ve implemented with it.