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?