xdg-desktop-portal-gnome: fix screen sharing on non-GNOME compositors

[jdd-canada]

Screen sharing is broken on Wayland compositors that register their Mutter.ScreenCast D-Bus service after the portal starts (niri, Hyprland, etc). GNOME doesn't hit this because Mutter registers ScreenCast before portals launch.

The gnome portal backend creates and exports the ScreenCast skeleton only when Mutter.ScreenCast appears on D-Bus. By that point the main xdg-desktop-portal has already created a proxy and cached the default zero capabilities. Since properties are set before export, no PropertiesChanged signal fires, so the proxy never updates.

Fix: export the skeleton at init with zero capabilities, then update properties in-place when the compositor appears. The 0->7 change emits PropertiesChanged, proxy re-syncs.

Testing the changes

• I tested the changes in this PR: YES

Local build testing

• I built this PR locally for my native architecture, x86_64-glibc

[ahesford]

What is the provenance of this patch?

[jdd-canada]

I am building a Niri fork with a tiling wm for myself. Obs screen sources and Signal screen sharing were silently failing. I used Claude to pin down the reason why. Coles notes: gnome portal ends up depending on mutter to populate sources for sharing. The gnome project has signups disabled, and I think this would benefit other void users, as I am pretty sure anything not gnome/mutter is going to have the same issue.

[ahesford]

First, screen sharing is working fine on niri with xdg-desktop-portal-gnome when properly configured. Claude has most likely misdiagnosed your issue. Second, we don't accept patches that haven't been merged upstream; even then, we only pull upstream patches that fix critical issues which can't await a new official release.

You should take up this matter with the upstream project.

[jdd-canada]

Screen sharing on niri likely works because most niri users run elogind, which manages session startup ordering. I'm running seatd + pam_rundir with no logind. Portals D-Bus activate as soon as any GTK app starts, before the compositor registers Mutter.ScreenCast. The race is real and exists upstream (niri issues 571, 3117, 3085 report it too, but changing session managers masks it.)

I'd love to take it upstream to gnome - but they have participation in their community disabled

It's not a configuration issue.

I appreciate your time, my local patch runs fine. delete this or ignore or whatever is you do.

[ahesford]

I am also using seatd.

Whether or not GNOME allows community participation, this is not our issue to fix.