배경 지식으로 저는 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를 올바르게 사용합니다. 다만, 다운로드 위치를 선택할 때 사용하는 파일 관리자의 구성이 다른 것으로 보입니다.
아래 스크린샷에서 볼 수 있듯이 내 OS는 브라우저가 파일을 다운로드하기 위해 여는 창을 "모든 파일"로 정의하고 언급한 대로 창은 노틸러스처럼 보이지만 만약 그렇다면 "노틸러스"가 보일 것으로 예상합니다. "모든 파일" 대신에 이것이 전혀 구성 가능하지 않은지, 아니면 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 MIME 유형 연결을 사용합니다.오직폴더. 이 경우 D-Bus 구성은 중요하지 않습니다. xdg-open은 이를 생성 nautilus <url>하거나 유사하게 만듭니다. (노틸러스 자체는 내부적으로 D-Bus를 사용할 수 있지만 여기서는 이것이 중요한 요소가 아닙니다.)
반면에 브라우저가 폴더를 열려고 하는 경우미리 선택된 항목으로(예를 들어 다운로드한 파일에서 "폴더에서 열기"를 클릭한 경우) 파일 관리자와 직접 통신해야 합니다. 브라우저는 D-Bus 함수 호출을 보냅니다 org.freedesktop.FileManager1. 현재 실행 중인 프로세스에 의해 이름이 요청된 경우 해당 프로세스가 호출을 처리합니다. 이름이 현재 요청되지 않은 경우 dbus-daemon은 파일을 일치시키고 Name=지정된 바이너리를 생성합니다. (해당 .service 파일이 여러 개 발견되면 무작위로 하나 이상을 선택합니다.)
그러나 당신에 관한 한,어느 것도 아니다이런 일들이 일어나고 있습니다. 스크린샷이 표시됩니다.전혀 파일 관리자가 아닙니다– 전통적으로 프로그램의 UI 툴킷에 내장되어 실행되는 파일 선택기 대화 상자입니다.진행 중애플리케이션(브라우저 또는 편집자 등)의 경우. Qt 툴킷으로 구축된 프로그램은 항상 Qt 파일 선택기를 사용합니다.
스크린샷의 파일 선택기는 GNOME 응용 프로그램에서 사용되며 "GTK" UI 라이브러리의 일부이며 어떤 방식으로든 Nautilus 또는 Thunar 파일 관리자와 상호 작용하지 않습니다. 노틸러스와의 유일한 관계는 "위치" 사이드바를 구현하는 코드가 둘 사이에 복사되어 붙여넣어졌기 때문에 노틸러스와 "조금 비슷해 보인다"는 것입니다.
즉, Chromium 기반 브라우저는 GTK를 기반으로 하지 않고 대신 "크로스 플랫폼"으로 표시하고 GNOME 또는 KDE 파일 선택기를 별도의 도우미 프로세스로 실행하려고 하기 때문에 여기서 약간 이상합니다. 예를 들어 Chromium이 한때 zenity --file-selectionGTK3 프로그램이었고 GTK3 파일 선택기를 사용했던 를 실행했던 기억이 납니다 .
최근 Flatpak 및 Snap의 응용 프로그램 샌드박싱 기능의 일부로 대부분의 데스크탑은 샌드박스 응용 프로그램에 호스트 제한 액세스에 대한 액세스를 제공하는 "XDG 포털" 시설의 일부로 파일 선택기를 D-Bus 서비스로 제공합니다. 방금 말씀드린 것과는 다르게 포털에서 제공하는 파일 선택기는예호스트 데스크탑에 따라 달라질 수 있는 완전히 별도의 프로세스입니다. 예를 들어 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 구현이 시작됩니다. Selection 과 KDE는 Qt 구현을 시작하며 둘 다 동일한 D-Bus 서비스 이름을 선언합니다.