Domyślna lokalizacja ikon wskaźników innych niż domyślne?
Nie ma domyślnej lokalizacji, w której przechowywane są te ikony. Każda aplikacja (-developer) może przechowywać je tam, gdzie zostanie to uznane za właściwe.
Jednak dobrą wiadomością jest to, że wskaźniki zwykle nie instalować niekończące się listy plików i obrazów. Możemy ograniczyć nasze wyszukiwanie poprzez (oprócz patrzenia na kod) spojrzenie na wynik polecenia:
dpkg-query -L <packagename>
W moim przykładzie
dpkg-query -L placesfiles
w wyniku tego powstałyby następujące obrazy:
/opt/placesfiles/images/dir_icon.png
/opt/placesfiles/images/placesfiles64.png
/usr/share/pixmaps/placesfiles.png
... Co ograniczyłoby wyszukiwanie.
Od człowieka dpkg-query
:
-l, --list [package-name-pattern...]
List packages matching given pattern. If no package-name-pattern
is given, list all packages in /var/lib/dpkg/status, excluding
the ones marked as not-installed (i.e. those which have been
previously purged). Normal shell wildcard characters are allowed
in package-name-pattern. Please note you will probably have to
quote package-name-pattern to prevent the shell from performing
filename expansion. For example this will list all package names
starting with “libc6”:
W przypadku Radiotray znalazłem następujące .png
pliki (działające dpkg-query -L radiotray | grep png
):
/usr/share/radiotray/images/radiotray_connecting.png
/usr/share/radiotray/images/radiotray_on.png
/usr/share/radiotray/images/radiotray_off.png
/usr/share/radiotray/images/radiotray.png
/usr/share/pixmaps/radiotray.png
Jeśli naprawdę musimy się dowiedzieć, przeszukujemy kod
... możemy przeglądać (wewnątrz) zainstalowane pliki pod kątem dopasowania ciągu „ikona”. Wiele wskaźników jest napisanych w jednym z języków skryptowych (jak python
), co oznacza, że można je bardzo łatwo przeszukiwać.
Przykład
Ponownie korzystając z radiotray
przykładu
dpkg-query -L radiotray | xargs grep icon
w danych wyjściowych znajduje się:
/usr/lib/python2.7/dist-packages/radiotray/SysTrayGui.py
self.icon.set_from_file(APP_ICON_CONNECT)
Przeglądając plik SysTrayGui.py
, możemy zobaczyć:
from lib.common import APPNAME, APPVERSION, APP_ICON_ON, APP_ICON_OFF, APP_ICON_CONNECT, APP_INDICATOR_ICON_ON, APP_INDICATOR_ICON_OFF
Na tej podstawie możemy wywnioskować, że wspomniane ikony są zdefiniowane w module common
wewnątrz (pod) katalogu lib
. (Zobacz tutaj, jak Python znajduje to moduły, sekcja Podkatalogi )
W tym module możemy przeczytać sekcję:
# Media path
if os.path.exists(os.path.abspath('../data/images/')):
IMAGE_PATH = os.path.abspath('../data/images/')
else:
IMAGE_PATH = '%s/%s/images' % (datadir, APPDIRNAME)
# Images
APP_ICON = os.path.join(IMAGE_PATH, 'radiotray.png')
APP_ICON_ON = os.path.join(IMAGE_PATH, 'radiotray_on.png')
APP_ICON_OFF = os.path.join(IMAGE_PATH, 'radiotray_off.png')
APP_ICON_CONNECT = os.path.join(IMAGE_PATH, 'radiotray_connecting.gif')
APP_INDICATOR_ICON_ON = "radiotray_on"
APP_INDICATOR_ICON_OFF = "radiotray_off"
APP_INDICATOR_ICON_CONNECT = "radiotray_connecting"
...i oto jesteśmy...
Wyjątkowe sytuacje
Po praktycznym zastosowaniu wszystkich moich wskaźników udało mi się znaleźć odpowiednie ikony, korzystając z powyższych metod.
Okazuje się jednak, że jest możliwe skompilowanie obrazów wraz z kodem w jeden plik wykonywalny. Nie musisz wyjaśniać, że w takich przypadkach nie znajdziesz osobnego obrazu ani nie będziesz mógł go zastąpić bez edycji kodu i ponownej kompilacji.
Tak wygląda przypadek własnej chmury. Zastosowanie powyższych metod pokazało, że zestaw ikon został zainstalowany w środku /usr/share/icons/hicolor/<size>/apps
. Żadna z tych ikon nie okazuje się być jednak używana we wskaźniku na Ubuntu .
OP wykonał sporo pracy przed (i po) pytaniem. Jednym z nich było uruchomienie:
gdbus call --session --dest com.canonical.indicator.application --object-path /com/canonical/indicator/application/service --method com.canonical.indicator.application.service.GetApplications
... co daje nam całkiem przydatne informacje. Dane wyjściowe zawierały sekcję:
('146028888067', 2, 'org.kde.StatusNotifierItem-22055-1', '/StatusNotifierItem/menu', '/tmp/iconcache-50ePXx', '', '', '', 'owncloud', 'ownCloud')
Przeglądając katalog /tmp/iconcache-50ePXx
, znalazłem dokładne ikony, których używał wskaźnik:
... co wydaje się dowodzić, że te ikony są generowane w locie; zamknięcie owncloud powoduje zniknięcie katalogu i jego ikon.
Okazało się, że można zmienić ikonę wskaźnika, zastępując te ikony:
co dowodzi, że rzeczywiście były to ikony, których szukaliśmy.
Jednak aby zautomatyzować to, co zrobiłem ręcznie, wymaga skryptu / opakowania, ponieważ nazwa utworzonego katalogu jest zmieniana przy każdym uruchomieniu owncloud. Najwygodniejszą opcją byłoby oczywiście zmodyfikowanie kodu klienta własnego klienta.
Zobacz także naszą dyskusję tutaj .
Ciąg dalszy nastąpi...
dpkg -L
robi tego samego?dpkg-query -L
. Wyszukiwaniefind / -name state-ok -type f
wygląda na to, że utknęło w martwym punkcie, ale zostawię to na noc./usr/share/icons/hicolor/<size>/apps
. Niestety, plik .deb nie instaluje się:Errors were encountered while processing:
Ikony i ich potencjalne lokalizacje
Istnieją dwa sposoby wykorzystania ikon przez wskaźnik:
/usr/share/pixmaps/
, chociaż niektórzy autorzy mogą wysyłać ikony wskaźników do innych katalogów. Jacob Vlijm, którego odpowiedź znajduje się na tej stronie i który jest także autorem wskaźnika SpaceView, na przykład zdecydował się umieścić w nim ikony tego wskaźnika/opt/spaceview/icon
. Z tego rodzaju ikonami jest to nieco trudne, ale nie skomplikowane - użyjdpkg -L <package name>
lubcat /var/lib/dpkg/info/PACKAGE.list
i wyszukaj plik ikon, z rozszerzeniem.png
lub.svg
. Te są najbardziej typowe/usr/share/icons
folderze. Na przykład w moich wskaźnikach, takich jak Udisks Indicator, często polegam na tym, co jest/usr/share/icons/gnome
, ponieważ są one standardowe i są dostarczane z każdą instalacją Ubuntu. Jeśli nie znajdziesz ikony z zapytaniadpkg
, istnieje szansa, że pakiet używa standardowej ikony.Idę do źródła
Jeśli wskaźnik jest napisany w języku Python lub Ruby, przeglądanie kodu źródłowego w poszukiwaniu wskazówek może być stosunkowo łatwe, ponieważ są to skrypty i wystarczy użyć go
grep
do przeszukiwania kodu źródłowego. Skompilowane języki, takie jak C i Vala, nie są dostarczane z kodem źródłowym, więc musisz go uzyskać za pośrednictwemapt-get source package-name
lub z dowolnego miejsca, w którym pakiet został uzyskany. (Żądni przygód użytkownicy mogą użyćhexdump
lub zdekompilować plik wykonywalny, ale IMHO to zbyt wiele pracy dla samej ciekawości ikony).UWAGA : jeśli ikona znajduje się w jednym ze standardowych katalogów, takich jak
/usr/share/icons/
lub/usr/share/pixmaps
, autor oprogramowania może wybrać wywołanie ikony po prostu z nazwy, bez rozszerzeń. Na przykład w mojejudisks-indicator
używam tej linii do wywołania jednej ze standardowych ikon:Zauważ brak
.svg
lub.png
rozszerzenie. Dlatego w tym przypadku mamy nazwę ikony i możemy ją zlokalizować za pomocą standardowych poleceń Linuksa, takich jaklocate
lubfind
.Wyszukaj za pomocą standardowych narzędzi Linux
Jeśli naprawdę chcesz mieć polecenie wyszukiwania ikon, użyj tej prostej kombinacji:
Oto przykład. Wiem na pewno, że wskaźnik diskman używa niestandardowej ikony. Co więc mówi nam to polecenie?
Zwróć uwagę
/usr/share/pixmaps/indicator-diskman.png
na ostatni obraz, który faktycznie pokazuje wskaźnik na panelu.A jeśli wskaźnik używa standardowej ikony? Cóż, oczywiście nie będzie wyjścia:
Wniosek
Chociaż nie ma ustalonego standardu, istnieje zestaw typowych miejsc, do których idą ikony, i możemy użyć
dpkg
do zapytania informacji o tym, jakie pliki są dostarczane z każdym konkretnym pakietem. Wreszcie, być może nie jest to najbardziej techniczna sugestia, ale rozważ wysłanie programistom wiadomości e-mail lub zatrzymanie się przez IRC lub czat i po prostu z pytaniem „Hej, jakiej ikony używa twój wskaźnik?”. Programiści zazwyczaj chętnie słuchają informacji od osób korzystających z ich oprogramowania i nie mają nic przeciwko, aby odpowiedzieć na szybkie pytanie.źródło
/tmp
, nie jest to praktyczne. Dostosowanie ich do większości aplikacji jest jednak łatwe przy użyciu odpowiedzi, ponieważ używają zainstalowanych zestawów ikon.