Maps wrap-up 2022

 As I was quite busy during the days before Christmas this year I didn't get time to write the traditional holidays Maps blog post.

So I thought I should at least write a quick wrap-up of the happenings during 2022 before the end-of-year.

As always, we started out in spring with a new major release along the spring GNOME release (42.0).

In 42.0 (or rather during the development cycle leading up to it) Maps gained support for using the development profile, so that you can install nightly snapshot releases from the GNOME nightly Flatpak repo (or using locally-built bundles) in parallell with a stable release (using the Flathub release or from a „traditional“ distro package).

Like for other apps, the icon for the development release is distinguished by the „bio hazard stripe“.

Also in the 42.0 release, support for the maps: URI scheme was added. Using this a link can constructed that when opened will initiate a search using the encoded search term in Maps. This is now used by Contacts when a contact in the address book has an address set. There is also a DBus API for performing searches.

Later during spring, after the 42 release some additional spring cleaning was made.

Support for social media check-in was removed (and along with it the dependency on gnome-online-accounts). The one remaining implementation for Foursquare had not been working that reliably (and hasn't been widely used), and also the other implementation (for Facebook) had been removed one release before, and had been broken for a few years due to upstream API changes.

This was also done to get remove some mostly unused UI to get less code to port to GTK 4.

Another change was changing the process for performing OAuth setup for editing POIs in OpenStreetMap. Previously we had handled username and password locally and programmatically posted the OAuth authorization forms using a ported variant of the same code used by JOSM.

As this method is not really best-practice for doing OAuth sign-up, and this had already at one point been broken and needed fix due to changes on the server-side this was then rewritten to hand off the authorizing to use an external web browser.

   This has taken inspiration from how Cawbird implements signing in to Twitter.

Then in late June it became appearent that  due to other dependencies migrating to libsoup 3 (for HTTP request support) maintaining Maps using GTK 3, libchamplain (depending on libsoup 2.x) for GNOME 43 was looking impossible.

So, it seemed a last-minute port to use GTK 4 and our new libshumate map rendering library (based on the GTK 4 scene graph) should be attempted, even though the schedule was getting a bit tight…

But after some additional bumps (such as porting the OSM loging to use OAuth 2 due to needing to port to a new version of librest) and some frantic summer coding nights, just in time for GNOME 43 it was in working (good enough) condition.

Christopher Davis helped port the about window to use the new libadwaita version of the dialog. He also did some additional clean-ups after the GTK 4 port.

This release also involved settling on the API/ABI for libshumate and declare it as 1.0.0.

Following the release, I have also done some post-port mending to fix some brokenness left after the port.

Among the fixes, the „place bubbles“ has been fixed to get rid of the extraneous margin that unintentionally got there after the port (due to GtkPopover widgets behaving differently, they where special-cased in GTK 3 when it comes to applying the CSS spacing rules).

So after this fix the place image (when there is one) is now again „flush on“ with edge.

 This is available in the latest Maps release (43.2).

 James Westman has also been working on fixing some performance issues and memory leaks in libshumate (that has been backported to the 1.0 branch, currently the stable version released is 1.0.3).

James has also been continuing improving the vector tile support in libshumate.

I also took the time to implement one additional feature for the new major release (44.0).

Now Maps supports fetching the thumbnail and Wikipedia article extract when a place has a tag referring to an entry in Wikidata.

It is also now possible to edit those when editing a POI (and the Wikidata tag can be  „fetched“ semi-automatically when a Wikipedia article tag is filled in by pressing a reload button.

That's it for now. I said it was going to be a quick wrap-up, but I guess it got some length to it after all!

So, see ya in 2023 and happy new year!

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!

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();

becomes

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

becomes

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

Utils.someFunction(...);

 

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

 https://www.jwestman.net/2022/06/18/labelling-maps-is-surprisingly-hard.html

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! 😎