Please provide a Cinnamon-specific implementation of xdg-desktop-portal

[nielsdg]

XDG desktop portals are a set of D-Bus APIs that work independent of DE, display server, and works in containerized applications like Flatpak, Snap and others. It is already implemented by GNOME, KDE, Elementary and wlroots. It provides for example a way of grabbing the screen that can only happen after a user consents to it.

GTK-based DEs already have a shared implementation for a subset of portals, called xdg-desktop-portal-gtk. However, certain APIs are compositor-specific and can't be put there. GNOME has xdg-desktop-portal-gnome while Elementary also has their own version.

The expectation is that more and more applications migrate to these APIs, as they provide cross-platform support. Certain display protocols (like Wayland) also explicitly don't provide such API.

Note that at this point, there's a bit of a "happy accident": if people install xdg-desktop-portal-gnome, that backend actually uses the org.gnome.Shell.Screenshot API, which also exists on Cinnamon, so screenshotting actually already works there (some other endpoints don't). However, if either GNOME or Cinnamon decide to change that internal API, this will break. I'm mostly just mentioning this since it might be a good idea to take xdg-desktop-portal-gnome as a starting point.

[ItzSwirlz]

This sounds like a great idea! Except someone is going to complain about there being too many of similar packages (like the polkit) and not everyone probably won't be happy about it.

Context: We discussed a while back on having our own polkit-agent, since the gir or whatever is deprecated and instead of creating a polkit agent, we decided we would wait until it was neccessary, then work with XFCE to create a cross-DE polkit agent.

He complained about there being a polkit agent for every DE, and he probably would not be excited about an XDG portal. MATE and XFCE don't have one; I guess we could create our own?

I think this can actually be accomplished. I'll take a look at it-however,

APIs are compositor-specific and can't be put there

is that referring to Muffin or clutter? I'm not sure as I haven't been active here in cinnamon devel and all I know is that there's an attempt to rebase Muffin

[nielsdg]

Not sure who "he"/"someone" is referring to here, but I'm not sure how to address that complaint without getting some arguments on the actual downsides.

For what it's worth, there is already some code sharing going on: you can use the Cinnamon-specific implementation together with xdg-desktop-portal-gtk, which implements some of the API requests already with GTK dialogs. It's already being used by GNOME and elementary to share some parts of their implementation, so I guess it should be doable for Cinnamon to do the same.

is that referring to Muffin or clutter? I'm not sure as I haven't been active here in cinnamon devel and all I know is that there's an attempt to rebase Muffin

It's referring to the later on top of Muffin. Specifically, it's pretending to be GNOME Shell (probably inherited the code) by implementing the org.gnome.Shell.Screenshot API. That API is not stable however, and has changed already. I guess ideally it should provide its own D-Bus service, and then the xdg-desktop-portal-cinnamon implementation would call that.

[mtwebster]

We implemented the screenshot interface because that's what gnome-screenshot has used for quite some time, not because it's accessed by the portal api (I honestly wasn't aware of this aspect) - we had been using the x11 fallback code for screenshots.

He complained about there being a polkit agent for every DE,

The polkit discussion is hardly comparable to this one. That was talking about replacing a shared, stable (though currently unmaintained) package, and was pretty thouroughly addressed. This is about some functionality that is actually missing from Cinnamon currently.

I've run into an issue with Cinnamon notification actions previously, so was aware of some of this. Thanks for reminding me though. Added to our list, hopefully for 5.4.

[nielsdg]

We implemented the screenshot interface because that's what gnome-screenshot has used for quite some time, not because it's accessed by the portal api (I honestly wasn't aware of this aspect) - we had been using the x11 fallback code for screenshots.

Fair enough :-) The Shell screenshot API never had any API guarantees though, and it's even been restricted in the latest versions. Technically you could keep on implementing it (also adding the PickColor() method for example), but then beware that you might end up dealing with random API breakages.

In any case, if some application is still using the GNOME Shell Screenshot API, they should probably switch to the Screenshot portal from xdg-desktop-portals, which should then work for most DEs ^^

I've run into an issue with Cinnamon notification actions previously, so was aware of some of this. Thanks for reminding me though. Added to our list, hopefully for 5.4.

Great to hear! Feel free to ping me if you have any questions about xdg-desktop-portals in general

[omergoktas]

I have recently switched to Cinnamon from Gnome and am happy overall due to its established stability and performance, but lacking portal implementation is pretty ugly and feels staggering -FYI.

[mtwebster]

Working on this - https://github.com/mtwebster/xdg-desktop-portal-cinnamon

I don't see much wrong with gtk's implementation of things - at the moment I only plan on handling:

• screenshot interface (for reasons discusssed above)
• wallpaper (so our background settings are updated)
• inhibitor (so the cinnamon screensaver is used as a fallback - this probably is overkill but why not).
• settings (appearance-related, etc...)

I have recently switched to Cinnamon from Gnome and am happy overall due to its established stability and performance, but lacking portal implementation is pretty ugly and feels staggering -FYI.

Can you be specific?

[mikix]

Can I put a vote in for adding a Background portal implementation too?

Some apps (like my own Deja Dup Backups app) need it to support some user flows (like scheduled backups).

[omergoktas]

I.e, on Fedora, Flatpak apps are very typical, and I use them almost as drop-in-replacements for the apps provided by the Official Fedora Repositories (Snap apps are another example for Ubuntu-based distros). Flatpak apps provide a number of advantages over native apps provided by the official distro repos. One significant benefit is their ability to restric system access. Though, as you can imagine, these functionalities are provided by the FreeDesktop's Portal API (i.e., you can't use these security features of the Flatpak if the underlying shell does not fully implement the Portal API (i.e., Cinnamon))

Full scope of the Portal API can be found here: https://flatpak.github.io/xdg-desktop-portal/

(P.S. I don't think a half-broken-half-complete implementation is right way to do, but, you gotta start from somewhere, for sure)

[omergoktas]

So, lastly, none of the security features in the Flatseal app (the community supported GUI app to manage Flatpak Settings) shown below can be used on Cinnamon (controls are disabled like that):

[mtwebster]

Thanks, I'll look into the lockout stuff.

[ghost]

@mtwebster I don't know whom is working on the xdg portal that will be integrated into 21.2, I guess I can assume you're the one working on it, the filechooser API is essential for my workflow because I install xdg-desktop-portal-kde on every desktop because the filechooser for GTK applications is a significant improvement. Please consider adding in filechooser support to the xdg portals that will be used in 21.2. I really need a better filepicker than what GTK provides.

[mtwebster]

@jointri - the Gtk picker has been aggravating me for a while as well. I think it's something we'll end up doing but I'm not sure I'll get to it in the initial release.

[clefebvre]

https://github.com/linuxmint/xdg-desktop-portal-xapp