Still continuing with the theme of smaller yet important fixes and improvements though arguable the switch to SVG icons is actually pretty significant. Not only should the icons in modRana no longer be blurry - ever - but as a side effect the installation package is now just 1.3 MB instead of 1.9 MB, because SVG files compress really well. The installed size savings are less as unpacked SVG files often take up about the same space as the resulting bitmap in PNG format.

Work also continues on the two main planed bigger items, such as abstracting the API modRana uses to talk to the map page, so that an alternative map page based on MapBox GL Native can be added.

Changelog since last time (0.55.10):
* all icons are now SVG and thus resolution independent!
* it is now possible to easily clear things displayed on top of the map
* show distance on POI listings
* fix toggle highlight for centering icon
* show "Route here" option on all point & POI detail pages
* fix layout of search progress popup
* improved on-map button & button text sizing
* show distance to POI in POI detail page
* translation fixes & updates (big thanks to all translators yet again! )

Release statusOpenRepos package has been updated
Jolla Store package has been submitted to QA

@MartinK: I don't know how far are you with the porting to MapboxGL effort. Now, assuming that SFOS3 will come with QtLocation supporting Mapbox GL (5.9, isn't it?), maybe it will make more sense to port it over to QtLocation proper. That would allow you to get simpler installation on desktop (no extra plugins needed).

Although, without newer compiler, they will not be able to provide MapboxGL component in QtLocation and, in general, SFOS3 hopes should be probably as low as possible (aka 'please don't break anything'). But its an angle that you could think about when making priorities and timelines for future development.

In general, with this porting (mapbox gl plugin or qtlocation), make sure that Delete and Backspace and Ctrl-K work on your keyboard. There is a lot of code crafted around getting tiles that waits to be deleted. At least, that's expectation based on Poor Maps days.

@MartinK: I don't know how far are you with the porting to MapboxGL effort. Now, assuming that SFOS3 will come with QtLocation supporting Mapbox GL (5.9, isn't it?), maybe it will make more sense to port it over to QtLocation proper. That would allow you to get simpler installation on desktop (no extra plugins needed).

I've recently finished decoupling the map page API from the pinchmap based implementation. This way I should be able to integrate another map widget quite easily while keeping pinchmap based one working until the new widget supports all the expected features. I guess this could be helpful for any API uncertainities as well.

I would kinda fear the API is dumbed down to account for all the other plugins but (the QtLocation API, especially in the QtQuick 1.0 times was not very good). Or is it possibly the other way around (eq. we are missing some features they have ?).

Originally Posted by rinigus

Although, without newer compiler, they will not be able to provide MapboxGL component in QtLocation and, in general, SFOS3 hopes should be probably as low as possible (aka 'please don't break anything').

But who knows in which for it will actually be available, which plugins will work and if it will finally be whitelisted for Jolla Store apps.

BTW, thinking about it, would it be possible that the MapBoxGL plugin could be built with your updated GCC toolchain and still work with QtLocation 5.9 once available ?

That way there would still be a custom dependency that needs to be installed, but the custom element would not have to be maintained anymore & it would simplify desktop porting compatibility.

Originally Posted by rinigus

But its an angle that you could think about when making priorities and timelines for future development.

Definitely thanks for the heads-up! While I think I'll just start with our current known-working solution, it's definitely good to explore other options (technically, the modRana codebase could be now able to support both if really really needed ).

Originally Posted by rinigus

In general, with this porting (mapbox gl plugin or qtlocation), make sure that Delete and Backspace and Ctrl-K work on your keyboard. There is a lot of code crafted around getting tiles that waits to be deleted. At least, that's expectation based on Poor Maps days.

I don't know I understand this ? You mean in modRana, the custom MapBoxGL plugin on Poor/Whogo/Pure maps code ?

For the record I definitely plan to continue supporting "classic" tiled maps as well as vector tiles. There are various useful pre-rendered or aerial map tile sets that should definitely continue to be available to users together with the on-the-fly rendered vector layers.

Still if I understand things correctly the MapBoxGL widgets has custom bitmap tile caching code, so indeed the modRana tile handling machinery will not be needed when running with MapBoxGL based map page. But it will still be needed for the time being for the pinchmap based map page & the old GTK2 based UI people apparently still use on the N900.

From the brief look, it seems to have all features our plugin has. At least on 5.11 level. However, 5.9 seems to have backported Mapbox GL plugin as well, so it should be fine as well.

Originally Posted by MartinK

I would kinda fear the API is dumbed down to account for all the other plugins but (the QtLocation API, especially in the QtQuick 1.0 times was not very good). Or is it possibly the other way around (eq. we are missing some features they have ?).

While general interface is maybe dumbed down, there is an access to Mapbox GL specific constructs too.

But who knows in which for it will actually be available, which plugins will work and if it will finally be whitelisted for Jolla Store apps.

Thanks for links. I asked at their pull request regarding packaging, let's see what they will reply.

Originally Posted by MartinK

BTW, thinking about it, would it be possible that the MapBoxGL plugin could be built with your updated GCC toolchain and still work with QtLocation 5.9 once available ?

That way there would still be a custom dependency that needs to be installed, but the custom element would not have to be maintained anymore & it would simplify desktop porting compatibility.

Sure, the custom plugin works on 5.9 and probably later too. I am using it on PC.

Originally Posted by MartinK

Definitely thanks for the heads-up! While I think I'll just start with our current known-working solution, it's definitely good to explore other options (technically, the modRana codebase could be now able to support both if really really needed ).

I don't know I understand this ? You mean in modRana, the custom MapBoxGL plugin on Poor/Whogo/Pure maps code ?

I met mainly tile caching/downloading code in modRana . But if you want to keep backward compatibility, all is needed. As for raster tiles, they are supported by Mapbox GL too.