[SailfishDevel] Keep an application running without keeping the window open
Marcin Mielniczuk
marmistrzmar at gmail.com
Sun Feb 18 19:29:11 UTC 2018
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>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20180218/70fef4c3/attachment-0001.html>
More information about the Devel
mailing list