Use flatpak portal for background and autostart

[leolost2605]

Use the flatpak background portal to install the autostart file and request background permission.

Uses libportal.

Requires elementary/portals#73

Closes #880

[leolost2605]

Currently maybe blocked by the same as this

[meisenzahl]

We could prepare shipping Mail as Flatpak by guarding your code with something like this:

    public bool is_running_flatpaked { 
         get { 
             return FileUtils.test ("/.flatpak-info", FileTest.IS_REGULAR); 
         } 
     }

[leolost2605]

I updated it so that mail will only use the flatpak portal if it's sandboxed, so in theory this PR is ready for review again.
However as far as I know using the background portal is currently blocked entirely by this

[leolost2605]

Another thing: currently the background daemon isn't started automatically after it was granted permission on first run, it only starts after restart. Should this be changed?

[Marukesu]

Another thing: currently the background daemon isn't started automatically after it was granted permission on first run, it only starts after restart. Should this be changed?

in the calendar PR, i changed it to always start with the application, the --background flags only signalize that no window should be shown.

[leolost2605]

in the calendar PR, i changed it to always start with the application, the --background flags only signalize that no window should be shown.

Makes sense to me I'll do the same here then

[danirabbit]

@leolost2605 is this ready for review now that the background portal stuff has landed? Also I remember seeing some discussions around host apps being able to use the portal as well?

[leolost2605]

@danirabbit yes it is! And yes the deb version of mail can use the portal too (at least on elementary OS but that's probably enough :)
We should make sure though that if this gets merged elementary/portals should get a new release with/before mail
Also note that currently it's shown as deactivated in switchboard. It still works unless you activate it once and then deactivate it again. That's because of some deprecated stuff that's still used there, I plan on fixing that though.

[Marukesu]

Also note that currently it's shown as deactivated in switchboard. It still works unless you activate it once and then deactivate it again. That's because of some deprecated stuff that's still used there, I plan on fixing that though.

elementary/switchboard-plug-applications#184 is the fix for that.

[Marukesu]

Don't make the request_background call in the startup() method (i would say the call to activate here is wrong too), this will mess with DBus activation.

The way to go here is:

1. call only InboxMonitor.start() in the startup() method.
2. in activate() check if the background flag got used, if so call hold() and then request background, not having a parent window shouldn't be a issue.
3. if the request fail, call release().

there's no need to make the request if we open an window. instead, we should make the request in the window's delete_event and hold() if permission was granted. but this one can be done in a follow-up.

[Marukesu]

this line pass the 120 line limit, would be good to break it.

Suggested change

	return yield portal.request_background (parent, _("Mail needs to run in background in order to send notifications."), (owned) command, Xdp.BackgroundFlags.AUTOSTART, null);
	return yield portal.request_background (
	active_window != null ? Xdp.parent_new_gtk (active_window) : null,
	_("Mail needs to run in background in order to send notifications."),
	(owned) command,
	Xdp.BackgroundFlags.AUTOSTART,
	null
	);

Also, IIRC, the background frontend do not check if the application already has permission, so this would end in the permission dialog begin shown in every launch even when the user already give permission.

in the calendar PR, it stores if it had an successful request and skip the request_background call in the next launches.

[leolost2605]

there's no need to make the request if we open an window. instead, we should make the request in the window's delete_event and hold() if permission was granted. but this one can be done in a follow-up.

If that's okay from a design perspective I would integrate this here because it makes implementing the other suggestions quite a bit easier

Also, IIRC, the background frontend do not check if the application already has permission, so this would end in the permission dialog begin shown in every launch even when the user already give permission.

Actually I think it does here. However it would still overwrite any settings made by the switchboard plug every time mail is launched. On the other hand it allows to disable the autostart via flatpak permission which might be the way to go for the future?

[leolost2605]

Should I guard the hold with something like a first_activation variable? I saw that in the calendar PR it wasn't so I dont know...

[Marukesu]

Should I guard the hold with something like a first_activation variable? I saw that in the calendar PR it wasn't so I dont know...

Yes, it will be problematic when sandboxed, ask_background will always be true when running from host, so the amount of hold() done doesn't matter we will always hold. will update that there.

[Marukesu]

LGTM.