Starting in the background using Portals

[Alexander Larsson]

On Wed, Jun 12, 2019 at 11:19 PM David Strauss <david at davidstrauss.net> wrote:
>
> I'm working on a Flatpak app that provides lightweight system information to an IT reporting API. I've been using Builder 3.32.3 and Python 3.7.3 on Fedora 30 Silverblue.
>
> I would like this behavior:
>
> Starts in background at startup (after login), allowing it to collect data and upload reports
> If the user goes into GNOME Activities and chooses the app, the GUI should open
>
> How would I best go about doing this? I'm aware of org.freedesktop.impl.portal.Background.xml, but I'm not sure where to start in terms of using it. I'm very new to building apps using Flatpak. Specifically, I'm looking for advice based on starting with the Builder template for a Python GUI Flatpak app.

Yeah, the thing to use here is the background portal (which is kinda
new, so beware it may not be everywhere yet).
"org.freedesktop.impl.portal.Background" is actually the backend (thus
the ".impl"), so what you want to use is
org.freedesktop.portal.Background.

The docs for that are here:
  https://github.com/flatpak/xdg-desktop-portal/blob/master/data/org.freedesktop.portal.Background.xml

The portal apis are a bit complex since they are long-running and
abortable. But what it boils down to is calling the
RequestBackground() method with autostart=true and
commandline=/app/bin/data-collect-app (and possibly
dbus-activatable=true if the collector is a dbus service, which may be
a good way to talk to it). This will ask the user if it is ok for the
app to run in the background, and if so record this for the future (to
allow the app to run in the background)) and generate an autostart
file with the right contents to have your app started on login.
Once this is done you will get a signal on the request object that
this succeeded (or was denied).

Some portal are automatic behind other apis, but this one you need to
call manually. Here is some portal calling code you can use as a
template:
https://gitlab.gnome.org/GNOME/glib/blob/master/gio/gopenuriportal.c#L244

There has been discussions of creating a wrapper library for these
APIs, but there is none atm.

> I'm also looking for advice on the best way to manage app preferences (just some strings). Presumably, there's something I can do that eventually maps to GSettings/DConf, but I may be looking in the wrong places. I'm happy to use whatever is the best practice.

We've talked about how to best do this. A lot of currently packaged
gnome apps use dconf (via gsettings) which is not a great fit as you
need to grant full access to the centralized dconf daemon. The new
recommended way is instead to use gsettings with the keyfile backend
which uses regular files and inotify in a database used only for your
app.

This has been discussed here:
https://gitlab.gnome.org/GNOME/glib/merge_requests/450, and since glib
2.60.0 it the keyfile backend is the default inside a flatpak, and wit
flatpak 1.2 this will also pick up host-side defaults and locks. So,
if you use the gnome 3.32 runtime this should work.

Flatpak 1.2 also supports migration of dconf settings to the keyfile
backend. If you set the "migrate-path" key in the manifest it will do
a one-time migration of the dconf data into the right keyfile for
gsettings use.

-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                Red Hat, Inc
       alexl at redhat.com         alexander.larsson at gmail.com