J'aimerais trouver l'emplacement des icônes utilisées par certains menus d'état autres que ceux par défaut (également appelés indicateurs d'application ou applets d'indicateur).
Où se trouvent ces fichiers d'images d'icônes ?
Dans ma capture d'écran, j'ai ownCloud et Radiotray, mais j'aimerais une réponse générale non spécifique à ces icônes particulières, s'il vous plaît. Je ne connais pas les noms ou les types de fichiers, la recherche est donc difficile.
Réponse acceptée :
Emplacement par défaut pour les icônes d'indicateur non par défaut ?
Il n'y a pas d'emplacement par défaut où ces icônes sont stockées. Toute application (-développeur) peut les stocker là où cela est jugé approprié.
Cependant , la bonne nouvelle est que les indicateurs n'installent généralement pas de listes interminables de fichiers et d'images. Nous pouvons limiter notre recherche (en plus de regarder dans le code) en regardant la sortie de la commande :
dpkg-query -L <packagename>
Dans mon exemple de
dpkg-query -L placesfiles
cela produirait entre autres les images suivantes :
//eadn-wc01-5196795.nxedge.io/opt/placesfiles/images/dir_icon.png
//eadn-wc01-5196795.nxedge.io/opt/placesfiles/images/placesfiles64.png
//eadn-wc01-5196795.nxedge.io/usr/share/pixmaps/placesfiles.png
…Ce qui rendrait la recherche assez limitée.
De man 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”:
Dans le cas de Radiotray , j'ai trouvé le .png suivant fichiers (exécutant dpkg-query -L radiotray | grep png ):
//eadn-wc01-5196795.nxedge.io/usr/share/radiotray/images/radiotray_connecting.png
//eadn-wc01-5196795.nxedge.io/usr/share/radiotray/images/radiotray_on.png
//eadn-wc01-5196795.nxedge.io/usr/share/radiotray/images/radiotray_off.png
//eadn-wc01-5196795.nxedge.io/usr/share/radiotray/images/radiotray.png
//eadn-wc01-5196795.nxedge.io/usr/share/pixmaps/radiotray.png
Si nous vraiment besoin de savoir, rechercher le code
… nous pouvons rechercher dans les fichiers installés (à l'intérieur) les correspondances de la chaîne "icon". De nombreux indicateurs sont écrits dans l'un des langages de script (comme python ), ce qui signifie qu'ils sont très facilement consultables.
Un exemple
Encore une fois en utilisant le radiotray exemple
dpkg-query -L radiotray | xargs grep icon
dans la sortie, nous trouvons a.o. :
/usr/lib/python2.7/dist-packages/radiotray/SysTrayGui.py
self.icon.set_from_file(APP_ICON_CONNECT)
En regardant dans le fichier SysTrayGui.py , nous pouvons voir :
from lib.common import APPNAME, APPVERSION, APP_ICON_ON, APP_ICON_OFF, APP_ICON_CONNECT, APP_INDICATOR_ICON_ON, APP_INDICATOR_ICON_OFF
De cela, nous pouvons conclure que les icônes mentionnées sont définies dans le module common dans le (sous) répertoire lib . (Voir ici comment python trouve les modules, section Sous-répertoires )
Dans ce module, nous pouvons lire la section :
# 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"
…et nous y sommes…
Situations exceptionnelles
Avec la pratique de tous mes indicateurs, j'ai réussi à trouver les icônes correspondantes en utilisant la ou les méthodes ci-dessus.
En relation :Localiser des fichiers presque en double dans un dossier ?Il s'avère cependant possible de compiler des images avec le code en un seul exécutable. Inutile d'expliquer que dans de tels cas, vous ne trouverez pas d'image séparée, ni ne pourrez les remplacer sans modifier le code et recompiler.
Le cas d'owncloud semble être un tel cas. En utilisant la ou les méthodes ci-dessus, un ensemble d'icônes a été installé dans /usr/share/icons/hicolor/<size>/apps . Aucune de ces icônes ne s'avère cependant être utilisée dans l'indicateur sur ubuntu .
OP a fait pas mal de travail avant (et après) qu'il ait posé cette question. L'un d'eux devait courir :
gdbus call --session --dest com.canonical.indicator.application --object-path /com/canonical/indicator/application/service --method com.canonical.indicator.application.service.GetApplications
… ce qui nous donne pas mal d'informations utiles. La sortie comprenait une section :
('146028888067', 2, 'org.kde.StatusNotifierItem-22055-1', '/StatusNotifierItem/menu', '/tmp/iconcache-50ePXx', '', '', '', 'owncloud', 'ownCloud')
En regardant dans le répertoire /tmp/iconcache-50ePXx , j'ai trouvé les icônes exactes qui étaient utilisées par l'indicateur :
… ce qui semble prouver que ces icônes sont générées à la volée; fermer owncloud fait disparaître le répertoire et ses icônes.
Il s'est avéré possible de changer l'icône de l'indicateur en remplaçant ces icônes :
ce qui prouve que ce sont bien les icônes que nous recherchions.
Cependant, pour automatiser ce que j'ai fait manuellement, il faudrait un script/wrapper, puisque le nom du répertoire créé est changé à chaque lancement d'owncloud. L'option la plus pratique serait bien sûr que le code du client owncloud soit modifié.
A suivre…