Marble in your CMake or qmake based project, now more easy

Marble, the virtual globe and world atlas, at its core is a library intended for reuse, libmarblewidget. This library is done with minimal dependencies to ease usage (e.g. just needs a few Qt5 modules).

The new version of Marble, coming with libmarblewidget v0.26 and released as part of KDE Applications 16.12, is now making it more easy to integrate libmarblewidget in your own software project, when using CMake or qmake as buildsystem.

To link your project to libmarblewidget and find its headers, you can have that in 1-2 lines:

For qmake a qt_Marble.pri file is installed. So in the pro file of your project just add:

QT += Marble

For this to work you have to do one out of these:

  • install Marble into the same prefix as your Qt5 installation (e.g. /usr)
  • pass -DMARBLE_PRI_INSTALL_USE_QT_SYS_PATHS=ON to cmake when building Marble
  • use the environment variable QMAKEPATH to point to the installation prefix of Marble when calling qmake on your project

For CMake some CMake config files are installed. So in the CMakeLists.txt of your project just add:

find_package(Marble REQUIRED)
target_link_libraries(my_project  Marble)

No more need for some own FindMarble.cmake file.

The CMake variant is already possible since libmarblewidget v0.25 (part of KDE Applications 16.08).

Learn more about how to use Marble in your project, e.g. by simple examples, at

WIP: Plasma World Map Wallpaper & World Clock Applet, powered by Marble

The core of Marble, the virtual globe and world atlas, is a library, intended for reuse. Next to exposing its native C++ interface (see API dox of development version of the Marble library), there is also the option to use it in a QtQuick variant.

The Marble code repository itself holds a few application and tools based on the library. Additionally it also has extensions & plugins for other applications & workspaces, like the KIO thumbnailer plugins for previews of KML, KMZ, GPX & GEOJSON files in KIO-using file manager or file dialogs, a Plasma Runner plugin for looking up geo coordinates or a world clock Plasma applet.

Moving to Plasma5, Marble KRunner plugin arrives first

Having extensions for external applications & workspaces in your repo requires yourself to keep up-to-date with those externals. When Plasma5 appeared with the big switch to QML-only plugin architecture, that left the Marble-based plugins a little behind for now.

Good news is that the KRunner/Plasma Runner plugin was not affected by that, and with “KDE Applications 16.08” and the new Marble release will now also be out in a version working in all locales this month.

Reviving the Marble world clock plasmoid from 2009

The Marble world clock plasmoid, introduced already in 2009 (see bottom of page), though needs a full rewrite, from C++ to QML, which is a bigger undertaking. It also needs a port from KTimeZone & KTimeZoneWidget to QTimeZone, and in that course a cleanup of the mapping between time zones to geocoordinates.

Good news here is that some initial work has been done now and is up for review. A lot of the features are still missing, and there are some glitches (e.g. vertical offset, license info displayed). But it is a start, and the current state might be even fancy enough for some users already πŸ™‚ So it should see a first release with “KDE Applications 16.12”.

It is a small mutation from a Plasma Applet to a Plasma Wallpaper

With the applet initially working, the idea came to have the map also shown fullscreen as wallpaper. While I could not find documentation how to do a wallpaper plugin, the existing code and examples though gave enough hints, and one hour later there was the first incarnation of a Marble-powered Plasma Wallpaper plugin.

See here a screenshot with both the World Map Wallpaper and the World Clock Applet in their current state:
Plasma World Map wallpaper & world clock applet, powered by Marble

Tell what kind of world maps you want to see as wallpaper

Because the World Map wallpaper can make full use of all Marble plugins, a lot of different kind of setups are possible:

  • Plain political map view
  • Globe view with stars in the background
  • Map view of just a continent/country
  • Satellite-photos-based view with live cloud rendering

There could be also plugin variants for the Moon, Venus or Mars.

So start Marble, play around with the settings to learn what is possible. Then tell in the comments what other kind of maps (or globe views) you would like to use for a wallpaper, so we could consider them as predefined settings at least.
As with the rewrite of the World Clock applet, a first release of the World Map wallpaper(s?) should happen with “KDE Applications 16.12”.

Create your own Plasma Wallpaper quickly by a new template

BTW, if you have other fancy ideas for Plasma “Wallpapers”, as by-product I did a template for Plasma Wallpaper plugins. It is currently up for review, so hopefully will be part of future KF5 Plasma frameworks releases. With that template, your first own wallpaper plugin is just a few clicks away e.g. in KAppTemplate or KDevelop.
Update: Until it arrives in releases, for now you can download the template file plasma-wallpaper.tar.bz2 from here and manually install it by moving that file into the folder /usr/share/kdevappwizard/templates/.
When playing around with the wallpaper settings, be aware there might be at least the issue of the wallpaper config page not reading current/default settings when switching the wallpaper type. As workaround, after switching the wallpaper type, one first has to close and reopen the dialog to be able to adjust the settings of the new wallpaper type.

Randa Meetings 2016 Part II: Marble

User Interface Needs Work For Facing More Users

The Randa Meetings 2016 were centered on bringing KDE technology on every device.

With regard to applications created by the KDE community, this means two things:

  1. Getting the source code to build for the operating systems on the target device
  2. Adapting the application UI to the specifics of the target device

The first point is by good parts covered by using the cross-platform library Qt and the cross-platform build system tool CMake, which eases enabling the build on many mainstream and also non-mainstream operating system. And the add-ons to these developed in the KDE community as shared elements, the Qt5 extensions KDE Frameworks (KF5) and the Extra CMake Modules (ECM), see lots of good work to cover more platforms as well.

The second point though is the larger hurdle here, when it comes to non-workstation-like devices, like tablets, smartphones, smartclocks or also TVs, fridges, in-vehicle entertainment screens. There especially the input options are quite different, which is also reflected in the UX of those devices in general.

Most existing applications created in the KDE community though have a UI done and optimized for the classic workstation-like setting. A setting, where input is done with a keyboard and a mouse. Where the main application window follows the concept of a menubar with submenus at the top, one or more toolbars below the menubar, a statusbar at the bottom, and the content in the middle.
And the source code architecture of most applications is often strongly coupled to this one UI, here and there even using the UI classes to store data belonging to the content that is viewed or edited, so no clean separation between UI layer and content model.

So adapting the application UI to the specifics of the target device most often means a big refactoring of the source code or perhaps even a complete rewrite. Something which is not done in a few weeks, but needs a lot of work over quite some time. Something for which people need motivation e.g. by owning and using such target devices and thus having the desire to also use those applications on them.

This showed to be a big hurdle even with devices which came with Qt pre-installed as the native UI toolkit of the operating system. Like the Meego devices, the BlackBerry 10 devices or the Sailfish OS devices. Only a few applications from the KDE community ever made an appearance there.

New: Direct Shipping To Devices By Developers

Another, though smaller issue to tackle for application developers often is to have to become a packager and distributor as well. Because other than with Linux distributions or the BSD port system, where the application developer just releases a tarball with the current sources which then is picked up the distributions’ packagers or the port system maintainers to make the software available in the package system of the respective operating systems, on other (usually proprietary) operating systems the end-user is to get their software from the application developers themselves directly or indirectly in a ready-to-install format, either by download from their homepages or via the so-called “app stores”. Which means more work to do at least.

Marble, a globe app going globally

One of the applications created in the KDE community whose developers managed to get it ported to more than the classic desktop computer, with regard to both operating system and UI, is the virtual globe and world atlas Marble. The reasons for that possibly can be seen in the capable and hard-working developers, but also in these:

  • Structuring the application in a modular way (so ports could be composed specifically for the target device use case, also some module being unported might not block the others being ported)
  • Avoiding dependencies on external libraries & modules if possible (so less things that also need to be available for the target platform)
  • Keeping dependencies on external libraries & modules optional (so if missing they do not block the rest of the application to be made working)

Myself I am more a happy user of the Desktop app Marble, not a core-contributor. So far I only did work on integration of Marble with the Plasma workspace, by writing some KRunner plugins to start Marble for geo coordinates or thumbnailer plugins for previews of KML, GPX & Co. in the file manager or file dialog.

Marble Maps on SailfishOS

Now, currently the Marble developers are working especially on Marble Maps, as a dedicated version of Marble for navigation purposes, with a first release planned for autumn this year. The main target platform right now is Android. As owner of a Jolla phone, which uses SailfishOS and thus Qt as part of the platform, last autumn I gave it a try to write a SailfishOS native variant of Marble Maps, to some quick first success. The uncertain future of Jolla then and thus of SailfishOS though kept me from investing more time into it. With Jolla these days still not sub-surface luckily and still sailing, I picked up those efforts now again, with the goal to merge my Maps variant soon into the Marble main code repository and have it part of the upcoming release, with feature-parity where possible.

With Qt being part of the operating system (and even more, slightly tuned there), there is some challenge though: SailfishOS is based on Qt 5.2 (with some backports from Qt 5.3), whereas either the typical unixoid target platforms themselves are on a more recent Qt or, with self-contained packages for Android, Windows & Co., one for good reasons picks the latest released Qt to ship along. Luckily so far the Marble core code could be kept working for all Qt versions. And there is some hope for more ease in the future, as work on updating SailfishOS to Qt 5.6 has been spotted.

So during this Randa Meetings I joined the Marble developers in their room for many days. For talking about roadmaps, features and plans with Marble Maps, when they had their heads not deep in the code. And learning more about the technologies behind navigation in Marble Maps, e.g. about how the turn-to-turn navigation is done.

More, I got a few hours long introduction into Marble’s elaborated rendering architecture by Torsten. Given my interest in static rendering of maps/globes for printing purposes or video frames generation, after nagging for that all the years I possibly have to scratch my itch here myself finally πŸ™‚ Though that knowledge will also be helpful when perhaps starting a plugin for OpenTripPlanner, another thing I would like to use on my device with Marble Maps.

What excites me most about Marble currently is the on-going work on vector tile rendering, which will allow many new or improved features. See here for a sneak-peak some current WIP state when it comes navigating yourself around Trafalgar Square in London with Marble Maps for SailfishOS, partially rendered in-device from vectors already (you can spot the pixel-based tiles still used as base layer) :
Trafalgar Square in London rendered from Vector tiles in Marble Maps on SailfishOS

Marble, it is a wonderful toy not only for the kid in the developer πŸ™‚ Get involved, either by making use of the Marble lib and plugins in your own app (and follow e.g. Subsurface and Digikam) or contribute directly to Marble’s own apps, lib and plugins.
To experience the wide set of possibilities with Marble, install the Marble desktop app (which IMHO should be renamed Marble Gallery πŸ™‚ ) and walk through all the features, e.g. different sky objects as central globe, satellite display, time-lapses through sun or moon ellipses, interactive routing, or map editing. All waiting for you to compile your own special use-case app from them. Like happened with the Behaim globe app for Android.

Support us

The Randa Meetings and other sprints bring our software forward, and also to more people and more platforms. Please check out the fundraiser for the Randa Meetings, and consider to do your little contribution to get things going:

Marble Maps forking for SailfishOS

Marble, the swiss army knife for maps and globes, developed in the KDE community, this year has got an app variant added that is concentrating on maps and that is designed for today’s typical mobile devices with touch UI, called Marble Maps. It currently is in Beta state. Read “Announcing Marble Maps for Android Open Beta” for more info.

At this year’s Randa meeting for a few days I joined the people working on having KDE software run on Android. After all there are gazillions of such systems out there, and it only makes sense to have existing FLOS software, such as KDE ones, also run there, as a matter of dealing with realities. With the developers of Marble, KAlgebra and GCompris around, some experience could be shared, and I compiled what I learned into a small Hello KWorld example.

As a Marble fanboy, Marble Maps was my obvious toy project here when learning more about building Qt5-based software for Android. I had no Android device available, but a Jolla phone with SailfishOS. That one also has support for running Android apps, so I still could use it to test my self-built Marble Maps Android packages.

Now, it felt strange to run a Qt5-based application via Android emulation layer on an OS like SailfishOS which itself is using Qt5 and then some usual “Linux” software stack/middleware. Should it not simply run directly there?

So last week finally I gave it a try to build and to run Marble Maps natively on SailfishOS. And was presented with a problem: SailfishOS in the latest version is (still) at Qt 5.2 (with QML upgraded to 5.3 it seems) and, more important, has no QtQuick Controls. Which are used in Marble Maps for all controls. At least all the Marble C++ code was building fine after 2 small fixes, so that part was looking promising.

An option might have been to build a custom version of QtQuick Controls. But that somehow smelled like problems waiting. And I also was tempted to try to do some native UX to gather more experience with QtQuick and the SailfishOS ideas. So I forked the Marble Maps code and started to write a SailfishOS variant, using its Silica UI components. The code for Marble Maps is mainly the UI layer one, written in QML, with the actual business logic nicely in the shared Marble libs and components, so it is not that much logic which is duplicated here. Still it is not “Write once and run everywhere”. It’s up for discussion how much native multi-platform apps should go. For now I will play more with it.

Right now Marble Maps for SailfishOS almost has all current features of the “normal” Marble Maps implemented, modulo some small bugs:

Marble Maps on SailfishOS: Editing a route Marble Maps on SailfishOS: Adding a new point to a route

These days sadly many people hearing “marble” and “sailfishos” might rather think of “tombstone”, bad timing here. But until that OS is pushing up the water lilies I will play more with it, after all I can use the code on a working device of mine.

If you want to use the code on a device of yours, find first RPMs on and the code in branch “sfos” in my Marble repo clone clones/marble/kossebau/marble on the KDE git servers, see src/apps/marble-maps-sailfishos/ for the app code. Once it’s stable enough the code will be proposed for inclusion in the official Marble repo.
(Update: when installing the RPM on the Jolla phone, make sure you have “qt5-qtscript” installed, pkcon install qt5-qtscript in the terminal should get you there.)

Also looking forward to see the “normal” Marble Maps and other Marble-based apps soon on Plasma Mobile hopefully.
And anyone looking into an Ubuntu Touch version? Would that work with stock Marble Maps, thanks to QtQuick Controls, or would more native UX be needed there as well?

Thumbnails & previews for your Geo Data files (KML, GPX, OSM, …)

Almost two years ago (uh, already?) I went to Prague for a developer sprint of the team of Marble, the virtual globe and world atlas. My goal was to work on a proper maps shape plugin for Calligra.

We are ready to render, or? … Or?

Just, it showed that Marble at that time was not properly supporting the needs such a plugin has. Biggest showstopper was that Marble did not expose the information if and when all external data needed for rendering was available. Think e.g. of map pieces (so called tiles) still having to be downloaded from a server like OpenStreetMap‘s one. Not knowing the state is not good e.g. if a document with a map is to be rendered to a real printer.

Telling the File Manager some more about Marble and Geo Data Files

At that sprint then I worked instead on making sure that there are proper mime-types registered for the types of geo data files that Marble can read and display (like OSM data files, ESRI shapefiles and GPX files). So that such files are nicely displayed in the file manager with matching icon & type description and can get Marble assigned as handler. And:

Next step is to finish the thumbnail plugin, so one can also have nice previews of the content of these filetypes.

The thumbnailer was started in the train back from Prague, but Dresden was arrived before it was properly working. Then… the code went out of focus and mind, that step frozen in the middle of the air…

Getting ready to render!

These days, Calligra still has no maps shape plugin. Now and then I nag^Wbeg the Marble developers for the issue (how lame, indeed), as there are other interesting use cases for rendering of map stills, like:

  • Creating a jigsaw puzzle for Palapeli, the jigsaw puzzle gaming program
  • Creating an animation for a movie in Kdenlive, the video editor
  • Yes, even creating the thumbnails for geo data files, if not using the simple installed map theme

Last week luckily earthwings found some personal interest to draft code for renderer state. Time to add a bit of momentum, by reviving the thumbnailer code, to serve as a use case. Still found in its old place, after some bit-rot cleanup and finally solving the problems of last time (different mindset, and things seem so obvious) it works now good enough for serious usage:

Thumbnails for Geo Data files
Thumbnails for Geo Data files

Some things need some more thinking (which map theme to use when, how to properly detect the sky object the data is for, how to deal with thumbnail generation in offline-state), but it’s a good first complete step πŸ™‚ It does not yet use the new render state feature, but should be soon.

So look forward to Marble 1.9, bringing previews for geo data files to your filemanager and in the file dialogs! (And do not forget to enable them in Dolphin > Settings > Configure Dolphin… > General > Previews, disabled for all types by default).

And perhaps, perhaps, one day we finally also will have a maps shape plugin for Calligra…

BTW, if you want to help development of Marble, other KDE Edu projects and more, consider to donate for enabling the Randa Meetings 2014. Every little amount will help, as it sums up. Best do it now! πŸ™‚

Sculpting Marble in Prague

The Golden October should be a matching time to go to the City of Gold, Prague. That, it seems, thought the organizers of the OpenSUSE Conference 2012. And that also thought the developers of Marble, the virtual globe and map program/lib, who happily used the possibility to be hosted there.

And golden it was, the October, at least on friday, when the air was clear, the leaves mostly still at the trees, in all colors, and the pairs of shoes still on the line, off all kinds:

Saturday and Sunday then Prague turned into the City of Fog, especially dense at nights, perfect to stay inside to talk about how to make Marble even more awesome.

I initially went there to mainly talk and learn about how to use the Marble lib to resurrect in a proper way the Map shape for Calligra, the office, graphics and management suite. Like how to get the data used for the current view exported from the Marble lib to store it into the document, to be able to display the map without being connected to the internet, e.g. in a presentation. Or how to get rendering done in case of printing, where there is no way to simply update the view when the missing data arrives from the server and where all time-based layers (think satellites) should render for the exact same time setting. The latter might also be needed for a possible plugin for Kdenlive, the video editor, where you could render transitions between places with Marble lib, like e.g. for a short movie about your last vacation trip.

These needs were discussed to some detail, and it turned out that there is quite some work still needed to satisfy them. But any efforts in this direction are very welcome by the Marble developers, as they are in general pretty open to support all kind of usages of the Marble libs. Which for other use-cases is quite easy, as can be seen in the impressive presentation by Marble routing master Dennis NienhΓΌser showing how his students use the Marble libs in research projects.

Being a little bit disappointed I picked up some other little tasks that turned up in the discussions, like registering Marble as handler for OSM data files, ESRI shapefiles and GPX files, as otherwise most people might miss that Marble can read and display them. This also meant making these file types known to the mimetype database at all, so both a proper name for the file type and a nice icon are shown in the file manager/dialog (shapefiles being a little troublesome here, as they are split into multiple files, where some are hard to catch by magic rules, but at least the main file .shp is):

Opening these files in Marble is now just a single click away.

Next step is to finish the thumbnail plugin, so one can also have nice previews of the content of these filetypes. And then some more things. One day even the Map shape for Calligra hopefully πŸ™‚

It was a very good weekend, I am glad I could be there and meet almost all of the Marble developers (which to some degree I am now one as well, if only by my own copy of the Marble t-shirts Torsten handed out as present to his fellow developers).
And Prague is still an extremely beautiful city, also when with a foggy dress.

Thanks to OpenSUSE for hosting us there, and thanks to the supporters of KDE e.V. to enabling them to sponsor the Marble Weekend 2012!

Thanks for your help on writing geographic coordinates in $YOUR language

A few days ago I asked for help how to design the parser used in Marble to try to turn a text string into some geographical coordinates in such a way that it also can parse localized writings of such coordinates.

For those curious what came out of this, read on:

While I then forgot to mention the use-cases I was thinking of, like copying&pasting some pretty-printed string from some text, or entering the coordinates somebody tells you on the phone, still the broad feedback I got, both by those commenting on the blog post as well as those replying on the mailinglist of KDE’s translators (thanks to all of you), helped to accumulate quite some testing data, on which based the parser could be designed.

Well, it was done in a short rush, just in time for the translation soft freeze for the upcoming release of KDE Apps 4.8, but non-the-less can parse all of the testing data πŸ™‚ Which means basically the parser can parse coordinates in these patterns, for all languages:

  • with latitude or longitude given as first
  • with directions given as prefix or postfix
  • with values given just as pure degree, as degree and minutes, or as degree, minutes and seconds
  • the last subvalue can optionally be in floating point precision
  • the first subvalue can be negative or positive, optionally with the + prefix
  • latitude and longitude can be separated by the “,” or the “;” character or simply white space
  • symbols for degree, minutes and seconds can be given or left out, if directions are given

The parser first tries to parse using the localized direction terms, than falls back to try the English ones. For the degree, minutes and seconds symbols it is quite tolerant, tries to understand all kind of character (combinations) people might try to express the symbols, using what their keyboard layout offers. Basic rule: if a human would get what is meant, so should the parser (e.g. two consecutive LEFT SINGLE QUOTATION MARKs β€˜β€˜ would be accepted as seconds symbol). Additionally accepted would the localized variant of the symbol, like obviously typically found in non-latin based languages.

Additionally, for a very short notation, two pure floating point values, separated as described above, are parsed as first latitude degree and second longitude degree.

So also the Shorthand DMS notation, as hinted to by Kjetil Kilhavn, should be parsed without a problem. (Support for UTM is only worked on in Marble, no promises on when this might emerge)

For parsing of localized strings to work, the translators are asked to provide in the translation catalogs the information about additional local symbols for the degree, minutes and seconds, as well as how the directions are written. Per direction and symbol there can be multiple variants noted, so languages with variants of the direction terms are also covered. There is a short guideline for the translators, also linked from the strings in the code.

But things are not perfect yet:
only today I learned that Thai has a pattern which is not matching any of those described above, in that it also uses prefixes “longitude” and resp. “langitude” (in Thai) before those parts. Which is also the same pattern as with a sample I got for Icelandic, but I somehow had ignored that, only now found that entry marked as TODO.

So there are things left to do for the Marble version after the upcoming one. But then we all know, software is never finished πŸ™‚

Perhaps the geographic coordinates localisation should also be added/moved to the general regional system settings, like Date & Time are, as coordinates become more and more used, due to mobile devices. So all programs dealing with coordinates would benefit and also be consistent (think KStars or Digikam).