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

Active Topics

Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 2 days, 22 hrs ago
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 4 days, 19 hrs ago
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 5 days, 16 hrs ago
more...

Page 204 of 207

204

Thread Tools

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

Originally Posted by Dirish

Seems like a launcher is a no brainer. Why don't more people utilize that approach than?

It just fits pretty good to what modRana needs on Sailfish OS, other projects might have other (and likely simpler) requirements, especially if the application (or at least its GUI) is only targeting Sailfish OS.

Originally Posted by rinigus

@MartinK - good reasons. Few comments below

For Pure Maps, I am using symlinks to select platform (similar to your UC) and just import using a known symlink name in QML sources. That way QML files are the same and symlink is set while building a package.

That's clever, relatively clean & simple!

Would have not thought about something like this, but thinkin about it now, symlinks is what for example systemd uses to mark a unit enabled/disalber, to set the default target, etc. So that validates the concept I guess.

For modRana and Universal Components I guess it would likely work as well:

no UC backend seems to use "Import UC 1.0" internally, so it not being in QML import path should not be a problem
while technically possible there could be 2+ supported component sets on a single platform, non platform actually provides this (eq. two sets that are both supported well enough by UC)

The only possible problem I can thing of are environments where symlinks can't be used, such as running on top of FAT32 or from resource files on Android. But both is again more or less theoretical.

So while I don't think I want to change the launcher architecture for UC usage for modRana now, the symlink method seems like a good tip to add to the UC docs. Thanks for the idea!

Originally Posted by rinigus

I ended up writing bash script for harbour-pure-maps, but that was for command line options support. Not sure whether its store-compatible, but that's a future-me problem.

That's the conclusion I also ended with - since you can't prepend QML_IMPORT_PATH to the Exec line in the .desktop file, you would have to put that to a script instead. Not sure if "bash some script" is acceptable in the Exec line either, but maybe an executable script residing in /usr/bin/harbour-<app name> might get through. But that would still (due to Harbor requirements) require me to use sailfish-qml and submit to all its more or less stupid hardcoded limitations. At that point I've decided to just got the Qt5/C++ launcher code.

As I don't really do any C/C++ coding regularly, it was more or less cobled together from how other OSS Sailfish OS apps do app startup & QtCreator autocomplete.

Originally Posted by rinigus

Obviously there is more flexibility using C++, as you outlined.

Flatpak does require exe (script or something else), indeed. Have been using a script so far.

Do they provide a binary that can launch QML files (qmlscene ro something like that) ? IIRC from reading the Pure Maps flatpak packaging metadata it looked like such a binary the script can call is not available and the app needs to build it itself.

Originally Posted by rinigus

As for disadvantages - mainly missing noarch and a need to compile the code for distribution.

My idea is that the native launcher is only really important for modRana that gets installed from a package (or in the future Flatpak). The package already goes through a buildsystem so might as well contain some C++ code and generate arch-specific artifacts. Users will very likely not notice any difference.

ModRana itself still continues to be noarch and I don't plan to change it. Also all the other startup methods (running modrana.py directly or the qmlscene using shell scripts in the "run" subfolder are still fully supported & are actually the main/intended method of running modRana if you just do a checkout from git or grab a tarball.

Originally Posted by rinigus

As soon as you start extending with C++ (cannot use plane qmlscene or similar), development will be hit a bit. So, while not really needed, its better to avoid it as well.

This is just an idea at this point in time. If I ever start using that I plan to make the features provided by C++ code to either be backed a fallback implemented in Python (this is actually how many Python modules do C extensions - there is a fast C path and a slow but correct Python path that gets used if the compiled C code is not available) or make the functionality an optional addon, not something that would prevent modRana from running (otherwise) normally.

__________________
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 3 Users Say Thank You to MartinK For This Useful Post:
Amboss, juiceme, olf

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

Originally Posted by jobooth

Alright. Call me stupid but I can't get this installed on my trusty N900. Updated to 1.3 and on CSSU. When I run apt-get install modrana I get
The following packages have unmet dependencies:
modrana: Depends: espeak but it is not going to be installed
E: Broken packages

Originally Posted by justmemory

Modrana for N900 is version 0.53.1... All packages are in the repo so you should check which repos are enabled on your device. Otherwise you can still install it by hands - downloading and "dpkg -i"-ing the downloaded packages...

Indeed, the latest modRana Maemo package is indeed pretty old, yet stable. I have wanted to update it for quite some time but never really get to it so far. The other issue is that I'm starting to wonder if updating it is actually a good idea. I don't really have a working Maemo SDK available locally and all the "recent" Maemo packages have been built by the Maemo autobuilder.

Given that by now likely all remaining Maemo/N900 users have Extras Devel enabled & the autobuilder packages (if successfully built) do directly to Extras devel, I'm kinda afraid a broken package would affect users, resulting in possibly lengthy back-and-forth by feeding the autobuilder and hoping a working package comes out.

If someone had the needed knowledge/tooling (I barely understood how Maemo packages are made back then, let alone now) and wanted to accept the challenge of updating the Maemo modRana package I (and surely any remaining users on Maemo) would be very happy.

Originally Posted by justmemory

If you want an updated version you can use github repo - I use 0.55.18 on my N900 and it is working fine.

Yes, that's basically the recommended way & should work in general. Just grab a release tarball/checkout a release tag and run modrana.py.

I don't really test this regularly (as I don't have any functional Python 2.5 environment outside of my trusty N900), so please let me know if you hit some issues.

In any case, it's good to know there are still people using modRana on the N900 - which is what, 10 years old about now ?

Well, modRana itself will hit the 10 year mark in January of the next year. Crazy!

Is still don't have any immediate plans for dropping support for the N900, but there are a few things to consider:

I've recently completely dropped the old abandoned Qt4/QML UI that just kinda worked on the N900 and did not provide much useful features & AFAIK no one really used it anyway
I'm developing modRana on Fedora (and actually developing the Fedora installer as my day job ;-) ) and due to the upcoming upstream end of support for Python 2, Python 2 only packages are currently getting dropped left and right
it is therefore not unthinkable that some of the Python 2 only dependencies of modRana (such as PyGTK for example) will get dropped from Fedora in the near future

Not having the Python 2 only deps (and possibly even Python 2 itself!) available in the distro I use would make harder assuring that the Python 2/GTK2 based GUI used on the N900 continues to be working.

So at some point in the future a time might come, where it would make more sense to maintain basically a separate branch for the N900, that would likely just get occasional fixes than much (if any) new development.

On the other hand this could help to make the "modern" codebase targeting Python 3 + Qt 5 cleaner by dropping all the hacks needed to support Python 2.5 - 3.7 at the same time + all the (rather messy code) that constitutes the GTK GUI.

And, potentially the "n900-branch" would no longer need to care about any of that newfangled Python >2, GTK >2 and GUI != GTK stuff, potentially making the life of anyone interested in stepping in and improving the N900 version easier.

Quote & Reply |

The Following 5 Users Say Thank You to MartinK For This Useful Post:
Amboss, Boemien, juiceme, justmemory, olf

rinigus	2019-03-21 , 07:45
Posts: 1,414 \| Thanked: 7,547 times \| Joined on Aug 2016 @ Estonia	#2033

Originally Posted by MartinK

Do they provide a binary that can launch QML files (qmlscene ro something like that) ? IIRC from reading the Pure Maps flatpak packaging metadata it looked like such a binary the script can call is not available and the app needs to build it itself.

That's what https://github.com/rinigus/qmlrunner is for. It also has all options that are needed for flatpak distribution of Pure Maps and we can surely extend it as needed. Also, QML path can be extended as needed.

Quote & Reply |

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

jobooth	2019-03-21 , 21:48
Posts: 9 \| Thanked: 42 times \| Joined on Jan 2019	#2034

Nokia N900 1.3 on CSSU
I got modrana 0.53.1 installed and running from the repositories. Works great except trying to route just gives me a "routing failed". I had an active data connection the entire time.
I'm now trying to get offline routing working. The monav.openstreetmap.de site is down so I downloaded my state from data.modrana.org. The tar file was empty, however. It didn't create any directories. I tried the north-america_car.tar.gz as well. Empty. Tried with root too.
I guess I'll try to generate my own. It just seems like I'm either doing something wrong or nothing's working.

Secondly, how again to update? I downloaded the 0.55.18 file, tar'd it, and ran the modrana.py script. modrana opened but info-about doesn't show a version. The icon in the app drawer still loads 0.53.1 too

Quote & Reply |

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

MartinK	2019-03-22 , 02:42
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#2035

Originally Posted by rinigus

That's what https://github.com/rinigus/qmlrunner is for. It also has all options that are needed for flatpak distribution of Pure Maps and we can surely extend it as needed. Also, QML path can be extended as needed.

Interesting!

I guess I've basically just rolled all that and some into the modRana native launcher.

Due to some o the less than ideal packaging rules and practices on Sailfish OS, having the launcher as part of the modRana project is simply easier, than pulling in an external project. I guess I can always put it in a separate project if needed in the future and pull it in via git subtree like with Universal Components.

Thinking about it, some sort of a unified launcher that would accept config files in some unified format to set all the paths could be rather useful for any QML only or Python QML application that has grown too big to be launched by qmlscene or for environments where qmlscene is not available.

Originally Posted by jobooth

Nokia N900 1.3 on CSSU
I got modrana 0.53.1 installed and running from the repositories. Works great except trying to route just gives me a "routing failed". I had an active data connection the entire time.
I'm now trying to get offline routing working. The monav.openstreetmap.de site is down so I downloaded my state from data.modrana.org. The tar file was empty, however. It didn't create any directories. I tried the north-america_car.tar.gz as well. Empty. Tried with root too.

Weird, I'll try checking as well what's in those archives. These are all generated by my scripts, but I have not really re-run those since setting up the OSM Scout Server mirror.

Originally Posted by jobooth

I guess I'll try to generate my own. It just seems like I'm either doing something wrong or nothing's working.

Secondly, how again to update? I downloaded the 0.55.18 file, tar'd it, and ran the modrana.py script. modrana opened but info-about doesn't show a version. The icon in the app drawer still loads 0.53.1 too

That's expected - these are basically two independent modRana deployments. One installed from a package & the other one from a release tarball. The modRana that has not been installed via package not showing version is actually expected as well, as IIRC the version file gets generated at package build time.

In any case good to know recent modRana versions are still working on the N900.

Quote & Reply |

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

justmemory	2019-03-22 , 08:08
Posts: 391 \| Thanked: 908 times \| Joined on Aug 2011 @ suncity	#2036

Originally Posted by MartinK

Yes, that's basically the recommended way & should work in general. Just grab a release tarball/checkout a release tag and run modrana.py.

I don't really test this regularly (as I don't have any functional Python 2.5 environment outside of my trusty N900), so please let me know if you hit some issues.

Sure I will

BUT...

Originally Posted by MartinK

In any case, it's good to know there are still people using modRana on the N900 - which is what, 10 years old about now ? Well, modRana itself will hit the 10 year mark in January of the next year. Crazy!

Is still don't have any immediate plans for dropping support for the N900, but there are a few things to consider:
I've recently completely dropped the old abandoned Qt4/QML UI that just kinda worked on the N900 and did not provide much useful features & AFAIK no one really used it anyway

I'm developing modRana on Fedora (and actually developing the Fedora installer as my day job ;-) ) and due to the upcoming upstream end of support for Python 2, Python 2 only packages are currently getting dropped left and right

it is therefore not unthinkable that some of the Python 2 only dependencies of modRana (such as PyGTK for example) will get dropped from Fedora in the near future

Not having the Python 2 only deps (and possibly even Python 2 itself!) available in the distro I use would make harder assuring that the Python 2/GTK2 based GUI used on the N900 continues to be working.

So at some point in the future a time might come, where it would make more sense to maintain basically a separate branch for the N900, that would likely just get occasional fixes than much (if any) new development.

On the other hand this could help to make the "modern" codebase targeting Python 3 + Qt 5 cleaner by dropping all the hacks needed to support Python 2.5 - 3.7 at the same time + all the (rather messy code) that constitutes the GTK GUI.

And, potentially the "n900-branch" would no longer need to care about any of that newfangled Python >2, GTK >2 and GUI != GTK stuff, potentially making the life of anyone interested in stepping in and improving the N900 version easier.

... but I'm thinking about trying out Sailfish on a Samsung device (community port is available) because... Yes, n900 and Maemo 5 is pretty old. Still... I really need the capabilities that n900 has so I do not know. Talking about python... You know... Maemo 5 is quite old and even Leste won't be a real Maemo 6 but we will see. I do not know whether it is needed to have a n900 branch of ModRana if the tarballs are working so...

Quote & Reply |

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

MartinK	2019-03-22 , 15:44
Posts: 1,548 \| Thanked: 7,510 times \| Joined on Apr 2010 @ Czech Republic	#2037

Originally Posted by justmemory

I do not know whether it is needed to have a n900 branch of ModRana if the tarballs are working so...

To clarify, the idea is that - eventually in the future - a n900 Git branch for modRana would be needed as the default Git branch & releases would no longer run on Python 2.5 & N900 with GTK2.

The n900 branch would be kept Python 2.5, GTK2 & N900 compatible while the default development branch would be able to drop all the hacks needed for Python 2.5 support & all the GTK2 GUI code.

Quote & Reply |

The Following 4 Users Say Thank You to MartinK For This Useful Post:
Amboss, juiceme, olf, taixzo

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

A small modRana bugfix release - 0.56.17 - has been released, most likely fixing the incorrect viewport issue reported by Olf and others.

If you want to know what turned out to be the root cause and how it was fixed, check the corresponding issue on GitHub.

Quote & Reply |

The Following 7 Users Say Thank You to MartinK For This Useful Post:
Amboss, jobooth, juiceme, klinglerware, mosen, olf, xiskillo

jobooth	2019-03-29 , 23:07
Posts: 9 \| Thanked: 42 times \| Joined on Jan 2019	#2039

A huge thank you MartinK for all your hard work.

Quick question... Should online routing work on the N900?

Quote & Reply |

The Following 4 Users Say Thank You to jobooth For This Useful Post:
Amboss, juiceme, mosen, xiskillo

robthebold	2019-03-31 , 02:51
Posts: 1,038 \| Thanked: 3,980 times \| Joined on Nov 2010 @ USA	#2040

Originally Posted by MartinK

You can now easily start modRana from CLI on Sailfish OS by typing:
Code:
harbour-modrana

Does launching from CLI take any commands, parameters, options, etc.? I haven't found anything in the available documentation, but that could be my search skill and not the reality.

And thanks for continued support.