Tuesday, September 6, 2022

Maps goes four

 Just in time for the GNOME 43 release (the hard code freeze started this past weekend) the porting of Maps to GTK 4, using our new libshumate map rendering library has arrived at a working status

Earlier in the summer it became apparent that maintaining Maps using the technologies (GTK 3 and libchamplain) would became troublesome in GNOME 43, since other dependencies (such as libgweather and geocode-glib) was being ported to use the libsoup version 3 API/ABI (libsoup is the HTTP library used in the GNOME software stack). And libchamplain is still on libsoup 2.x (Corentin Noël prepared a merge request porting libchamplain to libsoup 3, but especially if we would support parallel-installable version of it using either libsoup API would mean extra work on a library, using the deprecated Clutter technology, which we probably would best avoid).

 So I took the decision to try and take the chances at racing the clock finishing the GTK4 port before September…

I decided to make it as a two-step rocket. First finishing porting to GTK4 and libshumate while still depending on libsoup 2 (building all the dependencies bundled locally in the development Flatpak manifest using libsoup2 build flags).

And then at the second stage switch over to using libsoup 3 (this mean also start using a newer version of the librest library that we use when accessing the OpenStreetMap API for editing POIs).

We only overhot the deadline for making UI changes before the release by a few days, but did get an exception from the release team (and a “blanket” exception for making smaller follow-up fixes up until the last RC before the release).

At this point I also found out that the latest librest has dropped support for OAuth 1…

So as a last push I had to migrate the OSM authentication to use OAuth 2. Which is something I have been intending to get done anyway eventually, as the use of OAuth 1 is discouraged as it has flaws…

Christopher Davis has also stepped up and helped out “evening out” some sharp edges after the initial GTK4 port (including using the libadwaita about dialog as shown above).

The layers menu has also gotten a bit of refresh to fit in better with newer styles used by GNOME core apps.

And the search results popover follows the new style without the “beak” pointing to the entry, as other content-completing widgets use nowadays.

There are still some rough edges when it comes to the place “info bubbles”.

The margins are a bit excessive and the bubbles don't always resize vertically as much as would be desired to avoid scrolling to see the Wikipedia summary as in this case. Also the thumbnail isn't flush on the edge as it was with GTK3, there's something missing with that custom CSS, or something like that…

There's also some GTK warning printed out on the console (which you would see when running from GNOME Builder…).

On the positive note, now we get the drop shadow beneath the bubble. Previously when using Clutter we didn't get that due to reasons down to how Clutter stages where emedded into GTK widgets).

The ”Export to image“ dialog (maybe the term is a bit weird, but renaming it to something better like “Save as image” would have to wait as the string freeze is affect now…) did (at least for the time being) loose the ability to “filter out” markers. Also the sizing of the preview thumbnail could use some tweaking. In fact this whole dialog would probably benefit from a rehaul, but that would have to be for some other day…

On the other hand on a positive note we now finally get the license information down in the corner “etched into“ the image when saving, something that never worked before and is probably a breach of OpenStreetMap's license if you put things to its edge.

Some other points worth noting is that the pinch gesture for zooming on touch screens and using touch pads now finally works in a decent way (it kinda worked with libchamplain, but without any intermediate feedback while the gesture is being performed, so it was always a bit of hit-and-miss in the blind. This is in part thanks to the support of fractional zoom levels in libshumate.

Speaking of which the fractional zoom level support will even more come to its right one day when we start using vector tiles with local rendering. As then labels will be able to stay sharp at all levels. Right now with raster tiles the non-integer levels gets a bit blurry. But zoom with the keyboard shortcuts, or using the zoom buttons goes in integer steps (but still with animation).

And one last thing, the map background context menu can finally be opened with long-press on touch.

And I would also like to once again shout out to, in particular James Westman and Corentin Noël for their amazing work on libshumate. Without which, nothing of this would have been possible.

Anyways, now I will try to take some rest for a while 😎

Until next time, stay safe!

Wednesday, June 29, 2022

Summer Maps

 So, as tradition has it here's the (Northern Hemisphere) summer blog post about GNOME Maps.

One large under-the-hood change I've made in Maps since last time is migrating the JS code to use ES6 modules.

So, using “import” instead of referring modules as objects from the old-school global “imports” object in GJS.

When using GI modules to access introspectable GObject-based libraries it means something like

const GLib = imports.gi.GLib;

let var = new GLib.SomeClassFromGLib();


import GLib from 'gi://GLib';

let var = new GLib.SomeClassFromGLib();


Here the URI scheme gi:// referres to the GObject introspectable libraries as seen in runtime in the managed code (in this case JS).

When using our own classes locally defined in JS, we can refer to resources found inside the program's GResource, so something that was before

const MapMarker = imports.mapMarker;

let marker = new MapMarker.Marker(...);


import {MapMarker} from './mapMarker.js';

let marker = new MapMarker(...);

Here we import then class definition directly into the local namespace (this could have been done before as well with the old “imports“ object, using

const MapMarker = imports.mapMarker.MapMarker;

but this was something we never did before, but now I've decided to go this path. Took some style guidance from Weather, which had already done this switch before.

These classes are now in turn defined in their sources as exportable

export class SomeClass extends GObject {...

rather than just being declared as “var” on the top level scope in the modules as before

var SomeClass = class SomeClass extends GObject {...

This makes it also clearer what is visible outside a module, so this works much like “public“ in Java, C#, and Vala for example.

For our utility modules containing non-class functions, typically wildcard imports are now used

 import * as Utils from './utils.js';

Functions in this modules that should be used from outside are defined with “export“ just like classes in the above example.

Now the utility function can be access just like it would have been in the cases before the change (when assigning the object from the “imports” global object to a local const variable as



There has also been some changes on the surface. Sten Smoller has contributed the missing “keep left” and “keep right” instruction icons for turn-by-turn-based navigation, so there are no missing icons in route instructions


Also over in libshumate James Westman has done some good improvements the in-progress vector-tile renderer that he has covered in an excellent blog post


And speaking of libshumate and GTK 4, recently the GWeather library has switched to be built by default using the libsoup (the GObject HTTP library) 3 API/ABI, and still uses the same library ABI version.

As our old libchamplain renderer makes use of the libsoup version 2 ABI we have kinda hit a bit of a wall here.

For our Flatpak builds we could still build the necessary dependencies with libsoup 2 build flags, and bundle them. But as this is not feasible for traditional packages (and it won't work for the GNOME OS builds) we pretty much have to make a go at migrating to GTK 4 and libshumate for GNOME 43 in September.

It will probably be a bit of a tight fit to finish it, but wish us luck!


Oh, and I couldn't resist adding a little special “summer feature”.

Quite a long time ago Andreas Nilsson designed a cute little steam locomotive icon for use in public transit itineraries for tourist railways.

I decided to include this icon now. But as none of the providers we currently support has this distinction I decided to put in a little hard-coding in the plugin for the Swedish Resrobot plugin to use this icon (or rather override the route type so that the icon gets used) for a couple selected agencies.

So that you for example gets this icon for journey's hauled by Lennakatten's locomotive Thor

 Until next time, happy summer! 😎

Friday, May 13, 2022

Maps Spring Cleaning

Thought it was time to share some news on Maps again.

After the 42.0 release I have been putting down some time to do some spring cleaning in Maps to slim down a little bit on the code.

This would also mean less stuff to care about later on when porting to GTK4.

First we have the “no network” view.

We used to use the network monitor functionality from GIO to determine if the machine has a usable connection able to reach  the public internet to avoid showing incomplete map tile data (where some parts might be cached from earlier, while others are missing).

Unfortunately there has been some issues with some setups not playing well NetworkManager (such as some third-party VPN software). So we have had several bug reports around this over the years.

At one point we even added a CLI option to bypass network checking as a sort of “workaround”. But now we decided to remove this (and along with some widgetry), and just rely on the user having a useful connection. The search and route functionality should still behave well and show error messages they were unable to read from the connections.

 Moreover, we dropped the dependency on GOA (gnome-online-accounts), and the remaining support for user check-in using Foursquare, as this has been pretty flaky (possibly due to quota issues, or something like that. Facebook support has been removed already since a few releases (and prior to that logging in to Facebook using GOA hasn't been working for many years). 

Next thing is the process for signing up with an OpenStreetMap account for editing points-of-interest.

Previously we had an implementation (which by the way was my first large contribution to Maps back in 2015) which was based on a literal translation for Java to JS of the “signpost” library used by JOSM which basically “programmatically runs” the HTML forms for requesting access to an OAuth access token when signing in with the supplied user name and password. It then presents the verification code using a WebKit web view.

This has a few problems: It involves handling passwords inside the stand-alone application, which goes against best practices for OAuth. Furthermore it implies a dependency on WebKitGTK (the GTK WebKit wrapper), which is yet another dependency that needs porting to GTK4.

So now with the new implementation we “divert” off to the user's default browser presenting them with logging in (or, if they're already logged in to OSM in the browser session (cookies) they will directly be prompted to grant access to the “GNOME Maps” application without giving credentials again. This implementation is pretty similar to how Cawbird handles signing in to Twitter.

There is also some new visual updates.

The search results now has icons for additional place types, such as fast food joints, theaters, dog parks, drink shops. I did some scouting around in the GNOME icon library 😄

Also, as a continuation of one of the last features added for 42.0, where Maps remembers if the scale stock was shown or hidden last you ran Maps when starting again. I realized the feature hiding the scale is a bit hidden (you need to look for it in the keyboard shorts menu), and also it is not possible to access on a touch-only device (such as on the Pine phone). So I added a checkbox for it under the layers menu (where I think it fits in).

 And that's about it for this time.

Next time, I think there will be some more under-the-hood changes.

Friday, March 11, 2022

Maps and GNOME 42


The release of GNOME 42 (and the Maps release accomplishing it) is due in a little over a week.

I have already covered some of the more visible updates for Maps 42.0 in the last update, such as the development profile (allowing to run directly from GNOME Builder, or install “nightly” Flatpak builds, and be able to run them in parallel with a stable release (distinguished by it's icon overlay and headerbar styling).

 Also we have the support for handling the maps: URI scheme, allowing to open search queries from other programs. This feature will already be utilized by GNOME Contacts for opening locations of contacts in your address book when they have a physical address set.

Some of the last changes involves utilizing the “tabular numbers” Pango font feature attribute, to get the time labels to align up vertically (even when the system font has variable-width digits) when rendering public transit itineraries.

Also, we have revised screenshots prepared by Sofie Herold, linked in the “appdata“ metadata to show in software centers like GNOME Software.

Another small attention to detail that I included pretty late, is that now the state of showing the scale (which can be toggled with the ctrl+s shortcut) is now stored in gsettings and remembered between runs (rather than always showing when you start next time, if you choose to hide it).

Unfortunalty, I totally forgot that adding new gsettings schema keys also means adding new strings for translation (the descriptions), so I accidentally broke the “string freeze” break (which started after the 42.beta release). So I had to retroactively ask for an exception.

Sorry about the inconvienience!

And, until next time!

Wednesday, December 22, 2021

Christmas Maps

So it's that time of the year again and about time for an end-of-year post.

Some news in Maps for the upcoming GNOME 42.

Finally, we have added support for running development versions of Maps (such as from the Nightly Flatpak repo) in parallel with the stable ones

The develop one is distinguished by the “cogwheel” background in the headerbar, and also by it's ”bio-hazard” strip icon as seen above.

Also we've had an old feature request laying around about supporting a command-line option to initiate a search.

In the meantime in Evolution there was discussions about being able to launch a search using a configured map application, rather than just using the OpenStreetMap web-based search. In that issue it was suggested there is a draft maps: URI scheme that has been used by Apple Maps on iOS.

So I have implemented this is Maps, so that Maps will now register as a mime-handler for the maps: URI scheme. And you can then open URIs of the form something like:


This could be tested from the command line using the gio command

$ gio open maps:q=search%20query


I also took the opportunity to add a DBus action to perform search.

This can be tested using a command-line like the following:

$ gdbus call --session --dest org.gnome.Maps.Devel --object-path /org/gnome/Maps/Devel --method org.freedesktop.Application.ActivateAction 'search' "[<'search query'>]" "{}"

 or by using the d-feet DBus debugger

 (and even though the output states no return, Maps will actually launch, or activate the currently running instance with the search performed).

And I also implemented an old-school command-line argument -S with the same semantic (taking the search query as it's argument) as per the original feature request.

These will either show the search popover in Maps when there are multiple search results, or just open the place bubble with the place selected when the search was specific enough to have a single result (such as when searching for a contact's address).

 Furthermore, as a little refinement the routing instructions for turn-by-turn based modes now also makes use of the u-turn icons:

 There was also a corner-case bug introduced by me when refactoring the instruction types to decouple them the GraphHopper-specific codes, resulting in a bug in some cases with u-turns preventing the route to show up. This was spotted, and fixed by one of our newcomer contributors Marina Billes.

One thing missing when it comes to the instruction icons by the way is that we miss icons for “keep left” and “keep right”. So I've created an issue for that (https://gitlab.gnome.org/GNOME/gnome-maps/-/issues/410). (I first gave Inkscape a go, but I quickly realized icons attempt to draw looks more like deformed sausages :-) ).


Another thing that's been on my mind for a while is the default zoom levels we use when “going to” a place when selecting a search result. Currently we find a suitable zoom level based on the so called bounding box of a feature (when it's available in the result item). This means things like buildings and parks can usually be shown initially so that it fits in the present window. For other object that are mere nodes (just a pair of coordinates), we have used some presets based on the place types as defined by the geocode-glib library. But these are quite limited and only covers a few cases.

So I started playing with a WiP branch to select more fine-grained default zoom levels for more place types with a heuristic based on the types we get from the OSM data.

This way, e.g. the continents (which are represented in OSM as nodes) gets a better fit, and not just defaults to a fully zoomed-in (as a fallback) place somewhere in a rural area or such:


And also a few more distinct levels for different place “sizes”, such as hamlets so we don't have to resort to a “one size fits” all level more suitable for larger towns and cities:


And I guess that will wrap it up for this time!

Happy Holidays everyone!

Monday, September 20, 2021

Maps and GNOME 41


 It's been a while since my last blog post. And in the meantime GNOME 41 was released. So I thought it would be time for a new post, although there's not been that much news to show in Maps itself since the last update (where I showcased the refreshed icons for search results.

But a few small visual improvements have been done since.

Already in 40.0, we made the display of population numbers for places (such as towns, cities, and similar) locale-aware. So that it now uses localized digits and decimal separators.

Now in 41.0 another small refinement has been made to show elevations below mean sea level expressed in words, rather that just showing a negative numer (which, although correct, may look a bit technical):

Also along the lines of visual polish, we now show population numbers in a rounded format if the value is an exact multiple of 100,000, assuming such a figure is most likely not an exact number but rather an approximation.

This utilises the localization API from ES (JavaScript) and as can be seen here gives a localized unit suffix and also in the case of Japanese as shown in the last example, the multiple in this case is 10,000, as this is based on traditional Chinese numerals, with denominations 10⁴, 10⁸ and so on. So in this case it would translate to “800 ten-thousands (man)”.

And over in libshumate (the new GTK4-based map rendering library we're working to eventually replace libchamplain, and enable migrating to GTK4), James and Corentin has been busy.

Among other things, James has implemented rotation support (for pinch gestures on tough screens among others), fractional scaling (should make smoother pinch zooming possible, something that has been quite poor currently in libchamplain, and thus in Maps). Also he started working on a renderer that vector format tiles:

Using vector tiles is something that's been in long-term plans for a long time. One thing that this could enable is the possibility to download map data for offline usage, something that is not really feasible with bitmap tiles. But actually I think something perhaps even more useful could be the possibility to render names in the user's language. This has always been an area where compromises had to be done. For example Mapbox' street tiles uses English names in the default tile set which would have the benefit of rendering as something that many people could read out as common Romanized transliterations of place names where the native reading is in a script they can't read. The downside being that they see place names near there home always in English, even though they could read (and might be more familiar with) the native reading. On the other hand the default openstreetmap.org tiles (which Maps now uses) renders the native names (which is better for your home location, but vice versa would make any place where the native script is unfamiliar not understandable).

And myself I have started on a little side project GNOME streets. a style for rendering bitmap tile maps using the GNOME color palette (though only some parts of the map uses these colors so far):

Eventually such a style could either be deployed on a GNOME-hosted bitmap tile server, or it could perhaps be used as the base of a stylesheet for rendering vectors tiles client-side in Maps.

So, over and out for now, until next time!

Tuesday, May 4, 2021

Spring Maps

 Since it was a while since the release of GNOME 40, I thought it might be time again for a post.

Since the 40.0 release there's just been a bug fix release (40.1) where, among other things, a bug where toggling a place as a favorite and then “unfavoring” it again, made it impossible to select that place again until restarting Maps.

And in master, leading towards 41 there's also been some goings-on.


A new Bookmarks button icon

First, one issue that was brought to our attention was that since we've used the star icon both for the favorites menu button in the header bar and for the button to mark a place as a favorite in a “place bubble” and this get a bit confusing when the new adaptive mobile mode is active. Since in this case the favorite button moves to the bottom bar and this lines up the favorite button in the place bar shown above that when selecting a place.

So, to mitigate this we decided to adopt the same bookmark icon as used in GNOME Web (Epiphany) for the favorites menu button to keep them apart.

In the desktop layout it looks like this:

And when in the mobile “narrow mode”:

Here, the buttons can be seen horizontally aligned, with the top one being the button to mark the place as a favorite.

An overhaul of the search result icons

For the icons shown in the search results list we always relied on the icons provided by the libgeocode-glib library. This has had some issues, however. For one this icon set is quite limited, so most places has just received a generic pin icon.

So now these have all been replaced with fresh new icons from the GNOME icon catalog:

Jakub Steiner also drew up some brand new icons for, among other things cafes (shown above), pubs, bars, cities, and towns.

These icons are also proper symbolic icons, meaning they adapt to the dark (night mode) theme also:

In contrast to the old icons, which didn't look to great against a dark background:

Furthermore, bus stops, train stations, and similar will now use the same icons as where already used to render journey plans, so this looks more consistent

I also couldn't resist adding a bit a fun as well, so now zoos get this little penguin icon:

Validating Wikipedia refs when editing OSM POIs

I also added validation for Wikipedia references when editing places. So now it will warn you if the reference does not follow the style language-code:Article title (such as “en:Article title“ for example).

The light bubble, as before, will show a hint explaining the format. And still  like before you can also paste in a URL from Wikipedia, and it will automagically re-format it, so for exmple it converts https://en.wikipedia.org/wiki/The_article_title → en:The article title.

Improvements to libshumate

And over in libshumate (the new library we're working on to enable migrating to GTK 4.x and away from using Clutter) Georges Basile Stavracas Neto and James Westman has been working on a number of improvments. So that now smooth scrolling works (meaning that when you let go of the mouse or touch pad gesture while in motion the map view continues moving a bit with inertia) and fractional scaled zooming that will be built upon later on when adding support for smooth animated zoom and pinch gestures for touch screens.

And that's that until next time!