Originally Posted by romu

Thanks, that was not so clear (at least to me) on their web site.

Originally Posted by otsaloma

Before starting to work on Poor Maps, I took a look at the Modrana codebase and I was horrified by the amount of code, amount of different Python versions, operating systems and toolkits supported

Originally Posted by otsaloma

and the amount of third party components bundled in.

Originally Posted by otsaloma

Agreed. Preferrably so that this offline map, geocoding and routing provider would be a server running on localhost so that it would be usable exactly the same way as online providers regarding the main codebase, i.e. HTTP downloads, status codes, timeouts, redownloads, Content-Type detection etc. But that of course depends on the practicalities of what can conveniently be run in a mobile environment.

Originally Posted by otsaloma

But, I don't expect to do much work on offline stuff for the simple reason that I don't have much use for it. I would hang along though if someone else takes the lead.

Originally Posted by MartinK

Yeah - this is definitely not ideal but kinda unavoidable mainly due to the aim of supporting multiple platforms while not wanting to not drop existing users.

So that's why there is code for 3 UIs - 2 actively maintained ones (GTK2 & Qt5) and a legacy/abandoned one (Qt 4).

Also all the core code shared by the UIs needs to be compatible with Python 2.5-3.4, as the N900 (where modRana still has many users) has only Python 2.5, while Sailfish has only 3.4 in a usable state.

I agree that the codebase can really look confusing/overwhelming as a result. I'm trying to generally improve this by incremental refactoring, modularisation, by adding more comments and docstrings, etc.

I've also started to split some parts to modules - such as the tile storage handling code. So hopefully this should generally improve. Also if someone wants to contribute to modRana I'm ready to help them get started - eq. explain how the stuff they want to improve works and where might be the best place in code for the change to be done.


This is unfortunately kinda unavoidable on mobile platforms given how limited the package management options generally are. I also generally aim for the code in the repo to be reasonably "zero install" - so that people could just clone modRana and just run it without installing a ton of dependencies.

Still I'm aware of all the issues bundling causes so I'm generally moving all the bundled modules to a single folder so that they can be easily unbundled when possible (such as when packaging for normal Linux distros with sane package management).


Yeah - while this principle is often used on "normal" Linux distros I wonder if there could be some issues with running custom stuff on Localhost in mobile environments. Eq. would for example HArbour QA have issues with it ? Etc.


You are welcome to use monav-light for offline routing (and modRana should also start making use of it soon) -
there already even monav-light packages for Sailfish OS.