Background portal implementation

[leolost2605]

• Implement the flatpak background portal
• Fixes Background Portal Implementation #68

Todo:

• Make notifications work (finish the NotifyBackground implementation) NotifyBackground might need some more work (tbh i've got no idea what I'm supposed to do with the handle) it's working and i've taken a look at the kde implementation and they don't use the handle as well
• Fix criticals
• Fix quoting of commandline args that don't have to be quoted
• In GetAppState: Don't hardcode application window state (background, at least one open, in the foreground) (might need some addition implementation effort on the gala side) Currently GetAppState only returns apps with at least one open window and being in the foreground is ignored. To change this (i.e. to return also background apps and check whether an app is in the foreground) additional implementation effort on the gala side is needed. IMHO for now this is enough and I wouldn't consider it blocking.

Heavily inspired by the gtk implementation

For testing purposes one can use e.g. elementary/mail#882 and run it as flatpak

[leolost2605]

If the background portal request is made by a non-flatpak application the app_id for the autostart file will most of the time be empty (see flatpak/xdg-desktop-portal#650). Usually we can then assume that the first commandline arg can be used as an app_id. Now this is up for discussion but I decided to use it if it is an io.elementary app_id and only then. This will be useful for mail (elementary/mail#882), calendar (elementary/calendar#681) and tasks which currently can't be shipped as flatpaks. It will give us some bonus features like allowing the user to disable autostart of these apps and us not having to install the autostart file manually.
Thoughts on this?

[Marukesu]

libnotify is used because
...
4. why go through the hassle of using the DBus stuff when we have such a nice library
5. if libnotify is a dealbreaker we can go through the hassle of using the DBus stuff

I tend to think different, i don't see DBus as a hassle in vala, and our needs for the notification is simple enough that libnotify don't give us too much. at least, i would like to see the notification tied to a request, so the frontend can close it when not needed.

If the background portal request is made by a non-flatpak application the app_id for the autostart file will most of the time be empty (see flatpak/xdg-desktop-portal#650). Usually we can then assume that the first commandline arg can be used as an app_id. Now this is up for discussion but I decided to use it if it is an io.elementary app_id and only then. This will be useful for mail (elementary/mail#882), calendar (elementary/calendar#681) and tasks which currently can't be shipped as flatpaks. It will give us some bonus features like allowing the user to disable autostart of these apps and us not having to install the autostart file manually. Thoughts on this?

i think it's fine to allow any host application to install a .desktop file via the portal, isn't like they cannot fake a portal dialog and install it by themselves. after all, background monitoring only works with flatpaks.

[leolost2605]

Should be ready again however one thing to note is that for some reason the background monitor doesn't really start/work (e.g. its DBus interface is not visible in D-Spy although it is visible on GNOME). I'm going to investigate here still a bit (if anybody already got an idea/solution for this it would be much appreciated :)) but for now I wouldn't consider it blocking. That's because the only downside we really have is that background activities are only checked once on every iteration instead of twice. This means that it could take up to a minute for the frontend to realize an app is running in the background and notify the portal because new applications have to be marked as "in the background" twice before the frontend takes action.

[Marukesu]

Should be ready again however one thing to note is that for some reason the background monitor doesn't really start/work (e.g. its DBus interface is not visible in D-Spy although it is visible on GNOME). I'm going to investigate here still a bit (if anybody already got an idea/solution for this it would be much appreciated :)) but for now I wouldn't consider it blocking.

The BackgroundMonitor was introduced in the version 0.16 of the frontend. AFAIK the version we have in horus is 1.14.

That's because the only downside we really have is that background activities are only checked once on every iteration instead of twice. This means that it could take up to a minute for the frontend to realize an app is running in the background and notify the portal because new applications have to be marked as "in the background" twice before the frontend takes action.

looking at the branch for the 1.14 version, it check the application states two times per iteration, the only change that i see there was that the sleep time before the checks was reduced.

[leolost2605]

Ah ok that's what I was missing; probably should have checked that first 😬
Regarding the timings: I just saw the 5 seconds from master and what I experienced felt quite a bit longer so I just asumed it was the run every minute (which according to the debug message timings seemed likely) but this makes sense now.

[Marukesu]

LGTM.

[danirabbit]

LFG 🚀