Flatpak: Create Autostart File Via Background Portal

[Marukesu]

with this calendar will call the background portal to create the daemon autostart on the first launch when sandboxed.

[marbetschar]

@Marukesu FYI I added a PR which unifies the daemon and regular app into the same binary. So we may have to rework this a little once this is merged: #702

[danirabbit]

@Marukesu can you update this/resolve conflicts since there's now a single binary?

[Marukesu]

Updated the PR, now this will show the dialog in two cases:

• during launch with --background.
• when closing the window.

Also, the daemon is always started now, so that we can show notifications when the application is open, even if we don't have permission to run in background.

[danirabbit]

Is there a reason to only use the background portal when running in Flatpak? Can we use it all the time?

[Marukesu]

Is there a reason to only use the background portal when running in Flatpak? Can we use it all the time?

The GTK portal backend uses the sandboxed app id to name the autostart file, but for host apps it is empty, so they create an unnamed .desktop that is replaced by others application on host that calls the portal (see flatpak/xdg-desktop-portal#650).

[jeremypw]

I can confirm that after removing the existing Calendar installation with AppCenter and renaming the existing autostart file and installing a flatpak built from this PR and logging out and in again the following:

1. No daemon was running initially
2. Running the flatpak with flatpak run launched the program but did not start the daemon
3. Closing the window triggered a dialog requesting permission to run in background
4. After giving permission the window closed but the daemon did not start
5. After logging out and back in, the daemon did autostart.
6. It was not possible to launch Calendar from the wingpanel indicator but launching from the dock and Applications Menu worked. (Is this an existing bug with flatpak/wingpanel?)

I would expect the daemon to start after giving it permission to do so and not have to log out and in.

[Marukesu]

2. Running the flatpak with flatpak run launched the program but did not start the daemon

I can't reproduce this here, starting the application should start the daemon, the only diference from master here is that starting the daemon is done before the --background check.

4. After giving permission the window closed but the daemon did not start

The last commit should fix that, for some reason, chaining up base.delete_event () was causing an segfault.

6. It was not possible to launch Calendar from the wingpanel indicator but launching from the dock and Applications Menu worked. (Is this an existing bug with flatpak/wingpanel?)

Looking at the code in the indicator, it tries to launch io.elementary.calendar --show-day, so i don't expect it to work with the sandboxed calendar.

[danirabbit]

@Marukesu wanna update this again and remove the flatpak check since the background portal can work with host apps now? :)

[Marukesu]

@danirabbit this should be good to review again.

[danirabbit]

Seems like it would simplify things quite a bit to use LibPortal like we did for Mail?

[danirabbit]

Should this be done in activate? it looks like Mail does the equivalent in startup

[Marukesu]

Well, Calendar doesn't have a startup method. This work since TodayEventMonitor is marked as a [SingleInstance] class and the construct method will only be called one time.

[danirabbit]

Let's go 🚀 Thanks for working on this!

Changes made