View Single Post
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#2013
Originally Posted by rinigus View Post
@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.

BTW, how is the "official" Mapbox GL plugin API compared to "our" custom MapboxGL element API ? Is it 1:1 match feature wise ?

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 View Post
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').
That's definitely the only sensible way. It looks like they are working on QtLocation 5.9:
https://git.merproject.org/mer-core/...n/tree/mer-5.9
https://git.merproject.org/mer-core/...n/tree/mer1911

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 View Post
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 View Post
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.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 10 Users Say Thank You to MartinK For This Useful Post: