Implement org.freedesktop.impl.portal.Background

[mildred]

The Background portal is required by multiple applications. Epiphany (for their web app), Pika Backup (for the scheduled backups) and probably a few others. Missing portals is making Sway / wlroot compositors perform less than the other desktop environments. I'm opening this issue to track the missing Background portal for wlroots.

Interface : https://github.com/flatpak/xdg-desktop-portal/blob/main/data/org.freedesktop.impl.portal.Background.xml

Discussion extract in the xdg-desktop-portal matrix channel:

A question for the portal devs : currently Sway and wlroots based compositors do not support any kind of background portal. I believe this breaks epiphany web apps and also Pika Backup and probably a number of other apps.

How would you go about implementing the background portal ?

EnableAutostart seems easy enough to implement (create the autostart desktop entry) but for the other endpoints I fail to see how to get it done. GetAppState and NotifyBackground requires the compositor to track all apps, including the background app. But an app might be started from anywhere like a terminal and any process can ask to display a surface on the compositor. Apps might even be started without displaying surfaces (the background apps). How do other compositors solve this issue?

That's why the mapping between application id and desktop file is usually employed

https://wayland.app/protocols/xdg-shell#xdg_toplevel:request:set_app_id

does that work for background processes that do not have any surface shown on Wayland?

mildred: it's not that hard, it just needs the compositor to tell xdg-desktop-portal which apps have a window. the backend interface is this one: https://flatpak.github.io/xdg-desktop-portal/docs/#gdbus-org.freedesktop.impl.portal.Background

the compositor does not need to track background apps. the compositor merely has to report which apps have a window, through their app ids

the NotifyBackground() method is called by xdg-desktop-portal itself. it tells the backend: "this app is running in the background, what do you want to do with that?"

in the past e.g. xdg-desktop-portal-gnome would show a notification. these days it just allows the app to run in background without any intervention, because we show these background apps in a menu

It's easy to get the list of applications showing a wingow on Sway using swaymsg -t get_tree

swaymsg -t get_tree -r | sed -n 's/\s*"app_id": "\(.*\)".*/\1/p' | sort | uniq

But this is specific to Sway, is there a way to get it for any wlroots compositor?

[columbarius]

Afaik sway and other wlroot based compositors in the tradition of window managers have their own way to autostart applications and ignore desktop entries. Please elaborate what interaction between the compositor and clients registering with this portal do you expect? A standalone application like darkman for settings might be more appropriate.

[Consolatis]

wlr-foreign-toplevel to get the "background" / non-background / active state + SNI to have notifiers for backgrounded apps seems like it should work. Nothing required from the compositor side (only wlr-foreign-toplevel support which I guess most wlroots based compositors already have). And if a compositor wants to show its own list of "background" applications it could implement its own SNI host within the compositor. Otherwise a user would just need to run some random panel that supports a SNI tray.