Yes. That is one case.

From: Marcin Mielniczuk []
Sent: 19. helmikuuta 2018 9:55
To: Sailfish OS Developers; Kimmo Lindholm
Subject: Re: [SailfishDevel] Keep an application running without keeping the 
window open

Do I understand correctly that the dbus daemons run as usual systemd --user 
daemons and simply communicate over dbus?

On 18.02.2018 22:59, Kimmo Lindholm wrote:
One small daemon you can take a look is my call fhasher
for complex one, take a look at tohkbd2 . it has 2 daemons, system and user, 
and ui app that all communicate together over dbus


Lähettäjä: Devel [] Puolesta Marcin 
Lähetetty: sunnuntai 18. helmikuuta 2018 21.29
Vastaanottaja: Adam Pigg <><>; Sailfish 
OS Developers <><>
Aihe: Re: [SailfishDevel] Keep an application running without keeping the 
window open

Is there any minimal example I could take a look at? I've never done anything 
more with dbus than dbus-send.
On 17.02.2018 22:06, Adam Pigg wrote:

You could create a dbus service for the application to talk to.  The gui 
application can launch the dbus service if it isnt running, and connect next 
time it is opened, leaving it running in the background.

On Sat, 17 Feb 2018 at 20:58 rinigus 
<<>> wrote:

from the point of view of portability, having a split GUI and backend should be 
nicely portable. Even focusing on systemd would cover large portion of Linux 
distributions, but you don't have to include any systemd dependencies as such. 
On desktop, it would allow you to move the backend into dedicated hardware, if 
you wish. Also, it would survive X11 crashes as a bonus. So, if you plan to run 
it 24x7, service running on the background is a good way of doing it.

But maybe someone has better idea.



On Sat, Feb 17, 2018 at 9:16 PM, Marcin Mielniczuk 
<<>> wrote:

I'm not sure if that's a good choice when trying to achieve portability. 
Usually on desktop you'd rather have a monolithic application with just 
minimize to tray.

Any other options?

On 05.02.2018 10:33, rinigus wrote:

the obvious solution is to run service that is 24/7 on and separate client for 
GUI. That's what stock messaging is doing. I would recommend it and use some 
simple messaging API for communicating between them. There are probably many 
APIs to choose that will allow you to set it up simply.

If you can withstand short shutdown of the service then you can combine it into 
the same application. It would require that application will start in GUI or 
server mode depending on command line option. If started in GUI mode, you would 
have to

* shut down service via systemd
* establish new connections

and on GUI exit you would have to

* drop all connections
* start service via systemd

The latter is the way OSM Scout Server works with the adjustment that its using 
systemd sockets to keep it switched off when user is not accessing it. Note 
that it was done for historical reasons (signaling between parts was 
implemented via Qt) and since its mostly used as a service anyway (users don't 
need to access GUI for weeks).

I would still recommend splitting service/GUI parts and use some messaging 
protocol in between. Myself I would have used zeromq, but you could choose 
probably many others.



On Mon, Feb 5, 2018 at 11:17 AM, Marcin Mielniczuk 
<<>> wrote:

When creating SFOS applications which should run 24/7 (e.g. IMs) we
would like to achieve similar behavior as the stock applications, e.g.
the stock e-mail client: the sync (*) runs in the background, even
though the application is closed. A window staying open just to make
sure the sync goes on clutters the open app view and makes it more
difficult to manage the open applications.

On a desktop DE one would simply minimize the application to tray.
Alternatively, one could create a daemon which the client app would
communicate with using UNIX sockets, but it greatly increases the
complexity of the application and slows down the development.

What's the easiest way to keep the sync process in the background
without keeping the window open?


(*) when speaking sync, I mean any kind of waiting for a remote event,
no matter if it's done by idle TCP (which is good) or HTTP polling
(which is not good)

_______________________________________________ Devel mailing list
To unsubscribe, please send a mail to<>

_______________________________________________ Devel mailing list

To unsubscribe, please send a mail to<>

_______________________________________________ Devel mailing list
To unsubscribe, please send a mail to<>

_______________________________________________ Devel mailing list

To unsubscribe, please send a mail to<>

_______________________________________________ Devel mailing list
To unsubscribe, please send a mail to

Reply via email to