Sun, 9 Dec 2018 14:40:30 +0200 Rinigus:
Hi,
I would like to add geo: handling into Pure Maps. While command line
arguments can be used through Qt.application.arguments in QML, its not
very clear how to take into account already running instance. Namely,
we are expected to have only one instance of application running and
as a result, if some other application calls geo: handler, it is
expected that the map application will become active and show
corresponding location.
Yep, that's how I would expect it to work on Sailfish OS as well.
For the record proper support for CLI arguments with the QML interface
on Sailfish OS is also on my TODO list for modRana and it sounds like it
might be a good idea to bump it up to keep functional parity with Poor
Maps in this regard. :)
If I would have full control over application start, as in C++
applications, I would probably made:
* DBus interface
* on start checked whether such interface is active/available.
* If active DBus interface is there, would have called corresponding
DBus method and exited
* If not, started full application
QML/Python apps, such as Pure Maps, are started using sailfish-qml.
This arrangement, as far as I can see, prevents such handling.
I wonder if maybe some non-graphical QML code could be executed before
sailfish-qml shows the window. Then potentially the QML coude could
check via the QML DBUS bindings if the application is already running
and forward it the command line arguments and then exit. Or start is as
normal if no instance is already running.
Alternatively, this could be something that could be built into the
sailfish-qml utility itself - the system has some accounting of what's
already running so that you will get the already running instance if
there is one or a new one gets started. Possibly something similar could
be used to check if an instance is already running & forwarding the argv
to it via say well known DBUS API or equivalent. In any case source for
sailfish-qml seems to be here:
https://github.com/sailfishos/libsailfishapp/blob/master/launcher/launcher.cpp
It looks to me that I should write some kind of launcher (Python
probably) that could be used to either communicate with the main
application via DBus or start the full application.
Yep, that should work & is a solution that does not need immediate help
from Jolla developers while still could be shared between insterested
community projects. DBUS should be easy to use from Python on Sailfish
OS via Pydbus:
https://together.jolla.com/question/181809/how-to-using-dbus-from-python-on-sailfish-os/
The case where the application is already running is IMHO simple - check
for the DBUS API being up and forward either the full CLI arguments or
potentially even individual actions (I think it should be much easier to
parse the arguments in Python than in plain QML) to the API, then exit.
In case the application is *not* running at the time I'm not 100% sure -
I guess the Python code would run sailfish-qml to start the application
as usual, forwarding the CLI arguments ? A couple things are unclear to
me at the moment:
- Can sailfish-qml actually forward CLI arguments in a way the
application can access them from either QML or Python ?
- What will happen with the Python instance used for the launcher ? I
wonder if it might lead to slightly increased memory usage if it
continues running due to sailfish-qml running being it's child process &
if it is possible to execute sailfish-qml in such a way that the Python
process can exit.
- What we be the delay of a Python process starting first, followed by
sailfish-qml vs sailfish-qml starting directly ? This would likely be
insignificant but could still be a good idea to measure just in case.
Also I guess (based on my *very* limited understanding of this) all the
re-loading/boosting machinery used by Sailfish OS should hopefully be
unaffected as long as the QML code is launched via sailfish-qml or other
libsailfishapp based launcher.
Or am I wrong? Maybe there is some better idea for implementation of
such functionality?
Cheers,
Rinigus
Best Wishes
Martin Kolman
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
