在阅读我的问题之前,请不要将其标记为重复。我知道已经有这些问题了,但是现有的答案没有按预期工作,这就是我问这个问题的原因。
已有答案说设置默认文件管理器的方法是xdg-mime default <app name> inode/directory
,使用默认文件管理器定位文件的方法是dbus-send --session --print-reply --dest=org.freedesktop.FileManager1 --type=method_call /org/freedesktop/FileManager1 org.freedesktop.FileManager1.ShowItems array:string:"<path>" string:""
。
但是,当我在一些基于 Arch 的发行版(包括 Arch with Gnome)上对此进行测试时,在安装 Nemo 文件管理器(Gnome 的默认文件管理器是 Gnome Files)之后,该dbus-send
命令并不总是打开指示的文件管理器。xdg-mime query default
在xdg-mime query default inode/directory
输出的同时nemo.desktop
,dbus-send...
上面的命令打开了 Gnome Files,当前者输出“org.gnome.Nautilus.desktop”时,后者打开了 Nemo。(这是没有正在运行的文件管理器的情况。如果已经有文件管理器的实例,dbus-send
命令似乎使用该文件管理器。)
dbus-send
上面的命令是“使用默认文件管理器定位文件”的正确命令吗?虽然dbus-send
上述命令没有按预期工作,但 JetBrain 的 IDE(如 Android Studio 或 IntellJ)使用默认文件管理器正确定位了文件,当我右键单击一个文件,然后单击“打开方式”,然后单击文件管理器的名称时。我想查看他们的源代码,但这些都是巨大的应用程序,尝试搜索他们的源代码没有返回任何结果(我使用了“打开方式”或“文件管理器”等关键字)。
这两个配置彼此无关,因为系统并没有真正统一的“默认文件管理器”概念。仅更改 MIME 类型关联,但对程序尝试通过 D-Bus
xdg-mime
通信时激活的服务绝对没有影响。org.freedesktop.FileManager1
(这有点像 .html 文件和 http:// URL 可以与不同的程序相关联。)
由于遗留原因,dbus-daemon 允许多个
.service
文件声称它们提供相同的服务名称。(这仅在激活尚未运行的服务时才重要;如果该名称已被已运行的进程占用,则不会使用激活。)第一步可能是找出哪些 D-Bus .service 文件提供了名称:
(不要介意文件名与它们显然提供的服务名称不匹配。)
然后通过以下方式覆盖不需要的服务
~/.local/share/dbus-1
:取名的
org.freedesktop.FileManager1.service
其实恰好是Nautilus,所以可以留着:验证是否有效: