search

flatpak / xdg-desktop-portal-gtk

Gtk implementation of xdg-desktop-portal
GNU Lesser General Public License v2.1
126 stars 98 forks source link

Move GNOME specific portal backends to GNOME #120

Open jadahl opened 6 years ago

jadahl commented 6 years ago

xdg-desktop-portal-gtk currently uses private GNOME API for some of the backends. This has a couple of implications.

  1. Private API stability is not guaranteed, and can be assumed to occasionally change from version to version, which puts xdg-desktop-portal-gtk in an awkward position where we need to handle multiple API versions. It also requires the API's to have versions, even though they are private and only expected to be usable from within the same GNOME platform version.

  2. One day we want more than just GNOME to be able use the GTK+ using parts of the backend. Does that mean we, when the day comes, want to maintain every GTK+ based desktop environments (such as Budgie, Cinnamon, Pantheon, XFCE, ...) private API using backends in xdg-desktop-portal-gtk?

Both these problems could be solved if we split up xdg-desktop-portal-gtk into a generic GTK+ part, and a GNOME part, where the GNOME part is turned into a GNOME platform component (e.g. xdg-desktop-portal-gnome), put in GNOME's gitlab, and tied to the GNOME release schedule. This will put the same expectations on other GTK+ using environments.

matthiasclasen commented 6 years ago

I'm not very concerned about this.

For the first point, the portal is generally shipped together with the desktop shell, as part of the host OS. It should not be too difficult for the provider of the host OS to make sure that the versions of supported apis match.

For the second point, we already have a mechanism in place to gracefully drop support for individual portal apis when the necessary backend is not found, which seems easy enough to keep doing, rather than splitting this into two separate processes.

soredake commented 3 years ago

Any progress on this?

soredake commented 3 years ago

@matthiasclasen

vially commented 3 years ago

In light of the conversation from https://github.com/flatpak/flatpak/issues/2861, maybe this should be reconsidered?

The current situation makes it impossible for users to only get the GTK functionality from xdg-desktop-portal-gtk without pulling in the GNOME parts too, which was reported to have unintended side-effects (https://github.com/flatpak/flatpak/issues/2861#issuecomment-743750577) for users of non-GNOME desktop environments.

IlgazC commented 3 years ago

Isn't the idea behind flatpak to free user&developer from installing hundreds of packages to get simple functionality working? To fix font rendering of GTK apps on openSUSE Tumbleweed I am installing the entire gnome which consists of 506 packages as of today. As it is a rolling release, this guarantees 100-200s of updates once gnome is updated. Flagship apps like GIMP, Handbrake are all effected by font rendering bug https://github.com/flatpak/flatpak/issues/2861

matthiasclasen commented 3 years ago

Reopening this, since there's renewed consideration of a move / split where we would move just the gnome-specific portals out of this repository.

GeorgesStavracas commented 3 years ago

I have an initial, probably not functional implementation of xdg-desktop-portal-gnome here: https://gitlab.gnome.org/feaneron/xdg-desktop-portal-gnome/

Eventually it'll move to GNOME/xdg-desktop-portal-gnome, but I think we can do some rounds of improvements there first.

matthiasclasen commented 3 years ago

We've now added configure options to disable the gnome-specific portals

616b2f commented 2 years ago

@matthiasclasen how can I use this option?

mcatanzaro commented 2 years ago

We've now added configure options to disable the gnome-specific portals

This issue should be closed now.

how can I use this option?

You shouldn't need to once we fix #355, but in the meantime you can build with e.g. --enable-settings, --enable-appchooser.

nielsdg commented 2 years ago

This issue should be closed now.

I agree here, but I wonder if this split could be explained a bit in the README before closing, so people can easily find the appropriate place to file bugs.