[Announce] modRana: a flexible GPS navigation system - Page 202 - maemo.org

Active Topics

Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 3 days, 1 hr ago
more...

Page 202 of 207

202

Thread Tools

MartinK	2018-06-24 , 22:28
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#2011

modRana 0.52.18 has been released !

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 status
OpenRepos package has been updated
Jolla Store package has been submitted to QA

__________________
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)

Quote & Reply |

The Following 12 Users Say Thank You to MartinK For This Useful Post:
Amboss, Feathers McGraw, Fellfrosch, Jordi, juiceme, justmemory, karlos devel, klinglerware, mrsellout, olf, peterleinchen, rinigus

rinigus	2018-08-31 , 07:49
Posts: 1,414 \| Thanked: 7,547 times \| Joined on Aug 2016 @ Estonia	#2012

@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.

Quote & Reply |

The Following 5 Users Say Thank You to rinigus For This Useful Post:
Amboss, Fellfrosch, juiceme, olf, peterleinchen

MartinK	2018-09-02 , 21:21
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#2013

Originally Posted by rinigus

@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

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

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.

Quote & Reply |

The Following 10 Users Say Thank You to MartinK For This Useful Post:
Amboss, carlosgonz, Feathers McGraw, Fellfrosch, juiceme, klinglerware, olf, peterleinchen, rinigus, t-b

rinigus	2018-09-03 , 07:30
Posts: 1,414 \| Thanked: 7,547 times \| Joined on Aug 2016 @ Estonia	#2014

Originally Posted by MartinK

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

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.

Originally Posted by MartinK

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.

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.

Quote & Reply |

The Following 7 Users Say Thank You to rinigus For This Useful Post:
Amboss, Feathers McGraw, juiceme, klinglerware, MartinK, olf, peterleinchen

MartinK	2018-09-06 , 21:31
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#2015

modRana 0.52.18 has been released !

This is still a rather small update that adds support for deleting individual stored POI and makes creation of new POI more intuitive.

Changelog
* it is now possible to delete individual saved POI
* adding new POI from the map should now be more intuitive
* translation update

Quote & Reply |

The Following 12 Users Say Thank You to MartinK For This Useful Post:
Amboss, carlosgonz, Feathers McGraw, Fellfrosch, juiceme, klinglerware, lal, Malakai, mosen, olf, pagis, rinigus

	carlosgonz	2018-09-06 , 21:44
	Posts: 175 \| Thanked: 515 times \| Joined on Jul 2018 @ Guatemala	#2016

yes \0/ new version finally.

thnks

__________________
Nokia N95 / Nokia N900 / Nokia N9 / Nokia N8 / Jolla 1 / Jolla C / Xperia X / Xperia 10 II / PinePhone / Librem 5 / Xperia 10 III / Xperia IV

Last edited by carlosgonz; 2018-09-06 at 21:51.

Quote & Reply |

The Following 3 Users Say Thank You to carlosgonz For This Useful Post:
Amboss, juiceme, MartinK

MartinK	2019-03-18 , 18:10
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#2017

So looks like Sailfish OS 3.0.2 Oulanka has broken modRana due to the Python 3 upgrade (3.4.3 -> 3.7.2).

Basically, modRana uses the work "async" in a couple places in its source code, but that work became a reserved word used by Python starting from Python 3.7 and causes modRana to crash.

In any case I should have a fixed modRana version available shortly.

Quote & Reply |

The Following 14 Users Say Thank You to MartinK For This Useful Post:
Amboss, Feathers McGraw, Fellfrosch, Jordi, juiceme, justmemory, klinglerware, lal, Malakai, mosen, nthn, olf, peterleinchen, taixzo

MartinK	2019-03-19 , 01:36
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#2018

modRana 0.56.14 has been released !

So finally, a new modRana release! There is not that much user visible (yet ;-) ) other than, well, working now with Sailfish OS 3.0.2 Oulanka, where Python 3 version upgrade (3.4.3 -> 3.7.2) kinda prevented modRana from starting correctly.

Other than that, modRana now has a shiny native launcher, that made it possible to drop many Sailfish OS specific packaging hacks, mainly imposed by sailfish-qml being very, very stupid. This also has user visible impact though.

You can now easily start modRana from CLI on Sailfish OS by typing:

Code:

harbour-modrana

That's the new native launcher binary, that launcher modRana the correct way (and no longer have to hack around sailfish-qml limitations). There is also some potential for modRana starting slightly faster.

This change also has an interesting side effect - modRana is no longer noarch - the launcher is compiled Qt5/C++ source code, so the modrana package needs to be architecture specific, even thought the rest of the application is all Python & QML.

I can't really think about any issues possibly stemming from this (other than me having to upload two packages to Jolla Store and OpenRepos.

Also, you can of course still just clone the modRana source code from git, install qmlscene and then start the sailfish script from the run subfolder.

Also, one more update - translations! Thanks a lot to everyone taking part, IIRC there should be some more complete languages as well as general translation updates.

Where can I get modRana 0.56.14 ?

link to Open Repos:
https://openrepos.net/content/martink/modrana-0

link to Jolla Store:
is not there as Jolla Store still has no web version! :P

Quote & Reply |

The Following 11 Users Say Thank You to MartinK For This Useful Post:
Amboss, Feathers McGraw, Fellfrosch, juiceme, justmemory, klinglerware, mosen, nthn, olf, P@t, rinigus

rinigus	2019-03-19 , 06:32
Posts: 1,414 \| Thanked: 7,547 times \| Joined on Aug 2016 @ Estonia	#2019

@MartinK: interesting, which limitations are you hitting with sailfish-qml? Having a dedicated launcher gives more flexibility in long run, though.

Quote & Reply |

The Following 3 Users Say Thank You to rinigus For This Useful Post:
Amboss, juiceme, mosen

MartinK	2019-03-19 , 09:52
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#2020

Originally Posted by rinigus

@MartinK: interesting, which limitations are you hitting with sailfish-qml? Having a dedicated launcher gives more flexibility in long run, though.

There were a couple, mainly with sailfish-qml forcing a certain application structure, which is not really compatible with how modRana files are laid out & how it is launcher on other platforms:

the main qml file needs to be called harbour-<app name> and located in /usr/share/harbour-<app name>
all the QML files need to be in in /usr/share/harbour-<app name>/qml
sailfish-qml sets the PWD to /home/nemo, which complicates loading of Python modules
there is no option to set QML import path (needed for Universal Components), it has to be done via an environmental variable, which is a problem as invoker can't really take those in the Exec line of a desktop file

Normally modRana supports multiple GUIs and the GUI files are located in the corresponding GUI sub folder, it's expected the PWD is pointing to the top level modRana directory and the currently selected UC backend should be added to the QML import path.

To achieve this I had to do some pretty nasty & fragile source code mangling during the build of the Sailfish OS package.

Now with the native launcher, I have full control over QML import path, PWD/PYTHONPATH, argv and the QML execution environment in general.

It has also the nice side effect that people now can easily start modRana by typing:

Code:

harbour-modrana

This is also in $PATH & autocomplete will find it, unlike before.

There are also some other reasons for this:

IIRC Flatpak will need a launcher like this anyway
if I ever start doing packages for Android again a similar type of launcher is needed there as well
argument passing should be more doable with native launcher
- no arg - start Qt 5 GUI
- some args - pass them to modrana.py instead of starting GUI
if I ever need access to some C/C++ API or just want to compute something really quickly in native code, I now have the option via the launcher (likely with a pure-Python fallback where possible)

The only possible downside/change (aside from the time spent on this) is that the modRana package is no longer noarch, but so far I have not hit any real issues because of that.