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