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