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 > <marmistrz...@gmail.com <mailto:marmistrz...@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-unsubscr...@lists.sailfishos.org > <mailto:devel-unsubscr...@lists.sailfishos.org> > > > > > _______________________________________________ > 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
