[SailfishDevel] Keep an application running without keeping the window open

[Marcin Mielniczuk]

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:
> Hi
>
> 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.
>
> Adam
>
> On Sat, 17 Feb 2018 at 20:58 rinigus <rinigus.git at gmail.com
> <mailto:rinigus.git at gmail.com>> wrote:
>
>     Hi,
>
>     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.
>
>     Cheers,
>
>     Rinigus
>
>     On Sat, Feb 17, 2018 at 9:16 PM, Marcin Mielniczuk
>     <marmistrzmar at gmail.com <mailto:marmistrzmar at gmail.com>> 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:
>>         Hi,
>>
>>         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.
>>
>>         Cheers,
>>
>>         Rinigus
>>
>>         On Mon, Feb 5, 2018 at 11:17 AM, Marcin Mielniczuk
>>         <marmistrzmar at gmail.com <mailto:marmistrzmar at gmail.com>> wrote:
>>
>>             Hi,
>>
>>             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?
>>
>>             Regards,
>>             Marcin
>>
>>             (*) 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)
>>
>>
>>             _______________________________________________
>>             SailfishOS.org Devel mailing list
>>             To unsubscribe, please send a mail to
>>             devel-unsubscribe at lists.sailfishos.org
>>             <mailto:devel-unsubscribe at lists.sailfishos.org>
>>
>>
>>
>>
>>         _______________________________________________
>>         SailfishOS.org Devel mailing list
>>         To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfishos.org
>>         <mailto:devel-unsubscribe at lists.sailfishos.org>
>
>
>     _______________________________________________
>     SailfishOS.org Devel mailing list
>     To unsubscribe, please send a mail to
>     devel-unsubscribe at lists.sailfishos.org
>     <mailto:devel-unsubscribe at lists.sailfishos.org>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20180218/70fef4c3/attachment-0001.html>