QML Layers in Marble

Categories: KDE, Marble
Tags: No Tags
Comments: Comments Off
Published on: May 27, 2012

KDE 4.9 Beta 1 is about to be tagged soon and so is Marble 1.4 Beta 1. Judging from the current bug reports and my own tests it is pretty stable already; I’m not aware of any major bugs. Still we’re not running short of things to do: There’s Marble Touch for Harmattan (Nokia N9), the to-arrive Marble Touch for Plasma Active as well as the usual development work currently centered around our four students and their projects (Google Summer of Code and Season of KDE).

One of Marble’s strength has always been that the vast majority of all functionality is contained in its library and shared by the two (with Marble Touch now three) applications that are shipped with the project as well as all other applications that embed the library. Given that Marble Touch is based on QML/Qt Components, this implies to expose parts of the API to QML.

The content presented by Marble consists of several layers stacked on top of each other. Usually this is a base map (based on several texture and vector layers), intermediate layers like search results, a route, postal codes, clouds and finally information boxes. Most of them can be configured: The base map is setup by .dgml files and brings it’s own properties that can further be tweaked through e.g. Marble’s interactive legend. Search and routing have their own control fields. Additionally these layers can be managed via the C++ API (and most parts also from QML).

What about postal codes? They’re part of the so-called online services, plugins that download a certain type of data for the currently visible map region and display them. Besides postal codes these can be Wikipedia articles, photos (from flickr), weather status and forecast, recent earthquakes and more. Each of these services provides limited interactivity in the Desktop version, but the QML interface was missing so far. Yet it is quite interesting to access the online service data from QML for those activities that are tightly coupled to them: Weather, Friends and the currently emerging “Around Me” that provides information about nearby places and events.

Today I extended the existing online service framework to be able to provide a QML delegate — pretty similar to a delegate e.g. in a QML ListView. Once the delegate is set it deactivates the QWidget based rendering for the given service. Instead the provided  QDeclarativeComponent is used as a factory to build and destroy QML item instances as needed as well as updating their screen positions automatically. The C++ data model item retrieved by the online service is set as the context object in the QML context of the QML item such that it can easily access its properties by their name. This approach has several advantages: Item culling, filtering and positioning can be done in the C++ part, which is faster, easier and reuses existing code. At the same time the layout can be done in QML, which usually results in less code and easily allows to add animations. And finally QML is great to allow interaction with the content.

For a proof-of-concept I took the existing Weather activity and replaced its C++ rendering with a QML delegate as you can see in the short screencast below (Youtube, direct .webm here). As expected the QML part is short, just 50 lines for the legend on the left and 60 lines for the delegate that renders the weather status icon and temperatures. Adding interactivity (showing details on selection of a weather station, marking stations as favorite) will be similarly easy.

Not everything works great though. The old z-value problem naturally comes up again with the QML weather items overlapping the information boxes (except for the QML rendered legend). This happens because of the different, independent rendering that does not allow to control the paint order. Unless I find a way around this I’ll probably go for replacing the remaining upper layers (information boxes mainly) with QML equivalents as well. That’d mean that the lower part of the layers was rendered by C++, the upper part by QML. On the one hand this sounds sane given that the lower layers need little interactivity, but are performance critical, while the upper ones are the reverse. On the other hand this would break the fine grained z-value control we currently have.

tl;dr

The QWidget based rendering of online service layers in Marble can now be replaced by custom QML delegates (sok-2012-plasma-active branch).

 

 

Comments are closed.

Welcome , today is Thursday, October 30, 2014