<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Is there any minimal example I could take a look at? I've never done
    anything more with dbus than dbus-send. <br>
    <br>
    <div class="moz-cite-prefix">On 17.02.2018 22:06, Adam Pigg wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CANFkB1xR5Qt52Ohbx0C1Or24P-PyM22gFwMaZL6CQCS7trYwVg@mail.gmail.com">
      <div dir="ltr">
        <div>Hi<br>
          <br>
          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.<br>
          <br>
        </div>
        <div dir="ltr">Adam<br>
        </div>
        <br>
        <div class="gmail_quote">
          <div dir="ltr">On Sat, 17 Feb 2018 at 20:58 rinigus <<a
              href="mailto:rinigus.git@gmail.com" target="_blank"
              moz-do-not-send="true">rinigus.git@gmail.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            <div dir="ltr">Hi,
              <div><br>
              </div>
              <div>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.</div>
              <div><br>
              </div>
              <div>But maybe someone has better idea.</div>
              <div><br>
              </div>
              <div>Cheers,</div>
              <div><br>
              </div>
              <div>Rinigus</div>
            </div>
            <div class="gmail_extra"><br>
              <div class="gmail_quote">On Sat, Feb 17, 2018 at 9:16 PM,
                Marcin Mielniczuk <span dir="ltr"><<a
                    href="mailto:marmistrzmar@gmail.com" target="_blank"
                    moz-do-not-send="true">marmistrzmar@gmail.com</a>></span>
                wrote:<br>
                <blockquote class="gmail_quote" style="margin:0 0 0
                  .8ex;border-left:1px #ccc solid;padding-left:1ex">
                  <div bgcolor="#FFFFFF" text="#000000">
                    <p>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.</p>
                    <p>Any other options?<br>
                    </p>
                    <div>
                      <div
                        class="m_-90190366793658063m_208903294917534939h5">
                        <br>
                        <div
class="m_-90190366793658063m_208903294917534939m_-5396081271493200703moz-cite-prefix">On
                          05.02.2018 10:33, rinigus wrote:<br>
                        </div>
                        <blockquote type="cite">
                          <div dir="ltr">Hi,
                            <div><br>
                            </div>
                            <div>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.</div>
                            <div><br>
                            </div>
                            <div>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 </div>
                            <div><br>
                            </div>
                            <div>* shut down service via systemd</div>
                            <div>* establish new connections</div>
                            <div><br>
                            </div>
                            <div>and on GUI exit you would have to </div>
                            <div><br>
                            </div>
                            <div>* drop all connections</div>
                            <div>* start service via systemd</div>
                            <div><br>
                            </div>
                            <div>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).</div>
                            <div><br>
                            </div>
                            <div>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.</div>
                            <div><br>
                            </div>
                            <div>Cheers,</div>
                            <div><br>
                            </div>
                            <div>Rinigus</div>
                          </div>
                          <div class="gmail_extra"><br>
                            <div class="gmail_quote">On Mon, Feb 5, 2018
                              at 11:17 AM, Marcin Mielniczuk <span
                                dir="ltr"><<a
                                  href="mailto:marmistrzmar@gmail.com"
                                  target="_blank" moz-do-not-send="true">marmistrzmar@gmail.com</a>></span>
                              wrote:<br>
                              <blockquote class="gmail_quote"
                                style="margin:0 0 0 .8ex;border-left:1px
                                #ccc solid;padding-left:1ex">Hi,<br>
                                <br>
                                When creating SFOS applications which
                                should run 24/7 (e.g. IMs) we<br>
                                would like to achieve similar behavior
                                as the stock applications, e.g.<br>
                                the stock e-mail client: the sync (*)
                                runs in the background, even<br>
                                though the application is closed. A
                                window staying open just to make<br>
                                sure the sync goes on clutters the open
                                app view and makes it more<br>
                                difficult to manage the open
                                applications.<br>
                                <br>
                                On a desktop DE one would simply
                                minimize the application to tray.<br>
                                Alternatively, one could create a daemon
                                which the client app would<br>
                                communicate with using UNIX sockets, but
                                it greatly increases the<br>
                                complexity of the application and slows
                                down the development.<br>
                                <br>
                                What's the easiest way to keep the sync
                                process in the background<br>
                                without keeping the window open?<br>
                                <br>
                                Regards,<br>
                                Marcin<br>
                                <br>
                                (*) when speaking sync, I mean any kind
                                of waiting for a remote event,<br>
                                no matter if it's done by idle TCP
                                (which is good) or HTTP polling<br>
                                (which is not good)<br>
                                <br>
                                <br>
_______________________________________________<br>
                                SailfishOS.org Devel mailing list<br>
                                To unsubscribe, please send a mail to <a
href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank"
                                  moz-do-not-send="true">devel-unsubscribe@lists.sailfishos.org</a></blockquote>
                            </div>
                            <br>
                          </div>
                          <br>
                          <fieldset
class="m_-90190366793658063m_208903294917534939m_-5396081271493200703mimeAttachmentHeader"></fieldset>
                          <br>
                          <pre>_______________________________________________
SailfishOS.org Devel mailing list
To unsubscribe, please send a mail to <a class="m_-90190366793658063m_208903294917534939m_-5396081271493200703moz-txt-link-abbreviated" href="mailto:devel-unsubscribe@lists.sailfishos.org" target="_blank" moz-do-not-send="true">devel-unsubscribe@lists.sailfishos.org</a></pre>
                        </blockquote>
                        <br>
                      </div>
                    </div>
                  </div>
                </blockquote>
              </div>
              <br>
            </div>
            _______________________________________________<br>
            SailfishOS.org Devel mailing list<br>
            To unsubscribe, please send a mail to <a
              href="mailto:devel-unsubscribe@lists.sailfishos.org"
              target="_blank" moz-do-not-send="true">devel-unsubscribe@lists.sailfishos.org</a></blockquote>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>