Implement XDG Desktop Portal support

[FifthTundraG]

Adds a framework for adding XDP portals and implements the Background portal for proper autostart.

Fixes flathub/com.nextcloud.desktopclient.nextcloud#18
Related: flathub/com.nextcloud.desktopclient.nextcloud#225

CC @mgallien

---

This is a draft. There are a few considerations that still have to be made:

• I have seen that sometimes the filename for the autostart file will be org.chromium.Chromium.desktop instead of com.nextcloud.desktopclient.nextcloud.desktop. It wasn't occurring on c21ff3d, which is before what seems to be a settings page redesign (which I did not notice until merging newer changes lol), so it may be related to that? This also isn't very consistent, it happened once and now it's not anymore.
• We need to figure out how we want portals to be configured
  • I think that portals should be the default, and if they fail then we fallback to legacy behavior.
  • We could also use a buildflag (something like USE_PORTALS) and make it configurable that way.
• Utility::hasLaunchOnStartup does not work (and has not worked) in a sandbox. Its usage in generalsettings.cpp was temporarily disabled, as it was preventing XdgPortal::background from being run when the "run on startup" toggle was unchecked, which meant the autostart file was never removed.
  • This check may never be able to work in a sandbox, as the portal API doesn't expose any obvious way to check if the app is already set to start on login.
• This PR has not yet been tested in an AppImage (i don't know how to build them and have not bothered to learn yet 🙃)

---

Please keep in mind that I'm quite new to C++ and insanely long buildscripts (lol), so please have grace on any silly mistakes :)

[nilsding]

Thanks for the PR! Looks promising so far :)

as for the AppImage, we build one as part of our CI for each pull request. if you would like to try that one I can start a CI run for this PR, provided the client builds just fine (and ideally after rebasing the changes on top of the latest master commit)

[nilsding]

hmm, I guess when portals are in use we have no other option than relying on the value of launchOnSystemStartup from the config file

perhaps we need to keep track of whether the background portal was used when setting this property

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)

[mgallien]

please do not leave commented out code and rather remove it 🙏

[FifthTundraG]

Requesting some assistance here: I am unsure of how to handle the Utility::hasLaunchOnStartup situation, and afaik it's the last thing that needs to be addressed before this PR is ready.

As mentioned in my comment, the portal does not expose a way to determine if the application is set to launch on startup. @nilsding mentioned we could keep track of if the background portal was used, and if so make Utility::hasLaunchOnStartup be based on ConfigFile().launchOnSystemStartup(), and this would probably work fine, but I'm unsure if it's the best solution.

It's also worth noting that the changes in #9773 to generalsettings.cpp (this line) made it so the value of the checkbox is determined by the return value of Utility::hasLaunchOnStartup instead of the config, so unless we were to change the code back to how it was originally, the checkbox will not flip to true even when Utility::setLaunchOnStartup succeeds and an autostart file is created. tl;dr we can't brush this under the rug and actually have to address it unless we change how the checkbox works.