0

As a bit of background, I'm using Arch Linux with i3 as my window manager and I recently stopped using Nautilus as my default file manager and started using Thunar. The browser I'm using is Brave and I have it configured to ask where a downloaded file should be saved prior to downloading, the problem I'm having is that the file manager that appears when selecting the download location is not Thunar and appears to be Nautilus even though it is uninstalled from my OS. My guess is that it's not actually Nautilus but if possible I would like the file manager that appears when downloading files to be Thunar.

So as a definitive question, how can I update my browser to use my system's default file manager when selecting a download location?

What I have tried

I have specified Thunar as the default file manager for my system using the below, which worked but not for the browser download location file manager.

xdg-mime default thunar.desktop inode/directory

To try and solve for this I have tried updating the following file locations to manually update the default application for inode/directory:

  • /usr/share/application/mimecache.info
  • ~/.config/mimeapps.list
  • ~/.config/mimeinfo.cache
  • ~/.local/share/applications/mimeapps.list
  • ~/.local/share/applications/mimeinfo.cache

These files were already configured correctly after running the intial command. My understanding is that the browser uses xdg-open to determine how to handle opening a file, which correctly uses Thunar when clicking "Show in folder" in the browser Downloads. However, It seems to be a different configuration for the file manager used when selecting a download location.

As seen in the screenshot below, my OS defines the window that the browser opens to download a file as "All Files" and as mentioned before the window looks like Nautilus but if it was I would expect to see "Nautilus" instead of "All Files". So I'm not sure if this is simply not configurable or if I missed something that needs to be updated to point to Thunar.

enter image description here

In addition to this I have tried looking at my Dbus settings and noticed that some people have a file /usr/share/dbus-1/services/org.freedesktop.FileManager1.service which I added with the following content, but didn't solve my problem.

[D-BUS Service]
Name=org.freedesktop.FileManager1
Exec=/usr/bin/thunar --gapplication-service

I'm not that familiar with xdgutils or Dbus to identify which (if either) would be handling this interaction between my browser and system defaults.

1 Answer 1

0

Programs use XDG mimetype associations when they want to open just the folder. In that case, D-Bus configuration would not matter – xdg-open would just spawn nautilus <url> or similar. (Nautilus itself might use D-Bus internally, but that is not a factor here.)

On the other hand, if your browser wants to open the folder with an item pre-selected (e.g. if you clicked "Open in folder" for a downloaded file), then it needs to directly talk to a file manager. The browser will send a D-Bus function call to org.freedesktop.FileManager1 – if that name is currently claimed by a running process, then that process will handle the call; if the name is not currently claimed then dbus-daemon will look for a .service file with a matching Name= and will spawn whatever binary is specified. (If it finds multiple such .service files, it chooses one more-or-less at random.)

In your case, however, neither of those things is happening. What your screenshot shows is not a file manager at all – it's a file picker dialog, which is traditionally provided built-in to the program's UI toolkit and would run in-process for the app (browser or editor or such). A program built using the Qt toolkit would always use the Qt file picker.

The file picker in your screenshot, used by GNOME apps, is part of the 'GTK' UI library and does not interact with the Nautilus or Thunar file managers in any way. The only relationship it has with Nautilus is that it "looks a bit like" Nautilus, as the code implementing the 'Places' side-bar is copy-pasted between the two.

That being said, Chromium-based browsers are a bit of an odd one here, as they are not GTK-based, instead trying to appear "cross-platform" and running either the GNOME or KDE file picker as a separate helper process. For example, I seem to remember that Chromium used to run zenity --file-selection, which itself is a GTK3 program and uses the GTK3 file picker.

Recently, as part of the app sandboxing features in Flatpak and Snap, most desktops now offer their file picker as a D-Bus service, as part of the "XDG Portals" facility that gives sandboxed apps limited access to the host. Unlike what I just said earlier, the file picker provided by the portal is a completely separate process which can vary depending on the host desktop, e.g. a Flatpak GTK3 program would use the Qt file picker when it's run in KDE.

Chromium, in its attempt to integrate with both desktops, now appears to deliberately use the file selection portal (even if it is not running inside a Snap or Flatpak sandbox). This means that whichever xdg-desktop-portal-* process is running (e.g. the GTK4 one or the Qt6 one) will be the one to provide the file picker for Chromium (and for Firefox as well), as well as any Flatpak or Snap containerized apps you might have.

(On startup, the main xdg-desktop-portal process uses either $XDG_CURRENT_DESKTOP or $XDG_SESSION_DESKTOP – not sure which – to spawn the appropriate implementation for whatever desktop environment you're logged in to. So if you are running GNOME, it will start the GTK implementation of portals, including the file picker, and KDE will start a Qt implementation, both claiming the same D-Bus service name.)

3
  • +1 This is extremely useful information and helps be better understand what is happening under the hood. Zenity is particularly useful to see because I am now noticing that Firefox seems to use that and it does appear as if Chromium is using xdg-desktop-portal-gtk. Both browsers display different file pickers but I can control Firefox's by using GTK_USE_PORTAL=1 firefox. Do you know if it's possible to modify the file picker Chromium uses without changing the underlying desktop toolkit? For some context, both $XDG_CURRENT_DESKTOP and $XDG_SESSION_DESKTOP are i3. Commented May 1, 2023 at 16:30
  • As a follow up based on the information @user1686 provided above, I was able to find this post which partially solved my problem in a way that I'm satisfied with the result. In summary I had xdg-desktop-portal, xdg-desktop-portal-gtk, and xdg-desktop-portal-gnome all installed, I uninstalled xdg-desktop-portal-gnome and restarted xdg-desktop-portal (shown in post) and now Chromium is no longer using the Gnome file picker but what I assume is the GTK file picker. Commented May 1, 2023 at 16:49
  • The GTK file picker is the "GNOME file picker", as all GNOME programs are built using GTK – what you showed in the screenshot was the one from GTK4 (with GTK3 looking very nearly the same). Compare the "Pickers" section in gtk-demo (gtk2), gtk3-demo (gtk3-demos), and in gtk4-demo (gtk4-demos). Do you have a screenshot of what you're seeing with the new setup? Commented May 1, 2023 at 16:57

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .