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

Marcin Mielniczuk marmistrzmar at gmail.com
Mon Feb 19 07:54:57 UTC 2018


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
> https://github.com/kimmoli/callflasher
>
> for complex one, take a look at tohkbd2 . it has 2 daemons, system and
> user, and ui app that all communicate together over dbus
>
>  
>
> -kimmo
>
>  
>
> *Lähettäjä:*Devel [mailto:devel-bounces at lists.sailfishos.org]
> *Puolesta *Marcin Mielniczuk
> *Lähetetty:* sunnuntai 18. helmikuuta 2018 21.29
> *Vastaanottaja:* Adam Pigg <adam at piggz.co.uk>; Sailfish OS Developers
> <devel at lists.sailfishos.org>
> *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:
>
>     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>
>
>  
>
>
>
> _______________________________________________
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfishos.org

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


More information about the Devel mailing list