☰

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

tag-icon • tag-icon arch-linux i3 d-bus thunar xdg-open
浏览器下载位置文件管理器未使用系统默认文件管理器

作为一些背景知识，我使用 Arch Linux 和 i3 作为我的窗口管理器，最近我停止使用 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

运行初始命令后，这些文件已正确配置。我的理解是，浏览器用于xdg-open确定如何处理打开文件，当单击浏览器下载中的“在文件夹中显示”时，它会正确使用 Thunar。但是，选择下载位置时使用的文件管理器似乎有不同的配置。

如下面的屏幕截图所示，我的操作系统将浏览器打开下载文件的窗​​口定义为“所有文件”，并且如前所述，该窗口看起来像 Nautilus，但如果是的话，我希望看到“Nautilus”而不是“所有”文件”。所以我不确定这是否根本无法配置，或者我是否错过了需要更新以指向 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 来确定哪个（如果有的话）将处理我的浏览器和系统默认值之间的交互。

答案1

程序在想要打开时使用 XDG mimetype 关联只是文件夹。在这种情况下，D-Bus 配置并不重要 – xdg-open 只会生成nautilus <url>或类似的。 （Nautilus 本身可能在内部使用 D-Bus，但这不是这里的一个因素。）

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

然而，就你而言，两者都不这些事情正在发生。你的截图显示的是根本不是文件管理器– 它是一个文件选择器对话框，传统上内置于程序的 UI 工具包中并运行进行中对于应用程序（浏览器或编辑器等）。使用 Qt 工具包构建的程序将始终使用 Qt 文件选择器。

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

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

最近，作为 Flatpak 和 Snap 中应用程序沙箱功能的一部分，大多数桌面现在将其文件选择器作为 D-Bus 服务提供，作为“XDG Portals”设施的一部分，该设施为沙箱应用程序提供对主机的有限访问。与我刚才所说的不同，门户提供的文件选择器是一个完全独立的进程，可能会根据主机桌面的不同而有所不同，例如，Flatpak GTK3 程序在 KDE 中运行时将使用 Qt 文件选择器。

Chromium 在尝试与两个桌面集成时，现在似乎故意使用文件选择门户（即使它是不是在 Snap 或 Flatpak 沙箱内运行）。这意味着无论哪个xdg-desktop-portal-*进程正在运行（例如 GTK4 或 Qt6）将为 Chromium（以及 Firefox）以及您可能拥有的任何 Flatpak 或 Snap 容器化应用程序提供文件选择器。

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

相关内容