Forum Debian Users Gang

W Internecie znajdziesz dziesiątki podobnych postów. Dopisałem się do zgłoszenia błędu w Debianie, ale w odpowiedzi usłyszałem, że to wcale nie jest błąd.

Jedynym skutecznym i trwałym rozwiązaniem, jakie znam, jest usunięcie w pliku gimp.desktop wpisu, że GIMP obsługuje PDF-y. Jak kiedyś będę chciał otworzyć PDF-a w GIMP-ie (co zdarzyło mi się raz w życiu), to sobie otworzę GIMP-a i z plik → otwórz wybiorę plik PDF.

Jedyny problem w tym, że ta zmiana zostanie usunięta przy najbliższej aktualizacji. Aby to obejść, ja sobie do /etc/rc.local dopisałem:

if grep -q pdf /usr/share/applications/gimp.desktop; then 
        sed -i -e 's:application/pdf;::' /usr/share/applications/gimp.desktop 
        /usr/bin/update-desktop-database /usr/share/applications/
fi

Nie jest to może najbardziej eleganckie rozwiązanie, ale przynajmniej jest skuteczne.

Podobne możesz chcieć zastosować dla Inkscape'a, który też lubi się czynić domyślną przeglądarką PDF-ów.

Tak, ~/.local ma pierwszeństwo przed /usr/. Więc przekopiowanie pliku .desktop z /usr/ do ~/.local i tam usunięcie irytującego wpisu powinno zadziałać.

Chociaż, oczywiście, w takim przypadku plik .desktop zostaje zamrożony i nie będą uwzględniane ewentualne poprawki po aktualizacji (jak dodanie nowych typów MIME obsługiwanych przez GIMP-a, zmienione opisy i takie tam). Raczej nie będzie to szczególnie uciążliwe, ale warto mieć świadomość tej różnicy.

assogiate wygląda obiecująco

Odświeżę trochę wątek, ponieważ znowu natknąłem się na podobny problem (Opera za domyślną przeglądarkę dokumentów uznawała coś, co nie jest Okularem) i próbowałem go rozwiązać w sposób bardziej subtelny niż usuwanie informacji o obsłudze PDF w odpowiednim pliku .desktop. To, co udało mi się dowiedzieć, zamieszczam poniżej.

1. Opera przy starcie zbiera informacje o dostępnych programach głównie w mimeinfo.cache oraz mailcap. Fragment strace:

open("/home/minio/.local/share//applications/mimeinfo.cache", O_RDONLY) = 37
open("/usr/share/applications/mimeinfo.cache", O_RDONLY) = 37
open("/usr/share/applications/mimeinfo.cache", O_RDONLY) = 37
open("/usr/share/application-registry/gnome-vfs.applications", O_RDONLY) = 37
open("/usr/share/application-registry/gnome-vfs.applications", O_RDONLY) = 37
open("/home/minio/.mailcap", O_RDONLY)  = 37
open("/etc/mailcap", O_RDONLY)          = 37
open("/home/minio/.kde/share/config/profilerc", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/share/applications/defaults.list", O_RDONLY) = 37
open("/usr/share/applications/defaults.list", O_RDONLY) = 37
open("/home/minio/.local/share//mime/aliases", O_RDONLY) = 37
open("/usr/share/mime/aliases", O_RDONLY) = 37
open("/usr/share/mime/aliases", O_RDONLY) = 37
open("/home/minio/.local/share//mime/subclasses", O_RDONLY) = 37
open("/usr/share/mime/subclasses", O_RDONLY) = 37
open("/usr/share/mime/subclasses", O_RDONLY) = 37
open("/home/minio/.local/share//mime/aliases", O_RDONLY) = 37
open("/usr/share/mime/aliases", O_RDONLY) = 37
open("/usr/share/mime/aliases", O_RDONLY) = 37
open("/home/minio/.local/share//mime/subclasses", O_RDONLY) = 37
open("/usr/share/mime/subclasses", O_RDONLY) = 37
open("/usr/share/mime/subclasses", O_RDONLY) = 37
open("/home/minio/.local/share//mime/globs", O_RDONLY) = 37
open("/usr/share/mime/globs", O_RDONLY) = 37
open("/usr/share/mime/globs", O_RDONLY) = 37

2. Nie znalazłem na ten temat słowa w dokumentacji, a na zrozumienie źródeł jestem za cienki w C, ale update-desktop-database (który generuje mimeinfo.cache) najwyraźniej działa w ten sposób, że czyta również pliki w podkatalogach, ale ukośniki zamienia na minusy. Czyli plik /usr/share/applications/kde4/kolourpaint.desktop zostanie w mimeinfo.cache zapisany jako kde4-kolourpaint.desktop. Opera nie bierze tej zmiany pod uwagę i będzie szukać pliku /usr/share/applications/kde4-kolourpaint.desktop, którego oczywiście nie znajdzie. To samo (ukośniki zamienione na minusy) dotyczy pliku defaults.list, o którym będzie mowa w punkcie 5.
Dotyczy to głównie użytkowników KDE, gdyż programy z tego środowiska umieszczają swoje pliki .desktop w podkatalogu kde4. Inne programy wrzucają pliki .desktop do /usr/share/applications/.
Jak widać, podana w mimeinfo.cache ścieżka jest ścieżką relatywną do /usr/share/applications/.

3. Opera listę aplikacji obsługujących dany typ pliku konstruuje na bieżąco, czytając pliki mimeinfo.cache, mailcap i defaults.list. Kolejność elementów na liście jest wyznaczana przez kolejność pojawienia się ich w tych plikach. Kolejnością pojawienia się elementów w plikach mailcap można manipulować poprzez edycję pliku /etc/mailcap.order oraz dopisanie własnych wpisów (wpisy te muszą być umieszczone przed wpisami wygenerowanymi automatycznie). Kolejność pojawienia się elementów w pliku mimeinfo.cache jest najwyraźniej podporządkowana kolejności sortowania w używanej lokalizacji (LC_COLLATE), przy czym najpierw odczytywane są pliki najgłębiej umieszczone w strukturze katalogów (czyli pliki w podkatalogu kde4 mają pierwszeństwo).

4. Opera nie potrafi połączyć wpisów z mimeinfo.cache oraz mailcap z odpowiednimi plikami binarnymi. Dlatego jeżeli jeden program znajduje się w obu z nich, ale pod różnymi nazwami (z dokładnością do wielkości znaków), Opera wyświetla go dwukrotnie — np. „okular” i „Okular”.

5. Domyślną aplikację można sobie ustalić w pliku defaults.list (globalnym w /usr/share/applications/; lokalny jest w ~/.local/share/applications/, ale jak widać po fragmencie strace, Opera nawet nie próbowała go odczytać). Format jest dość prosty:

[Default Applications]
application/pdf=plik.desktop;

Ponownie, podana ścieżka jest ścieżką relatywną do /usr/share/applications/.
Opera domyślną aplikację wyświetla na liście dwukrotnie — na samej górze listy i potem po wpisach z plików mailcap. Zapewne Opera chce być świętsza od papieża (wątek ten rozwinę przy końcu wiadomości) i poprawnie implementuje specyfikację MIME actions. Miałoby to sens — specyfikacja dopuszcza kilka wpisów, więc Opera pierwszy traktuje jako domyślny i dodatkowo wyświetla na górze podmenu, następnie zaś wyświetla je w takiej kolejności jaka tam jest. Nie ma to jednak sensu biorąc pod uwagę, że plik defaults.list jest czytany dopiero po mimeinfo.cache — tak więc Opera wyświetli najpierw programy jak leci, a potem w kolejności ustalonej przez użytkownika (w defaults.list). Innego uzasadnienia dla tego dubla nie znajduję.

6. Zarówno mailcap, jak i pliki .desktop mają mechanizm pozwalający określić, że dany plik ma zostać otwarty w terminalu. Opera jednak go ignoruje. Dlatego radośnie umieści np. lynksa na liście dostępnych przeglądarek, ale nie będzie potrafiła go skutecznie otworzyć.

Nawiasem mówiąc: biorąc pod uwagę punkty 3 i 4, jasne staje się, że bardzo łatwo jest dodać jakiś program do listy wiązanych z danym typem plików przez Operę, ale usunięcie go z niej graniczy z cudem. Trzeba go usunąć zarówno z mimeinfo.cache jak i mailcap. Opera czyta pliki zarówno użytkownika, jak i globalne. Globalne zaś są generowane automatycznie przez Debiana przy niemal każdej instalacji/deinstalacji pakietu. Należy więc zrobić dodatkowy skrypt, który usuwa niepożądane wpisy. Trzeba go dodatkowo uruchamiać w odpowiednim momencie — najlepiej po każdym wywołaniu skryptów postinst lub postrm (które mogą wywoływać aktualizację mimeinfo.cache i mailcap). Ewentualnie można napisać wrapper, który wywoła taki skrypt przed uruchomieniem Opery — w ten sposób Opera zawsze będzie czytać odpowiednio spreparowane pliki. Oczywiście zamiast Opery, należy wtedy uruchamiać ten skrypt.

Tak więc wracając do głównego problemu (Opera nadpisuje Okulara jako domyślną przeglądarkę PDF-ów): przyczyną tego stanu rzeczy jest fakt, że Opera oczekuje innego formatu mimeinfo.cache dla podkatalogów niż jest on w rzeczywistości (zamiana ukośnika na minus). W związku z tym pierwszy wpis dotyczący okulara, jaki znajduje, jest dopiero w plikach mailcap — ale pliki mailcap są czytane po mimeinfo.cache, w których znajdują się wpisy dla dosłownie każdego innego programu obsługującego PDF-y. Najlepszym rozwiązaniem, jakie znalazłem do tej pory, jest modyfikacja defaults.list (opisany w punkcie 5). Rozwiązanie to ma jedną zauważalną wadę — w podmenu „Otwórz w” dla PDF-ów Opera wyświetli aż trzy Okulary (co wynika z punktów 4 i 5 — jeden okular jest z pliku mailcap, a drugi z defaults.list, ale jest niepotrzebnie zdublowany przez Operę).

Na koniec jeszcze parę słów o pochodzeniu mimeinfo.cache — jest to fragment XDG, którego celem jest uspójnienie różnych, sprzecznych ze sobą implementacji obsługi Linuksa na desktopie. Jednym z elementów jest dostarczenie spójnego, dostępnego dla wszystkich systemów, mechanizmu otwierania określonych plików w dostępnych programach. Dotychczas panował w tym straszny bałagan — każde środowisko graficzne miało swój własny mechanizm, wprowadzony przez mutta mailcap stał się de facto standardem dla programów CLI oraz tych, które nie chciały być przywiązane do żadnego środowiska graficznego. XDG dostarcza całą infrastrukturę oraz program xdg-open, który automatycznie dobiera program, w którym należy otworzyć dany plik. Cały problem w tym, że xdg-open jest tymczasowym rozwiązaniem, które w rzeczywistości zadanie to oddelegowuje do programów konkretnych środowisk graficznych. Sam nie w pełni obsługuje swoją własną specyfikację, która — na domiar złego — jest niedopracowana. Prace nad specyfikacją oraz podstawową implementacją posuwają się do przodu w żółwim tempie. W ten sposób po raz kolejny podczas próby standaryzacji czegoś w rzeczywistości wprowadzono tylko większe zamieszanie.