Offer Thunar specific file selection dialog via DBus Service "org.freedesktop.portal.FileChooser"

So that all applications which want to pick a file, will see the thunar dialog, instead of the foreign GtkFileChooserDialog.

This dbus API seems to be used by xdg-desktop-portal-gtk and xdg-desktop-portal-kde,

The reason to offer such a dialog/service in thunar would be, that the 'known stuff' could be used, no need to get used to the different ui/ux of GtkFileChooserDialog.

I would not aim to support the full portal interface. Just this single service for now (Not a problem for thunar, since it anyhow runs as daemon)

Implementation:

The main thing to consider is, that existing widgets should be re-used as much as possible.Probably ThunarWindow could be extended/used as parent widget to inherit from. Or possible we need a abstract base-class and ThunarFileChooserDialog and ThunarWIndow inherit from that.

For more info, check the https://gitlab.freedesktop.org/xdg/xdg-specs/-/issues/64

added 2. Feature 5. Dialogs labels

changed title from Offer Thunar File Selection Dialog via DBus Service "org.freedesktop.portal.FileChooser" to Offer Thunar specific file felection dialog via DBus Service "org.freedesktop.portal.FileChooser"

To be checked: Is it a prerequirement to be able to use portal services in xfce to have a service xdg-desktop-portal-xfce ? Or should we just provide the required DBus Service directly in thunar ?

changed title from Offer Thunar specific file felection dialog via DBus Service "org.freedesktop.portal.FileChooser" to Offer Thunar specific file selection dialog via DBus Service "org.freedesktop.portal.FileChooser"

mentioned in issue apps/xfce4-screenshooter#46 (closed)

Thank you for your efforts in helping with the filechooser issue. The more I think about it, the more I believe that the only solution is for Gtk and Qt to give the users the option of using their own preferred file manager and/or allow customization of the interface.

It's not something gtk/Qt has to do. It's a matter of available DBus Services in Thunar. Thunar does not implement the related Service specified in "xdg-desktop-portal" yet. (And so far there is no xdg-desktop-portal-xfce)

Thank you for the info. I'm still trying to figure it all out. However, I do know this; it would have been better if the environment was so designed to have allowed all programs to automatically look to the default file manager for all file-related activities.

I confess that I do not understand why this was never done, even though it seems so fundamental in designing an OS system. But with that said, we now are stuck with these problems.

From what I have gathered, the reason my Xfce-based system has what looks like a trimmed down version of Files as a dialog window is because of GtkFileChooserDialog and no other reason. The same problem applies to those using a Qt-based environment, only they use the QFileDialog Class.

What I understand is that you are attempting to have Thunar be available thru the Dbus mechanism of a "portal".

I remain curious as to what a portal is, and how this may apply to the basic problem of changing the default "chooser".

mentioned in issue #776 (closed)

Hi, I'm not sure if this issue is still being looked at, but I just wanted to add my two cents. I'm the maintainer of Native File Dialog Extended, which has a C wrapper over the D-Bus portal interface.

Linux does not have a file chooser baked into the OS, and so GTK and Qt come with their own file choosers, which look quite different from one another.

Then Flatpak came around with a standardized interface (xdg-desktop-portal and the associated backends) so that their sandboxed applications can request a file from the user. Flatpak's backend came with the ability to customize the file chooser that was used (e.g. xdg-desktop-portal-gtk or xdg-desktop-portal-kde), which allowed distros can pick a file chooser that fits the UI theme. But its use expanded beyond Flatpak, and non-Flatpak applications started using the portal to open the "native" (or user-specified) file chooser. That's where we're at --- this portal thing is now the de-facto way to open the "correct" file chooser, instead of linking in GTK or Qt and forcing the user to use either of them. If XFCE wants applications to be able to show a file chooser that fits with XFCE's theme, then there needs to be a portal backend for it, since applications seeking to open the native file chooser will make a call through this portal interface. This post has a nice explanation.

Is it a prerequirement to be able to use portal services in xfce to have a service xdg-desktop-portal-xfce?

It's a pre-requirement to open a file chooser through the portal interface, but this isn't a hard requirement of a Flatpak application. It's possible to declare a Flatpak application as requiring special permissions to access the filesystem (or a particular directory in it) - I've seen it done in ImHex until I asked them to switch to the portal interface.

However, it is a pre-requirement if you want applications (that attempt to use the preferred dialog in the de-facto manner) to be actually able to show the correct dialog.

Thank you for all the details @btzy !

I'm not sure if this issue is still being looked at

Currently it is apandoned (I offered this issue as project idea for GSoC2022 .. though no participant took the bait .. maybe next year) Though if you are interested, a MR would be very welcome !

Is it a prerequirement to be able to use portal services in xfce to have a service xdg-desktop-portal-xfce?

It's a pre-requirement to open a file chooser through the portal interface,

Sorry, I think I should formulate my question in a better way: Does it make sense to just register the DBUS Service within the thunar-daemon, which anyhow runs in the background (Like we already do for the dbus service org.freedesktop.FileManager1)

Or should we rather implement a new xfce-specific xdg-portal-service daemon, which could as well manages other services which are possibly of interest.

Hmm, after re-reading your reply, perhaps you mean whether the same thunar-daemon can register the org.freedesktop.impl.portal.FileChooser interface as well. I don't know if that would work, but that's certainly not the convention.

In the end, it's just a DBUS service, so I suppose it would work.

The benefit would be, that we dont need to implemenet a whole, additional package, just for that single thunar feature. If there should be interest for other portal services later on, we still could move the service to a xdg-desktop-portal-xfce.

Yeah, I agree, and I can't think of any reason why it wouldn't work.

Please forgive me for seeming dense, but could we summarize this by saying that the need for a so-called "file chooser" dialog can be replaced by some sort of "portal" function?

Sorry, I think I should formulate my question in a better way: Does it make sense to just register the DBUS Service within the thunar-daemon, which anyhow runs in the background (Like we already do for the dbus service org.freedesktop.FileManager1)

I'm not too sure about this, but I think if you directly register org.freedesktop.portal.FileChooser, applications that are actually sandboxed by Flatpak might not work, because the frontend (xdg-desktop-portal) is part of the sandboxing mechanism. Maybe this design considerations section of the xdg-desktop-portal repo readme might clarify things. According to that repo, xfce will need to implement the org.freedesktop.impl.portal.* interfaces.

Please forgive me for seeming dense, but could we summarize this by saying that the need for a so-called "file chooser" dialog can be replaced by some sort of "portal" function?

Yes, precisely :) Instead of having the application bundle a file chooser with it, by using the portal interface the application is requesting to show a file chooser that is already installed in the system.

Yes, precisely :) Instead of having the application bundle a file chooser with it, by using the portal interface the application is requesting to show a file chooser that is already installed in the system.

I love that!

Next question is how do we get it implemented? Can we install something directly, or must each application be tweaked to look for the portal, or can it be done at the DE level (such as throughout Xfce)? Please make this a little clearer.

Thanks.

Next question is how do we get it implemented? Can we install something directly, or must each application be tweaked to look for the portal, or can it be done at the DE level (such as throughout Xfce)? Please make this a little clearer.

It's both:

• Each application must be written to use the portal. Many good applications are written to use this portal already, since there is currently a choice between the GTK and KDE file chooser backends (and perhaps a few others I don't remember), and users want to see their favourite file chooser. For example, Firefox can be made to use the portal by exporting GTK_USE_PORTAL=1. Applications typically use GtkFileChooserNative, the equivalent in Qt, or standalone libraries like mine --- all these libraries are wrappers over the underlying D-Bus portal call.
• The desktop environment (in this case XFCE) needs to supply the actual file chooser implementation by registering a listener on the org.freedesktop.impl.portal.FileChooser D-Bus interface and acting upon requests that it receives on that interface (by presenting a file chooser to the user).

The desktop environment (in this case XFCE) needs to supply the actual file chooser implementation by registering a listener on the org.freedesktop.impl.portal.FileChooser D-Bus interface and acting upon requests that it receives on that interface (by presenting a file chooser to the user).

Are you implying that Xfce could intercept and redirect requests from apps?

Are you implying that Xfce could intercept and redirect requests from apps?

Well I wouldn't really call it intercepting and redirecting requests, because the org.freedesktop.impl.portal.FileChooser interface is meant for third-party handlers (like XFCE) to listen to.

changed the description

mentioned in issue #897 (closed)

mentioned in issue #926 (closed)

mentioned in issue xfce4-session#159

marked this issue as related to xfce4-session#159

mentioned in issue #1074 (closed)

added 5. User Experience (UX) label

mentioned in issue xfdesktop#248

marked #1098 (closed) as a duplicate of this issue

marked this issue as related to #1098 (closed)

mentioned in issue #1154 (closed)

marked #1154 (closed) as a duplicate of this issue

marked this issue as related to #1154 (closed)

mentioned in issue xfce4-session#181 (closed)

Since xdg-desktop-portal 1.17, if Thunar wants to do this, it will need to coordinate with whichever component provides xfce-portals.conf: see xfce4-session#181 (closed).

mentioned in issue #1241 (closed)

mentioned in issue #1416 (closed)