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.

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!


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.

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.

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.

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.