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:

Randa Meetings 2016 Part I: Okteta

Last Sunday the full week of Randa Meetings 2016 had passed, and it was time to find a route home, e.g. using KDE’s currently developed Marble Maps (here in the SailfishOS variant):
Planning the route home from Randa with Marble Maps on SailfishOS

Home, that would be for a place somewhere on our planet, like Africa, Asia, Europe, North America, or South America, where the 40-50 people who had got together that week had come from. They came into the Swiss Alps, traveling through space (not sure if also time, but at least quite many for quite some time) to collaborate in a valley deep between mountains covered by glaciers. To collaborate on bringing more of the set of applications developed in the KDE community also to other, even non-libre operating systems.

Getting Dirty With Other Operating Systems

The KDE community these days creates a large set of applications, and many of these are not bound to the one workspace for unixoid operating systems created by KDE, which is Plasma. No, these applications also run more or less fine in other (unixoid) workspaces, thanks to all the shared specifications of the freedesktop.org movement and other shared stacks/technologies (like D-Bus, X11 & soon Wayland).

Unixoid operating systems, that does not only mean Linux, but also all the BSD derivats. Sadly the *BSD subcommunity in KDE had become quite inactive the last years. So it was good to see that with Adriaan some *BSD veteran reactivated himself and is now working hard to get current versions of KDE applications and also Plasma to first class positions in the official software supply system. Next to that he also showed his real-world server acting abilities, as kitchen demon for Saturday, to everybody’s pleasure.

While now the big majority of KDE developers develop their applications with FLOSS unixoid workspaces/operating systems in mind, they often also find themselves and their target groups being bound to devices controlled by non-libre operating systems, due to some key apps or infrastructure in work or other parts of life only available with those. Operating systems like Microsoft’s Windows or Apple’s OSX/macOS. Still, people needing to use these devices can liberate themselves a little by at least using FLOSS applications on them. Like Firefox as their Web browser, in place of the non-libre Internet Explorer or the non-libre Safari.

As almost all current KDE applications are based on the cross-platform library Qt and the cross-platform build system tool CMake, which include support for the platforms Windows, OSX, the extra development work needed to get KDE applications running also on those platforms should be relatively small. And indeed since many years some people have been doing that needed extra work, with more or less success (see wiki pages on Windows and Mac). And since using Qt5 work has started to also extend this for Android.

Still there are many things that need more work to create serious products on release day for the average enduser. From documentation for application developers what to care for, integration into the KDE CI with platform specific builds, organized pre-release testing of packages, to providing the software products to end-users via proper distribution channels. All these are areas which had been talked about and worked on during this year’s Randa Meetings (see also Kevin’s post with a KDE on Windows status update).

Okteta on Windows: built out of the source box

Already when Okteta was started many years ago, using CMake, Qt4 & kdelibs4 made it possible to have builds of Okteta for Windows (XP) and OSX done by mainly pointing some generic build and packaging scripts at its source code, as shown with Okteta 0.1 in 2008.

Today, with CMake, ECM, Qt5, KF5, it is still the same. When asking for a Windows build, just to see what the state is, it again was just a matter of pointing the generic scripts at the sources, and there was Okteta 0.19 running on Windows 10 (thanks Kevin for builds and screenshot):
Okteta 0.19 on Windows 10

One nice sideeffect of cross-testing on different platforms is that forgotten issues get into the spotlight again, like visible in the screenshot:

  • Accelerator syntax shown verbatim in docker widget title bars: KAcceleratorManager from the KWidgetAddons module needs to get an idea how to properly handle QDockWidgets
  • Bad initial size of window and set of initially shown dockers: the current hack to work-around improper API control in Qt needs adaption to Qt5 and perhaps also other platforms

Running the unit tests showed a few issues, half of them due to not using platform-neutral access to the filesystem (quickly fixed), the other half because of tricks with XDG env vars which need some platform-neutral solution (still to be solved). As a result Okteta’s source code will be more clean, which is also a win for the version for the libre operating systems.

So if somebody would want Okteta on Windows (I had a few people asking for that by the years) and/or OSX, you are welcome to help out in the packaging and testing area. I myself do not have any of those operating systems and also would not invest into that, given my own priorities. Still happy to work together.

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:

Notes on other activites of mine at Randa Meetings 2016 in a following post.