[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