浏览器下载位置文件管理器没有使用系统默认文件管理器。

Question

作为背景，我使用带有i3的Arch作为窗口管理器，最近我停止使用Nautilus作为我的默认文件管理器，并开始使用Thunar。我使用的浏览器是Brave，我已经将它配置为在下载之前应该将下载的文件保存在哪里，问题是在选择下载位置时出现的文件管理器不是Thunar，而是Nautilus，尽管它是从我的操作系统中卸载的。我的猜测是，这实际上不是Nautilus，但如果可能的话，我希望下载文件时出现的文件管理器是Thunar。

因此，作为一个明确的问题，在选择下载位置时，如何更新浏览器以使用系统的默认文件管理器？

我已经尝试过的

我已经指定Thunar作为我的系统的默认文件管理器，使用下面的内容，这是有效的，但不适用于浏览器下载位置文件管理器。

xdg-mime default thunar.desktop inode/directory

为了尝试并解决这个问题，我尝试更新以下文件位置以手动更新inode/directory的默认应用程序：

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

运行intial命令后，这些文件已经正确配置。我的理解是，浏览器使用xdg-open来确定如何处理打开文件的问题，当单击浏览器下载中的"Show文件夹“时，Thunar正确地使用了Thunar。但是，对于选择下载位置时使用的文件管理器，它似乎是一种不同的配置。

如下面的屏幕截图所示，我的操作系统将浏览器打开的下载文件的窗口定义为" Nautilus“，正如前面提到的，窗口看起来像Nautilus，但如果是的话，我希望看到的是”Nautilus“而不是"All Files”。因此，我不确定这是简单的不可配置的，还是我遗漏了一些需要更新的东西来指向Thunar。

除此之外，我还尝试查看了我的Dbus设置，并注意到有些人有一个文件/usr/share/dbus-1/services/org.freedesktop.FileManager1.service，我添加了以下内容，但没有解决我的问题。

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

我不太熟悉xdgutils或Dbus，以确定我的浏览器和系统默认值之间的交互(如果两者都是)。

Answer 1

当程序只想打开文件夹时，程序使用XDG mimetype关联。在这种情况下，D总线配置并不重要-xdg只会产生nautilus 或类似的。(Nautilus本身可能在内部使用D总线，但这不是其中的一个因素。)

另一方面，如果您的浏览器想要打开带有预先选择的项目的文件夹(例如，如果您为下载的文件单击“打开文件夹”)，那么它需要直接与文件管理器对话。浏览器将向org.freedesktop.FileManager1发送一个D总线函数调用--如果该名称当前由运行中的进程声明，则该进程将处理该调用；如果该名称目前未声明，则dbus-守护进程将查找具有匹配Name=的.service文件，并生成指定的任何二进制文件。(如果它找到多个这样的.service文件，它会随机选择一个或更少。)

然而，在你的例子中，这两件事都没有发生。屏幕截图显示的是not文件管理器(文件管理器)，它是一个文件选择对话框，传统上是为程序的UI工具包提供内置功能，并为应用程序(浏览器或编辑器等)在进程中运行。使用Qt工具包构建的程序总是使用Qt文件选择器。

GNOME应用程序使用的截图中的文件选择器是'GTK‘UI库的一部分，并且不以任何方式与Nautilus或Thunar文件管理器交互。它与Nautilus的唯一关系是它“看起来有点像”Nautilus，因为实现‘Place’侧栏的代码是复制粘贴在两者之间的。

尽管如此，基于铬的浏览器在这里还是有点奇怪，因为它们不是基于GTK的，而是试图显示“跨平台”，并将GNOME或KDE文件选择器作为单独的辅助进程运行。例如，我似乎还记得铬曾经运行zenity --file-selection，这本身就是一个GTK3程序，并且使用GTK3文件选择器。

最近，作为Flatpak和Snap应用程序沙箱功能的一部分，大多数桌面现在都提供他们的文件选择器作为D总线服务，作为"XDG门户“工具的一部分，该工具允许沙箱应用程序有限地访问主机。与我前面所说的不同，门户提供的文件选择器是一个完全独立的过程，可以根据主机桌面的不同而变化，例如，在KDE中运行时，Flatpak GTK3程序将使用Qt文件选择器。

在试图与两台桌面进行集成的过程中，or现在似乎有意使用文件选择门户(即使它没有在Snap或Flatpak沙箱中运行)。这意味着，无论哪个 xdg-desktop-portal-* process正在运行(例如，GTK4 1或Qt6 GTK4)，都将为Chromium (以及Firefox )提供文件选择器，以及您可能拥有的任何Flatpak或Snap容器应用程序。

(启动时，主xdg-desktop-portal进程使用$XDG_CURRENT_DESKTOP或$XDG_SESSION_DESKTOP --不确定哪一个--为您登录的任何桌面环境生成适当的实现。因此，如果您正在运行GNOME，它将启动门户的GTK实现，包括文件选择器，而KDE将启动一个Qt实现，两者都具有相同的D总线服务名称。