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-boun...@lists.sailfishos.org] > *Puolesta *Marcin Mielniczuk > *Lähetetty:* sunnuntai 18. helmikuuta 2018 21.29 > *Vastaanottaja:* Adam Pigg <a...@piggz.co.uk>; Sailfish OS Developers > <devel@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....@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
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
