Me gustaría encontrar la ubicación de los íconos utilizados por algunos menús de estado no predeterminados (también llamados indicadores de aplicación o subprogramas de indicadores).
¿Dónde se encuentran estos archivos de imágenes de iconos?
En mi captura de pantalla tengo ownCloud y Radiotray, pero me gustaría una respuesta general que no sea específica para estos íconos en particular, por favor. No sé los nombres de los archivos ni los tipos de archivos, por lo que la búsqueda es difícil.
Respuesta aceptada:
¿Ubicación predeterminada para íconos indicadores no predeterminados?
No hay una ubicación predeterminada donde se almacenen estos íconos. Cualquier aplicación (-desarrollador) puede almacenarlos donde lo considere oportuno.
Sin embargo , la buena noticia es que los indicadores no suelen instalar listas interminables de archivos e imágenes. Podemos limitar nuestra búsqueda (aparte de mirar el código) mirando el resultado del comando:
dpkg-query -L <packagename>
En mi ejemplo de
dpkg-query -L placesfiles
esto generaría, entre otras, las siguientes imágenes:
//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
…Lo que limitaría bastante la búsqueda.
Del hombre 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”:
En el caso de Radiotray , encontré el siguiente .png archivos (ejecutando 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 realmente necesito averiguarlo, buscando el código
…podemos buscar (dentro) de los archivos instalados las coincidencias de la cadena “icono”. Muchos de los indicadores están escritos en uno de los lenguajes de script (como python ), lo que significa que se pueden buscar muy bien.
Un ejemplo
Nuevamente usando la radiotray ejemplo
dpkg-query -L radiotray | xargs grep icon
en la salida encontramos a.o.:
/usr/lib/python2.7/dist-packages/radiotray/SysTrayGui.py
self.icon.set_from_file(APP_ICON_CONNECT)
Buscando en el archivo SysTrayGui.py , podemos ver:
from lib.common import APPNAME, APPVERSION, APP_ICON_ON, APP_ICON_OFF, APP_ICON_CONNECT, APP_INDICATOR_ICON_ON, APP_INDICATOR_ICON_OFF
De esto, podemos concluir que los íconos mencionados están definidos en el módulo common dentro del (sub) directorio lib . (Vea aquí cómo python encuentra sus módulos, sección Subdirectorios )
En este módulo, podemos leer la sección:
# 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"
…y aquí estamos…
Situaciones excepcionales
Con todos mis indicadores prácticos, logré encontrar los íconos correspondientes usando los métodos anteriores.
Relacionado:¿Ubicar archivos casi duplicados en una carpeta?Sin embargo, resulta posible compilar imágenes junto con el código en un solo ejecutable. No es necesario explicar que en tales casos no encontrará una imagen separada, ni podrá reemplazarla sin editar el código y volver a compilar.
El caso de owncloud parece ser uno de esos casos. El uso de los métodos anteriores mostró que se instaló un conjunto de íconos dentro de /usr/share/icons/hicolor/<size>/apps . Sin embargo, ninguno de estos íconos se usa en el indicador en ubuntu .
OP hizo bastante trabajo antes (y después) de hacer esta pregunta. Uno de ellos era ejecutar:
gdbus call --session --dest com.canonical.indicator.application --object-path /com/canonical/indicator/application/service --method com.canonical.indicator.application.service.GetApplications
… lo que nos da bastante información útil. El resultado incluía una sección:
('146028888067', 2, 'org.kde.StatusNotifierItem-22055-1', '/StatusNotifierItem/menu', '/tmp/iconcache-50ePXx', '', '', '', 'owncloud', 'ownCloud')
Buscando en el directorio /tmp/iconcache-50ePXx , encontré los íconos exactos que fueron usados por el indicador:
… lo que parece probar que estos íconos se generan sobre la marcha; cerrar owncloud hace que el directorio y sus iconos desaparezcan.
Resultó posible cambiar el ícono del indicador reemplazando estos íconos:
lo que prueba que estos son de hecho los íconos que estábamos buscando.
Sin embargo, para automatizar lo que hice manualmente, se necesitaría un script/contenedor, ya que el nombre del directorio creado cambia cada vez que se inicia owncloud. La opción más conveniente sería, por supuesto, que se cambiara el código del cliente owncloud.
Continuará…