There are two main disadvantages when using a QTabBar here: Only one of its widgets can be visible at a time, and switching between the widgets in the tabs involves much mouse moving from top to bottom and the other way round (have a look at the tab positions in the screenshot).

To improve things we now introduced a new layout based on QDockWidgets. Its initial view resembles the old look and feel with a sidebar on the left, but shows two widgets at one time:

Dock widgets alone are not enough of course; the screenshot above also shows many further improvements. The Map View makes better use of the available space using smaller icons, showing the name and description to the right and indicating whether map themes are favorite ones using small overlays. Controls to choose the projection (sphere vs. flat map) and celestial body (planet) are condensed into a toolbar unless there is more space available to expand them. The old Navigation tab is gone in favor of a new map overlay visible in the bottom right. It’s also the first overlay to receive a modernized styling. The search results previously also shown in the navigation tab have moved to the new search dock which also integrates the search field previously found in the main toolbar. The latter is disabled again to leave more space for the map and dock widgets.

A big advantage of dock widgets (in combination with QMainWindow) is their configurability by drag and drop. Wide aspect ratios like 16:9 are used for many monitors now, which results in a good opportunity to create a right sidebar by dragging the dock widgets you’d like to see elsewhere to the right window border:

On closer look you’ll find that the routing dock has received a small facelift as well. The input fields for via points now integrate the drop down button previously found to their left. Actions working on the route previously found in various push buttons are now grouped in a toolbar.

It’s very easy now to assemble a new layout that shows all the controls you need in a certain situation. All features shown in the screenshots here are available in the Qt version of Marble in the master branch and will become part of Marble 1.6 / KDE 4.11. Feel free to give it a try. Please note that only the Qt version bin/marble-qt has implemented the changes at this time; the KDE version bin/marble will follow shortly.

Popular star constellations — patterns in prominent stars within apparent proximity on Earth’s night sky — are now rendered by the extended stars plugin. Realized with much love for detail, Marble’s view of Earth from outer space is now more stunning than ever. See for yourself (yellow bubbles are manual annotations):

The screenshot also shows the new Earth at Night map theme which will replace the existing one. It features updated images with higher resolution. Further map themes have been completed or are in the works, among them Jupiter moons and historic map themes. To help you give proper attribution for derivative works, a new info box in the bottom right corner shows license information for the current map theme. Like all info boxes it can be disabled if needed.

Another main working area is KML support. While the most important KML elements are long supported, we are aiming for full KML 2.2 compliance in a future version. Towards this goal support for reading, writing and using more KML elements has been implemented. Among the new features is support for random color mode, reading and rendering screen overlays, reading balloon and list styles, rendering of remote images and writing of polygons, photo overlays, ground overlays and time spans. While preparing support for balloon style in placemark rendering the new webpopup plugin (annotated as map info dialog with webkit support in the screenshot below) was born. Given its nice look and generic applicability we’re currently replacing many QDialog based dialogs with it.

Much more has been realized in the last weeks and the above is just an incomplete high-level overview. Most of the features mentioned above are already merged into the master branch (to be part of Marble 1.6 / KDE 4.11). Some map themes will be deployed via GHNS and therefore be available in all KDE versions of Marble soon (File => Download Maps).

Google Code-in is still running for some weeks and we have a set of open tasks for volunteers to take. Check out Melange and search for Marble tasks (with KDE as organization) to see them. The marble.kde.org website has a lot of information to get started as well.

Do a usability overhaul for the measure tool: Improve the contrast to the various map backgrounds with the help of semi-transparent backgrounds, use alternating colors for neighboring line segments and show intermediate distances.
The mockup animation on the right shows the current measure tool and a possible improved version. Adjusting the line segment colors and improving the contrast of the vertices will be quite straightforward. Calculating suitable positions to draw the distance labels for each line segment will is more of a challenge.

Finding patterns in prominent stars within apparent proximity on Earth’s night sky is a human tradition dating back as far as the Neolithic Age. Marble already shows prominent stars — now teach it which to connect to form popular constellations!

To realize this, you first have to read and understand the current stars plugin. Fortunately the plugin is implemented in the brevity of 200 lines of code and Torsten is there to explain it. Afterwards you need to research common constellations, get their data, match it to the existing stars (or replace them), extend the file format and finally render the constellations. Implementing this will be awesome fun!

Carry back your mind to Venice at the start of modern history. Battista Agnese created a worldmap in 1544 which is still available today — help adding it to Marble’s collection of historic maps to make it available to an even larger audience! Creating map themes from images of historic maps involves much image processing. Depending on the projection of the original map, different tools are used. We have a Techbase Wiki page dedicated to that topic to get you started.

There are a lot of other tasks than those three: More  historic map themes and a couple of tasks related to quality assurance and extensions of Marble’s KML support.

Of course it’s also possible to contribute outside of Google Code-in: See our working areas. Those into social stuff can also follow us on Google+. We keep a nice stream of Marble news and media there.

Besides having a modern look, the new website integrates a lot of new content, for example information on the current KML support and a nice tool to generate .kml files from OpenStreetMap data.

Give it a try at marble.kde.org!

Why does Marble not support Google Maps?

From a technical point of view the answer is simple: Marble does support it (since a few years already). For educational purposes only some examples: If you would clone the googlesat map theme to ~/.local/share/marble/maps/earth/googlesat then a Google Satellite map theme would appear in Marble. And if you would clone the googlemaps repository to ~/.local/share/marble/maps/earth/googlemaps you’d have the vector based Google maps appear.

Now where’s the catch? Legal reasons prevent us from shipping them and also prevent you from using them. Here is an incomplete list of excerpts from the Google Maps/Google Earth APIs Terms of Service that are problematic for their use in Marble (and similarly a lot of other applications which simply seem to ignore that):

• 8.5 Proprietary Rights Notices, 9.3 End User Terms and Privacy Policy as well as 9.4 Attribution. We’d have to add a bunch of copyright notices which are not yet implemented (though we plan to add those)
• 10.1.1 (g) No Use of Content without a Google Map. One of the killer arguments: We cannot retrieve e.g. a route and display it on the OSM map, or use a reverse geocoding result from Google in a non-Google route result.
• 10.1.1 (h) No Use of Static Maps API(s) outside a Web-Based Application. This one is debatable. Marble is not a web-based application, yet we’re not exactly using the static maps API.
• 10.1.3 (b) No Pre-Fetching, Caching, or Storage of Content. Sorry, that’s one of the great features of Marble which we’re not going to restrict artificially.
• 10.1.3 (c) No Mass Downloads or Bulk Feeds of Content. See above.
• 10.2 (a) No “Wrapping.” The biggest part of Marble is a library intended to be used by various applications. It would wrap the Google services we would use (e.g. map display, routing, reverse geocoding)
• 10.2 (c) No Navigation, Autonomous Vehicle Control, or Enterprise Applications. Another killer argument against using Google services. Marble does real time navigation, route guidance and turn-by-turn route guidance.

Some people argue that a lot of existing applications do not comply with those terms of service without getting into any problem. But seriously… that’s not an argument.

Bottom line is that unless Google changes those terms of service, we’re not going to integrate them in Marble. Fortunately OpenStreetMap provides a great alternative to Google’s services and is nicely integrated in Marble already. Just like many more map themes that are not shipped by default for space or legal reasons. Many of the former ones can be installed from within Marble however: Just use File => Download Maps to install additional map themes.

Recording screencasts and post-processing them for publishing on sites like YouTube or as HTML5 videos was a tedious and error-prone task for me up until some months ago: Recording software like recordMyDesktop, istanbul or xvidcap didn’t produce good results, if working at all. Video editors like avidemux, cinelerra, kdenlive or kino were lacking important features, had a cumbersome user interface or crashed in the twinkling of an eye.

Fortunately things changed when I discovered that ffmpeg works great for taking raw screencasts and when kdenlive 0.8.2 was released. Kdenlive had always been a promising application: A solid set of features, more than I probably ever need, arranged in a convenient user interface. Yet I was never able to accomplish even the simplest task with it in earlier versions — it almost certainly crashed somewhere in between. This behavior has changed significantly in recent versions – I’ve produced a bunch of videos with it now without a single crash. And from what you can read in the web, this seems to be a common observation. Good work, kdenlive developers!

In the remainder I’ll describe my workflow for producing screencasts for upload to YouTube. It can easily be adjusted for other sites like blip.tv, vimeo or HTML5 videos.

Prerequisites

Please install ffmpeg – any version should be fine and your distribution surely has packages for it. Also install kdenlive, but take care to get version 0.8.2.1 or later. It’s available in Ubuntu 12.04 Precise (universe) or Debian testing for example.

Recording Raw Screencasts

I’ll assume you’re going to record a screencast of a specific application window. Usually you’re able to resize that and it makes much sense to optimize its size for the end presentation. Best results for YouTube are achieved with an aspect ratio of 16:9. Corresponding video sizes are shown in the following table (second column):

Now change the size of the window to record to your favorite size from the table above. One good way to achieve that is to use KWin (right-click on the window title, Advanced, Special Window Settings, Size & Position). You also need to know/change the position of the window. Again, KWin comes in handy:

Remember (or note down) the values and apply the settings. Afterwards it’s time to start recording the screencast.

ffmpeg -f x11grab -show_region 1 -y -r 25 -s 1280x720 -i :0.0+100,200 -vcodec ffv1 screencast.avi

Let’s review all the parameters briefly.

-f x11grab

-show_region 1

-y

-r 25

-s 1280x720

-i :0.0+100,200

-vcodec ffv1

Change the parameters as needed (you probably have to change 1280×720 and 100,200 and can leave the rest as is) and start ffmpeg. It will start recording the screencast immediately. To stop recording, hit Ctrl+C in the shell where ffmpeg is running. The raw screencast will be called screencast.avi and can be viewed with e.g. mplayer.

Possibly you have to repeat this step several times to find optimal settings. If the video stutters, record to a faster drive, use a smaller video size or lower the framerate. Don’t use a framerate lower than 25 though. If the video stutters because your hard drive is too slow and you don’t have a faster one, you can also try to use a different codec than ffv1. Try

ffmpeg -f x11grab -show_region 1 -y -r 25 -s 1280x720 -i :0.0+100,200 -b 8000000 screencast.webm

Post-processing for Publishing

A huge topic on its own, so I don’t really want to start writing much here, but just leave a couple of recommendations:

• If you recorded to .webm above, you can upload the video directly to YouTube
• If you recorded to .avi with ffv1 codec or if you want to add some background music, effects, title clip etc, I strongly recommend giving kdenlive a try.
• If you recorded to .avi with ffv1 codec and don’t want to use kdenlive for some reason, you can convert it using ffmpeg on the command line:

  ffmpeg -i screencast.avi -b 8000000 screencast.webm

  The value for -b should correspond to the bitrate in the table above, here 8000000 = 8000 kbps. Now upload screencast.webm.

• If you’re looking for some background music, jamendo.com is worth a try.

Wondering why this appears on planet KDE? The answer is simple: I want to see more screencasts here! (GSoC/SoK students, I’m looking at you!)

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).

Last week I packaged Marble Touch 1.3.3 for the Nokia N9/N950 and submitted it to the Ovi store. It’ll appear there in the next days. Compared to 1.3.2 there are the usual bugfixes and smaller improvements, but also new features — most prominently support for bookmarks.

In retrospect, I’m pretty satisfied with the choice to base its development on Qt Components. While I still have a lot of ideas for improving and extending it, the plan for world domination now wants me to shift attention towards a different, yet similar topic: Bringing Marble Touch to Plasma Active. Fortunately the Plasma guys were clever enough to develop the Plasma Components with a very similar API, so the initial port was an easy task for this rainy weekend. Marble Touch in master now supports both Qt Components and Plasma Components. It’s not polished yet, font and icon sizes need to be adjusted and most dialogs don’t play well yet, but the core functionality is all there and works happily. I even tested it on Kubuntu Active in a virtual machine.

One of the reasons I worked on this now is to set a solid base for Utku (you may remember him as the author of Marble’s earthquake and opendesktop plugins as well as the map creation wizard) to join me in his Season of KDE project. Great news! I’m sure we’ll have a nicely polished, end-user ready Marble Touch for Plasma Active at the end of the summer

With the technical and organizational stuff mostly covered it’s back to brainstorming: What use cases do we want to cover on tablets? Routing and navigation are fundamental ones on smartphones. They’re also important on tablets, yet their larger screen and different usage patterns (couch mode, second screen) enable further use cases. So the second part of our motto — “find your way and explore the world” — becomes more important. I’m thinking of showing more details about places (photos, weather, user content) arranged in a convenient way. Furthermore owncloud integration would be lovely to easily share/synchronize your bookmarks, routes and photos across devices. What would you like to see?

Something missing in the picture? community.kde.org/GSoC is the place to go both for prospective students and mentors. Please spread the word!

Don’t miss our nice Marble project ideas :-)