Monday, September 2, 2019

Maps and GNOME 3.34

Just released Maps 3.33.92, the last beta release before the GNOME 3.34.0 release next week.

I've already covered other news earlier, such as “search-as-you-type” auto-complete search and the new sharing dialog, allowing opening locations with any application capable of handling geo: URIs. I also implemented support for opening URLs pointing to objects in OpenStreetMap directly in Maps. This can be handy in cases when someone pastes such a URL in a chat for example (and the new sharing dialog allows to copy the same type of URL to the clipboard, or as an e-mail).

James Westman has also implemented a change in how startup works, so that Maps now will open directly at the location you last viewed, instead of starting from a view of the entire world and then animating to the location. We now also remember the map type as set when closing the app the last time (“normal” or aerial view).

Another thing (that is also already available in older versions as well) is that we have updated the tile style we use from MapBox.

I also started working on an idea I've been thinking about for a while, but that will not come in 3.34, so more on that later…

And one last thing, I also sneaked in a small little hidden feature for 3.34, let's see if anyone finds it… 😎

Wednesday, June 19, 2019

Midsomer Maps

Since it's been kindof a tradition for me to do some blogging around midsomer, I thought we might as well keep with that tradition this year as well… And there's been some nice news in latest beta release of Maps, 3.33.3.

First James Westman has implemented a new improved “Send to” dialog, as the old one had some problems. The way it interacted with the Clocks and Weather apps was a bit strange, adding the exact place (let's say a shop or a pub) as an entry in e.g. Weather, which is most likely not what the user intended. So the new dialog will offer to add the nearest city (or rather METAR weather station):


It also includes a summary with the name and address of the place, it's raw coordinates, and a link to the corresponding raw object in the OpenStreetMap database  as well as buttons to copy this information to the clipboard to be able to paste it elsewhere and also a button to initiate an e-mail message using the default e-mail client with this information, and the title of the place as the subject. Furhermore, along with the entries to add the nearby location to the Weather and Clocks apps, additionally if you have other apps capable of opening geo: URIs, they will appear at the end. In the case above I have JOSM (an OpenStreetMap editor written in Java, allowing nitty-gritty editing of OpenStreetMap data), so selecting that would open an area centered around this location in that app (however I also discovered a couple of bugs in JOSM's geo: handling, so you'll need their latest snapshot release for it to work).

Along with this, I started tinkering with allowing to enter the OpenStreetMap URL as a search term in Maps, so that you could open such URLs directly, without resorting to a browser. Ideally I would have liked if it was somehow possible to register as some kind of “partial” URL handler for http(s) restricted to certain patterns, but this is not currently possible with the mime support we have. So that would seems like a distant dream for now… Oh, and a somewhat crazy idea might be to attempt grocking some (subset) of Google Maps URLs.

The other big thing is that I completely rewrote the search engine, so now it uses either GraphHopper's API, or the search API of the Photon project. GraphHopper also uses Photon, but using their legacy API layer. The reason I implemented support for both is that GraphHopper was fine with using their service. The good thing is that quite a lot of the JSON parsing could be handle by a common module. And I also made it so that the search provider is auto-configured through the service file, so when/if GraphHopper switches to standard Photon, we can switch, and existing Maps clients will automagically use the new endpoint. Or if we want to change provider, that could also be done seamlessly this way.

What's more is that this finally gives us “search-as-you-type”, and this is something that calls for a video:

Thanks to the dynamic service file, it was also possible add attribution information that shows in the ”About“ box:

This is a pretty nice thing to do, I think.

And there was also time to fix a 4-odd year old bug, namely that in turn-by-turn routing our icons for roundabout navigation where always showing counter-clockwise variants. This has now been rectified to use clockwise variants for locations in drive-on-the-left countries/territories:

This might come in handy for this guy:

Not only those things, I also got around to fix an old, actually crashing bug when a user has more than some 250 contacts with addresses associated in their Evolution address book (such as when coupling with an enterprize Exchange server.

That's it for now, I guess… :-)

Friday, May 3, 2019

Some Maps news

I guess it's time for some news on goin ons in GNOME Maps again since been a couple of months since last time.

In the development branch (leading up to 3.34 this autumn) I have re-written the code used for producing printouts of route searches to not use the GtkOffscreen “pseudo widget“ to render instructions, since this will not be supported in GTK 4. Instead it now uses Cairo directly to do the rendering. The appearance of the printouts should however not really be any different, so in that respect it is not that exciting :-)

On the surface though there's been some concerns regarding the quality of the turn-by-turn-based route search results provided by GraphHopper, that in some cases gives quite a lot of unneeded “continue on” instructions on the same road, as shown in the following screenshot from a 3.30.x version:

This was something that there were upstream reports about in GraphHopper. But I thought that it might be worth a shot to try to do some client-side clean-ups of the results by merging consecutive instructions continuing on with a common part of the road name, and this is the after result:

Which makes a bit more condensed and easier to use. This has also been backported to the stable branch and will be available in next week's 3.32.2 release.

The other concern was that the search function is not that great at intelligently finding relevant, nearby results. And it's also not too forgiving to spelling mistakes and matching on partial strings. I have done some researching on alternatives for this as well. Will get back on the subject rather soon…

So, until next time!

Saturday, March 16, 2019

Maps and GNOME 3.32

So, a couple of days ago the GNOME 3.32 release came out and I thought I should share something about the news on the Maps side of things, although I think most of this has been covered in previous posts.

First up we have gotten a new application icon as part of the major overhaul of the icon style.

Furthermore the application menu has been moved into a “hamburger menu” inside the main window, in-line with the other applications in the desktop. This goes hand-in-hand with the gnome-shell top bar application menu not showing this application-specified menu anymore, since it was considered not too intuitive and also few third-party apps utilized it. But I'm pleased to see that the icon of the currently focused app is still shown in the topbar, as I think this is a good visual cue there.

And the other notable UI-wise fix is showing live-updated thumbnails for the in the layer selection menu for the buttons to switch between map and aerial view (contributed by James Westman).

These screenshots also shows some glimpses of the new GTK theme, which I think is pretty sleek, so well done the designers!

There's also been some under-the-hood fixes for silencing some compiler warnings (for the C glue library) contributed by Debarshi Ray.

Looking forward I started work on an issue that has been laying around in the bug tracker since I registered it around two years ago (tagged with the “newcomers” tag in the hopes someone would take it on :) ) that is about the we use a GtkOffscreenWindow to render the output when generating printouts of a routing search. This was done by instantiating the same widgets used to render the route instructions in the routing sidebar and the attaching this to an offscreen window to render them to bitmaps. But as this method will not work with GTK 4 (due to a different rendering architecture) this has to eventually be rewritten. So I started rewriting this code to directly use Cairo and Pango to render the icons and text strings for the printed instructions. And there's some gotchas with layouting and right-to-left locales, but this far I think it's working out right for the turn-based routes as shown by the these screenshots.

The latter screenshot showing a rendition using a Farsi locale (being RTL, using the Arabic script).

That's it for now!

Saturday, January 19, 2019

Starting on a new map rendering library

Currently in Maps, we use the libchamplain library to display the bitmap map titles (based on OpenStreetMap data and aerial photography) that we get from our tile provider, currently MapBox. This library is based on Clutter and used via the GTK+ embed support within libchamplain, which in turn makes use of the Clutter GTK embed support. Since this will not be supported when moving along to GTK+ 4.x and the Clutter library is not maintained anymore (besides the copy of it that is included in the GNOME Shell window manager/Wayland compositor, Mutter) eventually Maps will have to find a replacement. There's also some wonky bugs especially with regards to the mixing of event handling on the Clutter side vs. the GTK+ side.

So to at least get the ball rolling a bit, I recently decided to see how hard it would be to take the code from libchamplain and keep the grotty deep-down internals dealing with tile downloading and caching and such and refocus the top-level parts onto new GTK+ 4 technologies such as the Snapshot, GSK (scene graph), and render node APIs.

Picture under Public Domainfrom Wikipedia
I decided to call the new library “libshumate” in honor of Jessamine Shumate who was an artist, historian, and cartographer.

The code currently lives in this personal repo
So far it's not so exciting as I've only done some cleanups, based off the Meson build system port for libchamplain, removed support for the GNU Autotools build system, removed support for the unmaintained Memphis renderer library and the GTK+ Champlain widget, as the plan is to re-work the library to use GTK+ facilities directly. I've gone through all the files and renamed the API to use the new name. And rather than using something like sed, I went through all source and header files in GNOME Builder and use search and replace, this way I got to get a quick glance at the internals 😎.

The next step will probably be to change the “top” class into a GTK+ widget and try getting first to just display the initially downloaded tiles using the GSK and leave out all the other functionallity at first (handling input and the overlay layers and so on).

Let's see how it goes…

Tuesday, December 11, 2018

Christmas Maps

It´s been ages since I last shared any Maps news, so it´s probably about time…
Some things have happened since the stable 3.30.0 release in September.

First off we have a new application icon, courtesy of Jakub Steiner using the icon style for the upcoming GNOME 3.32

Furthermore the application menu has moved into the new “hamburger menu ” in the title bar, in-line with changes being carried out across the board for GNOME applications, since the adoption of the desktop top bar menu for application-wide action was never really adopted in any significance by third-party applications.

Lately James Westman have made various valuable contributions, among others a better experience on first launch (should be no more gray areas “north of the north pole” in these situations), getting rid of some deprecation warnings when running with newer GJS versions, and also a bug fix with some parts from our C-based glue library for loading addresses from the contact book not being exposed as introspectable (and thus not being visible from JavaScript code) which strangely somehow was still working on older GJS. So I also made an additional bug-fix for the 3.30 series (3.30.3) with this fix.

Another feature James has been working on is replacing our old thumbnails that was being used in the menu for selecting the map style. This has been using static graphics captured from our previous map tile provider (MapQuest) which are not only not in-line with the currenly used tile style but may also be in a legal grey-zone. So one idea I floated was to dynamically use content from the current map view for the thumbnails.

James made some experimenting with this in WIP branch:

We have not decided quite yet from a design perspective if we should go with this approach, but I think it looks and feels pretty sleek. One slight downside is that it generates some additional tile accesses, but I think it´s acceptable.

So thank you very much James!

That´s that for now, and all have happy holidays!

Thursday, June 28, 2018

Summer with Maps

It´s been a while since I wrote a blog post last time… and even though we´ve had summer weather here (more or less) since quite some while, it seems appropriate with a little “start of summer” summer post. Since last time time I´ve amended a pretty long-standing issue we´ve had when running under a Wayland compositor (at least with the Mutter compositor, as used by gnome-shell) that makes the revealer widgets we´ve had for showing notifications not working in this case, as the map view is using the Clutter scene graph library and overlaying GTK+ widgets on that is not working under Wayland. Since Clutter is deprecated and this issue won´t be fixed and re-writing the map view library using some other backend (also making it working under the upcoming GTK+ 4) is a rather big undertaking, I´ve went ahead with a few workarounds to get rid of the overlayed widgets.

Notifications used for showing i.e. the need to zoom in to add OpenStreetMap POIs and for informing that location services is turned off (and this has been an issue at least on Fedora, where user location is by default disabled for privacy reasons) have been replaced with modal dialogs (not as elegant, but better than not showing up at all)

The notifications showing when routing fails for some reason have been replaced with showing messages in place of the result list.

Furthermore the total number of “via points” for routing has been limited to 10. This has been done partly because GraphHopper imposes a limit of 30, and also the UI doesn´t really cope well with too many locations anyway.

And with that Maps wishes you all a continued happy summer (or winter if you´re on the sothern hemisphere) 😎