Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement org.freedesktop.impl.portal.Background #285

Open
mildred opened this issue Oct 30, 2023 · 2 comments
Open

Implement org.freedesktop.impl.portal.Background #285

mildred opened this issue Oct 30, 2023 · 2 comments

Comments

@mildred
Copy link
Contributor

mildred commented Oct 30, 2023

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
Copy link
Collaborator

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
Copy link

Consolatis commented Apr 26, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants